Investigations Learn. Corrective Actions Fix.

Sit in on most investigation meetings and you'll notice something: the moment someone proposes a fix, the questions stop.

Someone floats "we could add a second verification step," a few heads nod, and the conversation shifts to how to write it up. The investigation, functionally, is over. Whatever hadn't been understood yet stays that way, because a workable-sounding fix showed up and gave everyone permission to stop looking.

This happens constantly, and it happens because investigation and corrective action are treated as one continuous activity. They aren't. They're two different jobs with two different goals, and running them together quietly costs you both.

What Investigation Is Actually For

An investigation exists to build an accurate, complete understanding of what happened and how it happened. That's the entire job. Not to identify a fix, not to close a record, not to produce a corrective action. Just to understand.

That distinction matters more than it sounds like it should. The moment an investigator starts thinking in terms of solutions, they start filtering what they're looking at through the lens of "does this point toward something fixable." Facts that don't obviously lead anywhere useful get less attention. Threads that would take more digging get dropped, especially once a plausible explanation has already surfaced.

Good investigation resists that pull. It keeps asking what happened and how it happened well past the point where a comfortable answer has already appeared, because the comfortable answer that shows up first is rarely the complete one.

What Corrective Action Is Actually For

Corrective action is a separate discipline. It starts with the finished understanding an investigation produced and asks a different question entirely: given what we now know, what changes, who owns it, and how will we verify it worked.

This is engineering and management work, not investigative work. It requires different judgment: cost, feasibility, timeline, who has the authority to implement a change, how the fix will be tested. None of that has anything to do with whether the investigation accurately understood the event. It's a downstream decision built on top of the investigation's output.

Why Blending the Two Hurts Both

When a team moves straight from "here's what happened" to "here's the fix" without a real boundary between the two, both halves suffer.

The investigation suffers because it stops early. Once a fix feels available, there's no more incentive to keep digging, even if the understanding underneath that fix is still incomplete. A team that stops investigating the moment a solution appears is optimizing for feeling done, not for being right.

The corrective action suffers too, in a quieter way. A fix generated in the middle of an investigation, while people are still half-focused on figuring out what happened, tends to be whatever solution was easiest to reach for in that moment. It doesn't get the deliberate cost-benefit thinking a corrective action actually deserves, because nobody treated it as its own decision. It just fell out of the same conversation.

Keeping the Handoff Clean

The fix isn't complicated, though it takes discipline to hold. Finish the investigation. Reach a real, evidence-based understanding of what happened and how it happened, in full, before anyone in the room is allowed to propose a solution.

Then, and only then, open a separate conversation about corrective action. Bring in the people who own the process, the equipment, the budget. Treat that conversation as its own decision, with its own tradeoffs, rather than a natural extension of whatever came up while the investigation was still in progress.

Some teams find it useful to make this boundary explicit: a formal transition point in the record, a different set of participants, even a different meeting. The mechanism matters less than the principle. Learning and fixing are two jobs. Give each one the full attention it needs, and neither one gets cut short by the other.

--

Want the full framework for keeping these two steps distinct? Beyond Human Error is open now. Start the course.