JEV INPUT DESIGN GUIDE

How to design state for Jev

Structure Jev state as compact decision evidence: remove noise, preserve labels and units, and keep policy out of the model input.

Updated 2026-09-238–12 min
01

1. Start from the decision boundary

Write the exact Choice, Score, or Noul question first. Then include only facts that could reasonably change that answer. More context is not automatically better context.

02

2. Prefer labeled records over prose dumps

Stable field names make the evidence easier to audit and reduce accidental ambiguity. Preserve identifiers, dates, units, and source labels instead of flattening everything into one paragraph.

const state = {
  ticket_id: ticket.id,
  channel: ticket.channel,
  customer_message: ticket.message,
  product_area: ticket.productArea,
  account_tier: ticket.accountTier,
  previous_failures_24h: ticket.failureCount,
};

// Exclude access tokens, unrelated chat history, and policy decisions.
03

3. Filter deterministically before Jev

Use ordinary code for permissions, exact arithmetic, allowlists, deduplication, and size limits. Jev should handle the semantic judgment that remains after deterministic checks.

04

4. Test state changes independently

Keep a labeled test set and vary one field at a time. Log the normalized state shape so regressions can be traced to input design rather than hidden prompt changes.