Undertrust shows up as repeated manual checking, whose cost is often ignored

What it is

The translation is already good enough; the editor still drops every sentence into another engine to compare. On the surface the system is being “used”; on the books a whole shadow workflow has been added. Undertrust shows up as repeated manual checking, and that cost is often ignored.

Under is not “nobody clicks adopt.” People can click adopt every day and then do it again outside the system.

Why it happens

Checking happens where product dashboards cannot see: a second window, paper, a colleague. Adoption therefore looks healthy while time sits in duplicated labour. Lee and See draw undertrust as one side of calibration failure; the loss is labour, not an incident, so incident reports do not file it. Organisations further praise repeated checking as being careful; cost is covered by moral language.

Under often has a history: an early small miss, word of mouth, or never being allowed to see stable performance. Unlike the definition that both sides are failures, what to see here is the concrete form — checking — and how it vanishes from the books.

Studying it

On a task of known high reliability, log in-product operations and out-of-product checking (eye tracking, screen recording, self-report, or a required checking trace). Independent variables: whether a long-run hit rate is shown, whether checking is praised by the organisation, friction of switching to a checking tool. Dependent variables: out-of-product check count, share of checks that change not one character, total time to finish.

Checks that change not one character are this entry’s signature. Without that item, “being careful” and “undertrust” cannot be split.

Where it stops holding

When reliability has not been measured well, repeated checking is rational, not under. When stakes are high and failure is irreversible, checking cost may be accepted on purpose. Users treating the system as a learning tool (comparing in order to learn translation) is not under either. Checking after a severe collapse is a recovery process, not the ignored steady-state cost this entry names.

Applying it

• Put “adopted, unchanged” and “adopted, then processed again outside” into cost. Do not only watch adoption.
• On tasks that already almost never change, show the rate of “checked, unchanged” in the last hundred, so undertrust has a number it can come down on.
• Offer cheap sampling rather than silently allowing a full rerun: three sentences, the key figures, not the whole piece into another engine.
• Check: sit a day of work and count minutes in the shadow workflow. If adoption is high and shadow minutes are also high, undertrust is being counted as successful use.

Related

• Same group: L5.09.1 A reasonable trust level varies with task and situation; there is no globally correct trust · L5.09.2 A streak of successes pushes trust above the system's actual reliability · L5.09.4 Showing typical failures can suppress overtrust, at the cost of short-term adoption · L5.09.5 Trust is formed from personal use, not from statements and documentation
• Nearby: L5.03 Trust Calibration · L4.02 Automation Bias · L3.03 Hallucination and the Fact-Checking Burden
• Search terms: undertrust · rechecking cost · shadow workflow