Jev State: What to Send and How to Structure It

Every Jev request has one state and one or more questions. The state is the material; the questions are the judgments you want made about it. All questions see the same state and are answered independently.

Three formats

Format	Good for	Example
String	One message or passage	"The export button does nothing when I click it."
Object	Several named parts that relate to each other	{"message": "...", "order": {...}, "policy": "..."}
Array	A sequence of messages or records	["Hi there", "I am on the Team plan", "The export button does nothing"]

TypeSafe recommends an object for most requests, so each part has a name and the relationships stay clear. A string is fine when there is a single piece of text.

A useful mental model from TypeSafe’s docs: the state is what you would hand a panel of experts before asking them to judge. Everything they need should be in it; everything else should be left out.

An example object state

{
  "message": "You billed my card twice for the Team plan renewal. I only want to pay once.",
  "account": { "plan": "Team", "seats": 12, "customer_since": "2024-03" },
  "recent_charges": [
    { "date": "2026-09-18", "amount_usd": 1188, "description": "Team plan, annual" },
    { "date": "2026-09-18", "amount_usd": 1188, "description": "Team plan, annual" }
  ],
  "refund_policy": "Accidental duplicate payments are returned to the original card within 5 business days."
}

With this state you can ask, in one request: Is the customer asking for money back? Do recent_charges show the same charge twice? Does the policy cover this case? Comparing the two amounts and dates is safer in code, since Jev is weak at numbers and dates; the model’s job is the language part.

Point questions at the right field

When a question is about one part of a structured state, name that part in the instructions with a path in backticks, such as order.charges or messages[2].text. TypeSafe’s docs recommend this so the model knows exactly which part to judge, and its known-issues list for Jev 1.13 says direct references beat questions that make the model hop between fields.

How big can the state be?

TypeSafe documents 64k tokens per request, with 32k for the state plus the longest single question. In our tests on September 19, 2026, a request with 32,204 input tokens went through and one with about 33,600 was rejected with max_tokens_exceeded. TypeSafe puts the budget at roughly 150,000 characters of English prose; text heavy with numbers and IDs fits less.

Bigger is not better even below the limit. TypeSafe notes that accuracy falls as the state fills with material unrelated to the question. Retrieve, filter and trim in code first.

What the state cannot contain

• Images, audio, video or files. Jev accepts text only. Convert other media to text (OCR, transcripts, extracted fields) before sending.
• Instructions you want obeyed. The state is data. Put the question in instructions. Also note that text inside the state can try to steer the model, a known weakness TypeSafe lists; treat untrusted state with care.

Language

English is Jev’s primary training language. Other languages, including Chinese, Japanese and Korean, are accepted but less accurate. If your content is not English, test on your own data and pay close attention to confidence values.

Tips

• Keep keys descriptive (refund_policy, not p1); the model reads them.
• Send IDs rather than personal data when the decision does not depend on who the person is.
• If a question depends on the answer to another, make two requests: the first answer can become part of the second request’s state.

Related: Noul, Choice, Score, Jev limitations.