Refusals and safe failure

Every production assistant spends part of its life not answering: it refuses, hands off, abstains, asks a clarifying question or degrades. Each is a designed outcome with its own trigger, wording, next step and metric, not an error path. You measure two errors together: over-refusal (benign requests refused, pushing members to the phone queue) and under-refusal (requests answered that should not have been). You set the operating point per risk tier, and you choose per tier whether a broken guardrail fails closed or open. The result is a small, versioned policy function plus approved wording, both tested offline.

Key takeaways:

• "Not answering" has at least four shapes (refuse, abstain, clarify, hand off). Users and metrics need them kept apart.
• Over-refusal is a defect with a number. Track a false-refusal rate on a benign set alongside the unsafe-pass rate.
• Fail closed or fail open is a per-tier decision. A timed-out guardrail means "no decision", never "allowed".
• Every refusal names a reason category and a next step. A refusal without a route is a dead end.
• Fallbacks lower autonomy as they lower quality. The last rung is always a human.