State for Jev
Shape the material Jev will judge: string, object, or array of text.
State is the content you ask a System One model to evaluate. It can be a support message, a passage, or the current snapshot of an application. You pass it in the state field beside the questions. Each request evaluates one state against one or more questions. All questions see the same state and run independently. You can mix Choice, Score, and Noul in that map. Keep questions out of state and strip anything the judgment does not need.
Legal shapes
The simplest state is a plain string: "My card was charged twice." Use a string when the case is one piece of text. Use a JSON object when you have named fields, related records, or application state, for example a message plus an order id. Use an array of text for a sequence of messages or records. In Python, pass the corresponding string, dict, or list to client.system_one(state=...).
TypeSafe's state page recommends an object for most requests so each part has a descriptive name. A support conversation, an order with two captured charges, and a refund policy can live in one object. That is still one state. Put related information together when the decision requires comparing those parts. Do not hide a second question inside a field name.
Jev accepts text only. State must be a string, JSON object, or array of text values. Images, audio, and video are not supported. English is the primary training language; other languages, including CJK scripts, are accepted with lower accuracy. See the model card for that language note, and keep pixels out of the request by converting them to fields first.
Separate content from questions
State holds content and supporting facts. Questions define the judgments. Keep the refund request and the policy in state, then ask whether the customer requested a refund and whether the policy supports it. If you paste the question into the state blob, Jev still answers the instructions field, and you have duplicated the prompt in a place that eats the 32k state-plus-longest-question budget.
Large state full of irrelevant detail is a documented failure mode for jev-1.13. Accuracy falls as unrelated content acts as a distractor, and a bloated blob makes it harder to tell which field produced a wrong answer. Filter in code first. Send only the fields the question needs. When you cannot filter, a Noul can score passage relevance before the main judgment, as in TypeSafe's classifying RAG passages cookbook.
Context length is bounded. Jev 1.13 allows 64k tokens for the whole request and 32k for state plus the longest question. Speculative fan-out packs many short questions against a tight state. That is cheaper and more accurate than attaching a full ticket history when you only need the last customer message and two charge rows.
A support record as state
A documented object uses ticket.subject, ticket.messages as from/text pairs, order.id, order.charges with amount and status, and refund_policy as a sentence. The duplicate-charge case then becomes a set of Nouls and Choices over that object rather than a chat that has to restate the policy. Your code already knows the amounts; Jev judges whether the language asks for a refund and whether the policy sentence applies.
For a game loop such as Doom, state is structured text of the world, not frames. TypeSafe's demo feeds that text at about 10 queries per second. For Wikiracing, state is the page plus candidate links. For the smart-home assistant, state is the user utterance plus whatever device list you already have in memory. None of those demos send pixels to Jev.
When a field is numeric in your database, send a named bucket or a computed number if the judgment is semantic ("does this color read as a warning") and keep the hex math in code. jev-1.13 reads RGB triples and hex values poorly compared with English color names. The same advice applies to dates: extract parts with Choice, then compare in code.
Budgets and language
The 64k request window covers state plus every question. The 32k window is state plus the single longest question. A 20k policy PDF dumped into state leaves little room for the question map and also trips the irrelevant-detail failure mode. Retrieve first, then send the two paragraphs the judgment needs.
English is where accuracy is currently best. If your tickets are in Japanese or Korean, run a sample, plot Noul and Choice confidence, and keep a human in the loop until those histograms look like your English ones. The model will still accept the text; it will not silently refuse CJK.
Arrays of text are for sequences, not for smuggling a second schema. If you need named parts, use an object. If you need one blob, use a string. Mixing an image URL into a string does not give Jev vision; it gives Jev a URL token to misread. Fetch and describe in your workers, then send the description.
If a field is only for your logs, leave it out of state. Question IDs already give you join keys. State should be the evidence a human panel would read. That discipline also keeps you inside the 32k state-plus-longest-question budget when the ticket thread is long.
Named fields beat clever encodings. order_id, charges[].status, refund_policy are readable to you and to Jev. A single concatenated string of those same facts is legal and worse. The documented support-ticket object is the template: ticket, order, policy, then questions that point at those names.
Strip PII you do not need for the judgment. Jev is not trained on customer requests, but your own logs still are. Smaller state is both a jaggedness fix and a privacy habit.
An array of text is a sequence, not a set of named slots. If you need names, use an object.
Sources