Jev Glossary: System One, Judgment Model & API Terms

Plain-language definitions of Jev terms: System One, judgment model, judgment/choice/scoring questions, confidence, rationale, fallback, channel, typed output, example fixture.

TL;DR: Eleven terms you need to read anything else on this site: what a System One model is, the three Jev question types, the four fields of its typed output, and the operational words — fallback, channel, example fixture — that our guides and case studies rely on.

System One

“System One” is the fast, automatic mode of thinking — the one that recognizes a face or answers “is this rude?” before you have reasoned about it. TypeSafe AI borrowed the term from dual-process psychology for its model family: models that answer the quick-recognition layer of a task instead of composing long text. Jev is TypeSafe AI’s System One judgment model, released in September 2026. In practice, “System One” signals three things about the tool you are calling: it does not chat, its output is a decision, and the decision arrives as typed JSON (answer, confidence, rationale) rather than prose you have to interpret. When a guide on this site says “use a System One model here,” it means: this step is a decision step — route, flag, score — and a chat model was the wrong shape for it. See What is Jev AI.

Judgment model（判断模型）

A judgment model produces decisions, not conversations. Where a chat model completes text, a judgment model answers a structured question — is this spam? which team owns this email? how good is this answer, 1 to 10? — and returns a typed result with a confidence value. Jev is a judgment model in exactly this sense: its input is a question plus the material to judge, and its output is JSON you can branch on in code. The practical consequence is architectural: a judgment model slots into pipelines as a gate or a router, between a data source and an action, with no prompt-engineering session needed to extract a usable answer from a paragraph. It also means you should not ask it to draft an email or summarize a document — that is the chat model’s job two steps downstream. Compare the three question types below; they are the whole input surface.

Judgment question（判断题）

The first of Jev’s three question types. A judgment question has a closed answer space of yes, no, or unclear — nothing else. It fits any binary policy you can phrase as a question: is this comment spam, should this ticket be escalated, does this invoice qualify for auto-approval? The unclear option is a feature, not a dodge: it gives the model a legitimate way to say “this sits in a gray zone,” and mature pipelines treat unclear as its own routing path (usually: send to a human) rather than collapsing it into no. A judgment call returns {"answer": "yes", "confidence": 0.97, "rationale": "..."} in the site’s example fixtures — verify field names against official docs. See the ticket triage and invoice gate case studies for production shapes.

Choice question（选择题）

The second question type: pick exactly one option from a list you provide. The option list is yours — billing / technical-support / sales, spam / abuse / policy-violation — which makes the choice question the natural fit for routing and classification. Two rules keep it healthy. First, the option list must exactly match the destinations your code knows how to handle; an option your router has no queue for is a bug waiting to happen. Second, the answer arrives with a confidence value, and low-confidence choices should fall back to a human instead of being forced onto a team. In this site’s fixtures a choice call returns {"answer": "billing", "confidence": 0.94, "rationale": "..."} — an example fixture, not a live capture. See email routing to three teams for the pattern with fallback.

Scoring question（打分题）

The third question type: return a number on a declared scale, typically 1-10. Scoring questions fit when a binary answer is too coarse — resume fit, RAG chunk relevance, Q&A answer quality — but you still want a sortable value, not a paragraph. The fixture shape is {"answer": 8, "scale": [1, 10], "confidence": 0.86, "rationale": "..."}: the score, the scale it was scored on, how sure the model is, and a one-line justification. The scale field doubles as a sanity check — it echoes the rubric you declared, so a mismatch signals a malformed call. Use scores to order queues and trigger thresholds (publish at 7+, rerank above 8), and treat low-confidence scores as “re-check” rather than truth. Batching many scoring calls — eight RAG chunks, say — is the pattern in the RAG reranking case study.

Confidence

The model’s self-reported certainty about its own answer, returned as a number between 0 and 1 in every Jev response. Confidence is what turns a model call into a gate: yes at 0.97 can auto-approve, yes at 0.55 should not. Three habits make it useful. One, always pair it with the answer — a confident no and a hesitant yes route differently. Two, calibrate thresholds on your own traffic, not on a guide’s example; log the confidence distribution for a couple of weeks, review what the low bucket actually contained, then pick the cutoff your humans can afford to absorb. Three, parse defensively — a missing or non-numeric confidence means “fall back,” never “proceed.” Version changes can shift calibration, which is why the 1.13 release notes recommend comparing confidence histograms across upgrades.

Rationale

The model’s one-sentence justification for its answer, returned alongside answer and confidence in every Jev response fixture on this site. Rationale is not decorative — it is the cheapest audit trail you will ever get. Auto-hidden a comment? The rationale is the log line that explains why. Sent an email to billing? The rationale tells the receiving team what triggered the route. Returned an invoice for human review? The rationale tells the accountant where to look first. Two cautions: a rationale is a plausible explanation, not a proof — it should inform review, not replace it on high-stakes decisions. And because it is generated text, treat its exact length and formatting as flexible in your parser; log anomalies, do not crash on them. All case studies on this site store the rationale alongside the decision for exactly this reason.

Fallback

The rule that decides what happens when the model is not sure enough. A fallback is built on confidence and the unclear answer: for example, auto-approve only on yes with confidence at 0.8 or higher, and send everything else — hesitant yeses, all unclear responses, missing fields — to a human. This is the single most important pattern in production Jev usage, because a judgment model that is confidently wrong is worse than no model at all, and every model is sometimes unsure. Good fallbacks share three properties: the threshold lives in configuration, not code; the fallback path is a real destination with an owner (a moderation queue, a triage folder), not an error; and the fallback rate is monitored, because a sudden rise usually means your input mix changed. The confidence and fallback guide covers threshold selection; the invoice gate case shows the code.

Channel（渠道）

The endpoint where you actually call Jev. This site demonstrates everything through OpenRouter’s OpenAI-compatible endpoint — https://openrouter.ai/api/v1/chat/completions with the model id typesafe/jev-1.13 — because it is the fastest way to try the model: your existing OpenAI-shaped client works, and you swap one base URL. The channel also carries the price you pay: the figure quoted across this site, $0.0462 per 1M input tokens, is the OpenRouter listing as of September 2026, and you should verify both slug and price on the OpenRouter model page before budgeting — slugs and listings can change between releases. TypeSafe AI also offers official API access, and authoritative details about it belong to typesafe.ai rather than this site; we do not reproduce official endpoints here. Whichever channel you pick, pin the model slug in configuration so a channel-side change cannot silently alter your pipeline’s behavior.

Typed output（类型化输出）

The shape of every Jev response: JSON with fixed fields — answer, confidence, rationale, plus scale for scoring questions — instead of free-form text. “Typed” is the load-bearing word. It means the answer arrives already parsed: your code branches on "answer": "billing" the way it branches on any enum, sorts on an integer score, and gates on a float confidence, with no regex surgery over a paragraph. It also means the contract is checkable: answer should be one of the options you declared, confidence should be a number in [0, 1], scale should echo your declared rubric — so a malformed response is detectable, and the correct response to a detected anomaly is your fallback path, not a crash. Every example on this site is built on this contract, with one honest caveat: the JSON we show is example fixtures, and you should verify field names against official docs before hard-wiring them. That verification is part of your first API call.

Example fixture（示例数据）

The labeled sample responses used throughout this site — like {"answer": "yes", "confidence": 0.97, "rationale": "..."} — shown to teach request and response shapes rather than to claim live benchmark results. Fixtures exist for an honest reason: model behavior moves between releases, so any “captured” output would go stale, and this site refuses to invent benchmark tables. What a fixture reliably gives you is the contract — field names, value ranges, the way scale echoes a scoring rubric — which is stable enough to build a parser against, provided you verify field names against official docs first. What a fixture does not give you is a promise that your prompt will return that exact answer or that exact confidence. So treat every fixture here as a schema with example values: copy the structure, run your own inputs, and use the self-test steps in the 1.13 release notes before trusting any behavior in production.