Canon · When the tool is live and quiet
007

Refusal is usually a measurement signal

When people quietly stop using the tool, the standard reading is change resistance and the standard prescription is more training. Check the verification cost first, because it is usually the whole explanation.

Updated June 2026
In brief
  • Refusal is arithmetic, not attitude. If checking the output costs more than the task saved, stopping is the rational move and encouragement will not change it.
  • Verification cost is invisible on your dashboard because it happens outside the tool, in a second window and in the user's head.
  • Ask twenty regular users what they do before sending the output on. Do not ask whether they trust it; trust is an attitude and people report the one they think you want.
  • Showing provenance collapses verification from re-deriving the answer to reading one paragraph, which flips the arithmetic.

Adoption curves that rise for six weeks and then sag are read as a motivation problem. The programme responds with communications, champion networks, leaderboards, and a second round of enablement sessions. Some of that helps at the margin. Most of it is aimed at the wrong cause.

A professional deciding whether to use an assistant is running an implicit calculation. The tool saves them some minutes on the task. It also costs them some minutes checking whether the output is right, because they remain accountable for it. If checking costs more than the task saved, a rational person stops, and no amount of encouragement changes the arithmetic.

Why the check cost is invisible to the programme

Time saved gets measured. Time spent verifying does not, because it does not happen inside the tool. It happens in the user's head, in a second window, in a call to a colleague, in a re-read of the source document. None of it appears in your telemetry, so your dashboard shows a benefit with no offsetting cost and you conclude the users are being difficult.

The check cost is also non-linear in stakes. For low-consequence work, people will accept output with a glance. For anything they will be named on, they verify fully, which frequently means redoing the reasoning. In that band the assistant has to be reliable enough that spot-checking suffices, and reliable enough is a much higher bar than useful.

Exhibit 1
The calculation the user is actually running
The same tool is rational to use in one column and irrational in the other, and no amount of enablement changes which.
Low-consequence work
Work they are named on
Time saved
Real
Real
Checking behaviour
A glance
Verify fully, often by redoing the reasoning
Where the cost lands
Negligible
Outside the tool, so your dashboard never sees it
Net effect
Positive, and they keep using it
Negative, and they quietly stop
Reliability required
Useful
Good enough that spot-checking suffices, a far higher bar

How to measure it

Ask twenty regular users a single question: when you use it for real work, what do you do before you send the result on. Do not ask whether they trust it. Trust is an attitude and people report attitudes they think you want. Ask about the behaviour.

The answers sort into three groups quickly. People who send it on with a glance have a working tool. People who rewrite it substantially are getting a first draft, which has real value and much less than claimed. People who check it against the source every time are getting nothing and will churn, and they are the group your training programme is currently targeting.

What actually moves it

  • Narrow the scope until reliability inside that scope is high enough to spot-check. A tool that does one thing dependably beats one that attempts everything at eighty percent.
  • Show provenance. If the answer arrives with the source passage attached, verification collapses from re-deriving the answer to reading one paragraph, and the arithmetic flips.
  • Say plainly where it should not be used. Users who have been told the boundaries trust the inside of them. Users told it works for everything verify everything.