Aman's AI Journal • Primers • Jev

Overview
Jev’s Interface and System One Programming Model
Jev’s Likely Architecture: Shared-State Encoding and Decision-Native Readout
Training Jev: From Language Modeling to Calibrated Decision Learning
Evaluation, Latency, and Scaling Behavior
Open-Source Jev Recipes and Reproductions
References
Citation

Overview

Jev is TypeSafe AI’s first “System One Model,” a model designed around a different interface between neural networks and software than the conventional autoregressive large language model. Instead of accepting text and generating another sequence of text, Jev accepts an unstructured or semi-structured state together with a collection of explicitly typed questions, then returns probability distributions over the allowed answers. TypeSafe summarizes the abstraction as “unstructured state in, typed probabilistic decisions out” and positions Jev as a model for automation workloads such as classification, routing, scoring, verification, moderation, and workflow branching. Introducing System One Models & Jev.
The key conceptual shift is that many production AI tasks do not intrinsically require language generation. Suppose a system reads a customer-support ticket and needs to determine three fields:

department ∈ {payments, account, other}
escalate   ∈ {yes, no}
urgency    ∈ {low, medium, high}

A conventional LLM may be instructed to serialize those decisions into JSON. It must autoregressively generate braces, keys, quotation marks, labels, commas, and values, after which ordinary software parses the string back into typed values. The semantic work is deciding “payments,” “no,” and “high”; the rest is serialization. This unnecessary generation can be viewed as a “verbalization tax”: computation spent translating an internal semantic judgment into language merely so software can translate it back into a structured representation.
Jev instead treats the probability distribution over the legal decisions as the model output itself. If a question has candidate answers
\[C=\{c_1,c_2,\ldots,c_K\}\]
the desired output is directly
\[\mathbf{p} = \left[ P(y=c_1\mid s,q,C), P(y=c_2\mid s,q,C), \ldots, P(y=c_K\mid s,q,C) \right]\]
- where $s$ is the shared state, $q$ is the question, and $C$ is its prescribed answer space. This makes Jev closer to a general-purpose, zero-shot probabilistic decision function than to a chatbot. The output vocabulary is effectively supplied by the application at query time rather than being the model’s full natural-language vocabulary.
This distinction has architectural, computational, training, and systems consequences. At a high level, Jev combines four ideas:
- the expensive state should be understood once and reused across many decisions;
- independent questions about that state should be evaluated in parallel rather than through independent model calls;
- the model should directly score prescribed candidate decisions rather than autoregressively verbalizing them;
- the resulting probabilities should be trained to communicate useful uncertainty rather than merely being incidental token probabilities.
TypeSafe calls its post-training approach Reinforcement Learning for Calibrated Decisions, or RLCD. The company has not publicly disclosed the algorithmic details of RLCD or Jev’s exact architecture, so those aspects should be distinguished from independently reconstructed Jev-like implementations. What is public is the intended optimization target: calibrated decisions whose probabilities can be consumed programmatically. Introducing System One Models & Jev.

From Language Modeling to Decision Modeling

A conventional decoder-only Transformer starts with a sequence
\[x_{1:t}\]
computes hidden representations,
\[h_t = F_\theta(x_{1:t})\]
- and projects the final representation across its vocabulary:
  \[z_t=W_{\text{vocab}}h_t\]
The next-token distribution is
\[P(x_{t+1}=v\mid x_{1:t}) = \frac{\exp(z_{t,v})} {\sum_{u\in V}\exp(z_{t,u})}\]
The Transformer machinery underlying this computation originates with Attention Is All You Need by Vaswani et al. (2017), which introduced attention-based sequence modeling and the masked decoder architecture from which modern causal LLMs descend.
For ordinary generation, the selected token becomes part of the sequence and inference repeats:
\[x_{1:t} \rightarrow x_{t+1} \rightarrow x_{t+2} \rightarrow \cdots\]
If $M$ output tokens are required, the latency can be approximated as
\[T_{\text{LLM}} \approx T_{\text{prefill}} + \sum_{m=1}^{M}T_{\text{decode},m}\]
Constrained decoding, JSON schemas, grammars, and structured-output libraries can restrict what appears during this process, but they do not fundamentally remove the autoregressive dependency. The model still serializes its answer token by token.
A decision-native system instead aims for
\[T_{\text{decision}} \approx T_{\text{state}} + T_{\text{readout}}\]
- with no output-token decoding loop. The result can then be serialized into JSON by conventional application code at negligible cost.
This is an important distinction between Jev and “JSON mode.” JSON mode changes which strings an LLM is permitted to generate. Jev changes what the neural network is asked to produce in the first place. TypeSafe describes Jev as giving up arbitrary string generation in exchange for predefined typed outputs, parallel sampling, and probabilities associated with those outputs. Introducing System One Models & Jev.

Shared State as the Central Computational Primitive

The largest potential efficiency gain appears when many decisions depend on the same state.
Suppose an incident report contains $S$ state tokens and an application asks $N$ questions about it. A naïve implementation makes $N$ separate LLM requests:
\[F_\theta(s,q_1),\; F_\theta(s,q_2),\; \ldots,\; F_\theta(s,q_N)\]
The long state $s$ is consequently processed repeatedly.
The more natural decision-model decomposition is
\[H=E_\theta(s)\]
followed by
\[p_j=D_\phi(H,q_j,C_j), \qquad j=1,\ldots,N\]
Here $E_\theta$ performs the expensive semantic processing of the state and $D_\phi$ reads different decisions from the resulting shared representation. The desired scaling behavior is therefore
\[T(N) \approx T_{\text{state}} + T_{\text{decisions}}(N)\]
- where, for a practically useful range of $N$,
  \[T_{\text{decisions}}(N)\ll T_{\text{state}}\]
Public Jev behavior is consistent with this abstraction: TypeSafe explicitly encourages grouping multiple independent questions over a shared state, and Jev returns the resulting typed outputs together rather than requiring independent autoregressive completions. Introducing System One Models & Jev.
The following figure (Jev’s Architecture Unmasked) shows a proposed decision-model computation in which the message is encoded into shared state, independent question branches consume that state, and separate readouts produce probability distributions without text generation. The diagram is explicitly a reconstruction rather than a disclosure of Jev’s private implementation.
This representation also clarifies why “parallel” does not mean that a causal Transformer somehow violates causal attention. During prefill, all input tokens are already available. Positions within a Transformer layer can be processed concurrently while an attention mask controls which other positions each token is permitted to inspect. Autoregressive decoding introduces an additional serial dependency because output token $t+1$ does not exist until token $t$ has been selected. A prefill-only decision model can terminate before introducing that dependency.

Independent Questions over Shared State

A particularly plausible implementation pattern is to give every question access to the shared state while preventing questions from observing one another. Conceptually, for question representations $Q_1,\ldots,Q_N$ and state representation $H$,
\[Q_j \rightarrow H\]
is permitted, while
\[Q_i \not\rightarrow Q_j \qquad i\neq j\]
This property matters because otherwise the answer to one question could depend on the wording, presence, ordering, or candidate set of another logically independent question.
The open-source kev implementation demonstrates one concrete realization. It packs a document and all questions into one sequence and uses a block-causal attention mask so every question can attend to the document but cannot attend to sibling questions. A small pointer-style readout then scores each question’s allowed options from its decision representation.
Kev therefore computes something conceptually similar to
\[H,Q_1,\ldots,Q_N = F_\theta(s,q_1,\ldots,q_N;M)\]
- where $M$ is a structured attention mask satisfying
  \[M(q_j,s)=1\]
  - and
    \[M(q_j,q_k)=0 \qquad j\neq k\]
This is not evidence that Jev uses exactly the same block-causal mechanism. It is important because it demonstrates that the externally visible computational pattern can be implemented with an ordinary causal Transformer plus a specialized mask and readout head. Kev performs many typed decisions in a single prefill pass with no decoding.

Direct Candidate Scoring

The simplest approximation to a Jev-like model does not even require changing the Transformer architecture. A standard causal LLM already produces a probability distribution before it emits its first answer token.
Suppose three decisions are mapped to tokens A, B, and C. After processing the prompt, the model produces vocabulary logits $z$. Instead of sampling from the entire vocabulary, an application can extract
\[z_A,\;z_B,\;z_C\]
- and renormalize them:
  \[P(c_i\mid s,q,C) = \frac{\exp(z_i)} {\sum_{j=1}^{K}\exp(z_j)}\]
No answer token needs to be generated. A small Qwen reproduction demonstrates precisely this construction: perform one forward pass, extract logits for the prescribed answer slots, apply softmax, and let application code construct the typed object.
This reveals an important point about Jev-like systems. Much of the semantic capability required for decision making may already exist inside pretrained LLM representations. The research question is therefore not necessarily “how do we train intelligence from scratch for classification?” It can instead be “how do we expose pretrained semantic representations through a decision-native interface?”
A purpose-built model can go further than simply slicing vocabulary logits. If candidate $c_i$ has a semantic representation
\[u_i=G_\phi(c_i)\]
a readout can directly compare it with the shared state:
\[s_i=R_\phi(H,q,u_i)\]
followed by
\[P(y=c_i\mid s,q,C) = \frac{\exp(s_i)} {\sum_{j=1}^{K}\exp(s_j)}\]
The full language vocabulary $V$ disappears from the final decision normalization. Instead of computing scores for tens or hundreds of thousands of vocabulary entries and retaining three, the model can operate directly over the $K$ legal decisions.

Typed Probability Distributions as the API

Jev’s public interface supports multiple typed decision primitives. In the TypeSafe-compatible contract reproduced by open implementations, these include categorical choices, ordered scores, and Boolean-like noul questions.
For a categorical decision,
\[y\in\{c_1,\ldots,c_K\}\]
the model returns
\[\mathbf p = [p_1,\ldots,p_K], \qquad \sum_{i=1}^{K}p_i=1\]
For a Boolean decision, a single scalar is sufficient:
\[p=P(y=\text{true})\]
- with
  \[P(y=\text{false})=1-p\]
For ordered levels $r_1,\ldots,r_K$, the model can return a distribution over levels and an expected score:
\[P(y=r_i) = \frac{\exp(s_i)} {\sum_j\exp(s_j)}\] \[\mathbb E[y] = \sum_{i=1}^{K}r_iP(y=r_i)\]
This turns uncertainty into a first-class programming primitive. Rather than asking a model to generate something like “I am 91% confident this belongs to payments,” software receives the distribution itself and can implement deterministic policies around it:

if P(payments) > 0.90:
    auto_route()
elif P(payments) > 0.65:
    request_lightweight_review()
else:
    request_human_review()

The distinction is important. The probability that an LLM emits the text “91% confident” is not the same quantity as the probability that its underlying answer is correct. Jev’s stated objective is to make the latter quantity operationally meaningful.

Calibration as a Model Objective

A classifier is calibrated when predictions made with confidence approximately $p$ are correct approximately a fraction $p$ of the time over the relevant distribution. Informally,
\[P(Y=\hat Y\mid \hat P=p)\approx p\]
Thus, among decisions assigned confidence $0.8$, roughly $80\%$ should be correct.
This property is not guaranteed by softmax. On Calibration of Modern Neural Networks by Guo et al. (2017) showed that modern neural networks can be substantially miscalibrated and demonstrated temperature scaling as a particularly simple and effective post-hoc correction.
This explains why merely slicing the candidate logits of Qwen is not equivalent to Jev. It can provide useful relative scores,
\[p_i = \frac{\exp(z_i)} {\sum_j\exp(z_j)}\]
but nothing about the next-token objective
\[\mathcal L_{\text{LM}} = -\sum_t \log P_\theta(x_t\mid x_{<t})\]
requires $p_i$ to represent the empirical probability that decision $i$ is correct.
TypeSafe therefore describes Jev as being post-trained with Reinforcement Learning for Calibrated Decisions rather than conventional RLHF/RLVR. The stated objective is not preferred prose or merely verifiable generated answers, but “epistemically honest probabilities” for decisions. The exact RLCD loss, reward construction, calibration objective, and optimization procedure have not been publicly specified. Introducing System One Models & Jev.
Open reproductions demonstrate simpler approximations. Kev trains its readout with cross-entropy against labeled outcomes,
\[\mathcal L_{\text{CE}} = -\frac{1}{B} \sum_{n=1}^{B} \log p_\theta(y_n\mid s_n,q_n,C_n)\]
- and reports further improvement in expected calibration error using one-parameter temperature scaling. kev.
Another open implementation, Bespoke Nimble, takes a different route: it constructs contrastive training examples by modifying facts so that the correct decision flips, then fine-tunes Qwen on the allowed answer tokens. This emphasizes discriminative data construction rather than distillation from Jev; its initial release explicitly states that it does not yet reproduce RLCD.

Why the Combination Matters

Jev is therefore better understood as a combination of complementary changes rather than simply “an LLM that outputs JSON faster.”
The first change removes autoregressive verbalization:
\[\text{semantic decision} \rightarrow \text{probability distribution}\]
instead of
\[\text{semantic decision} \rightarrow \text{text tokens} \rightarrow \text{JSON parser} \rightarrow \text{typed decision}\]
The second removes redundant state processing:
\[s \xrightarrow{E_\theta} H \xrightarrow{\{D_\phi(q_j,C_j)\}_{j=1}^{N}} \{\mathbf p_1,\ldots,\mathbf p_N\}\]
The third narrows the output computation from arbitrary language to the candidate set relevant to each decision.
The fourth changes the training target from fluent or preferred strings toward useful probability estimates. Together, these changes transform the model from a text-producing component that software must interpret into a probabilistic decision primitive that software can compose directly.
TypeSafe reports that this specialization yields end-to-end response times in roughly the $70\text{ ms}$ to $500\text{ ms}$ range for its workloads and claims gains as high as $193.6\times$ in speed and $444.6\times$ in cost on its published workflow evaluations. These are TypeSafe’s own measurements rather than independent universal benchmarks, and the company explicitly notes that the largest gains represent the higher end of expected real-world improvements. Introducing System One Models & Jev.
The resulting design point is narrow but consequential: Jev is not intended to replace an LLM when the required output is an essay, program, conversation, or arbitrary new sequence. It targets the large class of workloads where the expensive problem is understanding unstructured state but the useful output is small, typed, and known in advance. Routing, moderation, policy decisions, risk assessment, scoring, verification, workflow branching, and classification naturally fit that shape.
In that sense, Jev’s central idea is less about making language generation faster than about recognizing when language generation should not occur at all.

Jev’s Interface and System One Programming Model

Jev’s programming model is built around a simple abstraction: an application supplies a shared state, defines one or more questions about that state, constrains each question to a typed answer space, and receives probability distributions over those answers. This differs fundamentally from conventional LLM APIs, where the model’s primary output is a sequence of tokens and structured data is imposed as a decoding constraint or recovered by parsing generated text.
Conceptually, a Jev request implements the mapping
\[\mathcal{J}: \left( s,\{q_j,C_j,\tau_j\}_{j=1}^{N} \right) \longrightarrow \{\mathbf p_j\}_{j=1}^{N}\]
- where $s$ is the shared state, $q_j$ is the instruction for question $j$, $C_j$ describes its allowed decisions, $\tau_j$ identifies the decision type, and $\mathbf p_j$ is the resulting probability distribution. This interface makes the model resemble a dynamically specified collection of classifiers whose label spaces can be defined at inference time rather than fixed during supervised training. Introducing System One Models & Jev.

State as Shared Semantic Context

The state is the information against which all decisions in a request are evaluated. It can contain natural language, semi-structured records, documents, messages, reports, or other textual context. The important systems property is that it is shared across the questions rather than repeated independently for every decision.
For example:

{
  "state": "My payouts have failed three times. The bank says everything is fine.",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this ticket?",
      "criteria": {
        "payments": "Payout failures and payment processing",
        "account": "Login and account access",
        "other": "Something else"
      }
    },
    "escalate": {
      "type": "noul",
      "instructions": "Does this require escalation?"
    }
  }
}

The two questions are not two independent prompts. They are different semantic readouts over the same underlying state. This distinction becomes increasingly important as the state grows. If a $20{,}000$-token document requires twenty classifications, a conventional architecture that independently prompts an LLM twenty times repeatedly performs substantial state processing. Jev’s interface exposes the common state explicitly, allowing the implementation to amortize that work across the decisions.
The computational objective can be represented as
\[H=E_\theta(s)\]
followed by parallel decision functions
\[\mathbf p_j = D_{\phi,\tau_j}(H,q_j,C_j), \qquad j=1,\ldots,N\]
Here the API structure mirrors the desired execution structure: one expensive semantic state representation followed by many comparatively cheap decision readouts.

Questions as Runtime-Specified Tasks

A Jev question does more than provide a natural-language prompt. It defines a decision task over the shared state.
This is an important distinction from a conventional classifier. In ordinary supervised classification, a model might be trained with a fixed output space
\[\mathcal Y= \{\text{billing},\text{security},\text{technical}\}\]
The meaning of each class is encoded implicitly in the training data and classifier parameters. Adding a new category may require new examples and retraining.
Jev instead permits the application to describe the task at inference time. A question can specify instructions such as

Which team should handle this request?

while its criteria define the semantics of the available decisions:

{
  "payments": "Payout failures, transfers, refunds, and payment processing",
  "account": "Authentication, account access, and profile management",
  "other": "Requests not covered by the other categories"
}

The decision space is consequently semantic rather than merely symbolic. The labels themselves identify programmatic outputs, while the accompanying descriptions communicate what those outputs mean.
A useful abstraction is to represent candidate $c_{j,k}$ as
\[u_{j,k} = G_\phi(q_j,c_{j,k},d_{j,k})\]
- where $d_{j,k}$ is its natural-language criterion. The decision layer then evaluates
  \[z_{j,k} = R_\phi(H,u_{j,k})\]
  - and normalizes across the candidates belonging to that question:
    \[P(y_j=c_{j,k}) = \frac{\exp(z_{j,k})} {\sum_{m=1}^{K_j}\exp(z_{j,m})}\]
The exact Jev implementation of these operations is private. The formulation captures the observable abstraction: candidate semantics are supplied at runtime, yet the result is a normalized decision distribution rather than generated prose.

Choice Questions

The most direct Jev primitive is a categorical choice. It represents a mutually exclusive decision among a prescribed set of alternatives.
For
\[C=\{c_1,\ldots,c_K\}\]
Jev returns
\[\mathbf p = [p_1,\ldots,p_K]\]
subject to
\[p_k\geq0\]
- and
  \[\sum_{k=1}^{K}p_k=1\]
A routing question might therefore return conceptually:

{
  "payments": 0.91,
  "account": 0.06,
  "other": 0.03
}

The distinction between this output and simply returning "payments" is operationally important. The argmax decision is
\[\hat y=\arg\max_k p_k\]
but the application retains the entire distribution.
A result such as
\[[0.91,0.06,0.03]\]
is qualitatively different from
\[[0.38,0.34,0.28]\]
even though both have the same argmax. In the first case, a downstream policy might route automatically; in the second, it might request human review.
This separation of prediction from policy is one of the most useful consequences of the Jev interface:
\[\text{model} \rightarrow \text{probability distribution} \rightarrow \text{application policy}\]
The model estimates the decision distribution. Ordinary software determines what operational consequence should follow.

`noul` Questions

Jev also exposes a binary decision primitive called noul. In the public API contract and compatible reproductions, it represents a two-way decision analogous to yes/no or true/false classification.
A noul question can be modeled with a scalar logit $z$:
\[P(y=1\mid s,q)=\sigma(z) = \frac{1}{1+\exp(-z)}\]
- with
  \[P(y=0\mid s,q)=1-P(y=1\mid s,q)\]
For example, an escalation question might yield

{
  "yes": 0.42,
  "no": 0.58
}

while the routing question over the same state might simultaneously yield

{
  "payments": 0.91,
  "account": 0.06,
  "other": 0.03
}

These probabilities represent separate uncertainties. High confidence about routing does not imply high confidence about escalation.
The following figure (Jev’s Architecture Unmasked) illustrates this distinction with a support request whose shared state is evaluated through multiple independent decision heads. Each head produces its own probability distribution rather than deriving all fields from a single generated continuation.
This property is especially valuable in workflows where different fields trigger different operational policies. A support system could confidently route the ticket while independently escalating only when
\[P(\text{escalate}=\text{yes})>\tau_{\text{esc}}\]
The escalation threshold need not have any relationship to the routing threshold.

Score Questions

An ordered score primitive represents a decision over levels that possess an ordinal interpretation. Instead of categories with no intrinsic ordering, the alternatives correspond to progressively increasing or decreasing values such as severity, relevance, quality, or risk.
For ordered levels
\[R=\{r_1,r_2,\ldots,r_K\}\]
the model can produce
\[P(y=r_k) = \frac{\exp(z_k)} {\sum_{m=1}^{K}\exp(z_m)}\]
This distribution supports both a modal score,
\[\hat r = \arg\max_{r_k}P(y=r_k)\]
- and an expected score,
  \[\mathbb E[r] = \sum_{k=1}^{K} r_kP(y=r_k)\]
Consider a five-level risk assessment with
\[R=\{1,2,3,4,5\}\]
A distribution such as
\[[0.01,0.04,0.15,0.50,0.30]\]
has expected value
\[\mathbb E[r] = 1(0.01)+2(0.04)+3(0.15)+4(0.50)+5(0.30) = 4.04\]
Returning the distribution rather than only 4 preserves considerably more information. Downstream software can distinguish concentrated and diffuse predictions even when they have similar expectations.

Heterogeneous Questions in a Single Request

A defining feature of the interface is that questions do not need to have identical types or numbers of candidates.
A single state might produce:

team        → 3-way choice
escalate    → binary noul
urgency     → 3-level score
fraud_type  → 8-way choice
policy_ok   → binary noul
severity    → 5-level score

Question $j$ can therefore have its own candidate count $K_j$.
The complete collection of candidate scores is jagged:
\[\mathcal S = \left\{ z_{j,k} \mid 1\leq j\leq N,\; 1\leq k\leq K_j \right\}\]
Normalization occurs within each question rather than across the complete batch:
\[p_{j,k} = \frac{\exp(z_{j,k})} {\sum_{m=1}^{K_j}\exp(z_{j,m})}\]
Thus,
\[\sum_{k=1}^{K_j}p_{j,k}=1\]
independently for every categorical question $j$.
This seemingly small API property has important implementation implications. The system cannot simply treat the output as one fixed classifier matrix
\[W\in\mathbb R^{K\times d}\]
because $K$ and the meanings of the classes vary from question to question. The readout must support dynamically defined, variable-cardinality candidate sets.
Open Jev-inspired implementations explore several approaches to this problem, including dynamically encoded candidate representations, pointer-like scoring heads, constrained vocabulary-logit selection, and candidate-conditioned attention. These implementations demonstrate possible mechanisms but should not be interpreted as disclosures of Jev’s private architecture.

Parallel Questions

The shared-state API becomes most consequential when $N$ is large. TypeSafe’s Parallel Questions cookbook recommends combining questions that operate over the same state rather than submitting them independently.
The conventional execution pattern is approximately
\[T_{\text{separate}} \approx \sum_{j=1}^{N} \left( T_{\text{state},j} + T_{\text{question},j} + T_{\text{decode},j} \right)\]
If the state dominates the prompt, then approximately
\[T_{\text{separate}} \approx N T_{\text{state}}+\epsilon\]
A shared-state implementation instead targets
\[T_{\text{parallel}} \approx T_{\text{state}} + T_{\text{question-batch}}\]
- where the question computations can themselves exploit GPU parallelism.
The desired amortized cost per decision is therefore
\[\bar T(N) = \frac{ T_{\text{state}} + T_{\text{question-batch}}(N) }{N}\]
As $N$ increases, the fixed state-processing cost is distributed across more useful decisions.
This is why Jev’s performance proposition cannot be understood solely as “zero output tokens.” Removing decoding matters, but shared-state amortization can become the larger systems advantage when applications need dozens of judgments about the same long document.

Question Independence and Isolation

Parallel evaluation introduces a subtle correctness requirement: adding another question should ideally not alter an existing decision.
Suppose
\[\mathbf p_1 = P(y_1\mid s,q_1,C_1)\]
After adding unrelated question $q_2$, a well-isolated implementation should preserve approximately
\[P(y_1\mid s,q_1,C_1,q_2,C_2) \approx P(y_1\mid s,q_1,C_1)\]
Otherwise, merely adding an analytics field to an API request could alter an unrelated production decision.
One architectural solution is block-isolated attention. Shared state tokens are computed once, and every question can attend to that state:
\[q_j\rightarrow H\]
Questions cannot attend to sibling questions:
\[q_j\not\rightarrow q_k, \qquad j\neq k\]
The open-source kev implementation demonstrates this design explicitly using a block-causal attention mask. Each question receives access to the document prefix while sibling question blocks remain isolated. This permits all questions to occupy one packed forward pass without making their representations mutually dependent.
An alternative implementation is KV-cache reuse. The model first prefills the state and stores its key-value cache:
\[K_s,V_s = \operatorname{Prefill}(s)\]
Each question then branches from that shared cache:
\[\mathbf p_j = D_\phi(K_s,V_s,q_j,C_j)\]
This avoids repeatedly processing the state while retaining conventional causal attention within each question branch. Public Jev-inspired Qwen reproductions use variants of this technique, demonstrating that meaningful shared-state acceleration is possible even without changing the underlying pretrained model.

Criteria as Semantic Labels

One of the more important details of Jev’s choice interface is that candidates can carry descriptions rather than functioning merely as opaque class IDs.
Consider two candidate definitions:

{
  "security": "Requests involving compromised credentials, suspicious access, or account takeover",
  "billing": "Requests involving charges, invoices, refunds, or payment methods"
}

The model does not need a training-time classifier weight corresponding specifically to "security". Instead, the candidate’s meaning can be constructed from language.
This suggests a general decision function of the form
\[f_\theta(s,q,c,d_c)\]
- where $c$ is the application-visible identifier and $d_c$ is its semantic description.
This design resembles zero-shot classification through natural-language label descriptions, but the output interface differs from common generative zero-shot methods because the result is explicitly normalized over the candidate set and returned as a programmatic distribution.
The flexibility is significant. An application can introduce a new candidate

{
  "trust_and_safety": "Threats, abuse, harassment, impersonation, or platform-safety incidents"
}

without modifying a fixed classifier head. The candidate set itself becomes part of the request.

Probabilities as an Application Boundary

The most consequential part of Jev’s API is arguably not the type system but the boundary it establishes between model inference and business policy.
Consider an application receiving
\[P(\text{fraud})=0.74\]
The model should not necessarily decide what happens next. Different systems can interpret the same probability differently:

P(fraud) < 0.20       → approve automatically
0.20 ≤ P < 0.70       → run additional checks
0.70 ≤ P < 0.90       → manual review
P(fraud) ≥ 0.90       → block pending review

Formally, the model estimates
\[p_\theta(y\mid x)\]
- while the application implements a policy
  \[a=\pi(\mathbf p,\lambda)\]
  - where $\lambda$ contains business-specific costs, thresholds, regulatory requirements, or operational constraints.
This separation enables decision-theoretic policies. If false positives have cost $C_{\mathrm{FP}}$ and false negatives have cost $C_{\mathrm{FN}}$, an action can be selected by minimizing expected cost:
\[a^* = \arg\min_a \mathbb E[C(a,Y)\mid\mathbf p]\]
A calibrated probability distribution is especially valuable here because the numerical confidence affects the expected utility calculation. This is why calibration is not merely an evaluation metric in Jev’s design. It is part of the contract between the neural model and the software consuming its outputs.

Decision Composition

Typed distributions can also be composed without converting intermediate results back into natural language.
Suppose a workflow estimates
\[P(\text{fraud}\mid s)=0.82\]
- and independently
  \[P(\text{high-value}\mid s)=0.63\]
A policy engine can combine these signals according to explicit business logic. More generally, the output of the neural system becomes structured state for downstream probabilistic or deterministic computation:
\[s \rightarrow \{\mathbf p_1,\ldots,\mathbf p_N\} \rightarrow \pi \rightarrow a\]
This architecture is fundamentally different from chaining LLM prompts:
\[s \rightarrow \text{generated explanation} \rightarrow \text{another prompt} \rightarrow \text{generated action}\]
The former keeps the machine-to-machine interface typed and numerical. Natural language can still be generated later when a human-readable explanation is needed, but generation is no longer required to connect every computational stage.

Where the System One Interface Fits

The “System One” terminology reflects the intended role of these models as fast decision systems rather than unrestricted deliberative generators. It should not be interpreted as a claim that Jev literally implements the cognitive architecture associated with human System 1 reasoning. In engineering terms, the distinction is primarily about the output contract and computational workload. Introducing System One Models & Jev.
A conventional generative model exposes
\[P(x_{t+1}\mid x_{\leq t})\]
repeatedly until a sequence has been constructed.
Jev instead exposes quantities closer to
\[P(y_j\mid s,q_j,C_j)\]
directly.
This makes the two model classes complementary. A generative model is appropriate when the output space cannot be enumerated in advance, such as writing code, drafting prose, answering open-ended questions, or constructing novel plans. A System One model becomes attractive when the semantic input may be extremely complex but the downstream action space is bounded.
The practical dividing line is therefore not “easy task versus hard task.” A decision may require sophisticated understanding of a long document while still having only three legal outputs. The relevant question is whether the desired output is fundamentally a new sequence or a decision over a known space.
That distinction motivates the remainder of Jev’s architecture: once arbitrary generation is removed from the contract, state computation, attention topology, readout design, batching, probability calibration, and serving infrastructure can all be optimized specifically for decision workloads.

Jev’s Likely Architecture: Shared-State Encoding and Decision-Native Readout

Jev’s exact architecture is proprietary. TypeSafe has publicly described its behavioral contract, including parallel questions, typed probability distributions, and Reinforcement Learning for Calibrated Decisions, but has not published the model architecture or training recipe. Consequently, the most useful architectural picture comes from combining those documented behaviors with controlled black-box experiments and open reproductions that demonstrate mechanisms capable of producing them. Introducing System One Models & Jev.
The evidence points toward a model that retains a Transformer-based semantic backbone but substantially changes how computation after state encoding is organized. At a high level, a useful abstraction is
\[s \xrightarrow{E_\theta} H_s \xrightarrow{\text{parallel decision readout}} \{\mathbf p_1,\ldots,\mathbf p_N\}\]
The central architectural idea is not simply a smaller output head. It is the separation of expensive shared-state understanding from relatively inexpensive question-specific decisions.

A Functional Decomposition

A conventional decoder-only LLM implements approximately
\[h_t=F_\theta(x_{1:t})\]
followed by a vocabulary projection
\[z_t=W_{\text{vocab}}h_t\]
- where
  \[W_{\text{vocab}}\in\mathbb R^{|V|\times d}\]
The model then samples or selects a token from
\[P(x_{t+1}=v) = \operatorname{softmax}(z_t)_v\]
- and repeats the operation autoregressively.
Attention Is All You Need by Vaswani et al. (2017) established the attention-based encoder-decoder architecture and masked self-attention mechanism underlying this general computational pattern in modern causal Transformers.
A Jev-like decision architecture can instead be decomposed into three conceptual components:
\[H_s=E_\theta(s)\] \[u_{j,k}=G_\phi(q_j,c_{j,k})\]
- and
  \[z_{j,k}=R_\psi(H_s,u_{j,k})\]
Here:
- $E_\theta$ is the shared semantic backbone;
- $G_\phi$ represents a question and one of its candidate decisions;
- $R_\psi$ evaluates that candidate against the shared state.
For a categorical question, normalization then occurs only across its candidate set:
\[p_{j,k} = \frac{\exp(z_{j,k})} {\sum_{m=1}^{K_j}\exp(z_{j,m})}\]
The complete request becomes
\[\mathcal J \left( s,\{q_j,C_j\}_{j=1}^{N} \right) = \{\mathbf p_j\}_{j=1}^{N}\]
This decomposition explains the most important observed properties without requiring assumptions about Jev’s undisclosed internal layers.

The Shared-State Backbone

The expensive part of a long-context decision task is generally understanding the state. If the state contains $L_s$ tokens and each of $N$ questions is evaluated using an independent conventional prompt, the model repeatedly performs computation over essentially the same prefix.
Conceptually,
\[F_\theta(s,q_1), F_\theta(s,q_2), \ldots, F_\theta(s,q_N)\]
contains substantial duplicated work.
A shared-state architecture instead performs
\[H_s=E_\theta(s)\]
once and reuses $H_s$.
The state representation need not collapse the document into a single vector. More plausibly, it remains a sequence of contextual representations:
\[H_s= [h_1,h_2,\ldots,h_{L_s}]\]
- where
  \[h_i\in\mathbb R^d\]
Retaining token-level state is important because different questions may need information from different portions of the document. A fraud question may attend to transaction details, while a routing question may depend primarily on the user’s stated problem.
The architecture therefore resembles a reusable semantic memory rather than a conventional pooled classifier embedding.

Why KV-Cache Reuse Is the Simplest Approximation

A standard decoder Transformer already provides one mechanism for reusing shared computation: the key-value cache.
For layer $\ell$, self-attention computes keys and values
\[K^{(\ell)}=H^{(\ell)}W_K^{(\ell)}\] \[V^{(\ell)}=H^{(\ell)}W_V^{(\ell)}\]
After processing the shared state, the model can retain
\[\mathcal C_s = \{ K_s^{(\ell)},V_s^{(\ell)} \}_{\ell=1}^{L}\]
Each question can then branch from the same cache:
\[\mathbf p_j = D_\phi(\mathcal C_s,q_j,C_j)\]
This transforms the computation from repeated full-prefill execution,
\[N\times\operatorname{Prefill}(s)\]
into approximately
\[\operatorname{Prefill}(s) + \sum_{j=1}^{N} \operatorname{Question}(q_j,C_j)\]
Open Jev-inspired Qwen implementations demonstrate this approach. They preserve the state prefix, reuse its KV cache, and evaluate multiple question suffixes without repeatedly processing the document. This reproduces part of Jev’s observed latency behavior while leaving the pretrained Transformer itself largely unchanged.
However, KV caching alone does not explain the full design space. A purpose-built decision architecture can optimize the question stage more aggressively because it does not need each question to behave like an ordinary causal-LM continuation.

Block-Causal Attention

A more integrated design is to place the shared state and multiple questions into a single forward pass while modifying the attention topology.
Suppose the packed sequence contains
\[[s,q_1,q_2,\ldots,q_N]\]
Ordinary causal attention would permit later questions to observe earlier questions:
\[q_2\rightarrow q_1, \qquad q_3\rightarrow\{q_1,q_2\}\]
- which is undesirable if questions are intended to represent independent decisions.
Instead, a block-causal mask can enforce
\[q_j\rightarrow s\]
- while prohibiting
  \[q_j\rightarrow q_k \qquad j\neq k\]
The corresponding attention mask has a conceptual structure
\[M= \begin{bmatrix} M_{ss} & 0 & 0 & 0\\ M_{q_1s} & M_{q_1q_1} & 0 & 0\\ M_{q_2s} & 0 & M_{q_2q_2} & 0\\ M_{q_3s} & 0 & 0 & M_{q_3q_3} \end{bmatrix}\]
Each question can inspect the shared state and itself, but sibling questions remain isolated.
The open-source kev project demonstrates this mechanism with a standard causal Transformer, packing the document and questions together while using a block-causal mask and pointer-style readout. The significance is architectural rather than evidentiary: it shows that Jev-like parallel semantics can be implemented without requiring a completely new foundation-model family.
This design also makes question batching highly GPU-friendly. Instead of executing $N$ serial forward passes, question tokens can participate in the same matrix operations while the attention mask defines their logical independence.

Question-Conditioned Readout

Once a question has accessed the shared state, the model needs to transform its representation into scores over arbitrary candidate decisions.
One possibility is a question summary vector
\[r_j = \operatorname{Read}(H_s,q_j)\]
followed by candidate representations
\[u_{j,k} = G_\phi(c_{j,k})\]
Candidate scores could then be computed using a bilinear function:
\[z_{j,k} = r_j^\top W u_{j,k}\]
- or a similarity function such as
  \[z_{j,k} = \frac{ r_j^\top u_{j,k} }{ \sqrt d }\]
A more expressive scorer might use
\[z_{j,k} = \operatorname{MLP} \left( [r_j;u_{j,k};r_j\odot u_{j,k}] \right)\]
Another possibility is candidate-conditioned attention, in which candidate representations query the shared state directly:
\[a_{j,k} = \operatorname{softmax} \left( \frac{ Q(u_{j,k})K(H_s)^\top }{ \sqrt{d_k} } \right)\] \[r_{j,k} = a_{j,k}V(H_s)\]
followed by
\[z_{j,k} = f_\psi(r_{j,k},u_{j,k})\]
The jevlike reproduction explored a version of this candidate-conditioned attention idea, where candidate representations query state tokens to produce a one-pass score over a variable set of text options.
Again, this is a plausible implementation family rather than evidence that Jev uses this exact mechanism.

Pointer-Style Decision Heads

A particularly natural solution to dynamic candidate sets is a pointer-style head.
Instead of learning a fixed classifier
\[W_{\text{cls}} \in \mathbb R^{K\times d}\]
the model represents candidates dynamically and computes compatibility scores between the decision representation and each candidate.
If
\[r_j\in\mathbb R^d\]
is the question representation and
\[u_{j,k}\in\mathbb R^d\]
is candidate $k$, a simple pointer score is
\[z_{j,k} = r_j^\top u_{j,k}\]
The model then normalizes only over candidates present in that request:
\[P(y_j=c_{j,k}) = \operatorname{softmax} \left( z_{j,1},\ldots,z_{j,K_j} \right)_k\]
This solves an important problem that a conventional classification head cannot: the number and semantics of classes can change at runtime.
The architecture is conceptually related to pointer mechanisms introduced in Pointer Networks by Vinyals et al. (2015), which replaced a fixed output vocabulary with attention over a dynamically supplied set of input positions. Jev-like decision heads need not literally implement Pointer Networks, but the same principle applies: the output space can be defined by the current example rather than fixed in the model parameters.

Removing the Vocabulary Projection

A standard language model’s final hidden vector $h$ is projected through
\[W_{\text{vocab}} \in \mathbb R^{|V|\times d}\]
Therefore,
\[z=W_{\text{vocab}}h\]
produces $$ V $$ logits even when the application ultimately cares about only a handful of possible decisions.
If
\[|V|\approx150{,}000\]
but the task has
\[K=4\]
legal answers, most of the output computation is irrelevant to the application.
A decision-native model can instead compute
\[z_k=f_\psi(H_s,q,c_k), \qquad k=1,\ldots,K\]
- and normalize only those scores:
  \[P(c_k) = \frac{\exp(z_k)} {\sum_{m=1}^{K}\exp(z_m)}\]
The output computation consequently scales with $K$ rather than $$ V $$.
This does not imply that removing the LM head alone explains Jev’s total speed advantage. For long contexts, Transformer state processing can dominate vocabulary projection. The more consequential optimization is the combination of shared-state computation, parallel questions, zero autoregressive decoding, and restricted decision readout.

The Minimal Qwen Construction

The simplest Jev-like implementation demonstrates how little machinery is actually required to remove generation.
Suppose a prompt ends by asking the model to answer using exactly one of

A
B
C

A Qwen model performs its normal forward pass and produces
\[z\in\mathbb R^{|V|}\]
Instead of decoding, extract
\[z_A,z_B,z_C\]
Then calculate
\[P(A) = \frac{e^{z_A}} {e^{z_A}+e^{z_B}+e^{z_C}}\]
- with analogous expressions for $B$ and $C$.
The model has produced a decision distribution after one forward pass:
\[(s,q) \xrightarrow{\text{prefill}} h \xrightarrow{W_{\text{vocab}}} z \xrightarrow{\text{candidate slice}} [z_A,z_B,z_C] \xrightarrow{\text{softmax}} \mathbf p\]
No answer token is ever emitted.
SemIf, formerly OpenJev, explores this approach using frozen Qwen models, direct option-logit readout, shared-state prefix caching, and parallel evaluation. Its importance is that it isolates the first-order systems insight: a pretrained generative model can already function as a zero-shot decision model if its logits are consumed differently.

Explicit Decision Heads

The next architectural step is to remove dependence on vocabulary tokens altogether.
Instead of requiring each semantic answer to map to A, B, or another token, construct explicit decision representations:
\[u_k=G_\phi(d_k)\]
- where $d_k$ is the natural-language description of candidate $k$.
Then evaluate
\[z_k=f_\psi(H_s,q,u_k)\]
This has several advantages.
First, candidate semantics no longer depend on arbitrary token identities.
Second, the model avoids projecting across the entire vocabulary.
Third, multi-token candidate descriptions can be represented naturally.
Fourth, the readout can be trained specifically for discrimination and calibration rather than next-token prediction.
NanoJev explores this direction using Qwen3-0.6B with explicit decision heads, dynamic candidate sets, multiple candidate paths, and no output-token decoding.
The conceptual progression is therefore
\[\text{full LM decoding}\]
to
\[\text{single-pass vocabulary-logit slicing}\]
to
\[\text{explicit semantic decision heads}\]
Each stage removes machinery inherited from language generation that is unnecessary for bounded decisions.

Candidate Interaction and Normalization

Dynamic candidate sets introduce another architectural question: should candidates be scored independently or jointly?
An independent scorer computes
\[z_k=f_\theta(s,q,c_k)\]
- for each candidate and normalizes afterward:
  \[p_k= \frac{e^{z_k}} {\sum_m e^{z_m}}\]
In this formulation, candidate $c_k$ cannot influence the representation used to score $c_m$ before normalization.
A joint scorer can instead process
\[C=\{c_1,\ldots,c_K\}\]
as a set and compute
\[[z_1,\ldots,z_K] = F_\theta(s,q,C)\]
This allows candidates to interact before the final softmax.
Black-box probing of Jev has examined candidate interaction, option position, fake candidates, and relational effects to infer which architectural family better matches its behavior. Those experiments provide evidence about observable invariances and interactions, but they do not uniquely identify the underlying network. The investigation explicitly distinguishes observed behavior from architectural interpretation and notes that the proposed mechanisms are precedents rather than proof of Jev’s implementation.
This distinction is important because multiple architectures can implement the same external conditional distribution
\[P(y\mid s,q,C)\]
Behavioral equivalence does not imply architectural equivalence.

Sparse Mixture-of-Experts as a Possible Backbone

One black-box investigation reports evidence consistent with a causal Transformer and suggests that the backbone may use sparse Mixture-of-Experts routing. This remains an inference rather than a TypeSafe disclosure.
A sparse MoE layer replaces a single dense feed-forward transformation with a collection of experts
\[E_1,\ldots,E_M\]
A router computes
\[g(x)=\operatorname{softmax}(W_rx)\]
- and selects a small subset of experts
  \[\mathcal T_k(x) = \operatorname{TopK}(g(x))\]
The layer output can be written
\[y = \sum_{i\in\mathcal T_k(x)} g_i(x)E_i(x)\]
Sparsely-Gated Mixture-of-Experts by Shazeer et al. (2017) established large sparse expert layers in which conditional computation increases parameter capacity without activating every parameter for every example.
Switch Transformers by Fedus et al. (2021) simplified this design by routing each token to a single expert, demonstrating large-scale sparse language-model training with comparatively low per-token active computation.
If Jev does use an MoE backbone, it would fit the broader goal of maintaining strong semantic capacity while reducing active inference cost. However, the public evidence does not establish the expert count, routing algorithm, sparsity level, or even definitively establish that Jev uses MoE. Those details should therefore remain hypotheses rather than architectural facts.

Prefill-Only Execution

The most important systems consequence of the architecture is that Jev can potentially operate almost entirely in the regime that LLM serving systems call prefill.
Ordinary generation has two phases:
\[\text{prefill} \rightarrow \text{decode}\]
Prefill processes the available prompt in parallel across positions. Decode repeatedly adds one token:
\[h_{t+1} \rightarrow x_{t+1} \rightarrow h_{t+2} \rightarrow x_{t+2} \rightarrow\cdots\]
The second phase is sequential.
A decision-native model can instead perform
\[\text{state/question prefill} \rightarrow \text{decision readout} \rightarrow \text{return}\]
There is no requirement to enter a long autoregressive decode loop.
This changes the hardware workload. Prefill tends to expose large matrix multiplications and substantial parallelism, while autoregressive decode repeatedly executes relatively small sequential steps and is often constrained by memory bandwidth and KV-cache movement.
Consequently, Jev’s interface is not merely reducing the number of output tokens. It shifts a larger fraction of inference toward a computational regime that accelerators can execute efficiently.

Parallel Readout as Batched Matrix Computation

Suppose the model produces $M$ total candidate representations across all questions:
\[U= [u_1,\ldots,u_M]^\top \in\mathbb R^{M\times d}\]
If the state has been summarized into compatible decision features
\[R\in\mathbb R^{d}\]
a simple scorer can evaluate all candidates simultaneously:
\[z=UR\]
- where
  \[z\in\mathbb R^M\]
For richer state-dependent scoring, candidate queries can attend to the shared state:
\[Q=UW_Q\] \[K=H_sW_K\] \[V=H_sW_V\] \[A= \operatorname{softmax} \left( \frac{QK^\top}{\sqrt{d_k}} \right)\] \[R=AV\]
All $M$ candidate queries participate in batched matrix operations.
The resulting scores are then segmented by question and independently normalized:
\[\mathbf p_j = \operatorname{softmax} \left( z_{o_j:o_j+K_j} \right)\]
- where $o_j$ is the offset of question $j$ in the packed candidate array.
This is one plausible implementation of Jev’s “jagged” output structure: variable numbers of candidates can be flattened for accelerator execution and segmented only at normalization and serialization time.

A Useful Architectural Mental Model

The strongest public evidence supports a functional architecture more confidently than any exact layer diagram.
A useful mental model is:
\[\boxed{ \text{shared state} \xrightarrow{\text{semantic backbone}} H_s }\]
followed by
\[\boxed{ (q_j,C_j) \xrightarrow{\text{decision representation}} U_j }\]
- and then
  \[\boxed{ (H_s,U_j) \xrightarrow{\text{decision readout}} z_j \xrightarrow{\text{typed normalization}} \mathbf p_j }\]
Across all questions,
\[s \xrightarrow{E_\theta} H_s \xrightarrow{ \{R_\phi(q_j,C_j)\}_{j=1}^{N} } \{\mathbf p_1,\ldots,\mathbf p_N\}\]
The architecture should therefore be understood primarily through the computations it eliminates:
\[\text{no repeated state encoding}\] \[\text{no required autoregressive output sequence}\] \[\text{no requirement to score the entire language vocabulary}\]
- and the computations it introduces:
  \[\text{dynamic candidate representation}\] \[\text{parallel question readout}\] \[\text{typed normalization}\] \[\text{decision-specific calibration}\]
The exact mechanisms used by Jev for each component remain undisclosed. The open reproductions are valuable precisely because they show that these properties can emerge from several architectural routes. Jev’s deeper contribution is therefore not necessarily one novel attention operation. It is the reorganization of a pretrained semantic model around decision computation as the primary inference primitive.

Training Jev: From Language Modeling to Calibrated Decision Learning

Jev’s architectural changes are only part of the system. A conventional pretrained LLM can already be converted into a crude decision model by extracting candidate logits or scoring candidate continuations, but those probabilities inherit the objectives and biases of next-token prediction. Jev’s more consequential training claim is that decision probabilities themselves should become the optimization target.
TypeSafe describes its post-training method as Reinforcement Learning for Calibrated Decisions, or RLCD. The publicly stated objective is to produce “epistemically honest probabilities” for System One decisions rather than merely generating plausible or preferred strings. The precise RLCD algorithm, reward construction, datasets, and optimization details have not been publicly disclosed, so a complete Jev training recipe cannot currently be reconstructed from public information. Introducing System One Models & Jev.
The distinction can be summarized as
\[\text{pretraining} \rightarrow \text{learn representations and world knowledge}\]
followed by
\[\text{decision post-training} \rightarrow \text{learn how to expose that knowledge as calibrated decisions}\]
Open Jev-inspired systems illustrate several increasingly sophisticated ways to approximate the second stage, ranging from zero-shot candidate scoring to frozen-backbone decision heads and LoRA fine-tuning.

Why Next-Token Training Is Not Enough

A conventional causal language model is trained to minimize next-token negative log-likelihood:
\[\mathcal L_{\text{LM}} = -\sum_{t=1}^{T} \log P_\theta(x_t\mid x_{<t})\]
This objective is extraordinarily effective for learning linguistic and semantic representations. However, it does not directly train the model to answer questions such as:
\[P(\text{transaction is fraudulent}\mid s)=?\]
- or
  \[P(\text{ticket should be escalated}\mid s)=?\]
Instead, it learns quantities of the form
\[P(\text{next token}\mid\text{prefix})\]
These can be repurposed for decisions. If a model is instructed to answer with A, B, or C, candidate probabilities can be constructed from its next-token logits:
\[p_i = \frac{\exp(z_i)} {\sum_{j=1}^{K}\exp(z_j)}\]
But these values should not automatically be interpreted as calibrated probabilities that the corresponding semantic decisions are correct.
This distinction is central to Jev. The desired quantity is not merely
\[P_\theta(\text{token ``A''}\mid\text{prompt})\]
but something closer to
\[P_\theta(Y=A\mid s,q,C)\]
The two can correlate strongly without being equivalent.

From Token Likelihood to Decision Likelihood

A useful intermediate approach is to score complete candidate continuations.
Suppose candidate $c_k$ tokenizes into
\[c_k=(w_{k,1},\ldots,w_{k,L_k})\]
Its autoregressive conditional likelihood is
\[P(c_k\mid s,q) = \prod_{t=1}^{L_k} P(w_{k,t}\mid s,q,w_{k,<t})\]
For numerical stability, implementations operate in log space:
\[S_k = \log P(c_k\mid s,q) = \sum_{t=1}^{L_k} \log P(w_{k,t}\mid s,q,w_{k,<t})\]
The candidate scores can then be normalized:
\[p_k = \frac{\exp(S_k)} {\sum_j\exp(S_j)}\]
The open Open Jev implementation demonstrates this construction with Gemma 3 4B. It prefills the shared context once, expands the KV cache across the candidate batch, and scores all option tokens in a padded forward pass without autoregressive answer generation.
This is an important implementation point. “No decoding” does not necessarily mean that only one candidate token can be evaluated. Entire candidate strings can be teacher-forced through the model in parallel.
For option $k$,
\[S_k = \sum_{t=1}^{L_k} m_{k,t} \log P_\theta(w_{k,t}\mid s,q,w_{k,<t})\]
- where $m_{k,t}$ masks padding positions.
The final prediction remains
\[\hat k=\arg\max_k S_k\]
This construction provides a strong baseline because it extracts decision information from a pretrained model without requiring new training.

Length Normalization

Raw sequence likelihood introduces a well-known issue: longer candidates accumulate more negative log-probability terms.
For example,

A: Fraud
B: Potentially fraudulent transaction requiring manual review

may receive very different raw sequence scores partly because candidate $B$ contains many more tokens.
A simple correction is mean log-probability:
\[S_k^{\text{mean}} = \frac{1}{L_k} \sum_{t=1}^{L_k} \log P(w_{k,t}\mid s,q,w_{k,<t})\]
The open implementation exposes both sum and mean normalization modes, as well as a PMI-style correction. This matters when arbitrary natural-language criteria serve as candidate answers rather than fixed single-token labels. Open Jev.
A generic PMI-style score can be written as
\[S_k^{\text{PMI}} = \log P(c_k\mid s,q) - \log P(c_k\mid q_0)\]
- where the second term estimates the candidate’s context-independent prior under an appropriate null or baseline prompt.
The intuition is to discount candidates that the language model inherently prefers regardless of the state.

Why Raw LLM Probabilities Can Be Misleading

Consider a decision with two candidates:
\[C=\{\text{approve},\text{reject}\}\]
Suppose the normalized candidate scores are
\[P(\text{approve})=0.99\] \[P(\text{reject})=0.01\]
This does not imply that, over all examples where the model outputs $0.99$, it will be correct $99\%$ of the time.
A calibrated predictor should approximately satisfy
\[P(Y=\hat Y\mid \hat P=p)=p\]
Thus, predictions made with confidence $0.9$ should be correct approximately $90\%$ of the time on the relevant data distribution.
On Calibration of Modern Neural Networks by Guo et al. (2017) showed that high-accuracy neural networks can nevertheless be poorly calibrated and introduced expected calibration error and temperature scaling as practical tools for measuring and correcting this mismatch.
This becomes especially important for Jev because probability is part of the product interface rather than merely an internal score.

Expected Calibration Error

A standard calibration diagnostic partitions predictions into $M$ confidence bins
\[B_1,\ldots,B_M\]
For bin $B_m$, define empirical accuracy as
\[\operatorname{acc}(B_m) = \frac{1}{|B_m|} \sum_{i\in B_m} \mathbf 1(\hat y_i=y_i)\]
- and mean confidence as
  \[\operatorname{conf}(B_m) = \frac{1}{|B_m|} \sum_{i\in B_m} \hat p_i\]
Expected calibration error is
\[\operatorname{ECE} = \sum_{m=1}^{M} \frac{|B_m|}{n} \left| \operatorname{acc}(B_m) - \operatorname{conf}(B_m) \right|\]
An idealized perfectly calibrated system has
\[\operatorname{ECE}=0\]
The black-box Jev investigation uses a 10-bin ECE calculation when evaluating calibration on MMLU-style decision tasks, while the open frozen-feature implementation also reports 10-bin ECE alongside top-1 and top-3 accuracy.
Calibration should not be reduced to ECE alone. ECE depends on binning and can conceal important behavior. Reliability diagrams, Brier score, negative log-likelihood, class-conditional calibration, and selective-risk curves provide complementary information.

Temperature Scaling

A simple post-hoc calibration method introduces a learned temperature $T>0$:
\[p_k = \frac{ \exp(z_k/T) }{ \sum_j\exp(z_j/T) }\]
When
\[T>1\]
the distribution becomes softer. When
\[T<1\]
it becomes sharper.
The temperature is typically selected on held-out calibration data by minimizing negative log-likelihood:
\[T^* = \arg\min_T -\sum_{i=1}^{n} \log p_{y_i}^{(T)}\]
Temperature scaling changes confidence without changing the class ranking because
\[\arg\max_k z_k = \arg\max_k \frac{z_k}{T}\]
This makes it attractive when a decision model already has strong classification accuracy but systematically overstates or understates confidence.
However, TypeSafe’s description of RLCD implies a deeper goal than post-hoc temperature correction. The aim is to train decision behavior itself so that uncertainty is represented meaningfully across tasks rather than applying one scalar correction after training.

Frozen Backbone, Trainable Decision Head

A stronger Jev-like approach preserves the pretrained language model as a semantic feature extractor and trains only a decision-specific head.
Let the frozen backbone produce state representations
\[H_s = F_{\theta_{\text{frozen}}}(s)\]
Candidate $k$ can similarly be represented as
\[U_k = F_{\theta_{\text{frozen}}}(c_k)\]
A compact decision head then computes
\[z_k = R_\phi(H_s,U_k)\]
- where only $\phi$ is optimized.
The open Gemma reproduction explores this strategy by extracting final hidden states from Gemma 3 4B and constructing masked-mean representations over option tokens. A small Jev-like cross-attention head learns to compare those candidate representations against the state.
A simplified version is
\[u_k = \frac{ \sum_t m_{k,t}h_{k,t} }{ \sum_t m_{k,t} }\]
followed by candidate-to-state attention
\[a_k = \operatorname{softmax} \left( \frac{ Q(u_k)K(H_s)^\top }{ \sqrt d } \right)\] \[r_k=a_kV(H_s)\]
- and a scoring network
  \[z_k=f_\phi(r_k,u_k)\]
The candidate probabilities are then
\[p_k=\operatorname{softmax}(\mathbf z)_k\]
This architecture is attractive because the large pretrained model remains fixed while a comparatively small number of parameters learn the decision interface.

Supervised Decision Training

Given labeled examples
\[\mathcal D = \{(s_i,q_i,C_i,y_i)\}_{i=1}^{N}\]
the most straightforward training objective is categorical cross-entropy:
\[\mathcal L_{\text{CE}} = -\frac{1}{N} \sum_{i=1}^{N} \log P_\phi(y_i\mid s_i,q_i,C_i)\]
For binary decisions,
\[\mathcal L_{\text{BCE}} = -\frac{1}{N} \sum_{i=1}^{N} \left[ y_i\log p_i + (1-y_i)\log(1-p_i) \right]\]
These are proper scoring rules: in expectation, the optimal prediction corresponds to the true conditional probability under suitable assumptions. This makes supervised probabilistic classification a natural starting point for a Jev-like model.
The open frozen-Gemma experiment used AdamW with learning rate
\[5\times10^{-4}\]
weight decay
\[10^{-4}\]
gradient clipping at
\[1.0\]
eight epochs, and batch size
\[64\]
On its synthetic split, the trained head reported top-1 accuracy of $0.970$, top-3 accuracy of $1.000$, and ECE of $0.027$. These results apply only to that synthetic experiment and should not be interpreted as Jev benchmark numbers.

Testing Whether the Head Uses the State

A decision head can achieve deceptively strong results by exploiting candidate priors, label wording, or dataset artifacts without actually understanding the state.
A useful diagnostic is therefore to shuffle state representations across examples.
For an original example,
\[(s_i,q_i,C_i,y_i)\]
evaluate instead
\[(s_{\pi(i)},q_i,C_i,y_i)\]
- where $\pi$ is a random permutation.
If the model truly relies on the state, performance should collapse.
The frozen-Gemma experiment reports exactly such a control. Its trained head achieved approximately $0.970$ top-1 accuracy on the ordinary evaluation set but only $0.258$ when context was shuffled; ECE also degraded substantially.
This type of negative control is important for decision-model evaluation because a superficially impressive classifier can otherwise succeed through spurious label regularities.

LoRA-Based Decision Adaptation

Instead of freezing the entire backbone, a Jev-like system can adapt a small subset of its parameters using Low-Rank Adaptation.
LoRA: Low-Rank Adaptation of Large Language Models by Hu et al. (2021) replaces a dense weight update
\[W'=W+\Delta W\]
- with a low-rank parameterization
  \[\Delta W=BA\]
  - where
    \[A\in\mathbb R^{r\times d}\] \[B\in\mathbb R^{d'\times r}\]
    - and
      \[r\ll\min(d,d')\]
The pretrained weight $W$ remains frozen while $A$ and $B$ are optimized.
This is useful for decision models because the pretrained backbone already contains substantial semantic capability. Training can focus on modifying how that capability is exposed for discrimination and uncertainty estimation rather than relearning language understanding.
Both Kev and Bespoke Nimble use parameter-efficient adaptation as part of their Jev-like training approaches. kev.

Kev’s Training Recipe

Kev provides a particularly concrete open recipe. It uses Qwen2.5-0.5B as its backbone, augments it with a small readout head, and trains a LoRA adapter plus the decision head rather than fully fine-tuning the model. kev.
Its training mixture contains roughly $13{,}000$ examples drawn from classification and inference datasets including Banking77, BoolQ, AG News, MNLI, SST-5, and Yelp Review Full.
These datasets expose the model to heterogeneous decision spaces:
\[\text{intent classification}\] \[\text{Boolean QA}\] \[\text{topic classification}\] \[\text{natural-language inference}\] \[\text{sentiment classification}\]
This heterogeneity matters because the goal is not to train one fixed classifier. The model needs to learn the higher-level operation
\[(s,q,C) \rightarrow P(y\mid s,q,C)\]
across varying candidate semantics.
The readout is trained using labeled outcomes and cross-entropy. This is considerably simpler than TypeSafe’s stated RLCD approach, but it demonstrates that a general decision interface can be learned with ordinary supervised objectives.

Contrastive Data Construction

Bespoke Nimble emphasizes another important training dimension: the quality of decision data.
Instead of relying exclusively on naturally occurring examples, Nimble constructs contrastive variants by making small factual changes that alter the correct decision. For example, if an original state implies
\[y=\text{approve}\]
a minimally modified state can be generated such that
\[y'=\text{reject}\]
The objective is to prevent the model from relying on superficial lexical cues.
Conceptually, given
\[(s,y)\]
construct
\[(s',y')\]
such that
\[d(s,s')\text{ is small}\]
- while
  \[y'\neq y\]
This creates a local decision boundary:
\[s \xrightarrow{\text{small semantic intervention}} s'\]
but
\[f(s)\neq f(s')\]
Bespoke describes this as contrastive data curation and notes that its training data need not explicitly contain probability labels. The model learns from correct outcomes, while probabilistic behavior emerges from the trained scoring distribution.
Its initial open recipe fine-tunes Qwen3.5-9B using LoRA with rank $16$, learning rate $5\times10^{-5}$, batch size $8$, one epoch, and BF16 training on an H100. The release explicitly states that this is supervised fine-tuning rather than a reproduction of RLCD.
The following figure (Bespoke Labs) summarizes the Nimble recipe, including shared-prompt serving, contrastive data construction, LoRA fine-tuning, and the initial evaluation setup.

Why Contrastive Examples Matter

Consider a fraud classifier trained mostly on examples in which fraud descriptions contain words such as “suspicious,” “unauthorized,” or “stolen.”
The model may learn
\[P(y=\text{fraud}\mid\text{``suspicious''})\gg P(y=\text{fraud})\]
without learning the underlying transaction logic.
A contrastive pair might instead contain:

Original:
The cardholder confirms making the purchase.

Counterfactual:
The cardholder denies making the purchase.

The lexical overlap is extremely high, but the relevant fact changes.
Training on such pairs encourages sensitivity to
\[\Delta_{\text{semantic}}\]
rather than
\[\Delta_{\text{surface}}\]
For a decision model, this is particularly important because high-confidence mistakes are more damaging than ordinary ranking errors. A model that exploits dataset shortcuts may appear accurate while producing dangerously miscalibrated probabilities under distribution shift.

From Supervised Fine-Tuning to RLCD

TypeSafe contrasts RLCD with RLHF and RLVR.
In Reinforcement Learning from Human Feedback, the training signal typically expresses human preference among candidate model outputs. In Reinforcement Learning with Verifiable Rewards, a model can receive reward from mechanically checkable outcomes such as whether generated code passes tests or a mathematical answer is correct.
Jev’s stated problem is different. The model must not only select the correct answer but assign an appropriate probability to it.
Suppose two examples are both answered correctly:
\[p_\theta(y_1)=0.99\]
- and
  \[p_\theta(y_2)=0.61\]
Accuracy treats both equally:
\[\mathbf 1(\hat y_1=y_1) = \mathbf 1(\hat y_2=y_2) = 1\]
A probability-sensitive objective does not.
For negative log-likelihood,
\[\mathcal L_1=-\log0.99\]
- and
  \[\mathcal L_2=-\log0.61\]
Likewise, a confidently wrong prediction receives a much larger penalty:
\[-\log0.01\gg-\log0.40\]
This basic property explains why proper probabilistic objectives naturally encourage calibration. RLCD presumably extends this idea into TypeSafe’s post-training regime, but its exact reward function is not public. Any more specific RLCD loss would therefore be speculative.

Proper Scoring Rules

The mathematical foundation for calibrated probabilistic learning is the notion of a proper scoring rule.
A scoring rule is proper when the expected score is optimized by reporting the predictor’s true belief distribution.
Negative log-likelihood is one example:
\[S_{\log}(\mathbf p,y) = -\log p_y\]
The Brier score is another:
\[S_{\text{Brier}} = \sum_{k=1}^{K} (p_k-\mathbf 1[y=k])^2\]
For a binary event,
\[S_{\text{Brier}} = (p-y)^2\]
Both penalize incorrect confidence, not merely incorrect argmax predictions.
This distinction can be illustrated by two incorrect predictions for a binary event with
\[y=0\]
A model predicting
\[p=0.55\]
is wrong after thresholding at $0.5$, but far less badly calibrated than a model predicting
\[p=0.999\]
A decision-training objective intended for operational probabilities should distinguish these cases.

Calibration Versus Sharpness

A model can be calibrated yet uninformative.
Consider a balanced binary dataset. A model that always predicts
\[P(y=1)=0.5\]
may be perfectly calibrated but provides no useful discrimination.
The desired model therefore needs both calibration and sharpness.
Calibration asks:
\[\text{Are probabilities statistically truthful?}\]
Sharpness asks:
\[\text{How concentrated can those truthful probabilities become?}\]
An effective decision model should confidently separate easy cases while remaining uncertain on genuinely ambiguous cases.
This motivates evaluating both discrimination metrics, such as accuracy or AUROC, and probabilistic metrics, such as negative log-likelihood, Brier score, and ECE.

Calibration Under Distribution Shift

Calibration measured on an IID validation set does not guarantee calibration after deployment.
If training data follow
\[P_{\text{train}}(x,y)\]
but production follows
\[P_{\text{prod}}(x,y)\]
then even a calibrated model may satisfy
\[P_{\text{train}}(Y=\hat Y\mid\hat P=p)\approx p\]
- while violating
  \[P_{\text{prod}}(Y=\hat Y\mid\hat P=p)\approx p\]
This matters for Jev-like systems because probability thresholds often directly trigger automation.
A robust deployment should therefore monitor calibration over time, ideally stratified by important subpopulations and task types:
\[\operatorname{ECE}_{\text{overall}}\] \[\operatorname{ECE}_{\text{task}}\] \[\operatorname{ECE}_{\text{class}}\]
- and, where appropriate,
  \[\operatorname{ECE}_{\text{slice}}\]
The model’s confidence should be treated as an empirical quantity whose reliability must be continuously validated rather than a permanent property established at training time.

Selective Prediction

Calibrated probabilities enable a particularly useful deployment strategy: selective prediction.
Instead of forcing the model to automate every example, define a confidence threshold $\tau$:
\[\text{automate} \iff \max_k p_k\geq\tau\]
Otherwise,
\[\text{defer to human}\]
Coverage is
\[\operatorname{coverage}(\tau) = \frac{ |\{i:\max_kp_{i,k}\geq\tau\}| }{N}\]
Selective risk is the error rate among accepted examples:
\[R(\tau) = \frac{ \sum_i \mathbf1[ \max_kp_{i,k}\geq\tau ] \mathbf1[\hat y_i\neq y_i] }{ \sum_i \mathbf1[ \max_kp_{i,k}\geq\tau ] }\]
As $\tau$ increases, coverage generally decreases while reliability among automatically handled cases can improve.
This converts calibration into direct operational leverage. The goal is no longer merely maximizing benchmark accuracy. It becomes choosing an automation frontier such as
\[95\%\text{ precision at }80\%\text{ coverage}\]

The Training Stack as a Continuum

The open implementations make it useful to view Jev-like training as a continuum rather than a single technique.
At the simplest level:
\[\text{pretrained LLM} + \text{candidate-logit extraction}\]
No training is required.
The next level is:
\[\text{pretrained LLM} + \text{candidate continuation scoring} + \text{calibration}\]
The next is:
\[\text{frozen backbone} + \text{trainable decision head}\]
Then:
\[\text{LoRA-adapted backbone} + \text{decision head} + \text{contrastive decision data}\]
Finally, Jev’s stated direction is:
\[\text{decision architecture} + \text{decision-specific post-training} + \text{calibration-oriented reinforcement learning}\]
The public evidence supports the first four stages through open reproductions. The final stage is TypeSafe’s stated RLCD approach, but its implementation remains proprietary.
The important conceptual progression is that each stage moves farther away from treating decision making as a side effect of language modeling. The model is progressively optimized for the quantity the application actually consumes:
\[P(y\mid s,q,C)\]
That probability distribution, rather than a generated explanation or serialized label, is the central training target of the System One paradigm.

Evaluation, Latency, and Scaling Behavior

Jev should be evaluated differently from a conventional generative model because its product contract is different. The central questions are not only whether the model selects the correct answer, but whether its probabilities are meaningful, whether many decisions can efficiently reuse the same state, whether latency grows gracefully with additional questions and candidates, and whether these properties persist across task distributions.
The available evidence is still early. TypeSafe reports public benchmark and systems results for Jev, independent investigations have probed Jev 1.13.0 through its API, and open reproductions provide controlled local measurements. These measurements should not be collapsed into a single leaderboard because they differ in hardware, datasets, serving environments, and experimental design. Introducing System One Models & Jev.

What Should Be Measured

For a decision model, evaluation naturally separates into four dimensions:
\[\text{quality}, \qquad \text{calibration}, \qquad \text{latency}, \qquad \text{scaling efficiency}\]
Quality asks whether the correct decision receives the highest probability. Calibration asks whether numerical probabilities correspond to empirical correctness. Latency measures the time required to obtain usable structured decisions. Scaling efficiency asks how that latency changes as the state, number of questions, and number of candidates increase.
These dimensions can conflict. A system may be extremely fast but poorly calibrated, highly accurate but expensive, or well calibrated while insufficiently discriminative.
For categorical decisions, top-1 accuracy is
\[\operatorname{Acc@1} = \frac{1}{N} \sum_{i=1}^{N} \mathbf 1 [ \arg\max_k p_{i,k}=y_i ]\]
When several candidates can be surfaced downstream, top-$K$ accuracy is
\[\operatorname{Acc@K} = \frac{1}{N} \sum_{i=1}^{N} \mathbf 1 [ y_i\in\operatorname{TopK}(\mathbf p_i) ]\]
For Jev, however, these ranking metrics describe only part of the interface. A prediction of
\[[0.99,0.01]\]
- and one of
  \[[0.51,0.49]\]
receive identical top-1 credit if their first candidate is correct, despite representing radically different levels of certainty.

Probability Quality

A decision model should therefore also be evaluated with probability-sensitive metrics.
Negative log-likelihood is
\[\operatorname{NLL} = -\frac{1}{N} \sum_{i=1}^{N} \log p_{i,y_i}\]
The multiclass Brier score is
\[\operatorname{Brier} = \frac{1}{N} \sum_{i=1}^{N} \sum_{k=1}^{K_i} \left( p_{i,k}-\mathbf1[y_i=k] \right)^2\]
Expected calibration error measures the discrepancy between confidence and observed correctness across confidence bins:
\[\operatorname{ECE} = \sum_{m=1}^{M} \frac{|B_m|}{N} \left| \operatorname{acc}(B_m) - \operatorname{conf}(B_m) \right|\]
The black-box Jev study evaluated calibration using ten equal-width bins and probabilities recomputed from the returned distributions rather than the API’s separate confidence field. It explicitly notes that probabilities were generally returned at two-decimal precision and that calibration estimates depend on sample selection, binning, and response rounding.
This distinction between probability and confidence is important.

Probability Is Not the Same as the Confidence Field

For a Choice question with $K>1$ candidates, the investigated Jev adapter computes its reported confidence from the maximum candidate probability as
\[c = \frac{ p_{\max}-1/K }{ 1-1/K }\]
For example, with three options and
\[p_{\max}=0.8\]
the confidence is
\[c = \frac{0.8-1/3}{1-1/3} = 0.7\]
Thus, confidence measures how far the winning probability lies above the uniform baseline. It is not an independently learned estimate of the probability that the prediction is correct. The Score type uses a different summary formula.
The conceptual separation is therefore
\[\mathbf p = \text{model predictive distribution}\]
- and
  \[c = g(\mathbf p) = \text{derived concentration summary}\]
A concentrated distribution can still be wrong. Applications that need calibrated decision thresholds should therefore reason about the underlying probabilities and validate them empirically rather than treating confidence as a second correctness predictor.

Calibration Evidence

The black-box investigation evaluated Jev on 1,200 MMLU items and a smaller set of freshly generated mathematics problems. Its reliability analysis compared the probability assigned to the selected answer against observed accuracy.
On generated three-digit multiplication problems, reported accuracy was
\[86.7\%\]
- with average top probability
  \[0.83\]
On generated two-step word problems, accuracy fell to
\[32\%\]
- while average top probability fell to
  \[0.30\]
The direction is encouraging because the model became less confident on the more difficult set. However, the study appropriately cautions that small category-level averages do not establish calibration on arbitrary unseen workloads.
It also found a counterexample. On modular exponentiation, the model was correct approximately
\[56\%\]
of the time while assigning a mean probability of only
\[35\%\]
Calibration should therefore be treated as distribution-dependent rather than as a universal scalar property of the model.

Benchmark Accuracy and Fresh Problems

The same investigation reports
\[84.6\%\]
accuracy on MMLU-Pro for the tested Jev version. Yet performance on newly generated word problems was substantially lower.
This difference illustrates an important evaluation principle. Public benchmark accuracy measures performance on one distribution:
\[P_{\text{benchmark}}(x,y)\]
- while a production workflow follows another:
  \[P_{\text{production}}(x,y)\]
Strong performance under the first does not establish equivalent performance under the second.
Freshly generated examples can reduce exact benchmark overlap, but even fresh wording does not guarantee that the underlying skill or fact was absent from training. The appropriate conclusion is therefore narrower: evaluation should combine established benchmarks with workload-specific held-out data and controlled counterfactual tests.

Contrastive Evaluation

Contrastive examples are particularly useful for Jev because they test whether the model reacts to decision-relevant changes rather than superficial prompt features.
Given an example
\[(s,y)\]
construct a minimally modified example
\[(s',y')\]
such that
\[d(s,s')\ll1\]
but
\[y'\neq y\]
A robust decision model should satisfy
\[\arg\max_k P(y=k\mid s) \neq \arg\max_k P(y=k\mid s')\]
Bespoke Nimble uses this idea both for data construction and evaluation. On its narrow 324-example synthetic holdout, the reported reference-match rates were approximately $66.36\%$ for the untuned Qwen3.5-9B base, $90.12\%$ for Bespoke-Nimble-9B, and $93.21\%$ for Jev 1.13.0. The examples consisted of 162 closely related pairs from only six source families, so the repository explicitly warns against treating the result as a broad benchmark. Bespoke Nimble.
The value of this experiment is therefore less the absolute percentage than the methodology. Small semantic interventions expose whether the decision boundary tracks the relevant fact.

Public Benchmark Breadth

Bespoke subsequently compared Nimble and Jev across thirteen public, human-labeled benchmark subsets. The accompanying release reports an aggregate result around
\[74.8\%\]
- for Nimble and
  \[76.0\%\]
  - for Jev across approximately $3{,}880$ examples, with Jev ahead on nine tasks and Nimble on four in that particular evaluation.
These results are more informative than the synthetic contrastive holdout because they broaden the evaluation distribution, but they should still be interpreted task by task. Aggregating heterogeneous benchmarks into one percentage can hide large differences in where each model succeeds or fails.
A more useful evaluation table therefore contains
\[\{\operatorname{accuracy}_d, \operatorname{NLL}_d, \operatorname{ECE}_d\}_{d=1}^{D}\]
- for each dataset $d$ rather than only
  \[\frac{1}{D} \sum_d \operatorname{accuracy}_d\]

The Latency Model

A conventional structured-generation request can be approximated as
\[T_{\text{LLM}} = T_{\text{prefill}} + \sum_{t=1}^{M} T_{\text{decode},t} + T_{\text{parse}}\]
For a Jev-like decision model,
\[T_{\text{Jev}} \approx T_{\text{state}} + T_{\text{questions}} + T_{\text{readout}}\]
The critical difference is the absence of a required autoregressive output loop.
For many questions over one state, the desired scaling becomes
\[T(N) \approx T_{\text{state}} + T_{\text{decision}}(N)\]
rather than
\[T(N) \approx N T_{\text{state}} + N T_{\text{decode}}\]
The systems question is therefore not merely whether Jev has low single-request latency. The more distinctive test is the derivative
\[\frac{\partial T}{\partial N}\]
- where $N$ is the number of decisions sharing one state.
A low value means the expensive state computation is being effectively amortized.

Controlled Evidence From Open Jev

The open Gemma implementation provides a particularly clean local experiment because it compares two inference paths on the same hardware and workload.
The reported workload used an M5 Pro with $64$ GB of memory, BF16 execution through MLX, a $202$-token context, eight options, and $242$ option tokens in total.
With the context cached once and options evaluated as a batch, median latency was
\[0.17\text{ s}\]
Re-encoding the context independently for each option required
\[0.68\text{ s}\]
The observed speedup was therefore
\[\frac{0.68}{0.17} = 4.0\times\]
This experiment does not benchmark Jev itself. It demonstrates the computational value of the shared-prefix pattern using a conventional Gemma model.
The result also illustrates why the main optimization is not simply avoiding JSON generation. Even before specialized decision heads are introduced, eliminating repeated state computation produces a substantial gain.

Shared Prefixes as a General Systems Optimization

The same principle has been studied independently in LLM serving research.
Hydragen: High-Throughput LLM Inference with Shared Prefixes by Juravsky et al. (2024) decomposes attention over shared prefixes and unique suffixes, batching queries against the common prefix to reduce redundant KV-cache memory reads; it reports up to $32\times$ throughput improvements in favorable shared-prefix workloads.
DeFT: Decoding with Flash Tree-Attention for Efficient Tree-Structured LLM Inference by Yao et al. (2024) similarly exploits shared prefixes in tree-structured inference, reducing redundant KV-cache I/O and reporting up to $2.52\times$ end-to-end speedup on its evaluated workloads.
These papers do not establish that Jev uses Hydragen or DeFT. They establish that the underlying serving pattern
\[\text{one shared prefix} + \text{many dependent branches}\]
admits substantial hardware-level optimization.

Scaling With the Number of Questions

Black-box measurements of Jev 1.13.0 suggest unusually weak latency growth as the number of questions increases.
The investigation reports that even requests containing approximately $1{,}500$ questions returned in a few hundred milliseconds in its tested environment. These timings came from the API’s x-envoy-upstream-service-time header rather than isolated accelerator measurements. Server load was uncontrolled, and the header’s queueing and execution boundaries were unknown.
Consequently, the result should be interpreted as evidence about end-to-end service behavior, not as a GPU kernel benchmark.
Still, the shape is informative. If every question independently reprocessed the complete state, one would expect roughly
\[T(N)\propto N L_s\]
- where $L_s$ is state length.
The observed behavior is more consistent with
\[T(N) = T_{\text{shared}} + f(N)\]
- where
  \[f(N)\ll N T_{\text{shared}}\]
over the tested regime.
That is precisely the scaling behavior expected from shared-state encoding plus batched question computation.

Request and Branch Limits

The black-box investigation identified two distinct context constraints in the tested Jev version.
Each state-plus-question branch appeared capped at approximately
\[32{,}768\]
tokens, while the entire request was capped at approximately
\[65{,}536\]
tokens.
This is architecturally interesting because the request-level accounting appears to count the state once.
For example, the study reports that a state of roughly $23{,}000$ tokens could coexist with thousands of questions within the request budget. If the state were physically replicated for every question, the logical token count would instead explode into tens or hundreds of millions of tokens.
The behavior is therefore consistent with a representation of the form
\[[s,q_1,q_2,\ldots,q_N]\]
- or an equivalent shared-prefix execution graph rather than
  \[[s,q_1], [s,q_2], \ldots, [s,q_N]\]
as completely independent sequences.
It does not uniquely reveal the implementation, but it is strong behavioral evidence for state sharing.

Scaling With Candidate Count

Question count and candidate count are different scaling dimensions.
Let question $j$ contain
\[K_j\]
candidates. The total number of candidate decisions is
\[M = \sum_{j=1}^{N}K_j\]
A dynamic decision head ideally performs work closer to
\[O(Md)\]
- or batched attention over those candidates rather than invoking the full semantic backbone independently $M$ times.
Candidate-count sweeps are therefore useful for distinguishing architectural possibilities.
If latency behaves approximately as
\[T(K)=a+bK\]
the fixed term $a$ suggests shared state/question computation while $bK$ captures incremental candidate scoring.
If instead
\[T(K)\approx K T(1)\]
the system may be independently evaluating candidates.
The Jev black-box study included 148 option-count latency requests specifically to probe this dimension, alongside 181 option-position and 105 fake-option requests. The authors correctly treat these measurements as behavioral evidence rather than a direct disclosure of the internal readout architecture.

Option-Position Tests

Decision models should ideally be robust to permutations of semantically equivalent candidate sets.
For permutation $\pi$, a desirable equivariance property is
\[P(y=c_k\mid s,q,C) \approx P(y=\pi(c_k)\mid s,q,\pi(C))\]
after mapping outputs back to the original candidate identities.
This is not merely a benchmark nicety. In a typed API, changing the order of enum values should not unexpectedly alter a business decision.
Option-position sweeps therefore reveal whether the model has learned positional priors such as
\[P(y=c_1)>P(y=c_K)\]
independently of semantics.
Similarly, fake-option experiments test whether adding an obviously irrelevant candidate substantially perturbs the existing distribution.
For
\[C' = C\cup\{c_{\text{irrelevant}}\}\]
one would like the relative ordering among plausible candidates to remain stable unless the new option carries relevant semantic information.
These tests are especially important for runtime-defined candidate spaces because candidate composition is itself part of the model input.

Latency Comparisons Require Care

Cross-model latency comparisons are unusually easy to misinterpret.
Bespoke’s current repository reports, on its 324-example contrastive holdout, median H100 inference latencies of approximately $58.1$ ms for the untuned Qwen3.5-9B and $106.0$ ms for one measured Nimble H100 run, while Jev 1.13.0 had a median TypeSafe API upstream time of approximately $246.7$ ms. The same repository reports much higher latency for conventional reasoning-model API calls. Bespoke Nimble.
These numbers should not be read as a hardware ranking.
The Qwen and Nimble measurements are local GPU timings. Jev is a remote service measurement. Network paths, serving overhead, batching, hardware, model size, and request accounting differ. The repository itself advises comparing models only when they were evaluated on the same examples in the same way.
The scientifically useful comparisons are therefore controlled deltas such as
\[\frac{ T_{\text{repeated-state}} }{ T_{\text{shared-state}} }\]
on the same model and hardware, or service-level comparisons where the full user-visible API latency is intentionally the quantity being measured.

Cost Scaling

TypeSafe’s launch pricing lists Jev input at
\[\$0.042\]
per million tokens and describes output tokens as free because Jev does not meter an autoregressive generated output stream. Introducing System One Models & Jev.
For an ordinary LLM API, cost is approximately
\[C_{\text{LLM}} = r_{\text{in}}L_{\text{in}} + r_{\text{out}}L_{\text{out}}\]
For Jev, the public pricing model is closer to
\[C_{\text{Jev}} = r_{\text{Jev}}L_{\text{input-accounted}}\]
The deeper systems advantage again emerges when multiple decisions share one state. If a document contains $L_s$ tokens and each question contributes $L_q$ tokens, naive independent calls consume approximately
\[N(L_s+L_q)\]
input tokens.
A shared-state request can approach
\[L_s + \sum_{j=1}^{N}L_{q_j}\]
under request accounting that counts the common state once.
For
\[L_s\gg L_q\]
the savings can approach a factor proportional to $N$.
TypeSafe’s public announcement describes Jev as substantially cheaper than conventional generative inference, but pricing is a product property rather than proof of underlying compute cost. TypeSafe explicitly notes that current pricing alone cannot establish whether the economics are subsidized.

Throughput Matters More Than Single-Request Latency

For high-volume automation, the relevant systems metric may be decisions per second rather than milliseconds per request.
Define decision throughput as
\[\Theta = \frac{ \sum_{r=1}^{R}N_r }{ T }\]
- where $N_r$ is the number of decisions returned by request $r$ during interval $T$.
A system that returns one decision in $50$ ms achieves
\[20\]
decisions per second if requests are serialized.
A system returning $100$ decisions in $200$ ms achieves
\[500\]
decisions per second despite having four times the request latency.
This distinction is central to Jev’s parallel-question design. The model is intended to increase the amount of useful structured computation obtained from each expensive state encoding.
Accordingly, a complete benchmark should report both
\[T_{\text{request}}\]
- and
  \[\Theta_{\text{decision}}\]

Amortization Curves

A particularly informative Jev benchmark is an amortization curve.
For fixed state $s$, evaluate requests containing
\[N\in\{1,2,4,8,16,32,64,\ldots\}\]
questions.
Measure
\[T(N)\]
- and compute average latency per decision:
  \[A(N) = \frac{T(N)}{N}\]
An architecture with effective state reuse should exhibit
\[A(N+1)<A(N)\]
over a meaningful range.
If
\[T(N)=a+bN\]
then
\[A(N) = \frac{a}{N}+b\]
As $N$ increases,
\[\lim_{N\to\infty}A(N)=b\]
Here $a$ corresponds roughly to fixed state processing and service overhead, while $b$ captures incremental per-decision cost.
This decomposition provides a much clearer view of Jev’s systems advantage than quoting a single latency number.

State-Length Curves

The same experiment should be repeated across state lengths
\[L_s\in \{512,1\text{K},2\text{K},4\text{K},8\text{K},16\text{K},\ldots\}\]
For a standard attention backbone, state-prefill cost increases with context length, although exact scaling depends on attention implementation and architecture.
The relevant quantity for Jev is how this expensive state cost interacts with question count:
\[T(L_s,N) = T_{\text{state}}(L_s) + T_{\text{questions}}(L_s,N)\]
If state reuse is effective, increasing $N$ should not repeatedly incur the full cost of
\[T_{\text{state}}(L_s)\]
The advantage of shared-state inference should therefore become more pronounced as
\[L_s\]
grows.
This is also why long-document extraction, moderation, policy checking, and multi-field classification are especially natural workloads for System One models.

Tail Latency

Median latency alone is insufficient for production systems.
At minimum, evaluation should report
\[p50, \qquad p95, \qquad p99\]
For automation pipelines, tail latency often determines whether a model can sit synchronously inside a request path.
A useful latency report therefore includes
\[\{ T_{p50}, T_{p95}, T_{p99}, \Theta, N, L_s, M \}\]
Without question count, state length, candidate count, hardware, concurrency, and serving environment, a latency figure is difficult to interpret.
This is particularly important for the current Jev measurements because the independent black-box study used a server-provided upstream timing header under uncontrolled service load.

Decision Stability

Because Jev is intended for software automation, repeated-decision stability also matters.
For deterministic or near-deterministic decision inference, repeated calls with identical input should ideally satisfy
\[\hat y^{(1)} = \hat y^{(2)} = \cdots = \hat y^{(R)}\]
A simple instability metric is
\[I = 1- \frac{ \max_k \sum_{r=1}^{R} \mathbf1[\hat y^{(r)}=k] }{ R }\]
Probability stability can be measured with
\[D_{\text{JS}} \left( \mathbf p^{(r)}, \bar{\mathbf p} \right)\]
- or another distributional distance.
This property matters more for decision APIs than for creative generation because identical business state should not ordinarily route to different workflows due solely to sampling noise.

Evaluation Should Match the Deployment Contract

Ultimately, Jev should not be evaluated as though it were simply another chat model.
A production evaluation suite should resemble the actual function:
\[(s,q,C) \rightarrow \mathbf p\]
That means measuring semantic correctness, calibration, counterfactual sensitivity, candidate-order robustness, abstention behavior, latency, throughput, state reuse, and scaling with both questions and candidate count.
The most informative evaluation unit is therefore not a single benchmark score. It is a surface such as
\[\mathcal E = f( \text{accuracy}, \text{NLL}, \text{ECE}, \text{coverage}, \text{risk}, \text{latency}, \text{throughput}, L_s, N, M )\]
This broader view explains why Jev’s architecture and evaluation methodology are tightly connected. If the system’s principal advantage is converting one expensive semantic understanding operation into many cheap probabilistic decisions, the benchmark must explicitly measure that amortization. Otherwise, the most distinctive property of the model disappears from the evaluation.

Open-Source Jev Recipes and Reproductions

Because TypeSafe has not published Jev’s architecture or complete RLCD training recipe, the open-source ecosystem should not be interpreted as a collection of faithful Jev replicas. Instead, these projects explore different ways to reproduce the computational properties exposed by Jev’s interface:
\[\text{state} + \text{runtime-defined decisions} \rightarrow \text{typed probability distributions}\]
- with as little autoregressive generation and repeated state computation as possible.
The implementations span a useful spectrum. SemIf asks how far an unchanged pretrained LLM can be pushed simply by consuming its logits differently. Open Jev extends this idea to multi-token option scoring and trainable heads. jevlike builds an explicit option-attention architecture. NanoJev develops a small end-to-end decision model with explicit heads and distribution learning. Kev implements shared-state parallel questions with block-causal attention. Bespoke Nimble emphasizes data curation and parameter-efficient post-training.
Together, they provide several concrete recipes for building systems that approximate different aspects of the System One model abstraction.

The Simplest Recipe: Read the Existing LLM Logits

The minimum viable Jev-like model requires no architectural modification and no additional training.
Given state $s$, question $q$, and candidates
\[C=\{c_1,\ldots,c_K\}\]
map the candidates onto single-token answer symbols such as

A
B
C

and construct a conventional prompt.
The model computes
\[h=F_\theta(s,q,C)\]
followed by vocabulary logits
\[z=W_{\text{vocab}}h\]
Instead of sampling the next token, extract only
\[z_A,z_B,z_C\]
Then compute
\[P(c_i\mid s,q,C) = \frac{\exp(z_i)} {\sum_{j=1}^{K}\exp(z_j)}\]
The pipeline becomes
\[\text{prompt} \rightarrow \text{one forward pass} \rightarrow \text{candidate logits} \rightarrow \text{softmax} \rightarrow \text{typed decision}\]
There is no generated answer.
This is the core idea explored by SemIf, formerly OpenJev. SemIf explicitly describes itself as an independent reproduction of Jev’s interface pattern rather than Jev’s undisclosed model or training system. Its implementation supports frozen open models and reads typed option probabilities directly from the model.
The importance of this baseline is conceptual: much of the semantic information needed for a bounded decision already exists before the model emits its first answer token.

SemIf: Frozen Models With Shared-State Inference

SemIf adds a second optimization when several questions share exactly the same state.
Rather than computing
\[F_\theta(s,q_1), F_\theta(s,q_2), \ldots, F_\theta(s,q_N)\]
independently, it first processes the common state:
\[\mathcal C_s = \operatorname{Prefill}(s)\]
- where $\mathcal C_s$ represents the reusable prefix state or KV cache.
Question branches then reuse that prefix:
\[z_j = F_\theta(q_j\mid\mathcal C_s)\]
The runtime shape becomes
\[T(N) \approx T_{\text{state}} + T_{\text{questions}}(N)\]
SemIf exposes a shared-state mode for workloads in which every row has the same state, prefilling that state once and evaluating criteria in parallel.
This makes SemIf a useful baseline when the research question is:
How much of Jev’s systems behavior can be recovered without training a > new model at all?
The answer appears to be: a meaningful portion of the inference pattern, but not necessarily Jev’s calibration or specialized decision capabilities.

Open Jev: Multi-Token Candidate Scoring With Gemma

Open Jev takes a related but more general approach using Gemma 3 4B and MLX.
Instead of requiring each candidate to correspond to one answer token, it permits arbitrary multi-token options.
For candidate
\[c_k=(w_{k,1},\ldots,w_{k,L_k})\]
the score is
\[S_k = \sum_{t=1}^{L_k} \log P_\theta( w_{k,t} \mid s,w_{k,<t} )\]
The implementation prefills the context once, expands the resulting KV cache across the candidate batch, and evaluates all candidate tokens in one padded forward pass.
Conceptually:
\[s \xrightarrow{\text{prefill}} \mathcal C_s\]
followed by
\[[c_1,\ldots,c_K] + \mathcal C_s \xrightarrow{\text{batched forward}} [S_1,\ldots,S_K]\]
Finally,
\[p_k = \operatorname{softmax} (S_1,\ldots,S_K)_k\]
This design is particularly useful when candidates themselves carry semantics, such as

Approve transaction

Escalate for manual review

Reject as suspected fraud

rather than arbitrary labels A, B, and C.

Open Jev’s Normalization Choices

Multi-token candidate scoring introduces length and prior-probability biases, so Open Jev exposes three normalization strategies.
Raw summed likelihood uses
\[S_k^{\text{sum}} = \sum_t \log P(w_{k,t}\mid s,w_{k,<t})\]
Mean normalization uses
\[S_k^{\text{mean}} = \frac{1}{L_k} S_k^{\text{sum}}\]
PMI-style normalization subtracts a context-independent candidate likelihood:
\[S_k^{\text{PMI}} = \log P(c_k\mid s) - \log P(c_k)\]
The repository recommends mean scoring when options differ in length, sum scoring when options are comparable in length or raw likelihood is desired, and PMI when differences in candidates’ base-rate plausibility may matter.
This illustrates an important limitation of adapting generative likelihoods into decision probabilities: the scoring rule inherits properties of language modeling that a native decision head could potentially avoid.

Open Jev’s TypeSafe-Compatible Layer

The same implementation exposes a /v1/systemone endpoint modeled after the System One interface.
It supports three decision types:
\[\texttt{choice}, \qquad \texttt{noul}, \qquad \texttt{score}\]
A Choice question scores runtime-defined option names. A noul question evaluates a binary yes/no decision. A Score question evaluates ordered level descriptions and converts their probabilities into a probability-weighted level index.
Thus, a generative Gemma backbone can be wrapped behind approximately the same programming abstraction:
\[\text{unstructured state} \rightarrow \text{typed probabilistic decisions}\]
This is useful because it separates two questions that are easy to conflate:
1. Does the System One programming interface require a fundamentally new model?
2. Does reproducing Jev’s quality, calibration, and efficiency require specialized architecture and training?
Open Jev suggests that the answer to the first is no. It does not establish the answer to the second.

Open Jev’s Trainable-Head Recipe

Open Jev also moves beyond zero-shot scoring by freezing Gemma and extracting its hidden representations.
The feature pipeline retains every state token’s final hidden state:
\[H_s = [h_1,\ldots,h_{L_s}]\]
- and computes a masked-mean representation for candidate $k$:
  \[u_k = \frac{ \sum_t m_{k,t}h_{k,t} }{ \sum_t m_{k,t} }\]
A compact cross-attention decision head then learns to match candidates against the state.
Only the head is trained.
The reported recipe uses AdamW with learning rate
\[5\times10^{-4}\]
weight decay
\[10^{-4}\]
gradient clipping at
\[1.0\]
batch size
\[64\]
- and eight epochs.
This produces a useful intermediate architecture:
\[\boxed{ \text{frozen semantic backbone} + \text{trainable decision readout} }\]
It preserves pretrained knowledge while allowing the output layer to learn a task-specific decision geometry.

jevlike: Explicit Candidate-Conditioned Attention

jevlike goes farther by making the decision architecture explicit.
Its goal is to train a small model that receives a context and a changing list of text options and returns one probability per option in a single pass.
Conceptually, the context produces token representations
\[H_s = E_\theta(s)\]
- while each candidate produces an option representation
  \[u_k = G_\phi(c_k)\]
The candidate then queries the context:
\[a_k = \operatorname{softmax} \left( \frac{ Q(u_k)K(H_s)^\top }{ \sqrt d } \right)\] \[r_k = a_kV(H_s)\]
A scoring head produces
\[z_k=f_\psi(r_k,u_k)\]
- and the option distribution is
  \[p_k = \frac{\exp(z_k)} {\sum_j\exp(z_j)}\]
This architecture removes the requirement that candidate meanings correspond to specific vocabulary tokens.
The output space is defined dynamically by
\[C=\{c_1,\ldots,c_K\}\]
That property is essential for a general System One model because different requests can introduce completely different decision vocabularies.

jevlike’s Evaluation Recipe

The repository emphasizes several evaluation practices that are broadly useful for Jev-like systems.
It reports:
- top-1 accuracy;
- top-3 accuracy;
- expected calibration error;
- shuffled-context controls.
The shuffled-context control replaces the correct state with an unrelated one while preserving the candidate menu.
If
\[f(s,C)\]
- and
  \[f(s',C)\]
perform similarly for unrelated $s$ and $s'$, the model may simply be exploiting candidate priors.
A meaningful decision model should instead exhibit
\[\operatorname{Acc}(s,C) \gg \operatorname{Acc}(s',C)\]
These controls help determine whether a dynamic candidate model is actually using the supplied state.

NanoJev: A Purpose-Built Small Decision Model

NanoJev is closer to a purpose-built System One architecture than the logit-slicing baselines.
Its public implementation uses Qwen3-0.6B as the semantic backbone and defines explicit behavior for Choice, Boolean, and Score decisions.
The architecture can be abstracted as
\[H=E_\theta(s,q,C)\]
followed by decision-type-specific readouts
\[z_k=R_{\phi,\tau}(H,c_k)\]
- where $\tau$ identifies the decision primitive.
Normalization then depends on the type:
\[P(y=c_k) = \operatorname{softmax}(\mathbf z)_k\]
- for Choice,
  \[P(y=\text{true}) = \sigma(z)\]
  - for Boolean decisions, and
    \[\mathbb E[y] = \sum_k kP(y=k)\]
    - for ordered scores.
This is closer to the architectural abstraction suggested by Jev than simply slicing a conventional LM vocabulary.

NanoJev’s End-to-End Recipe

NanoJev exposes an experimental pipeline of the form
\[\text{generate decisions} \rightarrow \text{organize splits} \rightarrow \text{train heads/backbone} \rightarrow \text{evaluate probabilities} \rightarrow \text{execute controllers}\]
It explores calibration-oriented objectives while treating broader RLCD-style experiments as research directions rather than claiming to reproduce TypeSafe’s proprietary algorithm.
This distinction is useful. NanoJev attempts to investigate the same research problem:
\[\text{How should a model learn probabilistic decisions?}\]
without claiming that its solution is Jev’s private training procedure.

Kev: Parallel Questions Inside One Transformer Pass

Kev provides one of the clearest open demonstrations of the shared-state, many-question architecture.
Kev combines a Qwen2.5-0.5B backbone with
\[\text{LoRA adapter} + \text{small decision head}\]
The document and all questions are packed into one sequence. A block-causal mask permits every question to attend to the document while preventing questions from attending to one another.
For state $s$ and questions $q_1,\ldots,q_N$, the allowed attention relation is
\[q_j\rightarrow s\]
but
\[q_j\nrightarrow q_k \qquad j\neq k\]
This gives the model a single computational batch while preserving logical independence between questions.
The architecture directly addresses the defining many-question problem:
\[s + \{q_1,\ldots,q_N\} \xrightarrow{\text{one prefill}} \{\mathbf p_1,\ldots,\mathbf p_N\}\]
No output decoding is required.

Kev’s Pointer Head

Each question contains a decision token whose representation summarizes the question in the context of the shared document.
Let that representation be
\[r_j\]
Each candidate has representation
\[u_{j,k}\]
A pointer-style head evaluates compatibility:
\[z_{j,k} = f_\phi(r_j,u_{j,k})\]
Then
\[p_{j,k} = \frac{ \exp(z_{j,k}) }{ \sum_m\exp(z_{j,m}) }\]
This provides a clean solution to dynamic candidate sets. The output dimensionality is not fixed when the model is trained. Instead, it depends on the candidates supplied at inference time.
Kev trains the head with cross-entropy against labeled outcomes, so the returned probabilities are learned through a decision objective rather than generated as serialized text.
Its training mixture contains roughly 13,000 samples spanning Banking77, BoolQ, AG News, MNLI, SST-5, and Yelp Review Full.

Bespoke Nimble: Data as the Main Lever

Bespoke Nimble explores a different hypothesis: much of the gap between a generic LLM and an effective decision model may come from post-training data rather than requiring a radically different backbone.
Nimble begins with Qwen3.5-9B and applies LoRA fine-tuning.
The central contribution is what the project calls contrastive data curation.
Given an example
\[(s,y)\]
the pipeline generates a closely related state
\[s'\]
by modifying a decision-relevant fact such that
\[y'\neq y\]
The training set therefore contains local contrasts:
\[(s,y), \qquad (s',y')\]
The model cannot succeed merely by recognizing the topic or broad vocabulary because most surface features are shared between the pair.
It must identify the semantic difference that changes the decision.

Nimble’s Training Recipe

The reported recipe uses Qwen3.5-9B with:
\[\text{LoRA rank}=16\] \[\text{learning rate}=5\times10^{-5}\] \[\text{batch size}=8\] \[\text{epochs}=1\]
- and BF16 training on an H100.
The project describes the recipe as distillation-free: Jev is used for evaluation rather than to generate the model’s training targets.
Thus,
\[\text{Jev} \not\rightarrow \text{training targets}\]
This makes Nimble especially interesting as evidence that decision-focused data can improve an ordinary pretrained backbone without reproducing Jev’s private RLCD procedure.

Nimble’s Serving Recipe

Nimble’s serving path again follows the prefill-first idea:
\[\text{context + schema} \xrightarrow{\text{prefill}} \text{KV cache}\]
followed by extraction of logits corresponding to legal answer codes.
The interface restricts the output space to decision-like fields rather than arbitrary prose. This captures the System One design philosophy:
\[\text{known answer space} \Rightarrow \text{score decisions directly}\]
If the required output is arbitrary text, the task moves back toward generation.

The Open Recipes Form an Architectural Ladder

The open projects can be organized by how much of the ordinary language-model inference stack they replace.
The first level changes only output consumption:
\[\boxed{ \text{LLM} + \text{candidate logit slicing} }\]
SemIf is the clearest example.
The second level scores complete candidates while reusing the state:
\[\boxed{ \text{LLM} + \text{prefix cache} + \text{batched continuation scoring} }\]
Open Jev demonstrates this approach.
The third level adds a learned candidate scorer:
\[\boxed{ \text{frozen backbone} + \text{semantic candidate representations} + \text{decision head} }\]
Open Jev’s trainable-head path and jevlike explore this region.
The fourth level modifies the backbone’s execution around multiple simultaneous decisions:
\[\boxed{ \text{shared backbone} + \text{question isolation} + \text{dynamic pointer/readout head} }\]
Kev is the clearest implementation of this pattern.
The fifth level trains the system explicitly as a decision model:
\[\boxed{ \text{decision backbone} + \text{typed heads} + \text{distribution-level training} }\]
NanoJev explores this direction.
Finally, Nimble demonstrates that the training-data axis is orthogonal to the architectural axis:
\[\boxed{ \text{strong pretrained model} + \text{contrastive decision data} + \text{parameter-efficient adaptation} }\]
These approaches are complementary rather than mutually exclusive.

A Practical Open Recipe

Taken together, the projects suggest a straightforward progression for building a Jev-like system.
Start with a pretrained causal LLM and establish the zero-training baseline:
\[P(y=c_k\mid s,q,C) \propto \exp(z_k)\]
Then remove repeated state computation:
\[H_s=E_\theta(s)\]
- and reuse $H_s$ or its KV cache across decisions.
If candidates are multi-token, evaluate them in a single padded batch rather than serially.
Next, replace arbitrary answer-token mappings with semantic candidate representations:
\[u_k=G_\phi(c_k)\]
Add a decision-specific readout:
\[z_k=R_\psi(H_s,q,u_k)\]
If multiple questions share one state, pack them together with an attention topology satisfying
\[q_j\rightarrow s\] \[q_j\nrightarrow q_{k\neq j}\]
Train the readout first while freezing the backbone. This provides a cheap diagnostic of whether the pretrained representation already contains the information required for the task.
Then introduce LoRA or another parameter-efficient adaptation method if the frozen features are insufficient.
For training data, construct contrastive examples in which small changes in state force different outcomes:
\[d(s,s')\text{ small}, \qquad y\neq y'\]
Train with a proper probabilistic objective such as cross-entropy or Brier score, and measure probability quality rather than accuracy alone.
Finally, evaluate with controls that distinguish semantic reasoning from shortcuts:
\[\text{ordinary test}\] \[\text{shuffled context}\] \[\text{candidate permutation}\] \[\text{irrelevant candidate insertion}\] \[\text{contrastive state edits}\] \[\text{calibration}\] \[\text{question-count scaling}\]
This progression allows each architectural intervention to justify itself empirically.

What the Open Recipes Do Not Yet Reproduce

The existence of these implementations should not obscure what remains unknown.
None establishes TypeSafe’s actual Jev architecture.
The exact pretrained backbone is undisclosed. The internal mechanism for sharing state across questions is undisclosed. The candidate representation and readout mechanism are undisclosed. The extent to which the language-model vocabulary projection survives in Jev is undisclosed. The details of RLCD are undisclosed.
Consequently,
\[\text{Jev-like behavior} \neq \text{Jev architecture}\]
The open projects instead establish a more useful engineering result: Jev’s interface exposes a computational target that can be approached through several independently viable designs.
A frozen LLM can already act as a primitive decision model. Prefix caching can eliminate repeated state work. Batched candidate scoring can eliminate serial option evaluation. Explicit decision heads can remove dependence on vocabulary tokens. Block-causal masks can support many isolated questions in one pass. Contrastive post-training can substantially improve decision boundaries. Proper probabilistic objectives can train the numerical distributions that downstream software actually consumes.
The emerging open-source recipe can therefore be summarized as
\[\boxed{ \text{reuse pretrained semantics} + \text{remove unnecessary generation} + \text{share state computation} + \text{score only legal decisions} + \text{train on decision outcomes} + \text{evaluate probabilities directly} }\]
rather than attempting to recreate a conventional LLM API more efficiently.
That is the common thread connecting the open Jev ecosystem, and it is also the broader architectural lesson of System One models: once the consumer of model intelligence is software and the action space is already known, language generation no longer needs to be the default computational interface.

References

Official Jev and System One resources

Introducing System One Models & Jev by Diogo Almeida / TypeSafe (2026)
TypeSafe documentation

Jev architecture, behavior, and independent analysis

Jev’s Architecture Unmasked by archerhume (2026)
Jev architecture: what is known and what is not by System One Models (2026)

Open-source Jev reproductions and recipes

SemIf by Theo Lee
Open Jev by Dasein Labs
jevlike by Vinny LaRouge
NanoJev by TianyuCodings
Kev by Jared Palmer; Kev model overview
Bespoke Nimble by Bespoke Labs (2026)
openjev-sglang by Eric Zhang

Jev ecosystem and implementation indexes

Shared-state and parallel decision inference

Hydragen: High-Throughput LLM Inference with Shared Prefixes by Juravsky et al. (2024)
DeFT: Decoding with Flash Tree-Attention for Efficient Tree-Structured LLM Inference by Yao et al. (2024)

Calibration and probabilistic decision outputs

On Calibration of Modern Neural Networks by Guo et al. (2017)
Strictly Proper Scoring Rules, Prediction, and Estimation by Gneiting and Raftery (2007)

Dynamic candidate decision heads

Pointer Networks by Vinyals et al. (2015)

Citation

@article{Chadha2020DistilledPhysical AI,
  title   = {Physical AI},
  author  = {Chadha, Aman and Jain, Vinija},
  journal = {Distilled AI},
  year    = {2020},
  note    = {\url{https://aman.ai}}
}

Overview

From Language Modeling to Decision Modeling

Shared State as the Central Computational Primitive

Independent Questions over Shared State

Direct Candidate Scoring

Typed Probability Distributions as the API

Calibration as a Model Objective

Why the Combination Matters

Jev’s Interface and System One Programming Model

State as Shared Semantic Context

Questions as Runtime-Specified Tasks

Choice Questions

noul Questions

Score Questions

Heterogeneous Questions in a Single Request

Parallel Questions

Question Independence and Isolation

Criteria as Semantic Labels

Probabilities as an Application Boundary

Decision Composition

Where the System One Interface Fits

Jev’s Likely Architecture: Shared-State Encoding and Decision-Native Readout

A Functional Decomposition

The Shared-State Backbone

Why KV-Cache Reuse Is the Simplest Approximation

Block-Causal Attention

Question-Conditioned Readout

Pointer-Style Decision Heads

Removing the Vocabulary Projection

The Minimal Qwen Construction

Explicit Decision Heads

Candidate Interaction and Normalization

Sparse Mixture-of-Experts as a Possible Backbone

Prefill-Only Execution

Parallel Readout as Batched Matrix Computation

A Useful Architectural Mental Model

Training Jev: From Language Modeling to Calibrated Decision Learning

Why Next-Token Training Is Not Enough

From Token Likelihood to Decision Likelihood

Length Normalization

Why Raw LLM Probabilities Can Be Misleading

Expected Calibration Error

Temperature Scaling

Frozen Backbone, Trainable Decision Head

Supervised Decision Training

Testing Whether the Head Uses the State

LoRA-Based Decision Adaptation

Kev’s Training Recipe

Contrastive Data Construction

Why Contrastive Examples Matter

From Supervised Fine-Tuning to RLCD

Proper Scoring Rules

Calibration Versus Sharpness

Calibration Under Distribution Shift

Selective Prediction

The Training Stack as a Continuum

Evaluation, Latency, and Scaling Behavior

What Should Be Measured

Probability Quality

Probability Is Not the Same as the Confidence Field

Calibration Evidence

Benchmark Accuracy and Fresh Problems

Contrastive Evaluation

Public Benchmark Breadth

The Latency Model

Controlled Evidence From Open Jev

Shared Prefixes as a General Systems Optimization

Scaling With the Number of Questions

Request and Branch Limits

Scaling With Candidate Count

Option-Position Tests

Latency Comparisons Require Care

Cost Scaling

Throughput Matters More Than Single-Request Latency

Amortization Curves

State-Length Curves

Tail Latency

Decision Stability

Evaluation Should Match the Deployment Contract

Open-Source Jev Recipes and Reproductions

`noul` Questions