Calling the cause human error restates what went wrong without explaining why

What it is

Writing "human error" as the conclusion of an investigation into an incident or accident looks like it names a cause, but it explains nothing: it just restates the already-known fact that someone did something wrong, without answering the more important question — why that person made that judgment at that moment, what information the system actually gave them, and how much room for error the situation left. When "human error" is treated as the end point of an investigation rather than its starting point, the systemic causes underneath never get chased down, and the resulting fix stops at surface-level moves like "remind the operator to be more careful," which touch nothing about the system itself.

Why it happens

"Human error" is easy to mistake for a sufficient conclusion because it fits an intuition: an outcome is caused directly by the action closest to it, so the cause should be assigned to whoever performed that action. But that intuition ignores that the action itself happened within a whole set of constraints — the information available, the options the interface presented, the time pressure at that moment, the training received beforehand — all of which are set by system design and organizational decisions. The operator was simply making a choice, inside a space bounded by those conditions, that looked reasonable at the time. Stopping the conclusion at "human error" describes only the last link in the causal chain while excluding everything upstream that shaped the choice from the analysis entirely. Those upstream conditions don't disappear when the investigation ends — the next person placed in the same conditions will very likely make the same choice.

Where it stops holding

Pointing out the limits of "human error" as a conclusion doesn't mean an operator's actions should never be scrutinized. If a person knew the procedure, was capable of following it, and chose to deviate anyway, that's a violation rather than a slip, and scrutinizing that person's choice is warranted — not something to sidestep by attributing everything to the system. The line is whether the person had a reasonable alternative given the information and constraints at the time: if not, responsibility sits with the system; if a clear alternative existed and the person chose to deviate from it anyway, then individual accountability enters the discussion.

Applying it

Ban "human error" from ever standing alone as the final cause in any incident review's conclusion field. Require the review to push at least two levels further: what information could this person actually see at the time, was that information sufficient to support the correct judgment, and would another equally-trained person, placed in the same position, have made the same choice. If the answer is yes, the problem is the system, not the person, and the fix has to land on information presentation, constraint design, or process structure — not on repeating "more training" or "be more careful," which change nothing about the system. Verification: check the remediation field of recent incident reports. Any remediation that consists only of training, warnings, or a reprimand, with no concrete change to the interface, process, or permissions, is a sign that a "human error" conclusion was never chased any further.

Related

• Same group: A10.09.1 human error rate quantification — scope and limits · A10.09.4 systemic causes should be examined before individual attribution · A10.09.5 skilled and novice users have different error profiles, so safeguards can't be one-size-fits-all
• Nearby: A10.13 violations and deviations · A10.07 Swiss cheese model · Y7.01 systemic causes
• Search terms: human error attribution · systemic cause · just culture