Commission errors: a step happens but comes out wrong
Aliases: wrong-action error · mis-execution
What it is
A commission error is when the required step does occur, but its content is wrong — the wrong key is pressed, the wrong object is selected, a value lands in the wrong field. It shares the same top-level question as omission — "which step went wrong" — but answers it the opposite way: omission leaves the slot empty, commission fills it with the wrong thing. The distinction describes only the surface outcome, not the cause — a wrong fill can come from many different channels: visually similar targets getting confused, data currently being handled intruding into the action sequence, or an internal associative chain steering the action off course. These channels have different mechanisms, but they all land on the same surface result: an action really did happen, it just wasn't the intended one.
Why it happens
At the core of a commission error, some action schema really was activated and ran to completion — it just wasn't the one the person actually wanted. This is the essential difference from omission: omission is "no schema fired at all," commission is "a schema fired, but the wrong target got selected." A commission error therefore always comes with a genuine, executed action, and that action is usually smooth, complete, and confident-looking, because the motor or interaction routine carrying it out has nothing wrong with it — the failure is entirely in which target got picked. This is why so many commission errors happen fast and look decisive: the hand isn't at fault, the selection is.
Studying it
Commission errors surface far more readily in system logs than omissions do, because they leave behind a concrete, recordable wrong action — which control was clicked, what value was typed — all directly capturable by the system without relying on self-report. This methodological asymmetry is worth flagging on its own: log-based error counts will naturally skew toward capturing more commission errors, while diary- or interview-based counts will more readily catch omissions — each data source misses the half the other is good at. A conclusion about "which error type is more common" drawn from only one method may simply reflect the collection method's own bias rather than the true error distribution.
Where it stops holding
An action that looks like a commission error on the surface — done, but wrong — is not automatically a slip. If the person's actual intent at the time really was to perform that "wrong" action, and the intent itself rested on a mistaken understanding of the system's state or rules, that belongs to a different error category and can't be classified by the action's correctness alone — it requires going back to check the person's intent at the moment. That check needs to happen as soon as possible after the action; the longer the delay, the more the recollection is contaminated by the outcome, and any reported "intent" risks being a post-hoc rationalization of the action rather than what was actually intended.
Applying it
Focus protection against commission errors on the moment before the action, not after: increase the discriminability between targets so the correct one and any adjacent wrong ones differ clearly in appearance, position, or label, cutting down the chance the wrong-object channel fires in the first place; in parallel, keep the cost of correcting after the fact as low as possible so a wrong selection can be undone cheaply. To verify: bucket the error log by the visual similarity between the mis-selected object and the correct one — if the mis-selection rate climbs with similarity, the problem is discriminability, and the fix is visual differentiation rather than an added warning message.
Related
- Same group: A10.03.1 Omission errors: a required step never happens · A10.03.3 Post-completion error: a trailing step is left after the main goal is reached · A10.03.4 Sequential interlocks to prevent step-skipping · A10.03.5 Explicit confirmation of critical-step completion · A10.03.6 Interruption makes resumption prone to dropped steps
- Nearby: A10.04 Description-similarity errors · A10.05 Capture errors
- Search terms:
commission error·action slip·error logging
Cards in the same group
- A10.03.1Omission errors: a required step never happens
- A10.03.3Post-completion error at the tail of a sequence
- A10.03.4Sequential interlocks that force step order to prevent skipping
- A10.03.5Critical steps need explicit confirmation of completion
- A10.03.6Interruption makes resumption prone to dropped steps