Jev Use Cases

Route a blank checkout

Use a Choice like this to send every inbound ticket to one of your queues. The answer names the team and carries a probability per option, so a close call can fall back to a human instead of a wrong queue.

Choice returns the owning team and the probability of each team.

{
  "model": "jev-1.13",
  "state": "Checkout shows a blank page after Pay is clicked. The customer is on the live store, not a sandbox.",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should own this ticket?",
      "criteria": {
        "payments": "Checkout, billing, or payment processing.",
        "frontend": "Rendering, layout, or browser behavior.",
        "account": "Login, permissions, or profile access."
      }
    }
  }
}

Is this a refund ask?

A Noul is the right shape when the question is binary — does this message ask for money back. Gate a refund macro or a review queue on the noul value rather than parsing generated text.

Noul returns a yes probability, not a paragraph to parse.

{
  "model": "jev-1.13",
  "state": "I was charged twice for the same annual plan this morning. Please send the extra charge back.",
  "questions": {
    "refund": {
      "type": "noul",
      "instructions": "Is the customer asking for money back?"
    }
  }
}

How urgent is the payout failure?

Score fits ranked judgment. Define your own levels — here a three-step urgency scale — and use the fractional score to sort a backlog instead of reading labels by hand.

Score places the note on your scale and returns the distribution.

{
  "model": "jev-1.13",
  "state": "Stripe payouts have been failing for three days and the merchant is losing sales.",
  "questions": {
    "urgency": {
      "type": "score",
      "instructions": "How urgent is this ticket?",
      "criteria": [
        "Can wait for the next release",
        "Should be handled this week",
        "Blocking revenue right now"
      ]
    }
  }
}

Credential request in a message

Run a Noul in front of a human review queue as a pre-filter. Messages asking for credentials get flagged by probability; the runner-up probability tells you how much to trust the gate.

A Noul probability is the gate before a human review queue.

{
  "model": "jev-1.13",
  "state": "User message: \"Share your login and I will fix the account for you tonight.\"",
  "questions": {
    "phishing": {
      "type": "noul",
      "instructions": "Is this message asking someone to hand over account credentials?"
    }
  }
}

Qualify an inbound note

Choice separates buying intent into the buckets your sales process already has — ready, nurture, ignore — so routing rules stay explainable and each option keeps its probability.

Choice separates a buying window from a note that only shows interest.

{
  "model": "jev-1.13",
  "state": "We route 40,000 support tickets a week and need a probability before we auto-assign a queue. Budget is approved this quarter.",
  "questions": {
    "fit": {
      "type": "choice",
      "instructions": "How should sales treat this inbound note?",
      "criteria": {
        "ready": "A real workflow, a volume, and a buying window.",
        "nurture": "Interest without a stated workflow or timeline.",
        "ignore": "No product fit."
      }
    }
  }
}

Guaranteed-return listing

Noul works for policy checks where the rule is written in plain language. The listing either promises a guaranteed return or it does not — the probability is your enforcement signal.

Noul answers the policy question you wrote, not a generic safety essay.

{
  "model": "jev-1.13",
  "state": "Listing text: \"Guaranteed 30% returns every month. Send crypto to this wallet to join.\"",
  "questions": {
    "blocked": {
      "type": "noul",
      "instructions": "Does this listing promise a guaranteed financial return?"
    }
  }
}

Renewal risk in a note

Score renewal risk on your own ladder instead of a vendor's sentiment score. Because the levels are yours, the fractional score maps directly to the playbook step you already run.

Score uses your three levels, from unlikely to likely to cancel.

{
  "model": "jev-1.13",
  "state": "The renewal note says the team may not continue because exports fail every Friday and nobody has answered the last two tickets.",
  "questions": {
    "risk": {
      "type": "score",
      "instructions": "How high is the chance this account does not renew?",
      "criteria": [
        "Unlikely to leave",
        "Unhappy, still using the product",
        "Likely to cancel"
      ]
    }
  }
}

Which invoice exception?

Choice with a 'both' option catches compound exceptions without a second call. Accounts payable gets the exception type plus per-option probabilities to route the dispute.

Choice can name over-PO, an unexpected line, or both, with probabilities.

{
  "model": "jev-1.13",
  "state": "Vendor invoice 4481 is $18,400. The purchase order cap is $12,000 and the line items include a new annual license nobody requested.",
  "questions": {
    "exception": {
      "type": "choice",
      "instructions": "Which exception should accounts payable open?",
      "criteria": {
        "over_po": "The amount is above the purchase order.",
        "unexpected_item": "A line item was not requested.",
        "both": "The amount and a line item are both wrong."
      }
    }
  }
}

Patterns that compose

The examples above are single calls. TypeSafe's docs describe a few patterns for combining them:

• Confidence-gated routing — act automatically only when confidence clears your bar, and send the rest to a person.
• Speculative fan-out — ask the same question with reordered Choice options or a trimmed state, and compare answers for consistency.
• Guardrails — run a Noul on user input before it reaches a generative model or a production action.
• RAG passage filtering — use a Noul or Score per candidate passage to keep only the relevant context before generation.

FAQ