Jeva: System One Models From First Principles

Qi Li, Xinchao Wang

Jeva is a decision-native architecture that decouples reusable candidate encoding from set-dependent judgment.

How can we design a "system one" decision model that respects the structure of a decision problem (like candidate order invariance) rather than just predicting tokens?

Current system-one models often encode requests and candidates as a single text sequence, which forces re-computation whenever the candidate set changes and allows incidental ordering to bias decisions. Jeva separates the language backbone from a compact decision module that refines the request state against immutable, pre-computed option memory. This allows the model to reuse candidate representations across different requests while maintaining set-dependent preferences. Jeva achieves near-perfect null detection and stable choices under permutation, while delivering up to 20× latency speedups through cross-request reuse.

Paper Primer

Jeva treats decision-making as a state-refinement process: a shared encoder maps options into a fixed memory bank, and a lightweight decision stack updates the request state by reading this memory. This design enables permutation-equivariant probabilities and variable-size candidate sets without requiring new output parameters.

Jeva eliminates decision flips caused by candidate reordering.

In controlled tests with original, reversed, and random candidate orders, Jeva recorded zero decision flips and a mean total variation of 3.17 × 10⁻⁸.

Why does Jeva separate the language encoder from the decision module?

Separation allows candidate representations to be computed once and cached, enabling reuse across different requests. It also prevents the model from treating an unordered set of options as an ordered sequence, which is a common source of bias in models that process candidates as serialized text.

How does Jeva distinguish between "no answer" and "uncertainty among candidates"?

Jeva uses a dedicated coverage gate that allocates probability between a null outcome and the candidate set. This allows the model to explicitly predict answer absence rather than forcing a choice among potentially irrelevant alternatives.

Introduction: The Decision Problem

Current models predict answers from text, ignoring decision structure and four key requirements.

Current decision models generate an answer token from serialized text, which fails to respect the inherent structure of decision problems; they miss four key requirements—null‑aware, permutation‑invariant, option‑scalable, and cacheable—leading to brittle, imprecise, and inefficient behavior.

Models that directly output a decision (choice, score, or null) for a request, bypassing any intermediate text generation.

The failure of serialized‑text prediction for structured decision problems forces models to ignore essential constraints, causing brittleness and inefficiency.

Related Decision Architectures

Survey of prior decision models and set‑encoding techniques.

Prior work on decision modeling can be grouped into three strands: direct token‑logit readouts, independent encoding with late interaction, and set‑function approaches that enable permutation‑invariant reasoning.

A Typed Decision pairs each candidate option with a type label, allowing the model to enforce type‑specific constraints during scoring.

Direct token‑logit readout methods such as System One, SemIf, JevK5, Intern‑Decision, ReFlex, KEV, and Laya all derive decisions from the same autoregressive generation pass.

Early decision models that predict answers by generating serialized text, then parsing the output for structured decisions.

Extracts option probabilities directly from answer‑token logits without performing autoregressive decoding.

Similar to SemIf, it reads option probabilities from answer‑token logits, eliminating autoregressive decoding.

Uses special decision markers in the generated text to read a distribution over permitted answer symbols.

Aggregates predictions across different option orders to reduce sensitivity to candidate position.

Introduces a pointer head that attends over contextualized option positions to select an answer.

Combines a bidirectional language encoder with a dedicated decision head for structured output.

Independent encoding and late interaction methods such as Dense Passage Retrieval, ColBERT, and Contrastive Language Models decouple query and candidate processing, enabling reusable candidate embeddings.

Encodes questions and passages independently, allowing passage embeddings to be precomputed.

Retains token‑level representations and performs late interaction via inner‑product matching.

Extends independent encoding and candidate caching to typed Choice, Noul, and Score decisions.

Set‑function approaches—Deep Sets, Set Transformer, and Perceiver—provide permutation‑invariant or equivariant mechanisms for modeling collections of options.

Establishes shared transformations and symmetric aggregation to achieve permutation‑invariant set modeling.

Introduces attention‑based interactions among set elements, enabling richer relational modeling while preserving permutation equivariance.

Processes large inputs through a compact latent representation, decoupling input size from model depth.

Finally, works on answerability and abstention such as SQuAD 2.0, selective classification, and temperature scaling address null detection and probability calibration.

Benchmark that evaluates both answerability and the ability to abstain when no answer exists.

Framework that permits a model to abstain from prediction to control risk.

Post‑training calibration technique that rescales logits to improve probability estimates.

Across these prior works, the common thread is the tension between joint encoding of requests and options versus reusable, set‑aware representations—a tension Jeva resolves by decoupling encoding and refining a request‑conditioned state against immutable option memory.

The Jeva Architecture

Jeva encodes requests and options separately, then refines the request using a shared option memory.

The core trick is to keep option representations immutable and only update a compact request state for each decision. This avoids recomputing option encodings for every query and enables reuse across requests.

Jeva splits the problem: a shared backbone builds a permanent pool of option vectors, while each request gets a temporary state that is repeatedly refined against that pool—like a librarian who keeps a fixed catalog of books (option memory) and a patron’s note that is edited as the patron browses the catalog.

Backbone outputs for the request and three options: $r = (1,0,1,0)$, $o_1 = (0,1,0,1)$, $o_2 = (1,1,0,0)$, $o_3 = (0,0,1,1)$.

Linear projections (identity for simplicity) give the same vectors; $\operatorname{nrm}$ scales each option to unit length, yielding $u_1 = (0,0.71,0,0.71)$, $u_2 = (0.71,0.71,0,0)$, $u_3 = (0,0,0.71,0.71)$.

Initial request state $z_0 = r = (1,0,1,0)$.

Block 1 computes an attention message $m_1$ as the average of the three $u_i$: $m_1 = (0.47,0.47,0.24,0.47)$ and updates $z_1 = z_0 + 0.5\,m_1 = (1.24,0.24,1.12,0.24)$.

RMSNorm of $z_1$ produces a normalized vector $z'_1$; the feed‑forward $F_1$ (implemented as a linear map) yields $f_1 = (0.1, -0.05, 0.2, -0.1)$. The second residual update gives $z_2 = z_1 + L^{-1/2} f_1 \approx (1.27,0.19,1.27,0.14)$.

The example shows how a fixed option pool $U$ remains unchanged while the request state $z$ evolves through two lightweight updates, illustrating the reuse‑vs‑refinement trade‑off.

**Figure 1.** **Top:** a representative joint-encoding system one architecture and Jeva; $N$ denotes the number of blocks in each architecture. **Bottom:** schematic illustrations of four structural properties: (a) an explicit null outcome when no candidate applies; (b) unchanged choices under candidate reordering; (c) support for variable-size candidate sets; and (d) reuse of option representations across requests.

How does Jeva’s request‑state update differ from standard self‑attention where the query also attends to itself?

In self‑attention the query vector is part of the same set that is being attended to, so each token can influence its own representation. Jeva separates the mutable request state from the immutable option pool; the request never appears in $U$, so updates are driven solely by the fixed option vectors, guaranteeing that option representations are reusable and that the request can be refined without contaminating the option memory.

Structural Properties and Memory

Symmetry and reuse give linear‑scale decision cost while preserving exact outputs.

Decision models that recompute every option for each request explode in compute as the candidate set grows. Reusing option representations while guaranteeing exact outputs solves this scaling bottleneck.

It stores each option’s raw semantic vector together with its projected key and value views, so the same option can be reused across many candidate sets without recomputing projections.

Store $M_t(o_1)=\{u_1,\{k_1\ell_1=v_1\ell_1=u_1\}\}$ and $M_t(o_2)=\{u_2,\{k_1\ell_2=v_1\ell_2=u_2\}\}$.

Request $r$ assembles candidate tuple $(o_1,o_2)$. The decoder reads the cached keys/values directly, no extra matrix multiply.

If a second request $r'$ also needs $(o_1,o_2)$, it reuses the exact same memory entries, incurring zero additional projection cost.

Swapping the order to $(o_2,o_1)$ only changes the order of reads; the stored vectors remain identical.

Reusing the same $M_t(o_i)$ across requests eliminates $O(Kd)$ projection work, making the per‑request cost linear in the number of distinct options rather than in the number of candidate permutations.

How does Atomic Option Memory differ from simply caching the whole option representation?

Caching the full representation would store a single combined vector per option, but attention needs separate key and value projections for each head. Atomic Option Memory stores those projections explicitly, enabling exact reuse without recomputing the linear transforms for every head.

The model treats a set of candidates as an unordered collection; permuting their order does not affect the probability distribution over them.

Why doesn’t reordering candidates change the model’s output?

Because the scoring operation aggregates candidate contributions via a sum, which is order‑independent. The subsequent softmax and state updates operate on that aggregate, so the final distribution is identical regardless of the input order.

The architecture includes an explicit “null” option that captures the case where no candidate is appropriate; its probability is invariant to candidate ordering and reuse.

What purpose does the explicit null option serve compared to a low‑score regular candidate?

The null option is a dedicated signal that the model believes no candidate satisfies the decision criteria. Unlike a regular candidate with a low score, the null option’s probability is computed separately and remains stable under candidate reordering, providing a reliable “no‑answer” indicator.

Proposition 3 formalizes candidate symmetry and exact reuse: with fixed weights and deterministic exact arithmetic, permuting candidates or swapping in cached option entries leaves $z_L$, the null probability, and all typed Noul/Score outputs unchanged. The proof follows from the commutativity of the sum in Eq. (3) and the fact that cached entries contain no request‑specific information.

**Figure 3.** Fixed options, set-dependent decisions. Replacing $C_+$ by $C_-$ changes the refined state and reverses the $A-B$ margin. Hollow markers show the independent-score tie. The state zoom uses equal scales; values follow Proposition 1.

**Figure 4.** **Competition differs from coverage.** (a) A score shift preserves $q$ but changes $\rho$. (b) Adding $s_C = 0.4$ at fixed scores preserves $\rho$ but redistributes $p$. Here $\tau_{dec} = 0.20$, $\tau_{cov} = 0.15$, and $b_{cov} = 0.50$.

Experimental Results

Jeva outperforms baselines on accuracy, null detection, and latency across all evaluated settings.

Jeva attains 69.88 % accuracy at $K\!=\!2048$, a 12.05‑point gain over JevK5.

Table 3 reports full‑set accuracy of 69.88 % for Jeva versus 57.83 % for JevK5.

**Figure 2.** Four structural properties of Jeva. (a) Null detection on BANKING77 (Casanueva et al., 2020) with 16 candidates. (b) Candidate-aligned probability changes under Choice permutations from Typed Decisions (LocalLaMA, 2026), with flip rates and mean total variation (TV). (c) Accuracy–latency trade-offs as candidate counts increase on our ToolRet-based diagnostic (Shi et al., 2025); solid and dashed lines denote native and recursive selection, respectively. (d) Cache-Off and Cache-On (set-cache, hybrid-cache) latency on Typed Decisions (LocalLaMA, 2026) and MLDR (Chen et al., 2024), with set-hit rates and effective reuse.

**Figure 5.** Reuse across new requests and sets. With a fixed model, type, and encoding policy, an initially empty option bank gives 0/3, 2/3, and 3/3 hits without eviction. Every whole-set lookup misses; state encoding and decisions remain fresh.

**Figure 6.** Decision quality and stability. (a) Noul Brier versus Score RMSE; lower is better, with different units. (b) Banking77 $K = 16$ null ROC: the legend gives full AUROC; markers show each measured near-5% FPR point. (c) Original and all-order accuracy on 600 Choice examples; filled markers denote all-order accuracy, and segments show permutation sensitivity.

**Figure 7.** Correctness across nested candidate sets. Columns show 83 fixed queries; rows indicate candidate count $K$. Colored cells denote correct predictions. All-size accuracy requires correctness at every tested size.

**Figure 8.** **ToolRet across six disjoint candidate-count cohorts.** (a) Full-support tied-top accuracy. (b) Natural-stream p50 latency; Jeva uses 256-row/131,072-token batching, with legacy encoding dashed. (c) Valid coverage; 77% denotes 65/84 requests. Unsupported slices are excluded from accuracy.

**Figure 9.** **Candidate reuse** (32-row/16,384-token batching). (a) Paired speedups over Cache-Off: 50 novel-set requests per reuse level, zero set hits, broken axis; boxes show median/IQR with 1.5-IQR whiskers. (b) Shared-bank p50 latency. (c) Encoded rows avoided. Priming is timed separately; no answers are cached.

Performance Benchmarks

Jeva‑4B dominates accuracy and fidelity metrics, confirming its competitive edge.

Jeva‑4B attains the highest first‑argmax accuracy of 92.05 % across all evaluated datasets, outpacing the next best InternDecision‑2B (86.14 %).

Table 1 shows Jeva‑4B leading in every column, with a gold‑shaded top score of 92.05 %.

**Table 1.** First-argmax accuracy (%, higher is better), including null outcomes where applicable. Mind2Web uses $K = 16$. $^\dagger$Supported-only accuracy; coverage is 99.2%, 99.8%, and 97.3% respectively; all other entries have full coverage. Dark-to-light gold marks the top three distinct full-coverage scores per column.

**Table 2.** Typed fidelity and order stability. Flip measures any decision change; all-order accuracy requires correctness under every tested order. Mean TV compares candidate-aligned probability distributions.

There exist fixed Jeva parameters and two candidate sets containing the same options $A, B$ such that, for the same request, a single block uniquely selects $A$ in one set and $B$ in the other. No independent scorer with set‑independent tie‑breaking can realize both choices.

At fixed final scores, adding options below the existing maximum leaves $\rho$ unchanged. By contrast, a flat softmax with null score $b_0$ and $K$ identical candidate scores $s$ assigns $p_{\text{flat}\,\perp} = \sigma\!\bigl((b_0 - s)/\tau - \log K\bigr)$.

These propositions illustrate how Jeva’s architecture can encode set‑dependent preferences and maintain robust coverage without relying on cardinality‑dependent normalisation.

Mathematical Derivations

Derivations and structural properties of the decision model are detailed.

This appendix supplies the mathematical derivations underlying the model’s decision mechanisms.

A.1 Entropy‑Regularized Candidate Reading

The attention weights are chosen to trade off raw compatibility with a spread‑out (high‑entropy) distribution, preventing the model from collapsing onto a single candidate.

A.2 Geometry and Single‑Block Expressivity

Each decision block contains a bias‑free SwiGLU network whose four projection matrices are initialized to identity (or zero) and then learned, allowing the block to shape evidence mixing.

Candidate interactions are captured by a matrix $G_{\ell,ij}$ that links the current state $u$ to value projections, allowing one candidate’s evidence to influence another’s score.

Proposition 1 demonstrates that a single‑head block can encode relational geometry between candidates without updating their representations.

A.3 Coverage and Candidate Count

Proposition 2 shows that adding low‑scoring candidates does not increase the coverage term, unlike a flat softmax which incurs a $\log K$ penalty.

A.4 Detailed Reuse and Symmetry Proofs

Proposition 3 proves that permuting the order of candidates leaves all attention weights unchanged, establishing candidate symmetry.

A.5 Joint Cross‑Entropy Identity

Method Proofs

Formal proofs and implementation details for the method are presented.

For any two‑dimensional vectors $v,w$ there exists an embedding $J(v)=H^{-1/2}\operatorname{Concat}_{h=1}^{H}(v_{1},v_{2},0,\dots,0)$ such that $J(v)^{\top}J(w)=v^{\top}w$, enabling the two‑dimensional attention weights to be used unchanged in $H$ heads of width $d_h\ge 2$.

For fixed logits $c_i$, the softmax attention entropy $H(a(\tau))$ is a non‑decreasing function of the temperature $\tau$.

Adding $r$ candidates whose logits are at most $c_{\max}-\delta$ increases total attention mass by at most $\beta\le \frac{e^{-\delta/\tau}}{1+e^{-\delta/\tau}}$, and the change in the aggregated value satisfies $\|\mu_{\text{new}}-\mu_{\text{old}}\|\le 2R_v\,\beta$.

When multiple candidates share the maximal score, any deterministic tie‑breaking rule yields identical selections across permutations; the proofs assume exact arithmetic, dropout is disabled, and cache identity requires unchanged encoder weights, tokenizer, templates, and numeric configuration.

For an uncached layer the leading MAC count is \$2K d^{2} + 2d^{2} + 2K d + 3 d f$, where the terms correspond respectively to option key/value projections, query and output projections, attention/aggregation, and SwiGLU.

The decision state is formatted as “Decision type: {t} Question: {question} State: {state}”, each option as “Option for {t}: {option}”, with right‑padding and pooling implemented via the last non‑padding hidden state; the Jeva‑4B checkpoint uses one matrix block, eight heads of width $96$, decision width $768$, and SwiGLU width $3072$, totaling $13{,}370{,}117$ parameters in the core.

The score loss includes normalized target $\bar{y}_i$, auxiliary terms $\sum_i \frac{(q_i-\bar{y}_i)v_i}{R}$ and $\frac{1}{K-1}\sum_{j=1}^{K-1}(Q_j-Y_j)^2$; gradient‑norm clipping at threshold $1.0$ is applied before synchronized optimizer updates, and non‑finite losses are rejected.

Experimental Protocols

Details of the training curriculum, evaluation setup, and caching mechanisms used in the experiments.

The staged curriculum begins with basic typed decisions, intent recognition, and action selection (~80 k examples), then expands to preference comparison and semantic judgments (~500 k). A counterfactual and verification stage adds ~250 k examples with replay, followed by evidence‑grounded and open‑set decisions (~60 k). Subsequent phases include reading and logical reasoning (~20 k), a mixed‑difficulty replay set (~60 k), targeted capability refinement (~10 k), long‑text and large‑candidate training (~80 k), and a feedback‑driven retention phase (~2 k) that can recur during the final scoring stage (~70 k).

The general evaluation suite comprises Typed Decisions, Banking77, MASSIVE (candidate counts $K\in\{8,16\}$), and three Mind2Web $K=16$ slices (cross‑task, cross‑website, cross‑domain). Typed Decisions contain 600 Choice, 600 NOUL, and 800 Score examples; Banking77 and MASSIVE include both answer‑present and answer‑absent requests; Mind2Web evaluates selection from a supplied candidate pool. Accuracy is measured by first‑argmax correctness (including null for open‑set requests), NOUL Brier loss, and Score MAE/RMSE against rubric units.

Null operating‑point experiments use 3 080 matched Banking77 $K=16$ requests (2 492 answer‑present, 588 answer‑absent). Jeva relies on its coverage head, while other interfaces use auxiliary NOUL outputs or an explicit “None” candidate. Candidate‑order robustness is tested on 600 Choice examples with original, reversed, and up to three random permutations; flip rate counts any order that changes the decision, and all‑order accuracy requires correctness under every permutation. Mean total‑variation distance quantifies distributional shifts.

The large‑set support experiment contains 500 distinct queries; ToolRet $K$ takes values $\{32,128,256,512,1024,2048\}$ with ~84 queries per cohort. Jeva achieves 78.40 % aggregate accuracy, 86.90 % at $K=32$, and 69.88 % at $K=2048$. JevK5 reaches 64.00 % aggregate accuracy by recursively selecting candidates in a single decision‑head pass. InternDecision variants support 65 of 84 requests at $K=32$ (77.38 %). Request latency is measured on a single NVIDIA H200 with device synchronization, excluding model loading.

Cache ablations compare an exact‑set cache, a hybrid cache that also reuses individual candidate representations, and a no‑cache baseline. Each experiment runs under Off, Set, and Hybrid conditions with cyclic ordering and cache reset between conditions, covering 171 episodes and 2 188 measured request identities. Novel‑set priming uses a different question and candidate set, guaranteeing zero exact‑set hits; priming time is excluded from reported request latencies.

Jeva formats requests and candidates with separate templates. The request template $T_x(t,\iota,x)$ inserts the decision type, question, and state; the candidate template $T_o(t,o_i)$ inserts the decision type and option text. Because candidates are encoded without the current request or other candidates, changing the question, state, or candidate order does not affect the candidate encoding. Example: for a Choice request about a double charge, the request input contains the decision type, question, and state, while each candidate input is “Option for choice: …”. Null probability is obtained from Jeva’s coverage gate; no explicit “None” candidate is encoded.

Open‑set evaluation adapters add an auxiliary NOUL question to the same state, using an instruction template that lists candidate options. The model outputs an affirmative probability $\hat{c}$ and conditional candidate probabilities $\hat{q}_i$, yielding $\hat{p}_\perp = 1 - \hat{c}$ and $\hat{p}_i = \hat{c}\,\hat{q}_i$. Some systems (JevK5, CLM) append an explicit “None” candidate; its probability is interpreted as the null probability. Hybrid caching reuses semantic vectors and key/value projections of previously seen candidates, computing only missing entries for new ordered tuples, while exact‑set caching recomputes the entire candidate memory on a miss.

Read the original paper

Open the simplified reader on Paperglide

Browse all simplified papers