Dont Call It A Decision Model
- Source
- typesafe.ai
- Author
- TypeSafe AI editorial sitemap
- Date

Context
TypeSafe AI argues that its Jev model should not be called a decision model, because in a well-built system Jev answers small judgment questions and ordinary code makes the decision. TypeSafe introduced Jev in September as a model that takes unstructured input and returns typed answers with probabilities attached, rather than generating free text. Its November 3 post keeps the company's own label, a System One model, meaning one that makes "the quick intuitive judgments a knowledgeable person makes in seconds."
The post's example is a customer-support router with six possible outcomes, from sending a case to the fraud team to issuing an instant refund of $25 or less. The tempting approach is to put the whole routing rule into one multiple-choice question for Jev, with every condition and exception written out as prose. TypeSafe calls the result "prompt gymnastics": each new edge case means rewriting those descriptions, and when a case lands in the wrong place, the only evidence of why is a single probability.
The alternative splits the decision apart. Facts that software already knows exactly, such as whether a refund claim is eligible or whether the amount is $25 or less, stay in code. Jev answers only the questions that need judgment, such as whether the customer is reporting an unauthorized charge, and each is scored separately. Code then combines those answers with fixed rules. The example log shows what that buys: a case went to the fraud team because the unauthorized-charge judgment scored 0.94 against a rule threshold of 0.6, so an engineer can tell whether the judgment or the rule was wrong. TypeSafe adds that new outcomes can be added without disturbing judgments already tested, because each judgment is evaluated in isolation.
This is a design recommendation from Jev's maker, not a measured result. The post reports no comparison of error rates between the single-question design and the split one. What it does show is why the split makes a wrong routing decision easier to trace and fix.
- TypeSafe's example splits a support-routing decision into model judgments (does the customer want money back, report an unauthorized charge, or ask for a person?) and facts code computes exactly (is the claim eligible, is the amount $25 or less), combined by ordinary logic.
- Decomposition makes failures diagnosable: instead of one probability for the chosen route, the trace lists each judgment's score and the rule that fired, so you can tell whether the judgment or the rule was wrong and fix only that piece.
- Adding an outcome such as waiving a fee takes one new judgment and one code-computed fact. TypeSafe says Jev evaluates each judgment in isolation, so adding judgments does not change ones you have already validated.
Checking sign-in…
Loading comments…


