TypeSafe State Design in 2026: Context Limits, Filtering and Context Rot

What Is State in TypeSafe in 2026?

State is the content you ask a System One model to evaluate. It could be a support message, a passage of text, or the current state of your application, and it goes in the state field of the request alongside the questions you want answered. Each request evaluates one state against one or more questions, and every question sees the same state and is evaluated independently.

That one-state-per-request design is what makes batching so cheap: the content is sent once and every question reads it. It is also why state design is the highest-leverage thing you can get right, because the same material is being used by every judgment in the call.

Explain It Like I Am Five: Packing the School Bag

What Shapes Can the State Be in 2026?

Three: a plain string, a JSON object, or an array. TypeSafe recommends an object for most requests so each part of the state has a descriptive name and its relationships remain clear, and reserves the plain string for cases where the use case is simple and requires only one piece of text.

TypeSafe's framing is worth borrowing when you are designing one: think of state as the material you would present to a panel of experts before asking them to make a judgment. That test tends to produce the right answer about what to include. You would hand the panel the complaint, the order record and the relevant policy. You would not hand them the entire policy manual and the customer's purchase history since 2019.

A structured state can hold several related things and still be one state. TypeSafe's documented support example contains a conversation, an order and a refund policy in a single object, on the grounds that you put related information together when the decision requires comparing those parts.

{
  "state": {
    "ticket_message": "My flight was cancelled. Can I get a refund?",
    "refund_policy": "Cancelled flights are eligible for a full refund."
  },
  "model": "jev-latest",
  "questions": {
    "policy_supports_refund": {
      "type": "noul",
      "instructions": "Does the refund policy support the refund requested in the ticket?"
    }
  }
}

How Do You Separate Content From Questions?

The state contains the content and supporting facts. The questions define the judgments to make about that material. TypeSafe's example of the split is exact: keep the refund request and the policy in the state, then ask whether the customer requested a refund and whether the policy supports it.

Getting this boundary wrong is the most common structural mistake. Evaluation logic that belongs in instructions ends up embedded in the state as a preamble, or reference material that belongs in the state gets pasted into every question's instructions and re-sent once per question. The clean version keeps facts in the state, judgment criteria in the questions, and rules in your code.

How Do You Point a Question at Part of the State?

Name the part in the instructions with a dot-and-index path to its key, including the backtick characters around the path, such as support.tickets[0].message. TypeSafe's guidance is that explicit paths make it clear which parts of a structured state should inform each judgment.

This matters more with Jev than it might with a chat model, because indirection is one of the documented failure modes: a question about a property of a property, or one that requires several hops of reasoning, costs accuracy. A path in the question removes one hop.

What Are the Context Limits for Jev in 2026?

Jev 1.13 has a 64k token budget per request covering the state plus all questions combined, and a separate 32k budget covering the state plus the single longest question. TypeSafe explains the structure: Jev ingests the state once and evaluates every question against it in parallel, which is why the two budgets are expressed differently.

The practical reading for 2026 is that your document budget is closer to 32k than 64k, and it shrinks by however long your wordiest question is. If you are feeding long documents, keep instructions and criteria terse on the longest question rather than the whole set.

Why Does a Bigger State Make Answers Worse?

Because accuracy falls as the state grows with content unrelated to the decision. TypeSafe lists this as one of nine documented failure modes for Jev 1.13 and states the mechanism: unrelated detail acts as a distractor, and a large state also makes it harder to tell which part of the input produced a wrong answer. Its summary line elsewhere is blunter, saying Jev suffers from context rot, so unrelated material in the state costs you accuracy.

This is the opposite of the habit many teams built with long-context chat models, where stuffing everything in and letting the model sort it out is often adequate. Here, the recommended approach is to retrieve and filter in code first and send only the fields the question needs.

How Do You Filter the State When You Cannot Filter in Code?

Use the model itself as the filter. TypeSafe's documented advice is that when it is not possible to filter in the state, you can use a Noul to filter for relevance, and it points to the classifying RAG passages cookbook as the worked example. That cookbook scores each retrieved passage with one TypeSafe request, then decides in code which ones reach the answering model.

That is a two-stage shape worth internalising, because it turns an expensive context problem into a cheap decision problem.

1. Retrieve broadly with whatever you already use, such as keyword search or embeddings.
2. Judge each candidate with one cheap question per candidate, all in a single request.
3. Select in code using a threshold you chose from your own data.
4. Build the real state from only the selected material.
5. Ask the actual questions against that much smaller, cleaner state.

The same shape underlies TypeSafe's reranking cookbook, which builds 30-passage shortlists for 40 legal queries and uses one question per query-candidate pair, reporting a rise in top-1 accuracy from 5 percent to 18 percent and top-10 accuracy from 38 percent to 62 percent over the shortlist it started from.

How Do You Handle Images, PDFs and Audio in 2026?

You convert them before they reach the API. Jev is text only, accepting a string, JSON object, or array of text values, with no image, audio or video input. TypeSafe's instruction is to pre-process non-text inputs into text or structured fields before sending them as state.

That last row is the one teams skip. Sending a raw page means sending menus, cookie banners and footers into a model that is documented to lose accuracy on irrelevant content.

What Should You Never Put in the State?

• Anything no question asks about. The single most reliable accuracy improvement available.
• Evaluation rules. Those belong in instructions and criteria, or in your code.
• Arithmetic to perform. Jev is not a calculator and does not count reliably. Compute in code and pass the result or a named bucket.
• Raw hex, RGB triples or binary encodings. TypeSafe notes semantic representations outperform numeric ones; convert to names or buckets first.
• Dates you want compared. Extract the parts and do the comparison in code, per the documented guidance.
• Untrusted text without thought. State is data, and TypeSafe states that Jev does not treat it as hostile by default, so content written to steer the model can move the answer.
• Facts you expect the model to already know. The build guide says not to rely on knowledge stored in model weights when current information can come from your own knowledge base.

How Do You Handle Adversarial Content in the State?

Carefully, and with the expectation that this is a live weakness rather than a solved problem. TypeSafe states that content written to adversarially steer the model, whether an injected instruction, a deliberately misleading framing, or text that argues for its own classification, can move the answer, and that the company expects to improve on this in future.

Its recommended mitigations are to be explicit in the criteria and to test your integration thoroughly before deploying it to many users. In practice, if your state contains text written by the people your decision is about, which covers moderation, applications, reviews and support, then adversarial robustness is your problem to design for. Keep the consequential actions behind a confidence gate and a human, as our confidence guide describes.

What Are the Common State Design Mistakes in 2026?

• Filling the window because it is there. The budget is a limit, not a target.
• Sending one giant string instead of named fields. An object makes each part addressable by a question.
• Pasting reference material into every question. Put shared material in the state once; the questions all see it.
• Assuming 64k of document space. The binding limit is 32k for the state plus your longest question.
• Sending raw HTML or unfiltered retrieval results. Boilerplate is a documented accuracy cost.
• Blaming the question when long inputs fail. Test the same question on a trimmed state first.
• Forgetting that state is data, not instructions. Hostile content in the state can influence answers.

Key Takeaways for 2026

• State is the content being judged, sent once per request and read by every question in that request.
• Use a JSON object for most requests so each part is named and addressable; a plain string suits only simple single-text cases.
• Jev 1.13 allows 64k tokens for the whole request and 32k for the state plus the longest single question.
• Accuracy falls as the state grows with irrelevant content. Filter in code first, and use a cheap Noul as a relevance filter when you cannot.
• Input is text only, so OCR, transcribe or describe non-text material before it reaches the API.
• Keep facts in the state, judgment criteria in the questions, and rules and arithmetic in your code.
• State is data and is not treated as hostile by default, so design for adversarial content where users write the text.

Distk builds the retrieval and filtering layer that sits in front of a decision model, which is usually where the accuracy is won or lost rather than in the model call itself.

Sources

• TypeSafe AI docs: State
• Models: context length and input
• Jev 1.13 jaggedness
• How to build with TypeSafe
• Primitives (Questions)
• Classifying RAG passages cookbook
• Re-ranking cookbook