Jeva: Rethinking System One Models from First Principles
Many LLM requests need a compact decision rather than a text answer: choose a tool, route a support ticket, test a condition, or assign a rubric score. System one models return such typed decisions directly instead of generating a rationale. TypeSafe introduced the term with its commercial Jev model, echoing Kahneman’s fast, intuitive System 1. Open models of this kind often put the request and every candidate into one prompt and read the answer from answer-token logits or a task-specific head. The paper argues that this design underemphasizes four requirements:
- Null-aware: the model should tell “no option applies” apart from “unsure which option applies”.
- Permutation-invariant: reordering the options should not change the decision.
- Option-scalable: a larger candidate set should not require a new output space.
- Cacheable: computation over recurring options, such as a tool registry, should be reusable across requests.
Jeva is a decision-native architecture designed to meet all four. A shared Qwen3.5-4B backbone encodes the request and each option independently, a single decision block refines only the request state, and a separate coverage gate produces the null probability. Jeva scores sets of up to 2048 options in a single pass of the decision block.
Jeva independently encodes the request and candidate options using a shared Qwen3.5-4B backbone, then applies a lightweight attention-based decision module that updates only the request representation while keeping the candidate representations reusable. Unlike a conventional bi-encoder, this still allows decisions to depend on the entire candidate set. A separate coverage gate estimates whether any valid answer exists, while the same architecture supports categorical choices, Boolean probabilities, and numerical scores. The resulting 4B model leads seven of eight reported selection benchmarks, achieves 98.66% AUROC for null detection, and exhibits zero decision flips under tested candidate permutations.
The approach
The request and each option get separate templates: the request holds the decision type, question, and state, while an option holds only the decision type and its own text.
In the example, the state “I was charged twice” and the question “Which team should handle this?” form one request, and Billing, Technical support, and Delivery become three separate inputs. Each text passes through the shared backbone separately and is pooled into a compact vector, giving an initial request state and one unit vector per option. With this independent encoding, Jeva’s encoder side is a DPR-style bi-encoder, so option vectors can be precomputed.
As in DPR-style dense retrieval, requests and options are independently encoded into fixed-size representations. Jeva differs by sharing the language backbone and applying separate request and option projections.
The decision block then lets the request state cross-attend over the option vectors and updates only the state, much like a Perceiver latent reading a fixed input array. Each option’s final score is its dot product with the refined state, so for the ticket above, Billing should score highest. Compressing each option into a single vector makes caching inexpensive, but introduces a representation bottleneck compared with architectures that perform token-level interactions between the request and candidate text.
Why refine the state
The simplest alternative would score each option independently against the request and apply a softmax. The probability ratio of two options then depends only on their own scores, because the shared denominator cancels. Adding or replacing a third option can therefore never flip the preference between A and B, which choice theory calls the independence of irrelevant alternatives.
Refinement makes decisions set-dependent, because a third option can move the state before scoring. The paper proves that one block is enough with a two-dimensional construction in which A and B tie under independent scoring. A third option close to A pulls the refined state toward A, its mirror image pulls it toward B, and the same request selects A in one set and B in the other.
Competition, coverage, and typed outputs
A softmax ignores a common shift of all scores, so a ticket that clearly matches Billing and a ticket that matches nothing can produce the same split among the three teams. Jeva therefore separates competition from coverage: the softmax gives the conditional distribution (which option, given that one applies), and the coverage gate gives the probability that any option applies. The gate is a sigmoid of the gap between the best score and a learned threshold; null receives one minus coverage, and each option receives coverage times its conditional probability. For “My package never arrived” with Delivery removed from the list, both remaining scores should stay low, and most of the probability should go to null.
A common alternative, a “None of the above” option inside the softmax, mixes the two questions: with many similarly scored candidates, its share shrinks as more are added, although answer availability has not changed. Jeva’s gate reads only the best score, so at fixed scores, adding weaker options leaves the null probability unchanged. In the actual model, adding candidates can change the refined request state and therefore the scores themselves, potentially changing coverage even when the new candidates are weak.
There are three output types:
- Choice picks the most probable option, or null when the request allows it.
- Noul is a truth probability for a yes/no question.
- Score is the expected rubric value under the option distribution.
Symmetry, reuse, and scaling
Attention aggregates the options as a weighted sum and the readout scores each with the same dot product, so reordering the options only reorders their probabilities; the state, null probability, Noul, and Score stay identical. This follows the Deep Sets recipe (a shared per-element transformation plus order-independent aggregation), so invariance holds by construction, without permutation augmentation or an order-consistency loss.
Because options are encoded independently and never updated, each option’s vector and per-layer key and value projections depend only on its text and decision type, so they can be computed once and stored as option memory. Unlike conventional transformer KV caching, which reuses activations associated with a previously processed context, Jeva caches independently computed candidate embeddings and their decision-layer key/value projections. These entries can be freely recombined into new candidate sets.
A set cache stores exact ordered option tuples, and a hybrid cache also reuses individual options across new sets. After a request over Billing, Technical support, and Delivery, one over Delivery, Billing, and Account security misses the set cache, but the hybrid cache encodes only Account security. The request is always re-encoded and the decision recomputed.
Unlike the option vectors, the request state is not normalized, preserving magnitude information that the coverage gate can use to estimate whether any candidate is acceptable.
With option memory prepared, the decision cost grows linearly with the number of options, with no pairwise interaction matrix and no new output parameters.
Training
Jeva-4B uses Qwen3.5-4B as its backbone and a single decision block with 768-dimensional states and eight attention heads. Its two input projections and decision head add approximately 13.37M parameters, excluding the backbone LoRA adapters.
The decision block and its two input projections are trained jointly with LoRA adapters on the backbone. The primary objective is a joint cross-entropy over the options and null, so examples where no option applies train the coverage gate without imposing a fake ranking on the options. A staged curriculum keeps one interface throughout, starting with basic typed decisions, intent recognition, and action selection, later extending to long texts and large candidate pools, and ending with a scoring-focused stage.
Experiments
Jeva leads seven of the eight main accuracy settings; the exception is the Typed Decisions test, where it is slightly behind Intern-Decision-4B. On BANKING77 intent selection with 16 candidates, it scores 91.62% against 82.50% for Jev-1.13.0. Its null detection on the same benchmark reaches 98.66% AUROC against 93.61% for Kev-4B.
One of the more interesting results is how sensitive the baselines are to option order: across reorderings of 600 Choice examples, even the most stable one, Jev-1.13.0, changes its decision on 17% of them. Jeva has zero flips, as its symmetric design predicts.
Conclusions
System One models differ mainly in where the options meet the request, and that determines what each new request must recompute. Most open baselines, including Jev (possibly, as the architecture is unknown), JevK5, ReFlex, InternDecision, KEV, and Laya, use joint encoding: the request and options share one input.
Like cross-encoders and listwise LLM rerankers, they must reprocess options for each new request, face context-window or output-interface limits as candidate sets grow, and can be sensitive to option order. Independent encoding, from DPR and ColBERT to CLM’s frozen Qwen3-8B backbone, allows candidate representations to be cached but typically scores each option in isolation, preventing set-dependent preferences.
Jeva combines the advantages of both approaches: reusable option representations, set-aware request refinement through cross-attention, and an explicit coverage gate for null decisions. The underlying techniques resemble bi-encoders, Deep Sets, and Perceiver-style latent attention, but their combination creates a decision-native architecture. Contextual Document Embeddings addresses a related limitation from the document side, incorporating corpus-neighbor information into embeddings rather than conditioning the request on the current candidate set.
The results are encouraging, although Jeva does not dominate every benchmark. Its efficiency advantages are especially attractive for applications with recurring options, such as tool registries and grading rubrics, although the largest speedups depend on cache reuse.
I like that the paper starts from four explicit requirements and ties each to a specific architectural component. The paper proves its expressivity through a constructed example but provides no controlled ablation against a plain bi-encoder with the same coverage gate. Comparisons with frontier general-purpose LLMs are also missing, making it difficult to judge the trade-off between specialized efficiency and general reasoning capabilities. Nevertheless, Jeva demonstrates a promising direction: instead of adapting general-purpose language models to every decision problem, design specialized models whose architecture already reflects the structure of the task.
paperreview deeplearning llm nlp transformer attention classification ranking efficiency
