Refund information check

Find out what a refund request is missing before anyone decides on it.

Problem

Refund requests often arrive without enough to act on: no way to identify the charge, or no reason. Agents spend a reply asking for it, and automated decisions on incomplete requests go wrong.

Goal

Choose the right follow-up (or none) so the customer is asked once, for the right thing.

Input / state

The message, the customer's recent charges looked up in code, and what the policy requires.

message: The customer's refund request.
account_charges: Recent charges from your billing system, fetched in code.
policy_requirements: What the refund policy needs to make a decision.

Decision question

ChoiceQuestion key missing_information

What, if anything, is missing from this refund request that `policy_requirements` needs before a decision can be made?

Options

completeOne charge in `account_charges` clearly matches the request, and the reason for the refund is stated.
missing_order_referenceThe reason is stated, but the request could match more than one charge, or none.
missing_reasonThe charge can be identified, but the customer does not say why they want a refund.
missing_multipleNeither the charge nor the reason can be identified.

Allowed outcomes

Decided in your code from the answer and its confidence. Thresholds are yours to set and test.

CompleteChoice is complete and confidence meets your threshold.
Ask which chargeChoice is missing_order_reference.
Ask for the reasonChoice is missing_reason.
Ask for detailsChoice is missing_multiple.
Needs a personConfidence is below your threshold.

Example scenarios

Predefined demonstrations. No model is called; the outcome shown is an illustrative judgment.

Example state

{
  "message": "I was charged twice for my subscription this month. Please refund the extra charge.",
  "account_charges": [
    {
      "id": "ch_1042",
      "description": "Pro plan, monthly",
      "amount": "$29.00",
      "date": "2026-10-01"
    },
    {
      "id": "ch_1043",
      "description": "Pro plan, monthly",
      "amount": "$29.00",
      "date": "2026-10-01"
    }
  ],
  "policy_requirements": "Identify the charge and the reason for the refund."
}

Outcome

Illustrative

Complete

Choice is complete and confidence meets your threshold.

Why

The two identical charges on the same day match the description, and the reason (a duplicate) is stated.

Better together with

Complementary classifiers, and what each one adds here.

Refund request detectionNoul
Run this only after a refund request is confirmed.
Combined inRefund request resolution
Refund policy eligibilityChoice
A complete request is what makes an eligibility decision meaningful.
Combined inRefund request resolution

Used in chains

Refund request resolutionStep 2 of 3

Sources

Primary documentation this classifier builds on. Scenarios on this page are illustrative, not taken from production use.

SourcedTypeSafe docs · Documentation
System One
Defines the Choice, Score and Noul primitives and walks through a refund request built from a state, independent questions and deterministic checks in code.
SourcedTypeSafe docs · Documentation
Model jaggedness
Lists known failure modes, including literal reading, arithmetic, date comparison, option order and adversarial content.

Using it well

Look up charges in code and pass them in the state. Ask whether the request matches one; never ask the model to produce an order number.
Write the follow-up message from a reviewed template. The classifier only decides which template to use.
Dates and amounts belong in code: compute values such as days since purchase before the request.

Request definition

POST https://api.typesafe.ai/v1/systemone

{
  "model": "jev-latest",
  "state": {
    "message": "<message>",
    "account_charges": "<account_charges>",
    "policy_requirements": "<policy_requirements>"
  },
  "questions": {
    "missing_information": {
      "type": "choice",
      "instructions": "What, if anything, is missing from this refund request that `policy_requirements` needs before a decision can be made?",
      "criteria": {
        "complete": "One charge in `account_charges` clearly matches the request, and the reason for the refund is stated.",
        "missing_order_reference": "The reason is stated, but the request could match more than one charge, or none.",
        "missing_reason": "The charge can be identified, but the customer does not say why they want a refund.",
        "missing_multiple": "Neither the charge nor the reason can be identified."
      }
    }
  }
}

Request shape from the System One API reference; a Kev server accepts the same body. Replace the placeholder state with your data. Requests need your own API key or server.