Post-completion error at the tail of a sequence

What it is

A post-completion error is a particularly regular shape of omission: the sequence's main goal has already been reached — the copies came out, the cash was dispensed — but a trailing action unrelated to that main goal is left undone, like forgetting the original on the copier glass or leaving the bank card in the machine. It shares the surface outcome of ordinary omission — a required step didn't happen — but this shape has a predictable location signature: what gets dropped is almost always the step positioned after the main goal, not one scattered randomly across the sequence.

Why it happens

A multi-step task runs on continuous monitoring: the person keeps tracking "what's still left" until the whole sequence is done. But that monitoring is typically organized around the main goal — once the system signals that the main goal has been reached (copies in hand, cash dispensed), the felt sense of "task done" fires early, and monitoring relaxes accordingly. The necessity of the trailing step was never evaluated on its own contribution to the main goal; it depended entirely on monitoring staying active. Once monitoring exits early because the main goal registered as complete, the trailing step loses the force that would have driven it to happen, and it simply gets dropped.

Studying it

The classic paradigm for this error uses simulated ATM tasks: participants run through a series of withdrawal transactions on a computer where the card must be retrieved before cash is released — deliberately ordering the trailing action before the main reward — while researchers manipulate working-memory load by adding a concurrent numeric memory task, and measure how often the trailing step (retrieving the card) is dropped. The reliably repeated finding is that higher working-memory load raises the post-completion omission rate, which locates this error as a working-memory-limited phenomenon rather than simple carelessness.

Where it stops holding

This effect depends on the trailing step not itself carrying the reward the user wants — once the trailing step IS the payoff (getting the cash, say), it's no longer caught by the monitoring lapse, because reaching the main goal and reaching the trailing goal are the same event. The omission rates measured in the lab were obtained under a specific working-memory load; lower-load, simpler real-world tasks shouldn't be assumed to reproduce the same numbers, only the underlying mechanism — monitoring exiting early once the main goal registers — which can be used to flag which real workflows carry a structurally similar risk.

Applying it

Wherever the trailing step can be reordered, move it ahead of the main reward's release, so the user cannot obtain the final result without first completing it — design "retrieve the card" to physically or procedurally precede "dispense the cash," not the other way around. When the trailing step genuinely cannot come first (the original can only be retrieved once all copies have printed), use an interlock that ties release of the main reward to the trailing step's completion state, making it a required condition for getting the result rather than an optional afterthought. To verify: run a batch of test users through the full flow and count how many leave immediately after the main goal is reached without completing the trailing step; reorder the sequence or add the interlock, then re-run the same task with the same population and compare the drop in the omission rate.

Related

• Same group: A10.03.1 Omission errors: a required step never happens · A10.03.2 Commission errors: a step happens but comes out wrong · 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.12 Loss-of-activation errors · A10.14 Forcing functions and interlocks
• Search terms: post-completion error · working memory load · sequential task