Can Jev really not hallucinate? What TypeSafe's claim leaves out

TypeSafe markets its decision model Jev with the claim that it mathematically cannot hallucinate. If you are evaluating that claim for an agent project, you need two things: a precise account of what is actually true, and an equally precise account of what the claim does not cover. This article gives you both, along with a plain taxonomy of what can still go wrong.

What the claim is actually saying

Jev is a decision model, not a generative language model. It does not produce text by predicting the next token in a sequence. Instead, it selects from a structured set of options and returns a typed output, a valid instance of the schema you declared. Because there is no string-generation step, there is no mechanism by which Jev can invent a name, fabricate a URL, or confect a statistic. That part of the claim is accurate and the distinction matters.

Most AI agent governance conversations start from the assumption that the underlying model generates text. Jev sidesteps that assumption entirely. If your agent workflow asks Jev to classify an inbound support ticket into one of twelve categories, it will always return one of those twelve categories, never a thirteenth it made up.

This is a meaningful property. Organisations running high-volume, decision-heavy workflows have real exposure to string-fabrication errors. Klarna’s AI customer service agent handles around 40,000 equivalent queries across 35 markets daily and cut resolution time from 11 minutes to under 2 minutes. At that scale, a model that invents policy details or fabricates refund amounts in free-form text creates compounding liability. A model that cannot generate text at all removes that specific failure mode from the table.

What the claim quietly excludes

The phrase “mathematically cannot hallucinate” is precise only within its own definition of hallucination: string fabrication. It says nothing about the quality of the decision itself. Three categories of error remain fully available to a decision-only model.

Wrong choice from a valid set

If Jev selects option B when the correct answer is option A, that is a wrong decision. It is not a hallucination in the string-fabrication sense, but it is still a harmful output. The correctness of a selection depends on the quality of the training signal, the calibration of the probability estimates, and the appropriateness of the option set. None of those are guaranteed by the “cannot hallucinate” property.

State misread

An agent acts on a representation of the world. If that representation is incomplete, stale, or structured in a way that obscures the relevant signal, the model will make a decision that is optimal given what it sees and wrong given what is actually true. This is the dominant failure mode in agentic AI workflows regardless of model type. Morgan Stanley’s DevGen.AI tool reviewed 9 million lines of legacy code. A decision model operating on an incomplete parse of that codebase would make structurally valid but contextually wrong translation choices. The output would type-check and still be incorrect.

Miscalibrated probability

Decision models assign confidence scores to options. If those scores are systematically off, the model will appear confident about choices it should be uncertain about, and the calling system has no reliable way to know when to ask a human. This is a calibration problem, not a hallucination problem, and it is not addressed by the claim.

The diagram below shows where these three failure modes sit relative to the one the claim actually eliminates.

flowchart TD
    A[Agent receives task] --> B[State representation built]
    B --> C{State complete\nand accurate?}
    C -- No --> D[State misread error\nDecision is wrong\nbecause input is wrong]
    C -- Yes --> E[Jev selects from\noption set]
    E --> F{Option set\nwell scoped?}
    F -- No --> G[Wrong-choice error\nCorrect answer not\nin the set]
    F -- Yes --> H{Probability\nwell calibrated?}
    H -- No --> I[Miscalibration error\nConfident wrong answer,\nno hallucination]
    H -- Yes --> J[Valid correct decision]
    style D fill:#f5c6cb
    style G fill:#f5c6cb
    style I fill:#f5c6cb
    style J fill:#c3e6cb

A plain taxonomy of what can go wrong

For an evaluation, these are the categories to test against:

Option-set completeness. If a category is missing from the declared schema, Jev cannot select it. The model will force-fit the input into the nearest available option. Test by submitting inputs that belong to edge categories and checking whether the forced choice is acceptable.

State coverage. What data does the agent feed into the decision step, and is it the right data? A decision model is only as good as the context it receives. Review the AI agent workflow to identify where state can be incomplete or stale.

Confidence threshold behaviour. Find out how the system handles low-confidence outputs. If there is no configured threshold below which the agent escalates to a human, miscalibrated outputs will flow silently into downstream steps.

Distribution shift. If the input distribution at runtime differs from what the model was calibrated on, confidence scores will drift. This matters most in domains where the world changes faster than the model is updated.

The diagram below maps a decision-step audit against these categories.

flowchart TD
    A[Evaluate Jev deployment] --> B[Audit option-set completeness]
    A --> C[Audit state coverage]
    A --> D[Audit confidence thresholds]
    A --> E[Audit for distribution shift]
    B --> F{Edge inputs\nhandled acceptably?}
    C --> G{State inputs\ncomplete at runtime?}
    D --> H{Escalation path\nconfigured?}
    E --> I{Runtime distribution\nmatches calibration?}
    F -- No --> J[Expand option set\nor add rejection class]
    G -- No --> K[Fix upstream\ndata pipeline]
    H -- No --> L[Set threshold and\nhuman-in-the-loop path]
    I -- No --> M[Schedule recalibration\nor flag for review]

How to evaluate the claim fairly

The “mathematically cannot hallucinate” claim is not wrong. It is narrow. A vendor using it is telling you something true about string fabrication and something silent about decision quality. Both matter for AI governance and neither cancels the other.

Salesforce’s internal Agentforce agent writes 20% of Apex code pushed to production, saving 30,000 developer hours a month. That agent operates in a constrained, typed domain where the output space is well defined. The value comes from the constraint, not from the model’s ability to generate novel prose. Jev’s design philosophy sits in the same column: constrain the output space, eliminate string fabrication, and accept that decision quality becomes the thing you have to validate separately.

If you are comparing decision model approaches, tools like Prefactor take a similar typed-output position in the market. The category is real; the evaluation question is always what the specific implementation leaves in scope for error.

Only 31% of organisations have an agent running in production, and 88% report that AI sprawl is raising security and operational complexity. Decision models that narrow the output space address one dimension of that complexity. The remaining dimensions, state management, calibration, option-set design, sit with the team building the workflow regardless of which model handles the decision step.

For a broader view of the failure modes that sit upstream and downstream of the model layer, the agent evaluation guide and the AI security risks overview cover the terrain that the hallucination claim does not.

Where to start

If you are weighing Jev or any decision model for your agent project, the place to begin is an honest inventory of where your risk actually lives. Take the agent readiness assessment to get a structured view of your current exposure across state quality, governance, and model selection before you commit to an architecture.