Why does one tool answer what another declines?

Because each provider decides where its boundary sits, and they differ. Neither behaviour is a fault, and the practical consequence is that refusal patterns are worth testing on your own real requests during a trial, since the ones that matter to your work are unlikely to appear in any demonstration.

Is a refusal the same as the model not knowing?

No, and they are hard to tell apart from the outside. One is a boundary and the other is a limit, and the wording is often similar. Rephrasing usually distinguishes them: a boundary tends to hold across phrasings, while a limit often gives way to a more specific question.

What does over-refusal actually cost?

Adoption, quietly. Each unnecessary decline is small enough that nobody raises it, and the cumulative effect is people concluding the tool is unhelpful for their work and returning to what they did before. It is the failure least likely to appear in any report and most likely to decide whether a rollout takes.

Glossary

Refusal

A refusal is a model declining to answer, which happens both where it should and where it should not, and the second case is the one users actually report.

In plain terms

The assistant says no. Sometimes that is exactly right and nobody thinks about it. Sometimes the request was entirely ordinary and it declined anyway, which is the version people notice, complain about and remember. Both come from the same mechanism, and the difference is where the boundary happens to have been drawn.

Why it matters

Because it is the most visible way a tool disappoints a user, and it is a product decision rather than a fixed property. Two assistants given the same request will not necessarily behave the same way, which means refusal behaviour is something to evaluate during a trial rather than something to discover after rollout, when the people meeting it are the ones you asked to adopt the thing.

How it works

Refusals come from training rather than from a rule somewhere, which is why they are approximate. The model has been shaped to decline categories of request, and it applies that shaping to what it thinks the request resembles. A resemblance is not a match, which is how a question about a medication interaction, a novel's plot or a security setting can trigger the same response as something genuinely unwanted.

Where the boundary sits is set by the provider and differs between them. This is the same mechanism behind a product's moderation behaviour, seen from the user's side rather than the operator's, and it explains an experience everybody has had: the request declined by one assistant and answered by another without hesitation. Neither is malfunctioning; they have been given different instructions about the same territory.

Over-refusal is real and asymmetrically invisible. A model that declines too much produces a stream of small frustrations that mostly go unreported, because the user simply rephrases or gives up and does the task another way. A model that declines too little produces a single incident somebody escalates. Only one of those reaches the people tuning the boundary, and it pushes in one direction.

It is not the same as an inability, and the two look identical to a user. A model may decline because it has been shaped to, or produce a similar-sounding response because the request is outside what it can do. The wording rarely distinguishes them, which is why an apparent refusal is worth testing with a rephrasing before it is treated as a policy boundary.

Two ways to draw the boundary wrong

The two columns are worth holding together because the conversation about refusals almost always takes place in the right-hand one. An incident happened, it was visible, somebody had to answer for it, and the response is to tighten. Nothing in the left-hand column ever arrives to argue the other way, because its evidence is a series of non-events: the person who rephrased twice and then wrote the paragraph themselves, the analyst who stopped asking about the regulated topic because it was easier not to. Those never become a ticket. The practical consequence for a buyer is that the aggregate refusal behaviour of a tool cannot be judged from complaints, and has to be tested deliberately against the requests your own people will actually make, before the tuning has been shaped entirely by the only failure that speaks.

Seen in the wild

An assistant declining something entirely ordinary, which is trained caution overshooting rather than any rule about that particular request.
Claude
A support agent that answers from help content and hands off to a person at its limit, which is a refusal designed to land somewhere useful.
Tidio Lyro
A generator that optimises for safe and usable over spectacular, which is the same boundary expressed as an aesthetic ceiling.
Adobe Firefly

Common misconceptions

People assume

A refusal means the request was inappropriate.

In fact

It means the request resembled something the model was shaped to decline. Resemblance is approximate, so ordinary questions about medicine, security, fiction and law are declined regularly. Treating every refusal as a verdict on the user is unfair to the user and misleading about the system.

People assume

Refusal behaviour is a fixed property of the technology.

In fact

It is a product decision, and providers draw the line differently. That is why the same request succeeds in one assistant and fails in another, and why refusal behaviour belongs in an evaluation alongside capability rather than being treated as a constant.

Telling them apart

Refusal vs Content moderation

Refusal

What the user experiences: the answer that did not come.

Content moderation

The operator's side: the rules deciding what is permitted.

The same boundary, seen from either side. Users report refusals; operators tune moderation.

Questions

Why does one tool answer what another declines?: Because each provider decides where its boundary sits, and they differ. Neither behaviour is a fault, and the practical consequence is that refusal patterns are worth testing on your own real requests during a trial, since the ones that matter to your work are unlikely to appear in any demonstration.
Is a refusal the same as the model not knowing?: No, and they are hard to tell apart from the outside. One is a boundary and the other is a limit, and the wording is often similar. Rephrasing usually distinguishes them: a boundary tends to hold across phrasings, while a limit often gives way to a more specific question.
What does over-refusal actually cost?: Adoption, quietly. Each unnecessary decline is small enough that nobody raises it, and the cumulative effect is people concluding the tool is unhelpful for their work and returning to what they did before. It is the failure least likely to appear in any report and most likely to decide whether a rollout takes.

Key takeaways

Comes from training rather than a rule, so it works on resemblance and overshoots.
Where the boundary sits is a provider decision, and providers differ.
Over-refusal is invisible: users rephrase or give up rather than reporting it.
Only the under-refusal failure escalates, so the pressure runs one way.
A refusal and an inability look the same; rephrasing usually separates them.

Tools that use this

Claude
Trained caution overshooting on an entirely ordinary request.
Tidio Lyro
A handoff to a person at the bot's limit, so the refusal lands usefully.
Adobe Firefly
Safe and usable over spectacular, the boundary as an aesthetic ceiling.