Overtrust and undertrust are both failures
Aliases: miscalibrated trust · too much trust · too little trust
What it is
Autocomplete in mail is never checked, and a wrong address goes out — trust sits above reliability. The same actually-stable document OCR is retyped in full by the bookkeeper every time — trust sits below reliability. Overtrust and undertrust are both calibration failures. One lets error out; the other leaves working capability idle and pays a checking cost.
The goal is still a match. Failure has two sides, not only the “trusted too much” side.
Why it happens
Matching error has a sign. Positive error (too much trust) switches checks off, and mistakes enter an outbound channel. Negative error (too little trust) switches extra checks on, and time is spent on steps that could have been handed over. The loss shapes differ, so products often see only one side: outbound incidents make the news; repeated checking is filed under “being careful.” Lee and See’s calibration picture draws both deviations as problems, rather than treating trust as a scale that is monotonically better as it rises.
Interface incentives also lean one way. Adoption, clicks on “apply suggestion,” fewer clicks — all reward overtrust. Time spent checking rarely enters a dashboard, so undertrust looks like a feature that is not loved, and persuasion is turned up, instead of admitting calibration has already leaned the other way.
Studying it
On a task of known reliability, log both misses (should have checked, did not) and extra checks (should not have checked, still did). Independent variables: strength of how the suggestion is presented, whether a base rate is shown, whether checking cost is visible. Dependent variables: counts of both error types, total time, outbound errors.
Reporting only adoption stacks undertrust and overtrust into one number. Split the sides.
Where it stops holding
When stakes are high and reliability has not been measured well, it can be right to lean under first — that is risk management, not a declaration that undertrust is success. When reliability is near a hundred percent and failures are almost irreversible, the cost of overtrust dominates and the sides are no longer symmetric. This entry only asserts that both sides are failures; how a success streak pushes people over, and how undertrust shows up as checking cost, is another set of dynamics.
Applying it
- Report both on the dashboard: items sent outbound with no check, and items checked that then changed not one character. Put thresholds on both sides.
- Do not use “raise adoption” as the only success criterion for an explanation or suggestion feature.
- On tasks that are already over-checked, cut persuasive copy and show the rate of “checked, unchanged” in the last hundred, so undertrust has a number it can come down on.
- Check: take a day’s log and label each output miss or extra check. If the product is only discussing one of those sides, calibration has been made into a one-sided sport.