Jev and the Problem of Perfectly Formatted Mistakes
Key takeaways
- Structured outputs constrain an answer’s format without guaranteeing its correctness.
- An AI restricted to fixed choices can still select an unsupported or incorrect answer.
- Claims about eliminating hallucinations depend on which errors are being measured.
- Practical evaluation needs to track decision errors, their costs, and when the system defers to people.
An AI can return a perfectly valid approve and authorize a refund that breaks the rules. The discussion around TypeSafe AI’s Jev and “System One Models” raises a useful question as AI takes on business decisions: how much trust should a neatly constrained answer earn?
Fixed choices make software’s job easier
Imagine a refund-review system with just three possible responses: approve, reject, or defer. There is no paragraph beginning “After carefully considering your circumstances.” The software gets a value it can act on immediately.
The rules defining those fields and their allowed values form a schema. With a fixed set of responses, the next system in the chain does not have to extract a decision from prose.
An approve response can start the refund process. A defer response can send the case to a support agent.
That is useful. It makes the interface predictable and the workflow easier to build. But it leaves a separate question unresolved: did the model choose correctly?
A wrong answer can pass every format check
Consider a hypothetical policy: refunds are available within 30 days of purchase, with no exceptions.
A customer applies after 45 days. The AI returns approve.
The response fits the schema perfectly. It also violates the policy.
Two different checks are needed:
- Format validation: Did the system return an allowed value?
- Decision validation: Was that value correct for this case?
It is the multiple-choice exam problem. Filling in every bubble correctly does not mean you picked the right answers.
A clean output can even make a mistake harder to spot. Someone reviewing a bare approve cannot see whether the model misread the purchase date, misunderstood the policy, or relied on an unsupported assumption. The interface looks tidy either way.
“No hallucinations” needs a definition
Any hallucination claim associated with Jev needs to be evaluated against a specific definition of the error.
Inventing a nonexistent fact and misapplying a supplied rule are different failures. Restricting an answer to three labels leaves no room for a fabricated research paper in a rambling explanation. It still leaves room for the wrong label.
Adding supporting fields does not automatically solve the problem. Suppose the system must return both a decision and a reference-document ID. The document might exist, and its ID might be valid, while its contents have nothing to do with the decision.
So a claim of “no hallucinations” needs a clear scope. Does it mean no malformed responses? No values outside an approved list? Or that the underlying facts and decisions have been checked?
Those are different guarantees. Schema compliance alone cannot establish factual accuracy or sound judgment.
Accuracy needs a cost attached
A refund system can fail in opposite directions. Approving an ineligible request costs the business money. Rejecting an eligible request harms the customer.
Counting both as one incorrect answer hides a meaningful difference.
A useful evaluation should ask:
- How often does the system reject requests it should approve?
- How often does it approve requests it should reject?
- Does it defer when essential information is missing?
- How accurate are the decisions it makes without human review?
Including defer in the schema is only the beginning. The system has to use it in appropriate cases.
The share of cases deferred matters, too. A system that hands almost everything to people serves a different purpose from one that handles nearly every request itself. The same headline accuracy can conceal very different workloads.
For Jev, the meaningful test is how reliably its decisions can be evaluated and trusted. Constraining the output is useful engineering, but every consequential decision still carries a cost if it is wrong. Sometimes the most valuable answer is the one that sends the case to a person.
Comments
Loading comments...