A result that violates expectation interrupts automated action
Aliases: mismatch detection · automaticity interruption
What it is
When an already-automated action sequence — one that needs almost no conscious monitoring to run — produces a result that violates the user's current expectation, that violation itself interrupts the sequence's automatic execution, switching attention from smooth execution back to consciously watching what's happening. This is the interrupting function of expectation violation at the level of automated action — it describes how that switch gets triggered, not how the user goes on to explain what happened afterward.
Why it happens
Automated action can run smoothly because its execution phase requires almost no conscious attentional resources — attention is directed elsewhere while a pre-formed program carries the sequence forward step by step. But this smooth execution depends on a low-cost comparison running continuously in the background: matching the actual outcome of each step against the expected outcome. As long as they match, execution proceeds uninterrupted and attention can stay elsewhere; once a step's actual outcome deviates from expectation by enough, that mismatch signal triggers an interrupt, forcibly pulling attention that was allocated elsewhere back onto the current action — this isn't the user deciding to check; the mismatch signal itself has the capacity to capture and pull attention, much like a salient stimulus does.
Studying it
A common paradigm has participants perform an action sequence practiced to the point of automaticity, with a result that deviates from the norm secretly inserted at one step; reaction time or eye-tracking measures the time it takes attention to be pulled back from the background task to the current action, and any hesitation or pause that appears in the sequence once it is pulled back. Varying the size of the deviation as an independent variable across trials traces out the minimum deviation needed to trigger an interrupt — this curve is the direct basis for judging whether a given deviation is "large enough to be noticed."
Where it stops holding
Not every deviation triggers an interrupt — below some threshold, a deviation gets absorbed as noise by the ongoing comparison process and execution continues unchanged, with the user never noticing at all. That threshold itself isn't fixed either: it shifts with how deeply automated the action is (the more practiced the action, the coarser the comparison) and with how much of the attention directed elsewhere is currently occupied, so whether the same size of deviation triggers an interrupt varies by state — a threshold measured once should not be treated as a fixed standard that applies universally.
Applying it
- A deviation that a user needs to notice promptly (an error, an abnormal state) has to be presented at a magnitude exceeding the user's current interrupt threshold for that level of automaticity; a weak cue in a highly automated, repetitive action is easily absorbed as noise by the comparison process and never triggers an interrupt at all.
- Don't introduce unnecessary small deviations on an otherwise normal, expected path — an unneeded shift in a button's position, jitter in feedback timing — because even if none of these individually counts as an error, each one keeps triggering this interrupt, breaking up action that could otherwise run automatically and accumulating into experienced fatigue.
- How to check: record a user performing a well-practiced action, insert artificial deviations of varying magnitude, and use eye-tracking or keystroke-interval changes to mark the deviation threshold that actually pulls attention back; use that threshold to calibrate the minimum presentation strength a cue needs in that scenario.