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.
{
"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.