Omission errors: a required step never happens

What it is

When a procedure goes wrong, the outcome takes one of two surface forms: a required step never happens, or it happens but comes out wrong. The first is an omission error — the step exists in the plan and the person is fully capable of it, but it simply does not occur during execution, leaving the system in a state that is missing that one step. This split classifies only the surface outcome, not the underlying cause: a step can drop out because an interrupted sequence never resumed correctly, because a trailing action got eclipsed by the sense that the main goal was already achieved, or because an unrelated action hijacked the moment. Whether something is missing versus wrong is the first diagnostic question when triaging a reported error.

Why it happens

Omission shows up as "nothing happened" because carrying out a step normally depends on some trigger — an explicit cue telling the person "this is your moment to act." A step with no such cue attached to it relies entirely on the person's own memory to retrieve it at the right point in the sequence; when that retrieval fails, the step doesn't surface as a wrong action, it surfaces as no action at all, because no motor or interface event ever occurs to carry an error. This is also why omissions are harder to spot in system logs than commission errors: a commission at least leaves a recorded wrong action behind, while an omission leaves only a stretch of time where an action should have been logged and wasn't.

Studying it

The earliest systematic record of omission errors came from diary studies: participants carried a notebook for weeks and logged slips as they noticed them, which researchers later sorted into omission versus commission. The method's limitation is direct — it only captures errors the person themselves became aware of, and omissions are exactly the class most likely to go unreported: a missing step often only becomes visible once its consequence surfaces (something wasn't picked up, a process stalled), so many small omissions leave no trace in a person's own memory at all, which systematically understates their true rate. Correcting for this requires an independent task analysis that enumerates which steps should have occurred, then reconciling that list against logged behavior rather than relying on self-report alone.

Where it stops holding

Calling something an "omission" presupposes an independent record — separate from the person's own memory — of which steps the plan actually required. Without that task analysis as a reference, there's no way to tell "this step was planned but skipped" apart from "this step was never part of this person's plan in the first place." Conflating an improvised, on-the-fly action with a genuinely planned-but-dropped step distorts any omission count. The classification also only speaks to outcome, not cause: an omission can result from post-completion neglect, resumption failure after an interruption, or some other mechanism, and attributing a specific cause needs more evidence than the bare fact that a step didn't happen.

Applying it

Run a task analysis first to break the process into an explicit step list, then give each step a queryable completion flag; at the end of the flow, run a single pass that checks every flag, and surface a prompt for any step never marked complete instead of counting on the user to remember it themselves. To verify: pull a sample of real operation logs and reconcile them against the task-analysis step list to find which steps left no completion record, then track how the omission rate changes with sequence length and interruption count — this surfaces omissions that user-reported feedback alone would miss.

Related

• Same group: A10.03.2 Commission errors: a step is executed but wrong · 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.01 Slips vs. mistakes vs. violations · A10.08 Error tolerance and graceful degradation
• Search terms: omission error · slip taxonomy · task analysis