Jev State Guide: How to Structure Context Correctly

State is the material Jev evaluates. Keep facts in state and judgments in questions.

Supported state formats

A string is useful for one short passage. A JSON object is useful when facts have different meanings: ticket message, account plan, region, or policy. An array is useful for a sequence of messages or candidate passages. Choose the shape that makes the judgment inspectable.

Objects are often easier to maintain because instructions can name a field precisely. They do not make unrelated facts useful and they do not guarantee that the model will obey an embedded hierarchy.

Before and after

Before: customer email + 100 previous emails + logs + unrelated profile + HTML + internal notes + every support policy.

After:

{
  "ticket_message": "I was charged twice this month. Please refund the duplicate before Friday.",
  "account": {
    "plan": "pro",
    "region": "US"
  },
  "relevant_policy": "Duplicate charges may be refunded after payment verification."
}

The better version preserves the evidence needed for routing while keeping authorization separate. “May be refunded” is a policy condition, not proof that two settled payments exist.

How much context to include

Start with the smallest state that contains the necessary evidence. Add the relevant policy excerpt and any definitions needed to interpret it. If a decision changes after adding unrelated history, inspect whether you have mixed time periods, conflicting facts, or incompatible instructions.

When evaluating retrieved passages, identify the passage and its source. When evaluating a tool action, include the proposed tool and arguments. Sending the whole conversation “just in case” often hides the important boundary.

Reference fields by name

Write “Which department owns the issue in ticket.message?” instead of “Where should this go?” when the state also contains internal notes. Descriptive field names reduce avoidable ambiguity. Question IDs are not a substitute for explicit instructions.

State vs question vs prompt

State contains the facts. A question specifies the judgment. Criteria describe the allowed outcomes. Keep untrusted user text inside state; do not concatenate it into your trusted instructions. This separation improves clarity but does not turn a classifier into a security boundary.

Large-state failure modes

Both token budgets and semantic relevance matter. A request can fit the budget while still burying the answer in irrelevant text. TypeSafe identifies large irrelevant state as a Jev failure mode. Filter, chunk, retrieve, and label before classification; then evaluate the resulting pipeline.

State checklist

• Is every included field relevant to at least one question?
• Are user claims distinguishable from verified account facts?
• Are dates, units, and identifiers preserved exactly?
• Does the state include the evidence required for the judgment?
• Are missing fields handled explicitly instead of guessed?
• Have you tested contradictory, empty, and very long input?