# Refusal > The assistant will not do the thing, and the viewer needs to know whether to rephrase or give up. - Canonical: https://patterns.konigi.com/ai-assistants/refusal - Group: Limits and failure - Level: implementation - Status: published - Updated: September 12, 2026 - Also called: declined response, safe completion, guardrail message --- ## Problem The viewer asked for something and got a polite paragraph explaining that it won't be provided. They can't tell whether the request was outside the product's abilities, against its rules, or simply misunderstood, and those three call for completely different next moves. ## Solution Separate the three cases, because collapsing them into one apologetic voice is what makes this pattern so disliked. **Cannot** is a capability limit. The assistant has no access to that system, cannot see that file type, cannot browse. The useful response names the limit and points at whatever does work. **Will not** is a policy decision. The request falls outside what the product allows. The useful response says that plainly, in one sentence, without explaining ethics to an adult. **Does not know** is a knowledge limit. The answer is outside training data, past a cutoff, or not in the retrieved corpus. The useful response says so and offers to look, and this case is the one most often disguised as the other two. Each of the three deserves a different sentence and a different offer, and the offer is what turns a refusal into a usable turn. HAX guideline 11 asks systems to make clear why they did what they did, and a refusal is the moment a viewer most wants that and is least often given it. PAIR's chapter on graceful failure supplies the rest of the shape: explain, then give a path forward. Tone is the most complained-about property of this pattern anywhere in the field. A refusal that moralises, restates the request back as if it were sinister, or lectures about responsibility produces more damage to trust than the refusal itself. State the limit and offer the nearest thing available. Length is a tell here, since a long refusal is almost always a defensive one. False positives are the real cost and the one the metrics hide. A refusal on a legitimate request teaches the viewer that the product is unreliable for a whole category of work, and they don't come back later to test whether the boundary moved. Because they stop asking, the failure never appears in the logs as a failure, which makes this the most under-measured problem in the pattern. An appeal path, even a simple report control that a human reads, is the only cheap way to find out how often it happens. Partial compliance beats refusal wherever it's possible. Answering the safe eighty per cent of a request and naming the part that was withheld leaves the viewer better off than a blanket decline, and it makes the boundary legible in a way the viewer can work with. ## Use when The system has a real limit, whether that limit is capability, policy or knowledge. ## Don't use when The request is answerable with a caveat. Reaching for a refusal where a hedged answer would serve is the habit that trains people to take their work somewhere with fewer rules. ## Trade-offs Naming the category is more useful and tells a determined person exactly which wall they hit, which is a genuine adversarial cost. Offering an alternative is kinder and occasionally reads as evasion when the alternative is much weaker than the request. Short refusals are better and can read as curt where a viewer expected an explanation. A per-category message is more useful than a generic one, and it creates a maintenance surface that drifts out of step with the policy it describes. ## Checklist - Can the viewer tell whether this is a capability, policy, or knowledge limit? - Is there an offer of the nearest thing the assistant can do? - How long is the message, and does it moralise? - Is partial compliance possible instead of a full decline? - Is there a way to report a wrong refusal, and does a human see it? - Is the false-positive rate measured at all? - Does the refusal contradict what the first-run state or the prompt starters promised? - Does it read the same way on the tenth occurrence as the first? - Is a policy decline visually distinguishable from an error? - Can the viewer tell whether rephrasing would help? ## Compare **Claude** tends toward explaining the boundary and offering an adjacent version of the request. The turn stays productive, and it runs long. **ChatGPT** favours shorter declines with a suggested reframing, so the next move is usually visible in the message itself. **Gemini** more often redirects to search for knowledge-limited cases, converting a decline into a handoff rather than an ending. **Microsoft Copilot** in an enterprise tenant has a fourth case the consumer products lack, where the refusal is about the viewer's permissions rather than the model's policy, and saying which one it is matters more there than anywhere else. ## Related Generation error looks similar on screen and means the system broke rather than declined. Knowledge cutoff notice covers the third category before a question is even asked. First-run state is where the limits should have been set out in advance. Prompt starters create the expectations a refusal disappoints. Usage meter is the other kind of no, where the limit is quota rather than policy. ## Related patterns - [Generation error](https://patterns.konigi.com/ai-assistants/generation-error) — The stream died halfway and left a half-written paragraph on the screen. - [Knowledge cutoff notice](https://patterns.konigi.com/ai-assistants/knowledge-cutoff-notice) — The answer is stated in the present tense about a world the model last saw a year ago. - [First-run state](https://patterns.konigi.com/ai-assistants/first-run-state) — The most common screen in the product is an empty box, and it has to teach without running a tour. - [Prompt starters](https://patterns.konigi.com/ai-assistants/prompt-starters) — An empty box tells a first-time viewer nothing about what the thing can do. - [Usage meter](https://patterns.konigi.com/ai-assistants/usage-meter) — The viewer is spending a finite resource they cannot see until it runs out. ## Sources - [Microsoft HAX Toolkit, Guideline 2, Make clear how well the system can do what it can do](https://www.microsoft.com/en-us/haxtoolkit/guideline/make-clear-how-well-the-system-can-do-what-it-can-do/) - [Google PAIR, Errors and Graceful Failure](https://pair.withgoogle.com/chapter/errors-failing/) - [Microsoft HAX Toolkit, Guideline 11, Make clear why the system did what it did](https://www.microsoft.com/en-us/haxtoolkit/guideline/make-clear-why-the-system-did-what-it-did/) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.