← The reading table What changes when a model returns a decision instead of a sentence
A typed output guarantees the shape of an answer, not its content. A decision model moves the question of what a system may decide on its own; it does not answer it.
A decision model returns a typed choice instead of a paragraph, which removes a whole class of parsing failure and none of the judgement. The schema guarantees you get one of the answers you allowed. It cannot guarantee the right one. What you may stop writing is the parser. What you still have to write is the rule about which choices the system is allowed to make alone.
TypeSafe AI announced a model called Jev in a post dated 12 October 2026. In its own FAQ, the question about how it performs on public benchmarks sits there without an answer under it.
Read the rest of the claims with that in mind.
What is a decision model?
A decision model takes a situation and returns a value you defined in advance, rather than text you have to interpret. You give it the state and the question; it gives back a choice from your list, a score, or a probability, already in the shape your code expects.
TypeSafe calls this class System One Models and describes them as "a new class of frontier models built to make fast, structured decisions that software can use directly". Its own shorthand for Jev is "unstructured state in, typed probabilistic decisions out".
Put plainly: a language model writes you a sentence and your code has to work out what it meant. A decision model hands your code the answer in a form it can use without translating.
Does a typed output mean it cannot be wrong?
No. It means it cannot be malformed, which is a different and much smaller promise.
If you allow three answers and the model must return one of them, you will always get one of three. That removes the failure where a model replies "I would probably route this to refunds, though it depends" and your code, expecting the word "refunds", gets a sentence and falls over. Anyone who has shipped a system that parses model output has had a week ruined by exactly that.
What it does not remove is the model picking the wrong one of the three. The schema constrains the shape of the answer. The content is still a judgement, made at speed, by a model.
TypeSafe states that type errors are "mathematically impossible" for its models and that Jev "can't hallucinate". The first is a claim about structure and is the sort of thing a type system can actually guarantee. The second reads as a claim about structure too, and it is worth being clear with yourself about which one you are buying. A system that must answer "approve" or "decline" cannot invent a third option. It can still say approve when the honest answer was decline.
What should you believe about the numbers?
Read them as the vendor's, because that is what they are, and that is normal for a launch.
The published figures are 70 to 500 milliseconds end to end, and $0.042 per million input tokens with output tokens free. The comparison claims run from 40 to 200 times faster on what TypeSafe calls System One style queries, with larger numbers quoted elsewhere on its site. The evaluations are the company's own, run on four workflows, and the reference answers they are scored against are an average of two other frontier models. The post says the speed tests were run from the team's own laptops, and it acknowledges the evaluations carry bias.
None of that makes the numbers wrong. It makes them unreplicated. The useful posture is the one you would take with any vendor benchmark: the direction is probably real, the magnitude is the part to test on your own traffic, and the only number that matters to you is the one you measure on the job you actually have.
Where would you put one?
In the places where your system currently asks a language model a question whose answer was always going to be a short, fixed thing.
Routing a message to the right queue. Deciding whether a reply needs a person. Scoring a lead. Checking whether an incoming message looks like an attempt to talk the system out of its instructions. Those are branches. They were only ever text because that is what was available, and the sentence the model wrote around the answer was waste you paid for and then parsed away.
Where it fits badly is anywhere the output is meant to be read by a human. A support reply, or a summary someone acts on. Those want prose, and a model built to stop producing prose is the wrong tool.
The honest version of the pitch is narrower than it first sounds, and better for being narrow. It replaces the hidden model calls behind your customer-facing system, the ones that were never meant to talk at all.
What still has to be written down?
The same thing as before: which decisions the system makes on its own, and which it hands to a person.
OWASP ranks this sixth in its 2025 Top 10 for LLM Applications, under Excessive Agency: systems given more autonomy, more permissions or more tools than the task needs. Nothing about a typed output touches that. A model that returns "issue_refund" with a confidence score of 0.91, in 80 milliseconds, has still issued a refund if you wired it to.
If anything the speed makes the rule more urgent. A slow system gives you a natural place to put a person. A system that decides in under a tenth of a second will do the wrong thing several thousand times before anyone opens the dashboard, which is the argument for writing the list of what it may do without asking before you connect it to anything, rather than after. That is the same list every agent needs, and it does not get shorter because the output is typed.
Two questions are worth answering before this goes anywhere near a customer. What does the system do when the confidence is low, and who sees it. And what happens on the day the model is confidently wrong, which is the day an audit is for.
What a decision model moves is the boundary, from parsing to trust. The parser was tedious and visible. Trust is neither.