Every AI product makes decisions it does not surface. What to answer. What to avoid. How much certainty to project. When to punt to a human. The product team usually has opinions about all of these, even if those opinions have never been written down.
The refusal register is where you write them down.
I am not describing a content policy document. I am describing a design artifact: a named, versioned list of what your AI declines to do, under what conditions, and what it says instead. Not a legal document. A design resource that sits next to your interaction principles and gets reviewed the same way.
Why most teams skip it
The answer is usually one of two things. The first is that refusals feel like an edge case. The team has the core flow to build. The features to ship. The refusal states feel like something to handle later.
The second is that refusals feel defensive. Teams want to talk about what their product can do. Naming what it refuses feels like giving critics ammunition. Better to stay quiet.
Both of these are wrong in the same direction. The refusal state is not an edge case. It is the moment the product reveals what it actually is. A product that refuses confidently is a product with a clear behavioral contract. A product that refuses inconsistently, or that never refuses at all, is a product that has not been designed to handle the real range of what users will ask.
What a refusal register contains
It is four things per entry. The condition: what input or context triggers this refusal. The refusal text: what the product actually says. The rationale: why this is the right call. The alternative path: what the product offers the user instead of the thing it declined.
That last part is often missing. A refusal that terminates the interaction is a refusal that does not serve the user. A refusal that offers a next step is a refusal that keeps the relationship intact. The design work is in the alternative path.
The trust argument
I have audited enough AI products to know that the refusal state is disproportionately important to user trust. Users remember when a product surprised them. They remember when it said something that felt wrong. They remember when it refused in a way that felt arbitrary or inconsistent. Those moments accumulate. They are hard to reverse.
A product that has done the design work on its refusal states does something useful: it gives users a mental model they can rely on. They learn what the product will and will not do. That predictability is the foundation the Trust Equation is built on. Without it, the score collapses.
Run the Manipulation Matrix on your refusal states. Ask whether a refusal is principled or defensive. Ask whether the alternative path serves the user or the product. The answers will tell you whether you are designing trust or just protecting yourself.