Decision models: when the answer is a probability

A support ticket arrives: “I was charged twice this month.” The application does not need an essay about billing. It needs a destination, an indication of uncertainty and a rule for what happens next.

Much of production software has this shape. A message needs a category. A workflow needs a branch. An agent’s proposed action needs a check. Language helps interpret the input, but the output often belongs in ordinary control flow.

TypeSafe AI’s Jev, introduced on 15 September 2026, takes that observation as its starting point. The company calls it a System One Model: a model built to return typed probabilistic decisions rather than prose. Five days after the launch, it is too early for a settled verdict on the product. The interface is already worth examining.

Start with the decision the software needs

In TypeSafe’s API design, a request contains the current state and one or more typed questions. The result belongs to a declared shape, so the application can branch on it directly. Questions in the same call are evaluated independently against the shared state.

The three primitives cover different kinds of judgement.

The design encourages narrow questions. Instead of asking whether a request should be handled automatically, ask what it concerns, whether information is missing and whether it needs specialist attention. Then make the combination explicit in code.

That is the architectural attraction for me. The judgement remains learned; the structure of the workflow becomes something a team can read, test and change.

A valid shape is only the first guarantee

It would be misleading to describe this as the first way to obtain dependable JSON from a model. Modern structured-output systems can constrain generation to a supported schema during decoding. OpenAI’s Structured Outputs is one example. The alternative is no longer simply free-form text followed by a fragile parser.

TypeSafe’s distinction is its decision-oriented model and interface: fixed output types, probability distributions and a design focused on short judgements. Whether that produces better accuracy, latency or cost on a particular workload is an empirical question.

The company’s schema guarantee also needs a precise reading. Returning one of billing, technical or sales prevents an undeclared fourth category. It does not prevent a technical question from being routed to billing. A well-formed answer can still be the wrong answer.

That is a useful boundary, not a reason to dismiss the idea. Software can handle a known kind of mistake more deliberately than an unexpected output format. It still needs a way to detect uncertainty and measure errors.

Probability and confidence are different signals

Suppose a model estimates P(refund_requested) = 0.03. That is a strong answer of “probably not”, not a statement that the model has almost no confidence in its answer. Around 0.5, the same binary question is much less settled.

Choice and Score expose a different signal. Their confidence field summarises how concentrated the returned distribution is. TypeSafe’s confidence documentation describes it as a statistic derived from that distribution. It should not automatically be read as the probability that the chosen answer is correct.

For a ticket router, confidence might determine whether to route immediately, gather more information or ask a person. For a binary risk question, a high probability might instead mean stop. The direction of the action comes from the meaning of the question.

The numbers need testing on representative data. An application’s tolerance for a wrong queue is different from its tolerance for an incorrect account action. Even a very confident answer must remain subject to access controls and any required approval.

Calibration has to survive your data

Calibration is a relationship between predictions and observed outcomes. Among comparable cases assigned a probability near 0.8, the event should occur roughly eight times out of ten. A single answer cannot demonstrate that relationship.

For my own evaluation, I would start with labelled examples from the intended workflow, separate the data used to set thresholds from the data used to assess them, and inspect the errors in each important slice. A good overall number can hide a weak result for one language, one customer group or one unfamiliar request type.

I would also measure the operating trade-off: how many cases the system handles automatically, how many it sends to review and how many errors remain at that setting. Sending everything to a person can look safe while defeating the purpose of the automation.

This is close to the discipline behind the QANTIS research: specify the reference, the conditions and the boundary of the result. “Calibrated” is most useful when followed by a dataset, a method and an account of where the claim stops holding.

Let code own the branch

A small example makes the separation easier to see. The following is illustrative application logic, not a TypeSafe SDK example. Its input is a validated Choice result, and its confidence thresholds are the same ones used in the diagram.

def route_ticket(ticket, decision, policy):
    if decision.confidence < 0.70:
        return send_to_reviewer(ticket)

    if decision.confidence < 0.98:
        return request_more_context(ticket)

    if not policy.allows_route(ticket, decision.choice):
        return send_to_reviewer(ticket)

    return assign_queue(ticket, decision.choice)

The model supplies the category and uncertainty. Code owns the conditions, the permitted destinations and the fallback. Changing a threshold becomes a versioned policy change that can be evaluated, reviewed and rolled back.

This connects directly to the harness engineering argument. A narrow model call can help interpret an input or flag a concern. It should not become the sole authority on whether an operation is permitted.

In NowFlow, an approval gate is an explicit route. In NODERIQ, evidence must reach the person who decides. In QANTIS, the planner stays classical while a separate component updates a belief. These are different implementations of a useful boundary: a probabilistic judgement can inform an action without owning the authority to take it.

Read the launch numbers as a starting point

TypeSafe’s launch post reports large speed and cost advantages on its workflow evaluations. It also says those workflows were created by its own model-capabilities team, may reflect bias and sit toward the high end of expected gains. Those caveats belong beside the claims.

For a deployment decision, I would compare the complete workflow: task accuracy, latency across the distribution, total cost, review rate and the effects of retries or extra checks. A fast model call is valuable; the application’s useful output is the end of the measurement.

As of 20 September 2026, this is an early-access product with a short public history. That leaves substantial questions about performance across domains, distribution shifts and sustained production use. I would treat the launch as an invitation to evaluate a new component.

The useful boundary is between judgement and authority

Generative models still have a role in writing, planning and working through open-ended problems. Decision models offer a different interface for the narrower judgements that sit between those tasks.

The promising architecture combines those abilities with explicit control. A model interprets the messy input. A typed result exposes the judgement. Code applies policy. The environment provides a result that can be checked.

That is the part of the idea I expect to matter beyond any one product: make uncertainty visible enough to work with, and keep the decision to act somewhere people can inspect.