Most Jev accuracy problems people blame on the model are state problems. The question is fine; the state handed to it is ambiguous, redundant, or missing the one field the judgment depends on. This is the design-side guide to what belongs in a state, in the order the primitives docs and the advanced guide frame it.
The state is the input, not the prompt
Jev takes two things: a state and a questions map. Everything a question can see has to be reachable from that state. There is no conversation history, no system prompt, and no hidden context — if a field is not in the state, the answer cannot use it.
That constraint is a feature. It means the state is the complete, auditable record of what the decision saw, and a wrong answer can always be traced back to a state that did not contain the right information.
state = {
"ticket": {
"subject": subject,
"body": body,
"account_tier": tier,
},
"policy": { "refund_window_days": 30 },
}
Include the material, not your conclusion
The most common mistake is putting the answer into the state. A field named is_angry: true computed upstream hands the model a verdict and asks it to agree. Pass the words, the metadata, and the raw values, and let the question do the judging.
Keep derived business facts the model cannot infer — the account tier, the policy window, the current time — but leave out anything that is itself a judgment you are asking Jev to make.
Name the part you are asking about
When a question concerns one slice of a large state, name it explicitly with a backticked path in the instructions, the convention the primitives docs recommend. A question about ticket.messages[0].text gets a sharper answer than "is the message angry" over a state holding several messages, because the model is not left to guess which one you mean.
Separate the record from the instructions
Do not string-build "Here is the ticket: ... Now classify it." Pass the ticket as structured state and the question in instructions. The pre-parsed extraction cookbook shows why: pre-parsing the fields in code removes a formatting step the model is weak at, and the question only has to judge the values you already split out.
One state, many questions
Every question in a request is answered against the same state, which is what makes parallel fan-out cheap. Design the state to serve all the questions a branch might need in one pass, then decide in code which answers matter. Adding a field costs input tokens; adding a second request costs a round trip.
Keep the untrusted parts clearly untrusted
If part of the state is text a user wrote, treat it as material to judge, never as instructions to follow. The jaggedness notes and the guardrails cookbook both assume the model takes instructions literally, so anything user-authored belongs in a state field, not in instructions.
A short checklist
- Every field a question needs is in the state, and nothing else is.
- No field is a pre-made judgment you are asking the model to rubber-stamp.
- The specific slice a question is about is named with a backticked path.
- Structured state replaces string-built prompts.
- User-authored text lives in state, never in instructions.
- The state serves every question in the request, so one call answers them all.
Get the state right and most "the model was wrong" reports turn into "the state was ambiguous," which is a fix you can ship today.