index

Many uses of language models inside software end in a small decision: selecting a queue, assigning a score, deciding whether to call a tool, or estimating whether a case needs review. The output space is known in advance. What the application needs from the model is a judgment over that space.

Jev, released by TypeSafe in early access on September 15, 2026, makes this the model interface. Application state and typed questions go in; values and probabilities come back. TypeSafe calls this a System One model, borrowing the distinction between fast judgment and extended deliberation to describe the kind of work it is optimized for.¹

This changes how a model fits into a program. A decision can be composed with thresholds, rules, and downstream functions directly, while generation remains available for the parts of the workflow that need language.

State, questions, and return types

A request contains a description of the current state and one or more questions about it. The question defines the answer space. TypeSafe exposes three question types:²

The distinction matters to the caller. A queue selection is categorical. A score depends on the scale and rubric. A probability describes a specified event. These values support different operations even when each can be represented by a number.

A support workflow might be described as follows. This is a conceptual request, with the exact API representation defined in the documentation.

State:
    Customer reports a failed payment and a duplicate charge.
    Account history and the relevant support policy are attached.

Questions:
    route: choose [billing, fraud, technical]
    urgent: probability that the ticket requires a response within one hour
    refund_risk: score against the supplied refund-risk rubric

The application can send the ticket to billing, raise its priority, and request a human review independently. A generative model can then draft the response using those decisions and the same underlying evidence. Routing and writing have separate outputs and can be improved separately.

Parallel decisions within a request

TypeSafe describes the questions in a request as evaluated in parallel against the same state. Its launch reports end-to-end service latency of 70 to 500 ms and a training method called Reinforcement Learning for Calibrated Decisions.¹ The intended workload is a collection of bounded judgments that would otherwise be expressed through generated text.

This is useful for decisions on a frequently executed path. A tool router runs before the selected tool. A moderation decision runs before content is accepted. A retrieval filter runs before a larger model reads the remaining candidates. Latency at these boundaries is paid repeatedly, so reducing the work between state and decision can improve the whole interaction.

Parallel evaluation also makes decomposition useful. A support policy may depend on urgency, customer status, and the likelihood of a duplicate charge. Each can be a separate question, with application code combining the results. A policy change can then alter the combination without changing the definition of every individual judgment.

The joint probability still requires care. Knowing the probability of “urgent” and the probability of “billing” does not determine the probability of “urgent and billing.” Multiplying the two assumes independence. Where the joint event drives the action, it needs an explicit definition and evaluation.

Type safety, accuracy, and calibration

Three properties determine whether a returned decision is useful.

Type safety means the value belongs to the declared output space. A Choice answer selects from the available options. A numeric answer satisfies its representation constraints. The application receives a value it can process.

Accuracy concerns the judgment itself. A valid queue name may still be the wrong destination for the ticket.

Calibration concerns the relationship between probabilities and observed outcomes. Among cases assigned probability 0.8, the event should occur about 80 percent of the time over the relevant population. Calibration research treats this separately from classification accuracy.³

The definitions of the questions establish what can be measured. “Urgent” could mean a safety incident, an unhappy customer, or a response due within an hour. A labeling guide turns that ambiguity into a repeatable target. Cases with missing information can have their own outcome rather than being forced into a confident label.

Score has a similar dependency on its rubric. A risk score of 0.8 is not necessarily an 80 percent probability of a future loss. The application needs to preserve the meaning of the returned quantity when it uses it in a formula or threshold.

From probability to action

The threshold for taking an action follows from the relative costs of its errors. Consider a simplified moderation policy. Let p be a calibrated probability that a submission violates a rule. Assign a cost of 100 units to allowing a violation and 2 units to blocking a valid submission.

The expected losses are:

allow: 100 × p
block:   2 × (1 - p)

Blocking has lower expected loss when p exceeds 2/102, approximately 0.0196. The low threshold follows from the large cost assigned to a missed violation. The numbers are illustrative; the calculation shows how a policy threshold can be derived from consequences.

Human review introduces a third action. If perfect review costs 0.5 units, it is cheaper than allowing once p exceeds 0.005, and cheaper than blocking while p remains below 0.75. Under those assumptions, the middle range goes to review. Reviewer error, delay, and limited capacity extend the model with additional costs.

This separation gives the application a useful control point. The model estimates the event; the policy decides what to do about it. A change in review capacity or error cost can move the threshold without changing the question sent to the model.

Deterministic conditions fit naturally before or after that step. Missing required fields can route directly to review. A known duplicate can follow a fixed rule. The decision model handles the cases where the state requires judgment.

Measuring calibration

For binary outcomes, the Brier score averages the squared difference between each predicted probability and its observed zero-or-one label. A reliability plot groups predictions and compares the average probability with the observed event frequency.³

For example, suppose 100 held-out tickets receive probabilities between 0.75 and 0.85, averaging 0.80. If 58 are urgent under the labeling guide, the predictions are overconfident in that group. If 82 are urgent, the observed frequency is closer to the prediction, with uncertainty from the finite sample.

Breaking the result down by language, ticket length, and customer type identifies where the estimate transfers well. A model may be calibrated on common English requests while systematically overestimating urgency for another segment. Time-based holdouts are useful when policies and incoming traffic change, because near-duplicate conversations can otherwise appear on both sides of a random split.

Base rates provide another reference point. If only 1 percent of submissions violate a rule, a model that always predicts 0.01 may have a low aggregate error while offering little ranking value. Precision, recall, review volume, and expected cost at the chosen threshold describe what the application gains from the model.

The application path

The model call is one stage in a larger request. Input preparation, network transport, policy execution, and any fallback all contribute to completion time. An application-level outline is:

load policy and question definitions
validate the required state
request typed decisions within the remaining deadline

if the request completes:
    combine decisions with deterministic rules
    choose the action under the current policy
else:
    use the fallback queue

record the model, policy, probabilities, and action

The record makes the result reproducible. A later change in queue assignment can be traced to the model, question definition, threshold, or input. Retaining only the final label loses that distinction.

Deadlines connect this design to the rest of the system. A synchronous call inside a 300 ms interaction has a different budget from an asynchronous queue processor. Retries and review also contribute to total cost per completed workflow, even when the initial decision call is inexpensive.

Where the interface is useful

A bounded decision model fits applications with repeated judgments and explicit outcomes: classification, routing, ranking, scoring, and branching. A text model fits explanation, writing, code, and synthesis. Rules remain efficient for conditions that can be specified exactly.

Comparisons become clearer at that workflow boundary. Decision quality, calibration, schema failures, latency, timeout rate, and review cost can be measured on the same cases. TypeSafe’s published workflow evaluation uses reference-model probabilities for parts of its comparison; independently labeled application outcomes answer a separate question about correctness.¹

The architectural value is composability. A probability can feed a threshold, a Choice can select a function, and a score can order a queue. Giving these judgments explicit types and measurable outcomes makes them ordinary components of software, with the same scope for testing and improvement as the code around them.

References

Footnotes

1. Diogo Almeida, Introducing System One Models & Jev, TypeSafe, September 15, 2026. Release, design claims, latency range, and evaluation caveats. ↩ ↩² ↩³

2. TypeSafe, Developer introduction. Request types and supported model interfaces. ↩

3. Guo et al., On Calibration of Modern Neural Networks, ICML 2017. Calibration concepts and evaluation. ↩ ↩²

A typed return value fits an application interface, but the application still owns its decision rule.

1. State

   Build the typed input from the application state.

2. Estimate

   Ask the model for the supported decision and probability.

3. Policy

   Apply calibrated thresholds and explicit application constraints.

4. Outcome

   Record the action and its eventual result for evaluation.

Type checking validates an interface. Calibration and decision quality require outcome data.

Passing one check does not imply the other two pass.

Case	Question	Evidence
Type validity	Is the returned value allowed by the interface?	Schema and program-level validation
Calibration	Do events predicted near p occur at that frequency?	Grouped held-out predictions and observed outcomes
Policy quality	Does the resulting action meet the application objective?	Task outcomes, error costs, and threshold sweeps

A useful typed decision needs a valid representation, meaningful probabilities, and an appropriate policy.