Predictability comes from transparent rules, not from memorised exceptions

What it is

Predictability has two possible sources. Rule transparency: the rules themselves are inspectable and comprehensible — understanding them suffices to predict. Memorised exceptions: the rules are opaque, and users learn the system's quirks by long cohabitation — "it kills the lights on Wednesday afternoons", "open A before closing B or the alarm trips". Healthy systems run on the former; pathological systems on the latter.

Memorised exceptions are a fragile form of prediction: they do not transfer (new members, guests, babysitters have no access to them), they expire wholesale with system updates (one firmware upgrade and the whole list must be re-memorised), and they survive only on high-frequency contact — which ambient devices, by design, are not.

Why it happens

The dividing line between transparency and memorised exceptions is which side carries the prediction burden. Transparency pays it once on the system side (write it down clearly); the user only has to understand. Memorised exceptions amortise the burden across every use — and re-pay all of it after each update. Both reach "predictable", but their maintenance costs live in different universes.

The cognitive mechanism underneath is mode error: when the system's current mode is invisible, users interpret behaviour through the wrong mode. Payne and Squibb found in 1990, in text editors, that mode errors stem from behaviour that cannot be attributed to the current mode; Sarter and Woods carried it to the flight deck in 1995. Ambient automation is isomorphic: with home/away/eco/holiday modes unseen, "why won't the heating come on" has no answer — nobody told you the system was in holiday mode.

Memorised exceptions also fail on cognitive economics: people maintain detailed models only for frequently used things. Ambient devices are low-frequency, short-contact objects; the cost–benefit of maintaining an exception list is terrible — which is why it appears only where users are left no alternative.

Studying it

• The mode-error lineage: from text editors (Payne and Squibb 1990) to cockpit automation (Sarter and Woods 1995), the shared conclusion — when mode is invisible or underivable, users misattribute behaviour to other modes, and surprises and erroneous actions follow.
• Comprehension studies in smart homes: ask users to state their own automations' actual conditions; interviews consistently find only vague knowledge and frequent behavioural surprise — rule transparency is widely unmet in real products, and memorised exceptions are users' resignation strategy.
• Method: prediction tests — show users situation snapshots, ask them to predict system behaviour, compare with what happens; explanation tests — after a behaviour occurs, ask why it happened. Both measure user-side predictability; the latter directly exposes mode errors.

Where it stops holding

• Transparency's ceiling is working memory. Past a certain number of rules, transparent files stop helping — "inspectable" is not "holdable". The remedy is layering: frequent rules surfaced, the rest searchable — not a flat dump of everything.
• Rule transparency is unattainable for learning systems. There is no statable rule to show; the fallback is behaviour transparency: showing learned tendencies and recent adjustments. Drift and folk theories are learning systems' own territory; this entry's prescription (write the rules down) does not apply to them.
• "Users won't read the rules" is not a rebuttal. Transparency's value is verifiability and learnability, not universal reading — like a fire exit: unused on ordinary days, indispensable on the day it is needed.

Applying it

• Give every automation a one-sentence behaviour statement (trigger condition → action), inspectable at the point of outcome: "why did the lights go off" opens onto the answer, not onto a link to the settings home page.
• Make modes explicit: the current mode is visible, mode switches are logged, and each mode's behavioural differences are listed — "in holiday mode, it does not do these things".
• Ban hidden exceptions: every behavioural branch must be attributable to a rule the user can look up; a branch that cannot be attributed is an exception-memory generator and counts as a defect.
• How to check: explanation tests — sample behaviours that actually occurred and ask users to explain them; the explanation rate is a direct measure of predictability. Then test newcomers and guests: can they say "what happens automatically in this space" within five minutes?

Related

• Same group: Z3.05.1 Identical situations should produce identical automation behaviour · Z3.05.2 Unpredictable automation costs more mental effort than manual operation · Z3.05.4 Behavioural drift in learning automation keeps eroding predictability
• Nearby: Z7.01 Making system behaviour explainable · Z5.01 Automation rules
• Search terms: rule transparency · mode error · mode awareness · mental model