How a failure is handled can partly offset the damage; admitting the error beats downplaying it

What it is

A mail assistant sends to the wrong person. One response is “we do not think this is a defect”; another is “we sent this wrong; here is recall.” The failure has already happened; the second cannot erase it, but the drop in handover is a notch smaller. Handling can partly offset the damage; admitting beats downplaying.

Offset is a slice of arithmetic, not “handling governs whether trust breaks more than the error itself.” That sentence is the dominant factor in a collapse setting. Failures here need not be severe enough to empty; handling can still change the step size.

Why it happens

Part of the downward step in an asymmetric update comes from “will it conceal again, will it push the miss onto me.” Admission leaves the event as a capability problem; the drop mainly walks that item. Downplaying adds a second item: unpredictable treatment. The two stacked, the step is larger. So the same miss, the downplay group drops more — the extra is not more wrongness, it is a relationship signal.

Admission has to be matched. Verbal admission and a recall that does not click is another miss, and the offset turns negative. Lee and See’s attitude includes whether the automation still stands on the same side; handling is an input to that judgement, not to the error rate.

Studying it

The same moderate failure (a recallable mis-send, a correctable wrong timezone), randomly admit-and-repair / downplay / push onto the user. Measure how much of the handover drop relative to a “no copy” baseline can be taken back. Independent variables: handling type, whether repair actually runs. Dependent variables: drop, fraction taken back, judgement of “will they treat me like this next time.”

The fraction taken back is “partly.” Do not make the admit group zero damage; that would blur into the collapse entry.

Where it stops holding

If the failure has crossed the severity threshold (irreversible harm), admission is still right, but do not promise it can buy trust back — that is recovery time and success counts. In collapse, handling can be the dominant factor in whether the break happens; in a moderate miss it only changes step size. If the user never discovers the failure, handling does not arise. A first-person “I’m sorry” has a separate inner-state problem and is not the admission here.

Applying it

• Default script for a moderate miss: mark that the system got this one wrong, what the scope is, and a repair that can be pressed now. Ban “perhaps it was your input.”
• Repair before explanation. Recall, resend, export a record take more of that notch back than model internals.
• Make “admit / downplay” a contrast item in incident review; see which class drops more, and use it to change default copy.
• Check: the same mis-send, two scripts, next-day handover gap. If the admit group clearly drops a notch less, the offset exists; if both groups are equally bad, admission was not matched with executable repair.

Related

• Same group: L5.10.1 One failure weakens trust more than one success strengthens it · L5.10.2 Users generalise a failure in one domain to the system's whole capability · L5.10.3 An early failure weighs more than an equivalent late one, because there is no success history to offset it · L5.10.5 Restoring trust takes far more successes than the failures that caused the damage
• Nearby: L5.04 Collapse of Trust · L5.06 Risks of Anthropomorphism · L1.06 Graceful Degradation of AI Failure
• Search terms: admit versus downplay · trust repair · offsetting a miss