Corrective actions that survive 90 days

Almost no corrective action is formally abandoned. Nobody convenes a meeting to cancel it. It simply stops being mentioned, and then enough time passes that raising it would be awkward, and then it is gone.

Disagreement is not what kills them. Everyone in the room genuinely agreed the thing should happen. The failure is that nothing about the plan made its own absence visible: no date on which somebody would notice, no signal that would be missing, no person whose job it was to look. An action with no observable consequence of not happening is indistinguishable, ninety days later, from an action that happened.

This is why the standard remedies underperform. A tracker helps only if somebody reads it. A monthly review helps only if the item is specific enough that its status is knowable. Adding an owner column helps only if the owner agreed to it, rather than being assigned in their absence.

The problem is not follow-through as a virtue. It is that the plan was written in a form that cannot be checked, and no amount of diligence recovers a plan you cannot check.

The reframe that makes the rest of this work: a corrective action is not a decision you have made. It is a prediction you are proposing to test.

When somebody says we will add a second person to post moves, they are claiming that a second person will be available, that crews will actually use them, that using them will change the maneuver, and that changing the maneuver will affect the outcome you care about. That is four claims stacked, and any of them can fail independently while the others hold.

Treating it as a decision means it goes on the list as done-when-implemented. Treating it as a claim means you write down what you would expect to observe if it were working — which is a completely different artefact, and the only one that lets you answer the ninety-day question honestly.

This is also the more truthful description of what the evidence supports. A record that shows a condition recurring tells you the condition is worth addressing. It does not establish that any particular control will address it. Calling the control a candidate rather than a solution is not hedging; it is an accurate statement of what you currently know.

All five have to be attached in the room, while the decision is being made. Retrofitting them later is possible, but by then the decision they were meant to shape has already been made.

A named owner, who is present and has agreed. Not a department, not a role — a person. The distinction sounds pedantic until the ninety-day review, when a department cannot be asked what happened.

The constraint that should hold. What must be true, stated as a condition rather than an activity: no reposition happens without a second set of eyes. This is the thing you actually want; the action is only a means to it.

The operational step. What somebody does differently on Monday, concretely enough that a crew member could describe it. This is where most plans are vague, and vagueness here is what makes the status unknowable later.

The observable check. What you could look at that would show the control was available and used — not whether the policy exists, but whether it operated. If you cannot name one, you have not got a control; you have got an intention, and it is better to discover that now.

And the exception condition: what it would look like if the control were absent, mistimed, unusable, or applied on the basis of a wrong understanding. Naming the failure modes in advance is what stops a control being recorded as in place when it has been quietly impossible for two months.

The five attachments are the minimum. If you want to go further — and a working session is where this usually happens — there is a set of questions that turns each candidate into a miniature control problem, in the systems-safety sense. They are worth knowing even if you never write them down formally, because each one exposes a way the plan could fail that a status column never would.

Start with the condition you are responding to and ask what hazardous state it could contribute to. Then, of the control: what safety constraint should hold? Who is the controller — a person, not a department, and someone with the authority the constraint implies. What control action is actually provided, meaning the thing somebody does differently. What feedback would confirm the control was both available and effective, which is a stronger question than whether it exists.

Then the two that get skipped. Why might the control be absent, mistimed, unusable, or applied on the basis of an incorrect understanding of the situation? That question is where most real-world failures live, and asking it in advance is how you find out that the control is impossible on night shift before you discover it in ninety days. And at reassessment: did the constraint actually perform, and did the hazard measures you care about move — reported separately, because they are separate questions and only one of them is about your control.

None of this requires a formal analysis or specialist training. It is a way of interrogating a decision you are making anyway, and its whole value is that it produces disagreement in the room rather than surprise a quarter later.

At review time, in place is not a status. It is a sentence people say when nobody has looked.

The useful states are more specific. Was the control available — did the second person, the equipment, the checklist actually exist at the moment it was needed? Was it used when it was available? Was it unavailable, and if so how often and why? Was it corrected when somebody noticed it missing? Or was it deliberately overridden, and by whom, and for what reason?

Those five states have completely different implications and identical appearances on a status report. A control that was available and used and did not help is a failed prediction, and you learn something real from it. A control that was never available is not a failed prediction at all — it is an implementation that did not happen, and treating it as evidence against the idea is a mistake people make constantly.

The override case deserves particular attention, because an override tells you something the plan did not anticipate. People override controls that are impossible to follow under real operating conditions. An override is not primarily a compliance problem; it is a report that the control does not fit the work, delivered by the only people in a position to know. That includes the case where a rule is operationally impossible to follow — which is a policy problem rather than a compliance one.

The temptation at ninety days is to check whether the count went down and declare accordingly. Resist it in both directions.

A count going down is not proof the control worked. Volume moves, seasons move, reporting behavior moves — and reporting behavior in particular is sensitive to exactly the kind of attention a corrective action program creates. A quieter record can mean fewer events or fewer reports, and the count alone cannot tell you which.

A count staying flat is not proof the control failed either, especially where the control was available on only a fraction of the occasions it was meant to cover. The prior question is always whether the thing was actually operating, which is what the availability and use states are for.

The defensible version of the answer has three parts: whether the constraint held, what the observable check showed, and what happened to the condition — reported separately, in that order, with the population each figure was measured over. It is a longer sentence than it worked, and it is the only version that survives somebody asking how you know.

And plan for the most common outcome, which is that nothing moved. That is a real result and it is worth having honestly. A program that can only report successes is one that will eventually report a success it did not have, and everything it said before that becomes unreliable in retrospect.