Ask Multiple Jev Questions in One Request

One state, many independent questions

Jev ingests state once and evaluates the question map against that state in parallel. A support ticket can produce department (Choice), urgency (Score), refund_requested (Noul), and churn_risk (Noul) in one response.

Do not send the same state four times unless those questions genuinely require different context, provider settings, or execution timing.

A fourth question

Add the following member to the complete question map in the API guide:

{
  "churn_risk": {
    "type": "noul",
    "instructions": "Does the customer explicitly threaten to cancel their subscription?"
  }
}

Keep this distinct from refund detection. Asking for a duplicate charge to be returned does not necessarily mean the customer plans to cancel. The question key only identifies the returned answer; the meaning must be in instructions.

Parallel does not mean sequential reasoning

A later entry cannot consume an earlier answer in the same request. If you first classify a product and then need product-specific policy, your code must select that policy before a second request. Alternatively ask speculative independent questions and use only the relevant answers afterward.

Both token limits apply

The request budget is 64000 tokens for state and all questions. State plus the longest single question must fit 32000. A long state can violate the second constraint even if your total remains under the first.

Cost and reliability

Shared state avoids duplicated input, but extra questions are not free input. Compare the batch’s actual usage with separate calls. Do not add speculative judgments you never consume unless their latency benefit is worth their cost.

Treat a missing required answer as a failed decision, not as permission to continue. Validate expected keys and types before calculating a combined action. Store one request ID and model version so a batch can be traced without losing which question caused the route.

When separate requests are better

Separate requests when a dependency exists, different evidence is required, privacy boundaries differ, or one low-priority judgment should not affect the latency budget of another. Use fan-out for independent decisions and a cascade for staged computation.