A mirrored layout or reversed control that's a minor annoyance normally turns dangerous under emergency workload
Aliases: compatibility errors under emergency workload · control-room interface
What it is
A compatibility error is not a distinct error type; it is a mapping among display, control, object, or direction that is easy to misread — a mirrored layout, or a control direction reversed relative to its effect. Under routine operation such a defect rarely causes harm, because operators have time to check and memory to correct it. Under emergency workload, the compressed time window strips those buffers away at once, and the same latent defect becomes consequential for the first time.
Why it happens
Emergency conditions do not change the mapping itself; they change the resources available to catch it. Under Rasmussen's skill–rule–knowledge framework, less available time pushes behavior toward the skill-based level — acting on the most practiced, most automatic response instead of checking rules step by step, which is exactly the level at which an incompatible mapping most easily overrides training and reverts to the default stereotype. Layered on top of that, Reason's defense-in-depth view treats routine slips as needing to pass through several independent barriers — cross-checking, alarm confirmation, supervisory review — before they become consequences. Nearly all of those barriers draw on the same scarce resource: available time and attention. An emergency compresses both simultaneously, so barriers that are normally independent develop gaps at the same moment — the holes line up — and the slip passes straight through instead of being caught at any one layer. The system is also typically closer to a safety boundary at that point, so the same size of error leaves a smaller margin for correction before a limit is crossed.
Where it stops holding
Training reduces the rate of this error but never eliminates it — this is Reason's "strong-but-wrong" habit intrusion, where the most practiced action is the one most likely to fire unbidden under load, even when training explicitly covered the counterexample. "Emergency" should not be judged by subjective feeling; it needs to be defined by the available response time window — the same mapping defect may never surface when the window is generous and become critical the moment the window shrinks to seconds. Guard against the opposite misuse too: not every accident should be attributed to "chose the wrong direction under pressure." Authority conflicts, missing procedures, and equipment failure can equally be the dominant cause; stress is an amplifier, not a universal explanation.
Applying it
Audit and remove incompatible mappings first on high-consequence controls, and rank that list by available response time window rather than subjective importance — the shorter the window, the less margin a mapping error leaves. Where the mapping risk cannot be fully removed, add physical proximity between object and control, give it a distinctive shape or texture that supports blind confirmation, and provide immediate reversible feedback so a wrong-direction choice is not irreversible before it is noticed. How to check: test the operator's first-choice action under time pressure that matches the real response window, combined with a realistic concurrent interference task (an alarm, a communication interruption) — not merely whether the mapping is learnable in a calm setting, since learnability and what fires under load are two different questions.