The shape of the thing
You assemble a state. You attach typed questions to it. The model answers them with values and probabilities. Your code decides what happens next.
That last sentence is the whole design. TypeSafe puts it flatly: System One is “TypeSafe’s model for building AI-powered software, not agents. It does not generate code or choose its own next action.” No tool calls, no plans, no control flow. If a refund gets issued, your code issued it.
Which means the interesting work is deciding what goes in the state, what questions to ask, and where the thresholds sit, rather than prompting.
Build the state carefully
State is whatever content you want judged: a message, a document, a JSON object, an array of text values. Jev takes up to 32k tokens for state plus the longest single question.
The guidance from the docs is to “include only the context relevant to the current questions. This helps the model avoid distractions and context rot.” The jaggedness page lists large states full of irrelevant detail as a documented weakness, so the extra context you pasted in for safety is actively making the answers worse.
Structure it as nested JSON when the content has parts, and point questions at specific values rather than at the blob. A support state might carry the ticket body, the customer’s plan and the last two messages, and leave out the other forty messages in the thread.
Ask narrow questions
“Ask the most explicit, narrow, specific, atomic questions you can. Break down complex or ill-defined questions into separate questions that each evaluate one property.”
That is the single most useful line in TypeSafe’s docs. “Is this ticket a problem?” is a bad question, because it is four judgments wearing a trench coat. Ask whether the customer reports something broken, whether they are asking for money back, how urgent the wording is, and which product area it touches. Four narrow questions, one call, evaluated in parallel.
Picking the type is mechanical once the question is narrow. One of a known set: Choice. A position on an ordered scale: Score. Yes or no: Noul. The primitives guide has worked examples of each.
Let your code own the thresholds
Confidence comes back as a number from 0 to 1 on Choice and Score answers. What you do at 0.62 is your decision, not the model’s.
TypeSafe’s confidence docs sketch three bands. High confidence: act automatically. Medium: proceed with care, confirm with the user, or flag for review. Low: do not act, and route to a human or fall back to something else. The worked example uses 0.5 as the floor for genuine uncertainty and 0.9 as the bar for destructive operations running without confirmation.
Those are starting points, not settings. Refunding money and reordering a list have different costs when they go wrong, so they get different bars. The docs end that page with the right framing: “Your code encodes the risk tolerance.”
Noul needs a different test, since it returns no confidence value. Threshold on distance from 0.5 instead: act above 0.9 or below 0.1, escalate everything between.
The four patterns
TypeSafe documents four. Most real systems combine two or three.
Speculative fan-out. “Send many questions in a single call, including speculative ones, and let your code decide what’s relevant.” All questions in a request run in parallel, so adding more “typically doesn’t add any latency to the response.” Ask the bug-severity question even when the ticket might not be a bug, then ignore the answer if the category came back as billing. One round trip instead of two. The fan-out recipe has the code.
Confidence-gated routing. “Use confidence as a second decision axis to build safer systems.” The answer says what; the confidence says whether you are allowed to act on it unsupervised. This is the pattern behind confidence-gated actions and the one that turns a classifier into something you can put in front of a customer.
Composite scoring. “Combine several dimensions of analysis into a single score.” Ask four separate Score questions, then weight and sum them in your code. The weights live in your repository, in version control, reviewable, changeable without a model update. Composite lead scoring is the worked version.
Intent routing. “Classify a user’s intent and route to the appropriate handler.” A Choice over your handler names, then a dispatch table. Intent and model routing covers the variant where the thing being routed to is another model.
Design around the jaggedness list
TypeSafe publishes what Jev 1.13 does badly. Read it as a specification for what your code has to do instead.
Arithmetic and counting stay in code. The model is documented as weak at both. Counting occurrences, summing line items, checking list lengths: all of that is a loop you write.
Dates stay in code too. “Jev reads dates as text, not as ordered quantities.” Parse dates yourself, compute the durations yourself, and if you need the model’s judgment about a date, hand it a pre-computed boolean in the state rather than asking it to compare.
Screen hostile input before it arrives. “State is data, and jev-1.13 does not treat it as hostile by default.” Anything user-supplied that reaches the state wants a prompt injection screen in front of it, and that screen is a Noul question on its own call.
Decompose multi-step reasoning. Indirection and double negatives both reduce accuracy, so a question requiring two inferences becomes two questions with your code joining the answers.
Do not count on logical consistency. A question and its negation can both return 0.7, because there is no guaranteed relationship between related questions. Ask one, or reconcile them yourself.
Test it like a decision system
Log the answer, the full probability distribution, the confidence and the eventual real outcome. That log is the only way to know whether your thresholds are set correctly, and it is what you measure calibration from, the property RLCD is meant to deliver.
Pin the model version rather than an alias. jev-latest resolves to jev-1.13.0 today and will not always, and every threshold you tuned is tuned against a specific model.
Watch the escalation rate as much as the accuracy. A gate set too tight sends everything to a human and costs more than doing nothing; set too loose it acts on cases it should have flagged. Browse what people have built for how others have landed those numbers.
FAQ
How many questions should I ask per call?
As many as you might need. Questions in one request are evaluated in parallel, so adding them typically does not add latency, and the state is charged once. The limit is the 64k token context budget. TypeSafe does not document a maximum question count per request.
Where do the thresholds live?
In your code, always. The model returns a confidence number and nothing else; the decision about what counts as high enough belongs to whoever owns the consequences. TypeSafe’s docs use 0.5 as an uncertainty floor and 0.9 for destructive operations, but both are examples rather than defaults.
What if the model returns low confidence often?
Usually the questions are too broad or the state carries too much irrelevant content. Split the judgment into narrower questions, trim the state to what the questions actually need, and make sure your Choice options have clearly distinct descriptions rather than overlapping ones.
Can the model call my tools?
No. A System One model does not choose the next action, call functions, or produce control flow. It answers the questions you asked about the state you supplied. Turning an answer into a tool call is code you write, which is the point of typed tool dispatch.
Do I need to handle contradictory answers?
Yes, if your logic depends on consistency. TypeSafe documents that related questions have no guaranteed mathematical relationship, so a yes/no pair can both come back high. Design so that no two questions are logical mirrors, or reconcile the pair explicitly before acting.