Jev: Typed decisions for enterprise AI

Imagine a customer writes: “I was charged twice. Please refund the duplicate today.” An AI system may need to draft a courteous reply, but before it does that, the application needs three smaller answers: Which team owns the case? Does the refund policy apply? How urgent is the request?

An LLM can answer those questions, but its native operation is to generate a sequence of tokens. If the application only needs a label or score, generating a paragraph or JSON document is a roundabout way to get there.

Jev is TypeSafe AI's model for that narrower job. You give it the relevant text and define the possible kinds of answer. It returns typed values and probability distributions that ordinary code can inspect. Jev does not draft the customer response or decide which tool to call; it supplies the judgments that help the application make those choices. TypeSafe's introduction to Jev.

Figure 1. When the possible answers are known in advance, Jev maps shared textual state to bounded probabilistic judgments.

TypeSafe calls Jev its first System One Model, borrowing the name from the fast, intuitive mode of cognition popularized by Daniel Kahneman. The product was announced on September 15, 2026 and is currently in early access. The company says it developed a new architecture, a parallel sampler, and a post-training method called Reinforcement Learning for Calibrated Decisions, or RLCD. TypeSafe's launch article.

Jev in one minute🔗

A Jev call follows a simple four-step pattern:

1. The application gathers the relevant state, such as a support conversation, policy excerpt, or agent trace.
2. The developer defines bounded questions: yes or no, one choice from a list, or a score on an ordered rubric.
3. Jev evaluates the questions independently and returns a probability distribution for each one.
4. Code applies thresholds, permissions, and business rules before anything happens in the outside world.

The model is therefore better understood as a learned decision primitive than as a faster chatbot. It fits routing, scoring, verification, triage, and guardrails. It does not replace an LLM when the task requires an explanation, a plan, code, or new prose.

What is publicly known: TypeSafe has described Jev's interface, parallel sampler, and RLCD post-training method. It has not published the neural topology, parameter count, training recipe, or loss. The diagrams below explain the observable inference contract rather than hidden internal layers.

A Jev request has two parts:

1. State describes the case: a support conversation, security alert, invoice, agent trace, policy, or another text-bearing record.
2. Questions define the judgments the application needs and the allowed answer space.

The public API exposes three question types.

“Does the customer explicitly request a refund?” is a Noul question. “Which team owns the case?” is a Choice. “How severe is this incident?” is a Score, provided the levels define what low, medium, and high mean. TypeSafe primitives.

Figure 2. One Jev call takes shared state, evaluates several independent questions, and hands typed results back to code. Sources: TypeSafe introduction and primitives documentation.

For the duplicate-charge ticket from the introduction, an illustrative result might be:

Jev has not authorized a refund. It has supplied three semantic measurements. Code must still verify that two charges exist, confirm the customer's identity, apply refund limits, and check permissions before queuing an action.

All three questions read the same state but not one another's answers. If a later question depends on an earlier result, code starts a second request with the new state. This gives us the main design rule: one semantic judgment per question, composition in code.

Why Jev behaves differently from an LLM🔗

The clearest comparison is to imagine two forms. An LLM receives an almost blank page and writes the answer one token at a time. Jev receives a scorecard whose boxes and allowed values have already been defined, then fills those boxes with values and probabilities. The first interface is open-ended; the second is deliberately bounded.

A conventional LLM generates a sequence🔗

A decoder-style language model assigns probabilities to the next token given the tokens already present. It selects a token, appends it to the sequence, and repeats until the response is complete. This autoregressive process is powerful because a sequence can represent almost anything: prose, code, a plan, a tool call, or structured data.

The flexibility has a cost. Output length adds sequential decoding work. If the result must drive software, the system also needs a contract around the generated sequence. Modern structured-output APIs can constrain an LLM to valid JSON, so malformed output is not inevitable. But the model is still being used as a generator, and application-level uncertainty over the business choices is usually not the native output.

Jev returns bounded decisions🔗

TypeSafe says Jev uses a new model architecture and a parallel sampler. The caller declares Noul, Choice, and Score answer spaces before inference. Jev returns the requested distributions without generating an explanatory string token by token. Questions sharing the same state are processed in parallel and independently.

Figure 3. An LLM generates a sequence; Jev returns distributions over answer spaces declared by the caller. Source: TypeSafe's launch description.

The resulting advantages follow from specialization:

• Less sequential output work. The model is not decoding a paragraph or JSON document token by token.
• A bounded result by construction. Choice cannot invent an option outside the supplied set; Noul remains a yes/no probability; Score remains on the declared rubric.
• Many questions can reuse one state. A long document does not need to be resent in a separate call for every independent judgment.
• Uncertainty is available to policy. Code can inspect the complete distribution rather than only the winning label.
• Control flow stays visible. Thresholds, deterministic rules, permissions, and side effects remain in ordinary software.

These benefits appear when the answer space is known in advance. Jev gains a tighter interface by giving up the ability to write arbitrary strings.

Reading Jev's probabilities🔗

TypeSafe describes RLCD as training Jev to produce calibrated decisions. Think of a weather forecast: if rain occurs on roughly 80 out of 100 comparable days labelled “80% chance of rain,” the forecasts are calibrated. For Jev, the same idea applies to groups of decisions assigned probability 0.8.

Calibration says nothing certain about a single case. A ticket routed to billing with probability 0.8 can still belong to fraud. The schema only guarantees that the answer is one of the declared choices; it does not guarantee that the chosen answer is correct.

For Choice and Score, the API also supplies confidence, a scalar derived from the shape of the probability distribution. A distribution concentrated on one option has higher confidence than a flat distribution. Noul needs no separate confidence field because its single probability already describes the split between yes and no. TypeSafe's confidence documentation.

Compare two Choice results:

A: billing 0.94 | technical 0.05 | other 0.01
B: billing 0.40 | technical 0.35 | other 0.25

Both select billing, but they tell different stories. Result A is concentrated around one answer. Result B is almost a three-way contest and should be treated more cautiously. Looking only at the winning label would hide that difference.

Four related quantities are easy to confuse:

• Probability belongs to an outcome, such as P(refund permitted) = 0.83.
• Confidence summarizes how concentrated a multi-option distribution is.
• Correctness is established only by comparing the prediction with an appropriate reference outcome.
• Calibration asks whether probability estimates match frequencies over many cases.

TypeSafe documents these intended semantics but has not published reliability diagrams, expected calibration error, Brier scores, or an independent calibration study. Treat the returned probabilities as measurements to validate on representative labelled traffic, especially after changing the model version or deployment domain.

Reading the published benchmark🔗

TypeSafe publishes four workflow evaluations: security incidents, agent-trace observability, invoice processing, and customer service. Each one turns a business policy into narrow model questions plus deterministic code, then runs the same workflow with Jev and several LLMs. Interactive workflow evaluations.

In Figure 4, moving right means spending more per case and moving up means agreeing more often with TypeSafe's reference. The most attractive region is therefore the upper-left corner.

Figure 4. Jev reports 67.8% mean agreement at $0.0004 and 0.4 seconds per case. GPT-5.6 Terra reports 67.9% at $0.0304 and 10.1 seconds; GPT-5.6 Sol reports 74.1% at $0.0836 and 23.3 seconds. Data: TypeSafe workflow evals, accessed September 17, 2026.

Jev sits far to the left while remaining close to several LLM configurations on the vertical axis. The clearest pair is Jev and GPT-5.6 Terra: their reported agreement differs by only 0.1 percentage point, while Terra costs about 76 times more and takes about 25 times longer per case using the rounded values shown. That comparison applies to these four bounded decision workflows, not to the open-ended generation and reasoning tasks that Jev cannot perform.

The vertical axis is agreement, not independently annotated accuracy. TypeSafe constructs its reference by averaging answers from GPT-6 Astra and Claude Fable 5.1 at high thinking. Its own model-capabilities team wrote the workflows, and each non-reference model uses its provider's default reasoning setting. These choices make the evaluation useful as a vendor demonstration, but not an independent leaderboard.

Where Jev changes an enterprise agent stack🔗

Jev is not an agent: it does not choose a goal, generate a plan, write a message, or operate tools. Its role is closer to a decision layer between unstructured evidence and the code that controls a workflow.

Consider a support agent. The LLM may need to understand a conversation, retrieve evidence, draft a response, and call an approved tool. Jev can sit at several narrower decision boundaries:

• before the LLM, classify intent and choose the appropriate specialist;
• after retrieval, score passages for relevance, contradiction, or prompt injection;
• before a tool call, judge whether the request matches policy and whether review is needed;
• after generation, verify that a response addresses the request or that cited evidence supports a claim;
• after the run, triage the trace for silent failures and prioritize human review.

Figure 5. Code owns state preparation, policy, permissions, and side effects. Jev supplies bounded judgments; LLMs generate and reason; people handle uncertain or high-impact exceptions. Sources: TypeSafe's system-design guidance and intent-routing pattern.

Follow one request through the diagram. Code first retrieves the customer record and relevant policy, calculates exact values such as dates and amounts, and removes unrelated history. Jev then labels the intent, policy fit, risk, and urgency. A high-confidence order-status request can go directly to deterministic code; a product question can go to a specialist LLM; an uncertain complaint can go to a person. The thresholds remain visible in code rather than buried in an agent prompt.

It can also reduce sequential agent loops. If thirteen independent checks use the same long document, Jev can evaluate them in one batched request. TypeSafe's own regulatory-document cookbook reports that one 13-question call was 12.2 times cheaper and 10.0 times faster than thirteen sequential calls, with similar outputs across five repeats. The latency comparison sums sequential calls, so concurrent requests would narrow the time advantage, but not the repeated-input cost. Parallel-questions cookbook.

When to use code, Jev, an LLM, or a person🔗

A useful test is: Can I enumerate the valid answer space before seeing the case? If yes, and the hard part is a semantic judgment over text, Jev may fit. If the output must contain new language, a novel plan, or a chain of reasoning, use an LLM. If code can calculate the answer exactly, do not call either model.

A minimal workflow in code🔗

The official Python SDK makes the boundary explicit:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

state = {
    "message": "I was charged twice. Please refund the duplicate today.",
    "charges": [
        {"amount_usd": 49, "status": "captured"},
        {"amount_usd": 49, "status": "captured"},
    ],
    "policy": "Verified duplicate charges are eligible for a refund.",
}

with TypeSafeClient() as client:
    result = client.system_one(
        state=state,
        questions={
            "owner": Choice(
                instructions="Which team owns the primary issue?",
                criteria={
                    "billing": "Charges, invoices, refunds, or subscriptions.",
                    "technical": "Product failures or errors.",
                    "account": "Login, permissions, or account security.",
                    "other": "None of the listed teams fits.",
                },
            ),
            "refund_allowed": Noul(
                instructions="Does `policy` permit the refund requested in `message`, given `charges`?"
            ),
            "urgency": Score(
                instructions="How urgent is the request expressed in `message`?",
                criteria=[
                    "Routine: no stated deadline or ongoing harm.",
                    "Time-sensitive: the customer asks for prompt resolution.",
                    "Urgent: delay is causing material harm.",
                    "Critical: immediate intervention is required.",
                ],
            ),
        },
    )

owner = result.answers["owner"]
refund_probability = result.answers["refund_allowed"].noul

if owner.choice == "billing" and refund_probability > 0.90:
    queue_duplicate_refund_for_policy_checks(state)
else:
    route_to_review(state, result)

The model interprets language. Code still verifies identity, compares charge amounts, enforces authorization, applies refund limits, records the action, and makes it idempotent. A high model probability must never become a substitute for transaction controls.

Failure modes that matter in production🔗

TypeSafe's Jev 1.13 limitations translate into five practical boundaries:

1. Keep exact work in code. Jev is weak at numerical precision, counting, and date comparison. Parse timestamps, calculate amounts, check authorization, and enforce hard limits deterministically.
2. Prepare focused, untrusted state. Retrieve only the evidence needed for the question. Test adversarial content and prompt injection because text inside the state can influence the result.
3. Leave room for “none of the above.” A closed Choice with an incomplete option list forces the model to select the least-wrong answer.
4. Validate and version the decision boundary. Measure precision, recall, coverage, calibration, and business cost, then pin the model version used to set each threshold.
5. Engineer the surrounding service. Timeouts, retries, circuit breakers, fallbacks, human queues, and reversible side effects remain application responsibilities. Log the state and schema versions, distributions, route, overrides, tool outcomes, and eventual business result.

Jev returns no natural-language rationale. That avoids mistaking a fluent explanation for evidence, but it does not make the system auditable by itself. The audit trail comes from versioned inputs, explicit criteria, probabilities, policy code, and observed outcomes.

How to evaluate Jev in your own workflow🔗

Begin with one decision, not an entire agent. Define its allowed outputs, the business cost of each error, and which cases must always reach a person. Build a labelled set that includes common traffic, rare classes, ambiguity, missing evidence, and adversarial examples.

Next, compare complete implementations: deterministic rules, a conventional classifier, a structured-output LLM, Jev, and any useful hybrid. Use the same inputs and downstream policy for each. Alongside per-class precision and recall, measure calibration, latency percentiles, cost, and the share of cases sent to human review.

Run the preferred design in shadow mode before it can act. Compare its decisions with real outcomes and reviewer choices. When it goes live, begin with reversible, low-impact actions and continue monitoring input drift, confidence distributions, overrides, provider errors, version changes, and downstream outcomes.

Jev's low reported cost could make per-item checks practical across retrieved passages, proposed tool calls, generated outputs, and completed traces. Their value still depends on explicit policy, domain evaluation, observability, and safe fallbacks.

The current verdict🔗

Jev addresses a real mismatch in enterprise AI: many steps need a bounded judgment, not another paragraph. Its interface makes those decisions explicit and gives code direct access to their probability distributions. TypeSafe's early workflow results suggest that specialization can reduce cost and latency, although independent evidence is still needed for quality and calibration.

The practical lesson is to give each part of the system the job it handles best: code performs exact work and controls actions, Jev interprets text into bounded decisions, LLMs generate and reason, and people resolve consequential uncertainty. That is a more useful architecture than asking one model to do everything.

Related reading🔗

For the mechanism Jev deliberately avoids at output time, Transformer: Attention Is All You Need explains the architecture underlying modern sequence models, while Explaining neural language modelling develops next-token prediction from first principles.

For a different view of decision-making systems, Reinforcement learning: a practical primer explains states, actions, rewards, values, and policies. Jev is not an RL agent, but the distinction helps clarify why a probabilistic judgment model does not itself own goals, environmental actions, or long-horizon credit assignment.

Primary sources🔗

• Diogo Almeida. Introducing System One Models & Jev, TypeSafe AI, September 15, 2026. Primary launch description, disclosed components, company benchmarks, and caveats.
• TypeSafe AI. Introduction, System One, and Primitives. Public interface and answer semantics.
• TypeSafe AI. AI primer: RLCD and calibrated decisions and Confidence. Definitions of calibration, probability, and confidence.
• TypeSafe AI. Workflow evals. Interactive aggregate and per-workflow measurements, methodology, and reference construction.
• TypeSafe AI. How to build with System One, Intent routing, and Parallel questions. Official workflow patterns and batching example.
• TypeSafe AI. Jev 1.13 known limitations and Models and pricing. Version-specific failure modes, aliases, limits, and dated pricing.
• TypeSafe AI. Official Python SDK and JavaScript SDK. MIT-licensed client implementations and public request/response types.