Circular root causes

What “circular” means

A useful root cause answers why the failure was allowed to happen — process, design, materials, environment, documentation, or human factors with a specific mechanism. A circular cause answers with the failure itself, dressed as an explanation.

If you can swap the “root cause” line with the event title and lose no information, it is circular.

Patterns that usually fail a second read

• Symptom as cause — “Contamination occurred because the part was contaminated.”
• Category labels — “Human error,” “equipment failure,” “procedure not followed” with no mechanism.
• Fix that doesn’t match the cause — cause implies design or documentation; action is only “retrain.”
• Blame without barrier analysis — stops at the person closest to the event; no check of whether the system invited the error.

A quick smell test (before tools)

• Does the cause explain why, or only what / who?
• Could the same cause apply to almost any event in the plant? If yes, it is too generic.
• Does the corrective action address that specific cause — or a convenient training package?
• Would a reader who was not there understand what to change so it does not recur?

Why this shows up under time pressure

Quality events pile up under deadline. “Operator error / retrain” is fast to write, familiar in templates, and easy to close in a QMS workflow. It also leaves the same hole an inspector can walk through: nothing in the record shows the system was understood or improved.

Catching circular language early is mechanical work. Deciding whether the deeper cause is correct is not.