Users generalise a failure in one domain to the system's whole capability

What it is

A calendar assistant gets the timezone wrong; the meeting lands in the wrong morning. The user then also stops handing it email drafts — the mail skill did not fail this time. A failure in one domain is generalised to the system's whole capability. What people update is “this thing is not solid,” not “it cannot do timezones.”

Generalisation is a scope error. The failure is local; the trust penalty is spent on functions that did not miss.

Why it happens

Capability in a user’s mind is often one subject, not a feature table. The subject is wrong once, the subject’s label is rewritten, and the label walks every entry. A product name, an avatar, one dialog welds several skills into one “who.” The tighter the weld, the cheaper the generalisation.

Interfaces rarely cut scope at failure: “this miss was timezone conversion; composing is unaffected.” Without that sentence, users can only update at subject level. Stack the asymmetric unit update on top, and one miss is enough to switch adjacent skills off together. This is the failure face of “there is no globally correct trust, calibrate by task”: people did not update by task.

Studying it

Build the system as two separable skills (timezone / draft). Inject a failure in only one, and measure whether handover on the other falls. Independent variables: whether the two skills share a name and a dialog, whether scope is declared at failure, surface similarity of the skills. Dependent variables: drop in handover on the skill that did not fail, rate of subject-level evaluations (“it’s no good now”).

Shared surface is the key manipulation. If generalisation vanishes when they are split into two apps, the weld is the cause.

Where it stops holding

When two skills are inseparable in the user’s task (“schedule a meeting” needs timezone and the invite together), some generalisation is rational. A brand-level incident (a privacy leak) is already cross-capability and should not be called mis-generalisation. Streak overshoot happens inside one task; this is contagion across tasks. A severe collapse empties the whole relationship; generalisation is one way that can look.

Applying it

• Lock failure copy to the skill: “timezone conversion erred; auto-conversion is off; compose drafts were not affected.” Do not write “I messed this up.”
• Give highly independent skills separate switches and logs, so one failure key does not turn the whole product off.
• At entries to unaffected skills, give a scope-isolation sentence until the user has seen that skill still working on a later success.
• Check: after a miss in one place, does use of adjacent functions drop with it. If it drops and your reliability only broke in one place, generalisation has happened; see whether the failure copy gave a scope that can be cut.

Related

• Same group: L5.10.1 One failure weakens trust more than one success strengthens it · L5.10.3 An early failure weighs more than an equivalent late one, because there is no success history to offset it · L5.10.4 How a failure is handled can partly offset the damage; admitting the error beats downplaying it · L5.10.5 Restoring trust takes far more successes than the failures that caused the damage
• Nearby: L5.09 Overtrust and Trust Collapse · L5.04 Collapse of Trust · L1.02 Expressing Capability Boundaries
• Search terms: domain-failure generalisation · trust contagion · scope of a miss