Most of the machine learning tooling built since 2022 assumes the model's output is text. You prompt it, it generates, you parse what comes back. That assumption runs deep — it shapes evaluation harnesses, serving stacks, and the way people talk about what a model is.
System One models break that assumption. They return a decision: one option from a known set, a score, a ranking, together with a probability distribution you can actually branch on.
The shape of the output
Here is the whole difference, in two responses to the same input.
A language model:
The customer appears to be experiencing an authentication issue following
a credential rotation. I would suggest routing this to the technical
support team, as it likely requires...
A System One model:
{
"decision": "technical_support",
"probabilities": {
"technical_support": 0.91,
"billing": 0.06,
"general": 0.03
},
"confidence": 0.91
}
The first needs parsing, and the parse can fail. The second is already a value your code can switch on. No prompt engineering, no output schema coaxing, no retry when the model decides to be conversational today.
Why "System One"
The name comes from Kahneman's two systems. System 2 is slow, deliberate, effortful reasoning — that is what a large language model imitates when it works through a problem step by step. System 1 is fast, automatic judgement: the answer that arrives before you have finished reading the question.
Most production software needs System 1 far more often than it needs System 2. Route this ticket. Score this payment. Rank these results. Decide whether this needs a human. These are decisions that happen thousands of times a second and have to be right, cheap and fast — not eloquent.
What changes when the output is a decision
Evaluation changes. Accuracy alone is not enough. A routing model that is 94% accurate but wildly overconfident on the 6% it gets wrong is worse in production than one at 91% that knows when it is unsure. So calibration error sits beside accuracy as a first-class number, not a footnote.
Latency changes. A decision model usually sits inside a request path, not beside a chat window. Median latency in single-digit milliseconds is normal and expected. A p95 of two seconds makes the model unusable regardless of its accuracy.
The failure mode changes. A language model fails by being wrong in prose. A decision model fails by choosing an action that is not valid in the current context — routing to a queue that does not exist, selecting an option that was not offered. That is why valid action rate is a metric worth publishing.
Deployment changes. These models are small. They run on CPU. The entire economic argument for GPU-backed inference endpoints mostly does not apply.
What this means for infrastructure
General ML platforms can store a decision model perfectly well — it is a file. But storage is not the same as a workflow. The metadata that matters for a decision model is different: what primitive it implements, what action space it is constrained to, how well calibrated it is, how fast it responds.
That is the gap systemonemodels.tech exists to fill. A repository where the decision-specific facts about a model are structured fields rather than prose buried in a README, and where you can filter by capability and sort by calibration because those are the axes that decide whether a model fits.
Start with the model registry, or read the systemone.yaml specification that makes the metadata comparable across architectures.