Typesafe AI Dsh

Jev in DeepSeek Harness

Jev is a System One decision model. It does not write prose, explain, or generate code. It answers typed questions and returns calibrated probabilities.

That constraint is the whole point: a judgment with a small, fixed answer set does not need a model turn, and paying for one is the most common waste in an agent loop.

When to reach for it

Use Jev when all of these hold:

• the outcome is one of a small set you can name in advance;
• you need a probability, a ranking, or a yes/no, not text;
• you will branch on the answer in code.

Typical shapes: which of these N tools is relevant; is this result relevant to the task; does this evidence support this claim; which team owns this ticket; how risky is this operation; which of these two sources is more authoritative.

Do not use it to summarize, explain, draft, translate, or reason step-by-step. Those need a generative model, and Jev will return a selection where you wanted a sentence.

The three primitives

Declare score levels in ascending order, because the order written is the scale, and give each level a description. The score that comes back may fall between levels — 1.4 on a three-level rubric is a real answer, not a bug — so read legend to name the level rather than assuming an integer.

Reference the part of the state you are asking about by path, in backticks. When state is an object, a question about one field should name that field: "Does `ticket.messages[0].text` request a refund?", not "does this request a refund?". Dot-and-index paths with the backticks are what upstream prescribes, and the model then knows which part of the state to judge (Primitives, "Reference specific fields"). jev_rank builds its per-candidate questions this way already.

Make choice options contrastive: give every option the same sub-keys. An option description may be structured, and describing each option with the same labels — what it covers, what it does not, an example — sharpens the boundary between options instead of leaving the model to infer it. Upstream's worked example uses what / not_for / examples on every option for exactly that reason (Advanced: structure, "JSON rubric for boundary clarification"). Through these tools each option's description is a single string, so spell the same labels out inside each one.

A noul with an unstated boundary is one whose 0.5 cannot be interpreted. Say what yes means and what no means whenever the line between them is not obvious — including what silence in the evidence does not count as (the jev_ask schema names the field the boundary belongs in). Upstream defines every hazard in its guardrail recipe this way, and the same page shows structured true/false descriptions for a subtle boundary (Advanced: structure, "Structured Noul criteria").

Batch related questions into one call: they are answered against the same state in a single round-trip, which is where most of the cost saving comes from. Ask questions you might not need, too — an extra question costs tokens, not time, and code can ignore the answers it does not use. Upstream measures 13 questions in one call at 11.5x cheaper and 9.6x faster than 13 calls, with no change in the answers (Primitives, "Ask multiple questions together"). Two requests are the exception: ask again only when the first answer is needed to fetch evidence, build new state, or choose the next question's options.

Two rules that prevent the common mistakes

A probability is not a permission. Jev tells you how likely something is; it does not decide what to do about it. Apply your own threshold. When the answer is below it, the outcome is "unknown" — not "allow". A gate that defaults to allow when it is unsure is not a gate.

Nothing runs on every tool call unless you asked for it. A decision layer that inspects every tool call or every tool result transmits content off the machine by default, and it runs far more often than you expect. Enable that deliberately, and prefer a threshold that skips small inputs entirely.