Worked example: design a Jev workflow for a missing delivery

What does the support team actually need to decide?

1. Customer: “My order was marked delivered yesterday, but there is no parcel at my door. I need it today. Can you refund me now?”
2. The narrow task is to choose the first handling queue: shipping, billing, technical support, or review. A refund is a separate authorized workflow.
3. The application verifies that the order belongs to this account, the carrier says delivered, and the signer is unknown. Jev cannot know facts that the application did not supply.

01 · Define the action boundary

Only assign a reversible queue automatically when facts are complete and a threshold validated on your own cases is met. Missing data, conflicting intents, uncertain output, and API errors go to review. Refunds require identity, order, and policy checks.

02 · Build the state

Keep the current message and verified delivery facts, not an entire account history. Label the customer's claim separately from the carrier's record. Remove names, addresses, phone numbers, and payment details that do not affect routing. If the order cannot be found, gather facts first.

03 · Ask three atomic questions

Choice selects the first team. Noul asks whether the message conveys time pressure. Score rates the tone against a defined low-to-high rubric. These are independent answers. Code can prioritize urgent tickets without treating tone as refund authority.

04 · Read an illustrative response

Imagine Choice selects shipping with confidence 0.84, Noul returns 0.91, and Score lands in the middle. If a threshold of 0.88 had been validated for this workflow, this ticket would still go to review. All three figures are invented to show the decision path, not Jev measurements or recommended cutoffs.

05 · Test what breaks

A refund-only message exposes a poor option set; a missing carrier record needs fact gathering; overlapping shipping and charge disputes may need two tickets or review. Keep negations such as ‘I am not in a hurry’ and mixed-language cases in regression data.

A minimal state with provenance

customer_claim: marked delivered but missing; today_needed: true
verified_order_owner: true; carrier_status: delivered
signature: unknown; refund_authorized: not_checked

Three questions against one state

This uses the shape shown by the official API docs with synthetic values. Check current API constraints and access before sending a real request.

{
  "state": "customer_claim: marked delivered but missing; today_needed: true\nverified_order_owner: true; carrier_status: delivered\nsignature: unknown; refund_authorized: not_checked",
  "model": "jev-latest",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this ticket first?",
      "criteria": {
        "shipping": "Delivery, tracking, missing parcel",
        "billing": "Charges, payment, subscription",
        "technical": "Product bug or integration",
        "review": "More than one intent or insufficient information"
      }
    },
    "urgent": {
      "type": "noul",
      "instructions": "This message expresses time sensitivity."
    },
    "tone": {
      "type": "score",
      "instructions": "How distressed does the customer appear?",
      "criteria": [
        "Calm, factual",
        "Concerned but civil",
        "Strong distress or anger"
      ]
    }
  }
}

An illustration, not a benchmark

These numbers were written by us for explanation. Choice and Score expose confidence and probabilities as distinct fields; Noul exposes noul. Check answer IDs, types, and required fields before acting.

{
  "answers": {
    "team": {
      "type": "choice",
      "choice": "shipping",
      "confidence": 0.84,
      "probabilities": {
        "shipping": 0.81,
        "billing": 0.1,
        "technical": 0.02,
        "review": 0.07
      }
    },
    "urgent": {
      "type": "noul",
      "noul": 0.91
    },
    "tone": {
      "type": "score",
      "score": 1.0,
      "confidence": 0.78,
      "probabilities": {
        "0": 0.08,
        "1": 0.82,
        "2": 0.1
      }
    }
  }
}

Six regression cases to label before using a model

When is this ready to ship?

1. Sample de-identified target tickets. Have people label the first team and whether automatic routing is permitted. Report common cases separately from costly rare ones.
2. Tune a threshold on one set and verify on held-out cases. Measure costly misroutes, review rate, end-to-end p50/p95, and cost per thousand tickets.
3. Roll out to a small share using reversible actions. Log model and question versions, request IDs, and human corrections. Re-evaluate after model or option changes.