JEV / LESSON 02 · 9 min
How to design Jev state: from raw text to usable facts
Scope the facts, add necessary context, remove sensitive data, and test four edge cases.
Define the decision before the input
For support routing, the state needs the current message and verified order facts, not a whole conversation archive. Write down what code will do with the answer, then work backward to the minimum useful facts.
Separate claims from verified facts
A customer saying a parcel is missing is a claim. A carrier status of delivered is a system record. An unknown signature is missing data. Name the source of each fact so a complaint is not mistaken for proof.
Compare two states
Weak: ‘The user is upset; handle this.’ Better: ‘message: parcel marked delivered but missing; carrier_status: delivered; signature: unknown; payment_issue: none.’ Verify and de-identify these fields in your application.
Validate with ordinary code first
Check required fields, permissions, enums, and length before the model call. Remove names, addresses, and payment details if they do not affect the decision. Use deterministic rules when they settle the case.
Four edge cases to keep
Test missing facts, overlapping billing and shipping language, negation such as ‘not urgent,’ and mixed languages. Label the expected route and acceptable review outcome before running a model.
Practice
List the minimum fields, their sources, and what happens when each is missing. Delete one field at a time. If the decision should remain unchanged, that field may not belong in state.
Practice
Practice
What if the carrier record is missing?
What does the support team actually need to decide?
Follow one support ticket from raw text and verified facts through three questions, an illustrative answer, edge cases, and launch evaluation.
Worked example: design a Jev workflow for a missing deliveryProgress is stored only in this browser