State: the material Jev evaluates
State is the content you ask a System One model to evaluate: a support message, a passage, or a slice of application data. It travels in the state field next to questions.
Each request evaluates one state against one or more questions. Every question sees that same state and is scored independently.
Allowed shapes
TypeSafe documents three useful formats:
| Format | Use when | Example |
|---|---|---|
| String | One piece of text | "My card was charged twice." |
| Object | Named fields and related records | { "message": "...", "order_id": "A-104" } |
| Array | A sequence of messages or records | ["Hi", "My card was charged twice."] |
Prefer an object for most production calls so each part has a name. Point questions at fields with backtick paths such as ticket.messages[0].text.
What cannot go in state
Jev accepts text only. Strings, JSON objects, and arrays of text values are valid. Images, audio, video, and binaries are not. Pre-process those into text or structured fields first.
English is the primary training language. Other languages, including CJK scripts, are accepted but TypeSafe says accuracy is currently lower. Test on your own content and watch confidence.
Filter before you send
The jev-1.13 jaggedness note says accuracy falls as the state grows with unrelated detail. Retrieve and filter in code. Send the fields the question needs. If you cannot filter, a Noul that asks “is this passage relevant?” is the documented workaround (see the classifying RAG passages cookbook).
Context limits live on the models page: 64k tokens for state plus all questions combined, and 32k for state plus the single longest question.
State is not the question
Keep facts in state. Keep the judgment in instructions and criteria. Mixing a long rubric into the state and a vague “decide” into the question is the opposite of the System One loop.
Sources
Public TypeSafe or adjacent documentation only. No private claims.