Field note · 013Apr 20266 min
Refusals are a product surface, not a safety afterthought
When a model says no, it is communicating with your user. That belongs to the design team as much as to trust and safety.
AL
The Acorn Labs bench
Southwark · SE1
Every team we have worked with has, at some point, treated refusals as something the model layer handles and the product layer hides. This is a mistake of about the same size as treating 500 errors as something the backend handles and the product layer hides.
A refusal is a moment of trust
When the user asks the system to do something and the system declines, the user has just learned something about the product. They have learned the shape of what it is, by being told the shape of what it isn't. The framing, the tone, the link to an alternative path — that is product design, not policy enforcement.
A model saying 'I can't help with that' is the AI-era equivalent of a 404 page with no nav.
What we ship instead
- A typed refusal contract between the model and the UI, so the front-end knows why.
- Per-category copy, written by a real writer, not by the model.
- A logged 'I wish this had worked' affordance, because every refusal is a roadmap signal.
end