What is the refund eligibility Jev pattern?

Refund eligibility uses two Nouls: refund_requested and policy_supports_refund. You supply order facts and the policy excerpt; your code moves the money.

Can refund eligibility issue the refund?

No. Jev returns probabilities. Your billing API issues the refund when both Nouls and your amount cap clear.

Why two Nouls for refund eligibility?

Asking and being allowed are different facts. A clear ask against a forbidding clause should not pay out.

What if the policy excerpt is missing?

Do not run refund eligibility. Fetch the clause first. A Noul without the text is a guess.

Is refund eligibility legal advice?

No. It is a starting schema. Calibrate on your own cases. Jev Patterns is not affiliated with TypeSafe AI and does not practice law.

OpsNOUL

Refund eligibility Jev pattern

Ask two Nouls: did they request a refund, and does the policy you passed in support one?

Refund and policy stamps on a blotter with a policy booklet — Two Nouls: requested, and policy supports.

Eligibility is not a vibe. It is “request present?” times “policy allows?”. Keep the policy text in state so the model is judging against your rules, not against internet averages. Combine the two numbers in code — that is where finance policy belongs.

This refund eligibility schema is a paste-ready TypeSafe Jev request for jev-latest. Copy the JSON, keep thresholds in your code, and calibrate on your labels. Jev Patterns is independent and not affiliated with TypeSafe AI.

Open in Studio

Use refund eligibility when

A ticket, chat, or chargeback note might contain a refund request.
You can pass the relevant policy excerpt in state.
You want a human to approve the actual money movement.

Do not use refund eligibility when

You need Jev to calculate proration or tax.
The policy is not in state and you hope the model remembers it.
You want a generated apology.

Confidence thresholds for refund eligibility

Keep these in your code. They are not part of the model call.

When	Action
refund_requested.noul >= 0.80 && policy_supports_refund.noul >= 0.80	Queue a refund for a human to execute
refund_requested.noul >= 0.80 && policy_supports_refund.noul <= 0.30	Send the decline template; do not invent a new policy
either Noul is between 0.30 and 0.80	Human review — 0.5 is unsure, not 'maybe refund half'

Pass examples

Cancelled by operator

Both Nouls high. Still have a human press the refund button.

{
  "ticket": "Can I get a refund?",
  "policy": "Cancelled flights are eligible for a full refund.",
  "order": {
    "status": "cancelled_by_operator"
  }
}

Change of mind

Request high, policy low. Auto-decline is allowed if you trust the excerpt.

{
  "ticket": "I don't want this anymore. Refund please.",
  "policy": "Change-of-mind returns are not eligible.",
  "order": {
    "status": "fulfilled"
  }
}

Status question only

refund_requested near 0. Do not start a refund workflow.

{
  "ticket": "Has my order shipped?",
  "policy": "Cancelled flights are eligible for a full refund."
}

Ambiguous examples

Store credit vs cash

Request is present. Cash vs credit is not in the policy excerpt.

{
  "ticket": "Can I get my money back or at least credit?",
  "policy": "Cancelled flights are eligible for a full refund."
}

Partial use

“Discretion” is a human word. Keep the Noul in the middle.

{
  "ticket": "Refund the days I didn't use.",
  "policy": "Unused time is refunded pro rata at finance discretion."
}

Policy not passed

Without policy in state, policy_supports_refund is undefined. Do not call it.

{
  "ticket": "Refund please."
}

The problem refund eligibility is for

Ops teams paste refund policy into a chat model and ask “should we refund?” The model writes a paragraph that sounds like a lawyer and then a boolean that does not match the paragraph. Finance still has to read it. Refund eligibility should not produce a paragraph.

This refund eligibility pattern asks two Nouls: is the user asking for a refund, and does the supplied policy excerpt support a refund given the order facts. Money movement stays behind your if statements. Jev never talks to the processor.

If the policy is not in state, policy_supports_refund is a prior, not a reading. That is the whole lesson.

Why this refund eligibility schema uses Jev

Splitting refund_requested from policy_supports_refund stops “they said please” from becoming a payout. A rant without a refund ask should not open a case. A clear ask against a no-refund digital-goods clause should not pay out just because the Noul on the ask is high.

Nouls return probabilities. 0.5 on policy_supports_refund means get a human, not “half refund.” Partial refunds are a finance rule, not a System One primitive.

Do not add a Choice of refund | credit | deny until those are real product actions with owners. Start with the two Nouls.

What to put in state for refund eligibility

Required: order date, product type, amount, reason text, and the policy excerpt that applies to that product. Refund eligibility without the excerpt is fortune telling.

Pass prior refunds on the account if your policy cares. Pass whether the download happened. Pass chargeback status so you do not double pay.

Keep card numbers out of state. You do not need them for refund eligibility.

How to wire refund eligibility in code

If refund_requested.noul >= 0.80 and policy_supports_refund.noul >= 0.85 and amount is under an auto-limit, call your billing API. Else queue. Log both Nouls next to the charge id.

If policy_supports_refund is in the middle, do not round. Show the excerpt and the Noul to an ops person.

Never generate the customer email with Jev. Templates: approved, denied, need-more-info.

Eval plan: replay a month of refund tickets with the policy excerpt that applied that day, not today’s clause. Refund eligibility that reads the wrong contract will look calibrated and still be wrong. Keep the excerpt id in the log.

Failure modes

Policy in the prompt, not in state

Instructions are not the contract. Refund eligibility reads state. Put the clause in the JSON.

Chargeback plus refund

Deterministic: if a chargeback is open, skip the model and follow finance. Do not ask Jev to be your processor.

Talking like support

This pattern does not apologize. It answers two booleans.

Copy, run, calibrate

The JSON in the rail is the refund eligibility request for jev-latest. Copy it into your stack, or open Refund eligibility in Jev Studio and draw the fixture bars. Thresholds stay in your repository. Calibrate on your labels before you auto-apply. Official model docs live at docs.typesafe.ai. Jev Patterns is independent and not affiliated with TypeSafe AI.

Refund eligibility: FAQ

What is the refund eligibility Jev pattern?: Refund eligibility uses two Nouls: refund_requested and policy_supports_refund. You supply order facts and the policy excerpt; your code moves the money.
Can refund eligibility issue the refund?: No. Jev returns probabilities. Your billing API issues the refund when both Nouls and your amount cap clear.
Why two Nouls for refund eligibility?: Asking and being allowed are different facts. A clear ask against a forbidding clause should not pay out.
What if the policy excerpt is missing?: Do not run refund eligibility. Fetch the clause first. A Noul without the text is a guess.
Is refund eligibility legal advice?: No. It is a starting schema. Calibrate on your own cases. Jev Patterns is not affiliated with TypeSafe AI and does not practice law.

Last reviewed 21 September 2026. Independent of TypeSafe AI.