Decision models: what Jev, Solar Decide and Span-01 mean for enterprise workflows

On 15 September 2026, TypeSafe AI came out of two years in stealth with Jev, the first of what it calls System One models: "a new class of frontier models built to make fast, structured decisions that software can use directly." On 24 September, Respan announced Span-01, a classifier that scores behaviours in agent traces. On 28 September OpenRouter listed Upstage's Solar Decide, which Digital Applied reports had gone into beta on Upstage's own console on 22 September. Three vendors in two weeks, all shipping the same idea: a model that does not write.

That last part is the whole story. You send one of these models a piece of state, such as a support ticket, a contract clause or an agent transcript, plus a list of typed questions. It sends back a probability for each possible answer and nothing else. No prose, no explanation, no reply to parse.

What a decision model actually returns#

TypeSafe's documentation defines three primitives. A choice picks from options you define, such as billing, technical or account. A score places the input on a scale you describe, such as 0 for calm, 1 for frustrated and 2 for very frustrated. A noul returns the probability that a proposition is true: does this message request a refund? OpenRouter's explainer, written from real calls against Jev 1.13, adds the detail that matters for code. A choice always comes back with the selected option, a probability for every option, and a confidence value.

TypeSafe's own one-line summary is the clearest description I have seen of where this sits: "Think of Jev as a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out."

Span-01 is the same shape pointed at a narrower job. You write a behaviour in plain language, such as user frustration or unreliable tool use, and it returns "direct present, absent, and not_observable probabilities" for each one in a single forward pass. Solar Decide is Upstage's version, built on Solar Mini 4. Its OpenRouter listing describes it returning "a choice, a score, or a yes/no answer, each with a calibrated probability taken directly from the model rather than written out as text."

The prices follow from there being almost nothing to generate. Jev is $0.042 per million input tokens with output free, per TypeSafe. Span-01 is $0.02 per million input tokens, and Span-01 Lite is free, per Respan. Solar Decide is $0.05 per million input tokens on OpenRouter against $0.10 listed by Upstage.

What System One is, and what it is not#

I went looking for a specification, because "System One endpoint" appears in Upstage's listing as though it names a standard. It does not. System One is TypeSafe's name for the model class, borrowed from Daniel Kahneman's Thinking, Fast and Slow, and for its API, which TypeSafe's docs expose as POST /v1/systemone.

What has happened in two weeks is adoption. OpenRouter serves Jev through a Decisions API at /api/alpha/decisions, and its SDK reference describes these as "System One endpoints for models such as Jev, compatible with the TypeSafe SDKs." Upstage's listing says Solar Decide "uses the same /v1/systemone schema as Jev." So one startup's request shape has been picked up by a router and by an established model maker inside a fortnight.

That is how de facto standards start. It is not the same thing as a standard, and nothing governs it yet. If you build on it today, you are building on TypeSafe's API design choices, with a second implementation for leverage. The word "alpha" in OpenRouter's path is the honest status of the whole category.

Respan's announcement does not say whether Span-01 uses that schema, so I would not assume it does.

Why a typed decision beats prose inside a workflow#

Most of the AI I would actually put inside an enterprise system is not a chatbot. It is a decision buried in a workflow. Which queue does this ticket go to? Does this request fall under the refund policy? Does this clause need a lawyer? Did the agent just try something outside its brief?

The common way to get those decisions from a model today is to ask an LLM for JSON and validate what comes back. That works until it does not, and when it fails the failure is either a parsing error in the middle of the night or, worse, a perfectly well-formed wrong answer.

A typed decision improves three things at once.

Routing becomes a threshold, not a parser. A probability is something ordinary code can branch on. There is no validation layer checking whether the model invented a fourth queue.

Audit becomes a row, not a transcript. A stored record of the question, the probability and the pinned model version is a fact you can count and query. A paragraph of model reasoning is an artefact someone has to read.

Cost changes category. When a decision costs a fraction of a cent, you can ask five narrow questions instead of one broad one. That is TypeSafe's own advice: many independent, decomposed questions, combined with deterministic checks in code.

It is the same instinct behind no source, no claim. In high-stakes work, the interface should make the uncertain case visible rather than smoothing it into confident prose.

"Can't hallucinate" is a claim about the type, not the answer#

TypeSafe's launch post says Jev "can't hallucinate", and I expect that line to be quoted more widely than it deserves. Read the post carefully and the claim is narrower. The possible outputs are "defined in advance", so the model "never makes type errors". That is true by construction. A choice between three queues cannot return a fourth.

It can still return the wrong one of the three, confidently. TypeSafe's documentation says so in what I think is the most important sentence on its site: "Calibration is measured across groups of predictions; it does not guarantee that an individual answer is correct."

OpenRouter's explainer makes the same point about the confidence number: "Confidence is a measure of how torn Jev is between options, but whether those options are well chosen is up to you." If your categories overlap, or the right answer is not among them, a decision model will still pick one, in a perfectly typed format.

What I would demand before putting one in production#

Calibration on your data, not theirs. Calibrated is a statistical property of a population of predictions, and the population that matters is your tickets. Label a few hundred real cases, bucket the model's probabilities, and check whether the cases scored around 0.8 are right about 80% of the time. As OpenRouter puts it, "the right cutoff for you depends on how expensive your mistakes are," and only you know that price.

The lineage of every benchmark. Every number in this category so far is vendor-run. TypeSafe scores its workflow evaluations against the average of GPT-6 Astra and Fable 5.1, built them with its own capabilities team, and says plainly that "some bias could exist." Respan ranked eleven decision models, with Jev 1.13.0 first at 0.932 accuracy, but the judge was Span-01 itself. Digital Applied notes that Upstage published no benchmark at all. I give TypeSafe and Respan real credit for printing the caveats next to the claims. They are still caveats.

The size of the ceiling. Respan's production behaviour table is the most useful chart of the month. Span-01 scores 0.806 F1 overall against 0.716 for Jev and 0.719 for Sonnet 5, while GPT-6 Sol scores 0.885 and leads Span-01 in six of the seven behaviour domains. In Respan's own words, "a full frontier model remains the strongest ceiling." The trade is speed and cost for some accuracy, and you need to know how big that trade is on your task before you take it.

A pinned version. OpenRouter's examples resolve typesafe/jev-1.13 to a dated snapshot, jev-1.13-20260917, while TypeSafe's docs default to the alias jev-latest. A threshold tuned on one snapshot is not valid for the next. Pin the version and rerun the calibration set whenever you move.

Where the state goes. TypeSafe says its service is currently based on the US West Coast. Solar Decide's listing sells its 512K context on the basis that "an entire document can serve as the state." That is a whole document leaving your network for every decision. For regulated data in Saudi Arabia this is the same residency question as any hosted model, and it is worth remembering that local hosting does not by itself guarantee PDPL compliance either. The hybrid local and cloud trade-offs apply here unchanged.

Honest economics. TypeSafe writes that "We can't prove it isn't subsidized." Design as though the price could move, and keep the fallback path to a general model working.

Where decision models fit, and where they do not#

The good fits share a shape: a small, known answer space and a real cost to being slow. Ticket triage and routing. Intent classification. Policy and compliance flags. Approval gates on agent actions. Guardrails and monitoring over agent traces, which is precisely Respan's pitch.

The poor fits are anything where the answer space is not known in advance, or where the explanation is the deliverable. A decision model can tell you a clause probably needs review. It cannot tell you why, and in legal work the why is the product.

The pattern I find most convincing is the one both TypeSafe and Respan point towards: decision models as a fast first layer, with a reasoning model or a person behind the uncertain band. That is how production agents should be built anyway. The model handles the volume. The escalation path carries the judgement.

What to watch next#

Three things. Whether a third, independent implementation of the /v1/systemone schema appears outside TypeSafe and Upstage, which would start to turn a vendor format into something closer to a standard. Whether anyone publishes calibration results for these models on a public, third-party dataset rather than a vendor's own. And whether OpenRouter's Decisions API leaves alpha, because until it does, anything built on it is built on a preview.