Data-driven errors are triggered by externally presented information hijacking a similar-looking action schema

What it is

The trigger for this class of error is external data — a piece of information currently being perceived or processed intrudes into the ongoing action sequence and gets treated as input for a different action. A data-driven error is exactly this: someone reading a phone number aloud while dialing a different number ends up typing the recited number into the dialer instead; someone reading a value off one document while filling in another form ends up entering that value into the sheet they're actually working on. What triggers it isn't what the person has in mind — it's the data currently being handled, which happens to match the input pattern of some unrelated, well-learned action schema.

Why it happens

Normally, perceived data is only used as the "content" of an action — reciting this number, copying this value. A data-driven error happens when that same piece of data also satisfies the activation condition of a different, unrelated but highly practiced action schema: that schema fires opportunistically on the data's surface features and treats the data currently being handled as its own input, instead of the action the person actually intended being carried out. This is why these errors so often occur where two actions share the same input format — both a string of digits, both a name — the formal match alone is enough for the wrong schema to fire first.

Studying it

This class of error was first documented through diary studies of naturally occurring cases: people were asked to record, right after the fact, what information they were handling at the time and what they ended up doing, and researchers later sorted these by whether the intruding content was genuinely present in perceptual input at that moment. This method has an obvious limitation — data-driven errors happen fast and are rarely noticed at the time, so most cases can only be reconstructed retrospectively once a consequence surfaces (the wrong number got dialed, the wrong field got filled), which makes them hard to elicit reliably under controlled lab conditions. As a result, the evidence base for this error type still rests mostly on naturalistic case records rather than experiments with manipulated variables.

Where it stops holding

Classifying an error as data-driven requires confirming that the intruding content really was present in perceptual input at the time, not just present in the person's train of thought — without being able to confirm that retrospectively, there's no way to tell it apart from an error triggered by internal association, even though the two can produce identical-looking outcomes. That distinction rests entirely on whether the person can accurately recall, after the fact, "what did I actually see or hear at that moment," and that kind of recall is itself easily contaminated by the outcome — which is the direct reason this line of research has such a thin evidence base.

Related

• Same group: A10.10.2 This error is intent-independent, driven only by perceptual surface features · A10.10.3 Interface elements that resemble a hazard's trigger cues keep inducing this error · A10.10.4 Reducing this error means redesigning the input side, not asking users to focus harder
• Nearby: A10.11 Associative-activation errors · A10.12 Loss-of-activation errors · A10.04 Description-similarity errors
• Search terms: data-driven error · action slip · perceptual intrusion