One state, several questions: using Jev’s parallel interface

A common first integration asks Jev one question about one message. The API also accepts several questions about the same state in a single call. TypeSafe’s introduction says those questions are evaluated independently and in parallel. That can simplify a workflow that needs multiple judgments about the same ticket, document, or request.

A support-ticket example

Suppose the state is a customer’s message and relevant account context. A Choice can pick a destination team. A Score can rate the level of frustration. A Noul can ask whether the message explicitly requests a refund. Your code receives three typed results and decides whether to queue, escalate, or request review. You avoid three separate request setups for judgments that all need the same state.

Independence is a design constraint

One answer is not automatically aware of another answer. Do not assume the questions form a chain of reasoning or that all outputs will satisfy a business invariant together. If a rule says “never auto-refund without a verified duplicate charge,” enforce that rule in code using trusted account data. If a later question depends on a previous result, make that dependency explicit in your program rather than hiding it in the wording of a parallel question.

Keep the request focused

More questions are useful only when each changes an action or supplies evidence to a reviewer. A long list of vague judgments makes evaluation harder. Start with an individual question, test edge cases, then group independent questions that share the same relevant state. The state guide explains how to structure that context, and the primitives guide helps choose a result type.

Published 24 September 2026. API behavior checked against the official introduction and state documentation available on that date.