Refund approval pack

When to run

• A refund/credit request arrives in a ticket or is raised by an agent
• "Should we refund Acme for the outage" / billing dispute review

Computer scopes

• Billing: invoices, payments, subscription terms for the account
• Docs: the written refund/credit policy (the source of truth for eligibility)
• Support: the triggering ticket and the account's request history
• Precedents: prior approved/denied refund decisions

Workflow

1. Identify the request: amount, period, stated reason, contract terms in force.
2. Run the eligibility check against the written policy clause by clause; cite each clause pass/fail. If the policy is silent, say the policy is silent — do not improvise doctrine.
3. Pull precedents: nearest prior decisions with outcomes, so like cases get like treatment.
4. Assemble context that bears on judgment: account health, lifetime value, prior make-goods, whether the root cause was ours (link incident records if so).
5. Compute the options: full refund, prorated credit, goodwill credit — each with financial impact and policy basis.
6. Package the recommendation with a stated rationale and stop. Route to the approver of record by amount tier. On decision, log outcome to the precedent corpus.

Guardrails

• Autonomy: L3-gated. This skill never executes a refund, ever. It prepares; a human approves; execution happens in the billing system by the human or a separately authorized flow.
• Recommendation includes the strongest argument against itself when precedents conflict.
• Every pack is written as if the customer might read it — because someday one will.

Output

Eval fixtures

• Set: 40 refund scenarios against a sandbox policy, including 8 policy-silent cases and 6 conflicting-precedent cases.
• Rubric: clause-check correctness; policy-silent cases flagged as such (never improvised); option math exact; recommendation consistency with like precedents.
• Ship gate: clause-check accuracy 100%; improvised-doctrine rate 0.