Refund policy eligibility

Read a refund request against your written policy and recommend a decision.

Limits to keep in mind

Refund decisions affect customers' money. Do not issue refunds on the model's answer alone. Keep code checks and human approval on this path, and keep an appeal route for "not eligible".

Problem

Refund policies have windows, plan types and exceptions. Agents apply them inconsistently, and customers in similar situations get different answers.

Goal

Recommend eligible, not eligible, or exception review for each complete request, and keep money-moving actions behind code checks and human approval.

Input / state

The request, the matched charge with values computed in code, and the policy text.

request: The customer's reason for the refund.
charge: The matched charge, including plan type and days since purchase computed in code.
policy: The refund policy, as written.

Decision question

ChoiceQuestion key policy_outcome

Under `policy`, how should this refund request be decided?

Options

eligibleThe policy clearly allows a refund in this situation.
not_eligibleThe policy clearly excludes this situation.
exception_reviewThe situation falls under an exception or discretionary clause, or the policy does not clearly cover it.

Allowed outcomes

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

EligibleChoice is eligible and probability meets your stricter threshold for refunds.
Not eligibleChoice is not_eligible and confidence meets your threshold.
Exception reviewChoice is exception_review.
Needs a personConfidence is below your threshold.

Example scenarios

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

Example state

{
  "request": "We're not using it as much as we expected.",
  "charge": {
    "plan": "annual",
    "amount": "$240.00",
    "days_since_purchase": 12
  },
  "policy": "Annual plans: full refund within 30 days of purchase. Monthly plans: no refunds after the billing date. Duplicate charges are always refunded. Other cases are reviewed by the billing team."
}

Outcome

Illustrative

Eligible

Choice is eligible and probability meets your stricter threshold for refunds.

Why

An annual plan 12 days after purchase is inside the 30-day window.

Better together with

Complementary classifiers, and what each one adds here.

Refund information checkChoice
Decide eligibility only on requests that have the charge and the reason.
Combined inRefund request resolution
Refund request detectionNoul
Detection is the entry point that starts this decision.
Combined inRefund request resolution

Used in chains

Refund request resolutionStep 3 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 · Pattern
Routing by probability
Gives riskier actions a higher probability threshold before code acts on them.
SourcedTypeSafe docs · Documentation
Model jaggedness
Lists known failure modes, including literal reading, arithmetic, date comparison, option order and adversarial content.
SourcedHugging Face · Model card
Kev-4B model card
Supports choice, score and noul questions in English, shows a billing/shipping/returns routing call, and lists fully automated consequential decisions without human review as out of scope.

Using it well

Give actions that move money a higher probability threshold than actions that only reply.
Compute days since purchase, amounts and limits in code and pass the results in. Arithmetic and date comparison are documented weak spots.
Treat "eligible" as a recommendation: code checks amount limits and earlier refunds, and a person approves anything above your limit.

Request definition

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

{
  "model": "jev-latest",
  "state": {
    "request": "<request>",
    "charge": "<charge>",
    "policy": "<policy>"
  },
  "questions": {
    "policy_outcome": {
      "type": "choice",
      "instructions": "Under `policy`, how should this refund request be decided?",
      "criteria": {
        "eligible": "The policy clearly allows a refund in this situation.",
        "not_eligible": "The policy clearly excludes this situation.",
        "exception_review": "The situation falls under an exception or discretionary clause, or the policy does not clearly cover it."
      }
    }
  }
}

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.