Missing feedback loops cause accidents to recur

What it is

A corrective-action feedback loop turns a finding into an owner, a concrete intervention, and a verification criterion, then returns the outcome to the people and sites it affects — a traceable chain from "was the recommendation adopted" to "was it actually implemented" to "did it change the system condition." A status of "completed" in a document only says an activity took place; closure requires evidence that the mechanism that produced the accident has actually changed, not that some action was performed.

Why it happens

Once an investigation produces recommendations, without a tracking mechanism that keeps recording the adopted–implemented–verified chain, a recommendation can easily stay on the page: investigation and daily operations run on different timescales, and organizational attention shifts to new priorities soon after a report is published. Without tracking, no one is required to go back and confirm the change actually landed.

A subtler failure mode than being forgotten is formal closure: the owning unit marks a tracking item "done" while the real change stayed at the document level — for example, only the wording of a procedure was updated, with no matching training rollout or interface/equipment change. The status in the tracking system and what actually changed on the floor drift apart. The next time the same preconditions arise, the accident recurs through nearly the same mechanism, only with different surface details, while the organization believes the issue was already resolved because the tracker shows it closed.

A less visible failure still is missing cross-unit propagation. Sister facilities in the same company, or other organizations in the industry facing the same equipment type and the same latent conditions, only receive the lesson if there is an active bulletin mechanism; otherwise the lesson stays inside the unit that had the accident. A tracking system can work perfectly for its own site and still never push a mechanism-level finding to a site that shares the same latent condition but has not yet had the accident.

Studying it

Trace a recommendation through design, deployment, adoption, effect, and cross-site transfer, and find at which stage information gets lost. Cluster recurrences by shared mechanism rather than by incident name or surface type — two events with the same underlying mechanism but different triggering scenarios will not surface as related under a keyword search. Before–after comparisons need to account for changes in exposure and reporting culture, or a drop in reported incidents gets misread as evidence the fix worked. At the verification level, audit how a "verified" status was reached: if the supporting evidence is just a self-submitted document from the implementing unit, with no independent field check, drill, or barrier test behind it, that "verified" status is suspect.

Where it stops holding

A short window without recurrence is weak evidence, especially for events that were already rare — the observation period may simply be too short to distinguish genuine improvement from not yet re-encountering the same conditions. Not every recommendation should be implemented as written; rejecting or substituting a recommendation is acceptable, but the rationale needs to be recorded rather than quietly dropped from the tracker. Closure itself can introduce new risk — an interlock added to remove one inducement can change the pace of work and create a different side effect, which needs its own assessment rather than an assumption that "closed" means "safe." Cross-unit sharing has its own limits too: differing operating environments, equipment batches, or staffing at different sites mean a specific fix from one unit may not transfer as-is; what should be shared is the causal mechanism and the conditions worth checking, not a mandate to copy one unit's specific intervention wholesale.

Applying it

• Give every recommendation a corrective action tracking (CAPA) record: owner, deadline, scope, and the specific evidence type required to call it effective — not a single generic checkbox.
• Keep decided, implemented, adopted-in-the-field, and verified as distinct states, each backed by its own supporting material, so a document update cannot substitute for a change on the floor.
• Before closing an item, check whether the accompanying actions covered training, interface or equipment, and procedure wording together — changing only one of the three counts as formal closure and should not be marked verified.
• Set up a cross-unit bulletin mechanism that pushes mechanism-level lessons (not incident-name-level ones) to sister facilities and peer organizations that share the same equipment type or latent condition.
• How to check: sample a batch of items marked "verified" and follow up for matching field evidence — change records, acceptance sign-offs, training attendance plus a later spot check — rather than trusting the status field alone.

Related

• Same group: Y7.05.1 Investigation should identify systemic causes rather than blame individuals · Y7.05.3 Findings must become concrete design or procedure changes · Y7.05.4 Investigation must be independent of routine management
• Nearby: Y7.02 Error reporting · Y6.04 Training, qualification, and recertification
• Search terms: corrective action · feedback loop · organizational learning