System One models explained: typed decisions instead of text

01

What is a System One model?

A model that answers for software rather than for people. It receives a state and a question and returns a typed value with a probability that the calling code can use directly.

A language model builds its answer word by word and returns text that the calling software then has to take apart again. For a conversation that is the right shape. For an assignment, an approval or a score it is a detour: the code never wanted a sentence, it wanted a class or a number.

A System One model skips the detour. It takes a structured state, meaning text, a JSON object or a list of passages, and answers one or more questions fixed in advance. What comes back is not text but the value itself, together with the probability the model attaches to it.

The middle position is the actual point. A trained classifier is faster and cheaper but needs a new training run and labelled data for every new question. A language model answers any question immediately but costs latency, money and a parser. A System One model sits between the two: new questions without training, typed answers without a parser.

02

Which questions can such a model answer?

Three types: a yes/no question with a probability, a choice from a fixed option set, and a position on a scale. There are no others, and the narrowness is the purpose.

The interface is three primitives. They cover a surprising amount of ground, because most steps in a pipeline reduce to one of the three once you state them one at a time.

The most useful lever in practice is decomposition. Instead of asking whether an invoice is in order, ask four independent questions: does the line match the order, is the price within the agreed range, is the vendor known, does delivery evidence exist. Four separate probabilities can be traced and tuned individually; one combined judgment cannot.

State:      the case as text or JSON
Question 1: choice  -> category from a fixed set
Question 2: scale   -> urgency, level 1 to 5
Question 3: yes/no  -> carries every required detail
Question 4: yes/no  -> needs human review

Returns:    four values, four probabilities, one pass

Because the output is small and every answer returns in one pass, it is cheaper to ask every plausibly needed question at once, including the ones whose answer may go unused. The second network round trip costs more than the extra question.

03

What does a calibrated probability mean?

It is a statement about a distribution, not about the single case. If the model says 0.8 across many cases, roughly eight in ten of those are right. About the case in front of you it says nothing.

When a language model states a confidence of 0.9, it writes the characters 0.9. That is a phrasing, not a measurement. A calibrated probability is anchored in frequency instead: across a large number of cases, the share of correct answers should match the stated value.

Two things follow. First, the threshold at which a case runs automatically or goes to a person is a decision about acceptable error and belongs in a document, not in a constant in a source file. Second, calibration has to be measured on your own data. A model calibrated on someone else's tasks is not automatically calibrated on one company's invoice pile.

04

Where does a decision layer sit in an AI pipeline?

Wherever there is a model call today whose result was going to be a JSON object anyway: intake classification, retrieval gating, tool selection, verification of extracted fields, and guardrails.

The ordering matters more than any single station. The decision layer supplies judgments, the code owns the consequences. Option set, threshold, permissions and fallback stay in ordinary code that can be reviewed and versioned. Where a project drops that split and lets the model decide what it is allowed to do, the failure case stops being manageable.

• Intake classification: what arrived, and does it need a person?
• Retrieval gating: does this passage support the answer, contradict it, or carry an injected instruction?
• Tool and route selection: which of the available paths fits, and how confidently?
• Extraction verification: does this value look complete and plausible against the source?
• Guardrails: does this request or this output break a rule?

For retrieval systems, gating is the single most effective step. The expensive failure is not the missing passage but the irrelevant one that gets processed into a confident wrong answer. Why that shapes answer quality more than model size is covered under Retrieval-Augmented Generation.

05

What does one decision cost, and how fast is it?

Published figures are 0.042 US dollars per million input tokens with output free, and 70 to 500 milliseconds of latency. The comparison multiples against language models are the vendor's own.

The first public implementation of this model class is Jev from TypeSafe AI, released on 15 September 2026 after a 40 million US dollar seed round. The figures below come from the announcement and from the documentation of the platforms that serve the model.

The order of magnitude changes behaviour more than it changes the budget. When a check costs almost nothing, you stop rationing: every retrieved passage is scored rather than a sample, every extracted field verified rather than a subset, every request held against the rule rather than only the flagged ones. That is exactly the pattern the first model is named after, a reference to the Jevons paradox.

06

Where are the limits?

No rationale, no world knowledge, text input only, and a calibration that holds only across many cases. For anything that has to be written, explained or researched, this model class is the wrong choice.

There are technical limits on top. State and questions share a budget of roughly 64,000 tokens. A choice carries up to 255 options, a scale 2 to 10 levels. It is text only: no image, no audio, no video. Anyone who wants a scene or a machine state judged has to translate it into a description first, and that translation is the actual engineering work.

How durable the advantage is remains open. The technical objection is that much of the speed may come from constrained decoding against a fixed option set rather than a new architecture. If that holds, the approach is reproducible. For the architectural decision it does not matter: separating decision from language pays off regardless of who supplies the model.

07

How do you start?

Pick one existing classification call, replay a month of production traffic through it, and read the disagreements. Not the aggregate score, but the cases where old and new contradict each other.

1. Pick the candidate

   A step in the running system whose result is a class, a number or a yes/no anyway. Usually intake classification or retrieval gating.

2. Decompose the question

   Turn one wide question into several narrow ones, each with its own answer. Anything that does not fit a choice, a scale or a yes/no does not belong in this layer.

3. Replay against production

   Run a month of real calls through it again and compare accuracy and upper-percentile latency.

4. Read the disagreements

   Only where old and new contradict each other does it show whether the task was ever a language task.

5. Fix threshold and record

   At what probability the system decides on its own, who owns that, and what gets logged per decision.

The bigger gain is rarely the saved inference. Most pipelines have thin observability, because evaluating each step costs another model call and nobody budgets for it. When that evaluation drops to a rounding error, every step of every run can be scored and drift becomes visible before a user reports it.