How to Design State for Reliable Jev Decisions
State is the evidence boundary for a Jev decision. Good state is named, minimal, traceable, and safe to treat as untrusted whenever a user helped create it.
Treat state as evidence, not persuasion
The state field should contain the material needed to judge a question: a message, selected records, relevant policy, or a compact combination of them. It is not the place to hide the task definition or business rule. Put the judgment in the typed question and put the evidence in state. This separation makes a failed decision easier to inspect because reviewers can ask independently whether the evidence was complete and whether the question represented the intended policy.
A useful review exercise is to imagine handing the state to a domain expert. Would they know what each value is, where it came from, and whether anything decisive is missing? If they would first need a database lookup, date calculation, or explanation of an unnamed column, prepare that information before inference. The model should not have to reverse-engineer your application's data model.
Prefer named structure when relationships matter
A plain string is enough for one self-contained passage. An object is usually clearer when a decision compares a ticket with a policy, account status, and recent events. Descriptive keys preserve those roles and let a question point to the relevant field. Arrays fit sequences of similar records, provided their order and speaker or source are unambiguous. Structure does not make the answer correct, but it reduces avoidable inference about what each fragment represents.
Include provenance outside the natural-language value. Record IDs, source type, event time, and extraction version help reconstruct a decision later. Do not overload the state with internal metadata the question does not need; keep audit metadata in your own logs when possible. The state sent to the service and the decision record retained by the application have overlapping but different jobs.
Filter before inference
More context is not automatically safer. TypeSafe documents degraded behavior when large state contains irrelevant material. A long account history can bury the one policy exception that matters and makes error analysis difficult. Retrieve records with deterministic filters, select relevant fields, deduplicate repeated passages, and impose a clear time window before building the payload. If selection itself is fuzzy, evaluate that retrieval stage separately rather than treating the final answer as one inseparable model decision.
Filtering also reduces cost and exposure. Every unnecessary token is information sent to a third party, time spent serializing and transmitting, and material an adversarial passage can use to steer the output. Establish allowlists for fields and sources rather than subtracting known secrets after an object has been assembled. Data minimization is both a reliability technique and a security control.
Pre-compute exact facts
Counts, totals, date differences, entitlement checks, and database joins belong in deterministic code. Supply their results as named facts if the model needs them for a fuzzy judgment. Asking the model to infer whether an invoice is overdue from two date strings adds a known failure mode to a task a date library can solve exactly. Asking whether the customer's language indicates likely hardship after code has calculated days overdue is a more defensible division of labor.
The same rule applies to upstream media. Jev's reviewed model consumes textual state, so OCR, speech recognition, or image analysis must happen before the call. Preserve the extracted text and the tool version. When a decision is wrong, you need to know whether the evidence was extracted incorrectly, selected incorrectly, or judged incorrectly. One final accuracy number hides those distinct repair paths.
Untrusted state is an attack surface
A customer message, web page, retrieved document, or tool output may contain text written to influence the evaluator. Typed output prevents an attacker from inventing a new enum value, but it does not stop them from steering which valid value wins. Do not rely on a sentence that tells the model to ignore instructions inside state as the only defense. Minimize untrusted content, define criteria precisely, test adversarial variants, and keep high-impact authorization outside the model.
Where possible, separate trusted policy from untrusted evidence with explicit fields and verify that a question points to both deliberately. Apply ordinary input controls: size limits, source validation, access checks, redaction, and retention rules. For irreversible actions, require deterministic conditions or a human review in addition to the model output. The state boundary deserves the same threat modelling as an API request body.
Version the state builder
Production evaluation must capture how state was assembled, not only the final model name. Give the builder a revision, test it with fixtures, and log which fields and retrieval rules contributed to each decision. A refactor that renames keys, changes a time window, or inserts a summary can shift model behavior without changing the question. Treat those edits as model-facing changes that require regression results.
Before release, inspect representative payloads and ask four questions: Is every included field relevant? Is every required fact present? Could any exact transformation move into code? Could any text be hostile? Then measure performance as payload size and composition change. Good state is not the largest state the context window accepts. It is the smallest auditable evidence package that supports the decision.
What to carry into your next build
- Keep evidence in state and the requested judgment in the typed question.
- Use named objects for multi-part evidence and retain provenance in your decision record.
- Filter irrelevant context and compute dates, counts, totals, and permissions in code.
- Treat any user-influenced state as untrusted and version the state-building pipeline.
Editorial method and source note
This article is an original synthesis based on Learn Jev's “Designing state Jev can actually use,” with input shapes and current limits checked against TypeSafe's official state and models documentation. Security recommendations are conservative engineering guidance, not a claim that any prompt technique eliminates injection. No source structure, prose, image, or code is reproduced.
Facts and product details should be checked against the linked source and current official documentation before making production decisions.