How Jev Might Work: Understanding the Architecture Behind System One Models

TypeSafe AI recently introduced Jev, its first System One Model.

At first, Jev can look like a normal classifier. You provide some state, ask one or more questions, define the possible answers, and the model returns probabilities.

For example:

text

State:
"My card was charged twice."

Question:
Which team should handle this?

Options:
- Billing
- Technical
- Sales

A result might look like:

json

{
  "billing": 0.97,
  "technical": 0.02,
  "sales": 0.01
}

That looks simple.

But the interesting part is not the classification itself.

The interesting part is that Jev appears to combine the general language understanding of a pretrained language model with an inference architecture designed specifically for structured decisions instead of text generation.

Before going further, one important point:

TypeSafe has not published Jev's complete internal architecture.

What we currently know comes from TypeSafe's public documentation and launch material, together with black-box experiments published by Archer Hume.

So this article describes the most likely architecture based on the evidence we have, not TypeSafe's confirmed source code.

The Main Idea

A normal language model is optimized to produce strings.

Given an input $x$ , it generates an output sequence:

y = (y_1, y_2, \dots, y_T)

one token at a time:

P(y \mid x) = \prod_{t=1}^{T} P(y_t \mid x, y_{<t})

That is extremely useful when we want the model to write:

an explanation,
code,
an email,
a plan,
a summary.

But many software workflows do not need generated text.

Sometimes we only need answers such as:

text

Is this fraud?
Which queue should receive this ticket?
How severe is this incident?
Should this request be escalated?

In those cases, generating a paragraph and then parsing the answer back into software is unnecessary.

Jev changes the contract.

Instead of:

\text{Context} \rightarrow \text{Generated Text}

the model behaves more like:

\text{State} + \text{Question} + \text{Allowed Answers} \rightarrow \text{Probability Distribution}

That single change explains most of the architecture.

The Whole Architecture

The easiest way to understand Jev is to follow one request through the model.

A simplified end-to-end flow is:

Loading diagram…

The proposed Jev architecture: a shared state representation branches into independent questions before direct probability readout and calibrated application results.

The most important architectural properties are:

A pretrained language model provides the semantic knowledge.
The shared state is processed once.
Each question gets access to that state.
Questions appear isolated from one another.
The options inside a question are interpreted together.
The model reads out probabilities directly instead of generating text token by token.
Those probabilities are trained to be calibrated.
Independent question branches can be scheduled together efficiently.

Now let's break that architecture down.

The Pretrained Model Is Where the General Knowledge Comes From

Suppose Jev receives this state:

text

"My card was charged twice."

The state does not explain what a credit card is, what a charge is, or how billing departments work.

The model already understands those concepts because of pretraining.

The model parameters contain semantic relationships between ideas such as:

text

payment
credit card
duplicate charge
refund
invoice
billing
customer support

We can represent the learned parameters as:

\theta

The model is therefore making a decision approximately of the form:

P(A \mid S, Q; \theta)

where:

$S$ is the current state,
$Q$ is the question,
$A$ is the allowed answer set,
$\theta$ contains the knowledge learned during training.

This distinction is important.

The state gives the model information about the current case.

The weights give the model general language and world knowledge.

The question tells the model what property of the state we care about.

And the answer set tells it what decisions are allowed.

This is why Jev can handle new classifications without training a completely new classifier for every task.

The Request Defines the Decision at Runtime

Traditional classifiers normally have fixed classes.

For example:

x \rightarrow \{ \text{Fraud}, \text{Not Fraud} \}

Those classes are usually part of the model's training setup.

Jev is more flexible because the decision itself can be described at inference time.

For example, the same model could receive:

text

Question:
Which department should handle this?

Options:
- Billing
- Technical
- Sales

and later receive:

text

Question:
How severe is this incident?

Options:
- Low
- Medium
- High
- Critical

The model does not need a new neural network for each of these tasks.

The language model understands the meaning of the question and the meaning of the options.

So the label space becomes dynamic.

A useful abstraction is:

(S,Q,A) \rightarrow P(A \mid S,Q)

This is one reason Jev is better thought of as a general semantic decision model rather than a traditional classifier.

The Shared State Is Processed Once

This is one of the most important efficiency ideas.

Imagine that the state is a long incident report containing 20,000 tokens.

Now imagine we want to ask 30 questions about it.

A simple LLM architecture could perform:

text

State + Question 1 -> Model
State + Question 2 -> Model
State + Question 3 -> Model
...
State + Question 30 -> Model

The same 20,000-token state appears in every request.

Conceptually, the repeated state processing grows roughly like:

Q \times S

where:

$Q$ = number of questions,
$S$ = number of state tokens.

With 30 questions and 20,000 state tokens:

30 \times 20{,}000 = 600{,}000

state-token appearances are repeated across those requests.

Jev's public documentation says that it ingests the state once and evaluates every question against it in parallel.

So a more likely architecture is:

S \rightarrow H_S

where $H_S$ is the model's internal representation of the shared state.

Then:

(H_S,Q_1)

(H_S,Q_2)

(H_S,Q_3)

can all reuse that state representation.

If Jev uses a causal transformer, one natural implementation would be to reuse the KV cache produced during the shared-state prefill.

That exact implementation has not been confirmed, but it fits the observed behavior well.

Important detail

Sharing the state does not make question processing free.

Each question still has to interact with the state through attention and additional model computation.

The advantage is that the system does not need to independently reconstruct the same state representation for every question.

Loading diagram…

Shared state reuse reduces duplicated prefill work; each question still requires computation.

Questions Appear to Be Isolated

This is one of the strongest findings from black-box experiments.

Each question can access the shared state.

But sibling questions appear unable to read one another.

Conceptually:

Q_1 \leftarrow S

Q_2 \leftarrow S

Q_3 \leftarrow S

but:

Q_1 \not\leftrightarrow Q_2

This is an important difference from a conversation.

Imagine:

text

State:
The customer says their card does not work.

Question 1 contains:

text

Secret code: ZEBRA-7741
Is this a billing problem?

Question 2 asks:

text

What secret code was mentioned?

Black-box testing found that Question 2 could not reliably access information that existed only inside Question 1.

When the same information was moved into the shared state, another question could use it.

That suggests a structure where:

text

Shared State
   ├── Question 1
   ├── Question 2
   └── Question 3

rather than:

text

Question 1 -> Question 2 -> Question 3

This isolation has two advantages.

Cleaner semantics

Asking:

text

Is the customer angry?

should not accidentally change the answer to:

text

Which team should handle the ticket?

Both questions inspect the same evidence independently.

Easier parallel execution

If Question 2 does not depend on the result of Question 1, the system does not need to wait for Question 1 to finish.

The branches can be evaluated together.

Options Inside a Question Appear to Interact

Questions are isolated from each other.

But the options inside one question appear to be interpreted together.

Suppose the question is:

text

What caused the payout failure?

- Bank
- Payment provider
- Customer
- Unknown

A very simple architecture could calculate each option independently:

z_i = f(S,Q,a_i)

and then normalize the scores:

p_i = \frac{e^{z_i}} {\sum_j e^{z_j}}

If those option scores were completely independent and fixed, adding an irrelevant fifth option should change the denominator but should not change the relative odds between two existing options.

For two options $a$ and $b$ :

\frac{p(a)}{p(b)} = e^{z_a-z_b}

The normalization term disappears.

However, Archer Hume's experiments found that adding another option could change the relative odds between existing choices.

That suggests the model is doing something more like:

text

Question
   +
Complete Option Set
   ↓
Joint Decision Representation
   ↓
Probability Distribution

instead of:

text

Option A -> independent score
Option B -> independent score
Option C -> independent score

This is often described as listwise processing.

It makes sense semantically.

Consider these two option sets:

text

Payments
Account Access
Other

and:

text

Bank
Payment Processor
Customer
Unknown

Even if the question is similar, the meaning of each available choice changes depending on the alternatives around it.

So the full option set provides context for the decision.

A Decision Representation Is Built for Each Question

After combining:

the shared state,
the question,
the instructions,
and the option set,

the model needs an internal representation that captures the decision it is about to make.

We can represent that as:

h_i = g_{\theta} (H_S,Q_i,A_i)

where:

$H_S$ is the shared state representation,
$Q_i$ is question $i$ ,
$A_i$ is its option set,
$h_i$ is the final decision representation for that question.

This is conceptually similar to asking:

"Given everything I know from the state, and given this particular question and its possible answers, what internal representation best describes this decision?"

The exact location of this representation inside Jev is unknown.

It could be:

a dedicated decision token,
the final hidden state of a branch,
a pooled representation,
representations attached to each option,
or another custom mechanism.

The important point is not the exact tensor layout.

The important point is that the system appears to create a decision-specific representation before producing probabilities.

Jev Ends With a Probability Readout Instead of Text Generation

This is probably the most important difference from a normal LLM.

A standard generative model might answer:

text

"The Billing team should handle this because the user is reporting a duplicate charge."

To produce that answer, it generates one token at a time.

Jev does not need to spell out the answer.

If the model has already constructed a useful decision representation $h$ , it can map that directly to logits:

z = Wh+b

where:

$h$ is the decision representation,
$W$ is a learned projection,
$b$ is a bias term,
$z$ contains one score for each answer.

Softmax converts those scores into probabilities:

p_i = \frac{e^{z_i}} {\sum_{j=1}^{K}e^{z_j}}

A result might be:

text

Billing:   0.97
Technical: 0.02
Sales:     0.01

For a yes/no decision, the system could use a sigmoid:

P(\text{yes}) = \sigma(z) = \frac{1}{1+e^{-z}}

The exact readout implementation is not public.

It could be:

a dedicated classification head,
reserved output tokens,
a pointer-style scorer over option representations,
or another custom design.

But the important distinction is clear:

Jev returns numerical decision probabilities instead of generating text that describes a decision.

That removes the need to generate:

explanations,
JSON syntax,
labels as text,
confidence percentages as strings.

Normal application code can serialize the result afterward.

Loading diagram…

Autoregressive generation versus a proposed direct readout. The exact numerical readout is not public.

Score Outputs Can Preserve Uncertainty

Jev also supports ordered score-like decisions.

Suppose the possible levels are:

text

0 = Low
1 = Medium
2 = High

Instead of returning only:

text

High

the model can produce:

P(0),P(1),P(2)

For example:

P(0)=0.05

P(1)=0.65

P(2)=0.30

The system can calculate an expected score:

\mathbb{E}[L] = \sum_{k=0}^{K-1} kP(k)

So:

0(0.05)+1(0.65)+2(0.30) = 1.25

This preserves more information than simply returning "Medium".

The application can see that the decision is mainly Medium but still has meaningful probability mass on High.

Calibration Is Part of the Model's Purpose

Probability outputs are useful only if they are meaningful.

Suppose the model says:

text

Fraud probability = 0.80

Ideally, among many predictions around 0.80, approximately 80% should actually be fraud.

Formally:

P(Y=1 \mid \hat{p}=0.8) \approx 0.8

This property is called calibration.

TypeSafe says Jev is trained using Reinforcement Learning for Calibrated Decisions (RLCD).

The exact RLCD algorithm is not public.

So we should not claim to know its exact loss function.

But the goal is clear: the model should learn not only which answer is most likely, but also how uncertain it should be.

That creates a much more useful interface for software.

For example:

python

if p_fraud > 0.95:
    block_transaction()

elif p_fraud > 0.60:
    send_to_human_review()

else:
    continue_processing()

A generated sentence such as:

text

"I am 95% confident this is fraud."

does not automatically provide that same guarantee.

It is still text generated by a language model.

Jev is designed so that probabilities themselves are part of the model output contract.

Calibration Lets Software Own the Final Policy

This separation is important.

The neural model does not need to decide every business action.

It can provide:

P(\text{urgent} \mid S)

and the application can decide what threshold makes sense.

Suppose:

a false escalation costs $C_{FP}$ ,
missing an urgent case costs $C_{FN}$ .

The application could escalate when:

(1-p)C_{FP} < pC_{FN}

which gives:

p > \frac{C_{FP}} {C_{FP}+C_{FN}}

If:

C_{FP}=1

and:

C_{FN}=9

then:

p > 0.1

So the application might decide that even a 10% urgent probability is enough to involve a human.

This is a useful architectural separation:

text

Model:
Estimate uncertain semantic facts.

Code:
Apply business policy.

The Serving Layer Can Batch Independent Question Branches

There is another important layer that is easy to miss: serving.

Even if the neural network architecture supports independent question branches, performance still depends on how those branches are scheduled on hardware.

Because the questions do not depend on one another, the system can treat them as a batch.

Conceptually:

python

shared_state = model.prefill(state)

question_batch = [
    question_1,
    question_2,
    question_3,
    question_4,
]

results = model.evaluate_branches(
    shared_state,
    question_batch,
)

This is different from a conversation:

python

a1 = model(q1)
a2 = model(q2, a1)
a3 = model(q3, a2)

The second design has a dependency chain.

The first design has independent work that can be scheduled together.

TypeSafe's documentation says Jev evaluates every question against the state in parallel, and black-box timing experiments are consistent with a serving system that batches those branches.

This is likely a major part of the speed advantage.

Context Limits Give Us More Architectural Clues

TypeSafe currently documents two relevant context limits for Jev:

64k tokens for the whole request
32k tokens for the state plus the longest individual question

This is interesting.

The total request budget contains the state once, even when there are many questions.

That behavior strongly supports the idea that the request is internally structured more like:

text

STATE
  ├── QUESTION 1
  ├── QUESTION 2
  ├── QUESTION 3
  ├── QUESTION 4
  └── ...

rather than:

text

STATE + QUESTION 1
STATE + QUESTION 2
STATE + QUESTION 3
STATE + QUESTION 4

It does not reveal the exact attention implementation, but it gives us another clue that the state is shared across branches.

Is the Backbone a Causal Transformer?

Probably.

But this is not confirmed.

A causal transformer is a reasonable hypothesis because:

Jev appears to inherit broad language-model knowledge.
TypeSafe describes RLCD as training/post-training for decision models.
Causal transformers naturally support shared-prefix KV caching.
Existing frontier language models commonly use decoder-style transformer architectures.

A normal causal LLM works roughly like:

text

Prompt
  ↓
Prefill
  ↓
Context Representation / KV Cache
  ↓
Token-by-token Decode

A Jev-like causal architecture could instead do:

text

State
  ↓
Prefill
  ↓
Shared Context
  ↓
Question Branch
  ↓
Decision Readout

The key change is that it stops before normal autoregressive decoding.

However, black-box behavior alone cannot prove that Jev uses a causal decoder.

A bidirectional encoder or another architecture could reproduce some of the same external behavior.

So this should remain an inference, not a fact.

Does Jev Use Mixture of Experts?

This is even more speculative.

Archer Hume suggests that a sparse Mixture-of-Experts (MoE) backbone could help explain Jev's throughput.

In an MoE layer, only a subset of the model's experts are activated for a token.

Conceptually:

r = \text{Router}(h)

and:

h' = \sum_{e \in \mathcal{E}(h)} g_e(h)E_e(h)

where $\mathcal{E}(h)$ is the selected expert set.

This can allow a model to have high total capacity without activating every parameter for every token.

But there is currently no strong public evidence proving Jev uses MoE.

Its speed could also come from:

a smaller dense model,
distillation,
quantization,
custom kernels,
specialized hardware,
serving optimizations,
or a combination of techniques.

So:

MoE is an interesting hypothesis, not part of the architecture we can confidently claim.

A Concrete Example From End to End

Let's put the architecture together with one example.

Suppose an enterprise support system receives:

json

{
  "customer": "ACME Corp",
  "plan": "Enterprise",
  "message": "Our payout failed three times. The bank says everything is fine.",
  "failed_attempts": 3,
  "account_status": "active"
}

We ask three questions.

Question 1

text

Which team should handle this?

Options:
- Payments
- Account
- Technical
- Other

Question 2

text

Does this require urgent human attention?

Options:
- Yes
- No

Question 3

text

How frustrated does the customer appear?

Options:
- Calm
- Frustrated
- Very frustrated

The architecture can be represented mathematically as:

Shared state

H_S = f_{\theta}(S)

Question branches

h_1 = g_{\theta}(H_S,Q_1,A_1)

h_2 = g_{\theta}(H_S,Q_2,A_2)

h_3 = g_{\theta}(H_S,Q_3,A_3)

Probability outputs

p_1 = r(h_1)

p_2 = r(h_2)

p_3 = r(h_3)

A hypothetical result might be:

json

{
  "queue": {
    "payments": 0.91,
    "account": 0.03,
    "technical": 0.05,
    "other": 0.01
  },
  "urgent": {
    "yes": 0.42,
    "no": 0.58
  },
  "frustration": {
    "calm": 0.04,
    "frustrated": 0.74,
    "very_frustrated": 0.22
  }
}

The application can then decide:

python

if result["queue"]["payments"] > 0.8:
    route_to("payments")

if result["urgent"]["yes"] > 0.7:
    request_human_review()

Notice the separation.

The model handles semantic uncertainty.

The application handles business policy.

Jev Is Not Simply a Faster Chat Model

This is an important distinction.

Jev gives up the ability to freely generate arbitrary strings.

That means it is not the ideal tool when we need:

text

Write an email.
Explain this bug.
Generate code.
Create a plan.
Summarize these documents.

But that tradeoff gives it advantages for structured automation:

text

Classify this.
Route this.
Score this.
Judge this.
Detect this.
Should we escalate this?
Which option best applies?

So Jev and generative LLMs can complement each other.

A useful architecture could be:

python

decision = jev.evaluate(state)

if decision.confidence > 0.90:
    execute_workflow(decision)

else:
    analysis = reasoning_llm.analyze(state)
    send_to_human(analysis)

The decision model handles fast, well-defined semantic judgments.

The reasoning model handles open-ended cases.

A Useful Three-Layer Mental Model

For production AI systems, I think Jev points toward a useful separation.

Layer 1: Deterministic code

Use normal software for things that should be exact:

python

amount > 10_000
status == "ACTIVE"
days_overdue >= 30
currency == "USD"

Layer 2: Semantic decision model

Use Jev-like models for fuzzy questions:

text

Does this look fraudulent?
Which queue best matches this issue?
How severe is the complaint?
Does this document satisfy the requirement?

Layer 3: Generative or reasoning model

Use a normal LLM when the system needs:

text

planning,
explanations,
generation,
multi-step synthesis,
code,
open-ended reasoning.

That gives us:

text

Exact rules     -> Code
Fuzzy decisions -> Jev
Open reasoning  -> LLM

This is often a cleaner architecture than asking one large generative model to do everything.

What We Know vs What We Are Inferring

This is the most important table to keep in mind.

Architectural claim	Confidence
Jev accepts shared state plus multiple structured questions	Confirmed
Jev returns structured values with probabilities	Confirmed
All outputs are produced without normal token-by-token text generation	Confirmed by TypeSafe
The state is ingested once for multiple questions	Confirmed by TypeSafe
Questions appear isolated from sibling questions	Strong black-box evidence
Options inside one question influence the joint decision	Strong black-box evidence
Independent questions are scheduled together efficiently	Strong evidence / consistent with observed timing
A shared KV cache is used internally	Plausible inference
The backbone is a causal transformer	Plausible inference
A dedicated classification head is used	Unknown
A pointer-style option scorer is used	Unknown
Jev uses sparse MoE	Speculative
The exact RLCD training objective is known	No

That distinction is important because Jev is still proprietary.

We can reconstruct the shape of the system from its behavior, but not every internal implementation detail.

Final Mental Model

The simplest way to think about Jev is this:

A pretrained language model already contains a rich understanding of language and concepts. Jev appears to reuse that intelligence, process shared evidence once, branch into independent structured questions, consider each question's answer set, and directly expose probability distributions instead of spending time generating text.

In compact form:

\boxed{ \text{Pretrained Language Intelligence} \rightarrow \text{Shared State} \rightarrow \text{Parallel Question Branches} \rightarrow \text{Joint Option Reasoning} \rightarrow \text{Direct Probability Readout} \rightarrow \text{Calibrated Decisions} }

That is why I do not think the most interesting part of Jev is simply that it is "a classifier."

The interesting idea is changing the interface between foundation models and software.

Instead of asking:

text

Please think about this problem and write the answer.

we can ask:

text

Here is the state.
Here is the decision.
Here are the allowed outcomes.

Give me the probability of each one.

For many automation workloads, that may be exactly the abstraction we need.

References

Archer Hume, "Jev's Architecture Unmasked", September 17, 2026
https://archerhume.com/posts/jevs-architecture-unmasked/?v=3
TypeSafe AI, "Introducing System One Models & Jev", September 15, 2026
https://typesafe.ai/blog/introducing-system-one-models-and-jev
TypeSafe AI, Jev Models Documentation
https://docs.typesafe.ai/models
TypeSafe AI, Machine Learning Primer, including RLCD
https://docs.typesafe.ai/introduction/machine-learning-primer
Ashish Vaswani et al., "Attention Is All You Need", 2017
https://arxiv.org/abs/1706.03762
Jordan Juravsky et al., "Hydragen: High-Throughput LLM Inference with Shared Prefixes", 2024
https://arxiv.org/abs/2402.05099
Jinwei Yao et al., "DeFT: Decoding with Flash Tree-Attention for Efficient Tree-structured LLM Inference", 2024
https://arxiv.org/abs/2404.00242
Chuan Guo et al., "On Calibration of Modern Neural Networks", 2017
https://arxiv.org/abs/1706.04599

Note

This article describes a reconstructed architecture, not TypeSafe's confirmed internal implementation.

The architecture is based mainly on TypeSafe's public documentation and Archer Hume's black-box investigation of Jev. Components such as a causal transformer backbone, KV-cache reuse, the exact readout mechanism, and MoE remain hypotheses unless TypeSafe publishes additional technical details.

How Jev Might Work: Understanding the Architecture Behind System One Models

The Main Idea

The Whole Architecture

The Pretrained Model Is Where the General Knowledge Comes From

The Request Defines the Decision at Runtime

The Shared State Is Processed Once

Important detail

Questions Appear to Be Isolated

Cleaner semantics

Easier parallel execution

Options Inside a Question Appear to Interact

A Decision Representation Is Built for Each Question

Jev Ends With a Probability Readout Instead of Text Generation

Score Outputs Can Preserve Uncertainty

Calibration Is Part of the Model's Purpose

Calibration Lets Software Own the Final Policy

The Serving Layer Can Batch Independent Question Branches

Context Limits Give Us More Architectural Clues

Is the Backbone a Causal Transformer?

Does Jev Use Mixture of Experts?

A Concrete Example From End to End

Question 1

Question 2

Question 3

Shared state

Question branches

Probability outputs

Jev Is Not Simply a Faster Chat Model

A Useful Three-Layer Mental Model

Layer 1: Deterministic code

Layer 2: Semantic decision model

Layer 3: Generative or reasoning model

What We Know vs What We Are Inferring

Final Mental Model

References

Note

Related articles

Building a High-Quality Medical Pretraining Dataset for Small Language Models

Building MedSLM: A 330M Parameter Medical Language Model

Curating a Medical SFT Dataset: From Raw QA Pairs to Instruction-Ready Data