Typed decision
A model call whose output is not free text but a bounded judgment: a declared answer space, a response shape that matches it, and a defined place in the calling application's control flow. The phrase and the framing come from jev-typesafe-typed-decisions-guide (2026-09-25), read back onto a pattern this spoke had already been describing without naming across system-one-models-and-jev, laya and open-jev-9b.
Why it is a category, not one product's feature
Three unrelated projects converged on the same three-question vocabulary within one week in September 2026 — see synthesis → A category, not a product: three System 1s in one week:
| Question type | What it returns | Jev / TypeSafe | Vercel's AI SDK | Laya | Open-Jev-9B |
|---|---|---|---|---|---|
| pick one of N | a choice plus a probability distribution over all options | choice |
choice |
choice |
Choice |
| an ordinal rating | a probability-weighted value, can fall between levels | score |
score |
score |
Score |
| a yes/no proposition | the probability of "yes" | noul |
boolean |
noul |
Noul |
Jev coined "noul"; Laya and Open-Jev kept the spelling even while disclaiming (Open-Jev) or not
mentioning (Laya) any direct relationship to Jev's implementation. Vercel's SDK renamed it boolean
for its own type system when it started reselling Jev through the AI Gateway — the one
place in the vocabulary where the integration layer's naming diverges from the model layer's.
The decision contract
Four rules recur across the sources that describe how to call one of these models rather than build one, most fully stated in jev-typesafe-typed-decisions-guide:
- Minimal state. Send only the fields a question needs — helps privacy and makes a case reproducible later.
- One decision per stable question ID. IDs like
departmentorneeds_humanare versioned, not silently repurposed, because downstream code and stored history key off them. - A described answer space with a catch-all. Without an "other/needs review" option, a
choicemodel is forced to pick the closest wrong category rather than admit it doesn't fit. - Policy stays outside the model. Authorization, payment and rate-limit decisions are enforced by deterministic application code that reads the typed answer — the model supplies a bounded judgment, never the action itself.
What "typed" does not mean
Every source that describes this pattern is explicit that a declared schema is not a correctness
guarantee. jev-ai-sdk-guide states it about Jev directly: "your schema constrains those answers,
but doesn't guarantee they're correct." jev-typesafe-typed-decisions-guide draws the runtime
consequence: a caller that only casts the response type (as JevResponse in TypeScript) has validated
nothing, and a response that fails hand-written validation should be treated as unavailable, not as
a low-confidence negative answer. That distinction — an explicit "don't know" state rather than a
default that looks like a normal answer — is the same gap demo-to-production-gap tracks in
production ML systems generally.
Related
jev-typesafe-typed-decisions-guide · system-one-models-and-jev · jev-ai-sdk-guide · laya · open-jev-9b · ml-system-design · demo-to-production-gap · synthesis