Skip to content
Secnd

Refund decision

Separate a refund recommendation from payment execution.

First compute deterministic eligibility: purchase ownership, refund window, amount, and previous refunds. The model can interpret the customer’s intent; it cannot override those checks.

request
{
  "model": "ren-zero-2026-11-12",
  "type": "choice",
  "situation": "Eligibility checks passed. Customer: The item arrived cracked and I want my money back. A replacement is also available.",
  "question": "Which resolution best matches the customer's explicit request?",
  "options": [
    {"id": "refund", "description": "Customer clearly requests a refund"},
    {"id": "replace", "description": "Customer clearly prefers a replacement"},
    {"id": "review", "description": "Intent is ambiguous, contradictory, or unsupported"}
  ],
  "threshold": 0.95
}

Treat refund as a recommendation. Your backend checks eligibility again, obtains any required approval, and uses the payment provider’s idempotency mechanism. Never put the payment operation inside an inference retry loop.

Send review or ask_human to a reviewer. Test negation, multiple orders, already-refunded cases, and requests that quote someone else’s words. The illustrative threshold is not evidence of financial safety.