Use case
Refund policy check
Ask whether a refund was requested and whether the written policy supports it.
The problem
Support agents re-read the same policy for every duplicate-charge ticket.
What your code does with the answer
Auto-approve only when both noul answers are high. Everything else goes to review.
Two yes/no questions instead of an agent's judgment call
The request carries the ticket, the structured order (two captured charges on one order number) and the refund policy text as state. Two noul questions: does the message request a refund, and does the policy support it given the charges? Both return a probability. With a clear duplicate-charge policy, the policy question comes back near 0.98 — the model is reading the actual policy text you shipped as state, which is why carefully worded policy pages pay off here.
The policy machine
Auto-approve only when both probabilities clear your bar on the same call — many teams run 0.9. One high and one low is not half-approved: it goes to review with the distribution attached, which is exactly what a support agent wants first thing in the morning. Nothing here invents policy positions: the model answers whether your written policy covers this ticket, so a pattern your policy excludes lands correctly in review.
Pitfalls specific to policy checks
The failure mode is policy text written for lawyers: "reasonable use of the refund window" parses as nothing, while "within 30 days of purchase" parses cleanly. Keep the decision scoped strictly to the written policy — if the policy contradicts itself (30 days in one section, lifetime warranty in another), rewrite it, because a typed answer over contradictory text is not a resolution. And when order data lives in your database, put the relevant fields into state explicitly rather than asking the model to infer charges from prose.
The request shape
This is the full request the playground sends for this preset — the same JSON your server sends to /v1/systemone with a Bearer key.
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": {
"ticket": {
"subject": "Duplicate charge",
"message": "I was charged twice for order A-104. Please refund the duplicate."
},
"order": {
"id": "A-104",
"charges": [
{
"amount_usd": 49,
"status": "captured"
},
{
"amount_usd": 49,
"status": "captured"
}
]
},
"refund_policy": "Duplicate charges are eligible for a full refund of the duplicate amount."
},
"questions": {
"refund_requested": {
"type": "noul",
"instructions": "Does `ticket.message` request a refund?"
},
"policy_supports_refund": {
"type": "noul",
"instructions": "Does `refund_policy` support the refund requested in `ticket.message`, given `order.charges`?"
}
}
}'FAQ about this use case
- Can I attach screenshots or PDFs?
- Not in this call — Jev reads text, so paste the relevant transcript or order facts into the state as text or JSON. Up to 100,000 characters covers a long thread.
- How is this different from a chat model decision?
- Its answer space is bounded: both questions return a probability over your declared reading of the policy, not generated prose you have to parse and trust — and the whole check is one credit.
- We change policies often — does that break it?
- No retraining is involved: policy is state, so shipping new text changes what the model sees. Do re-run your ten validation tickets whenever the policy meaningfully changes.