You Can't Write an After-Action Report for an Incident You Didn't Document

Three weeks after an incident closes, someone gets assigned the after-action report. They open a template, schedule a hotwash that half the participants can't attend, and start emailing people to ask what time things happened.

What comes back is memory. Confident, well-intentioned, and wrong by margins nobody can measure. The resulting AAR reads fine, gets filed, and changes nothing — because the findings it contains are impressions, and you cannot build a corrective action on an impression.

The after-action report is not a writing exercise. It is a data product. Its quality is capped by the quality of the record generated while the incident was running, and no amount of skill in the writing recovers what the operation didn't capture.

Your Exercises Get Better AARs Than Your Real Incidents

This is the uncomfortable inversion at the center of the problem.

An HSEEP-aligned exercise is instrumented on purpose. There are controllers. There are evaluators assigned to specific objectives with exercise evaluation guides in hand. Someone is watching the clock and writing down when the notification went out and when the resource arrived. The whole apparatus exists to produce evidence.

Then a real incident runs — higher stakes, more consequential decisions, actual failures worth catching — and none of that apparatus is present. The people who would have been evaluators are working the incident. The clock nobody is watching is the operational one.

So the events that matter most produce the thinnest evidence, and the events that matter least produce the thickest. Agencies quietly notice this and conclude that real-incident AARs are just softer by nature. They aren't. They're under-instrumented.

What an AAR Is Supposed to Contain

The HSEEP framework, managed by FEMA, sets the standard most states apply to both exercises and real-world events. An after-action report analyzes performance against each objective and its linked core capabilities, documenting strengths and areas for improvement. The improvement plan converts those areas into corrective actions with an assigned owner, a capability element, and a due date.

Walk that backward and the input requirements are specific:

• Objectives — what the incident was trying to achieve, per operational period, written down at the time and not inferred afterward
• A timeline — when decisions were made, when resources were requested, when they arrived, when conditions changed
• Performance against those objectives — what was actually done, by whom, under whose supervision
• Attribution — enough detail to assign a corrective action to a function rather than to "the EOC"

An agency running paper can usually produce the first item and almost never the second. The ICS 202 objectives exist because someone typed them for the IAP. The timeline exists only in ICS 214 activity logs, and if those logs were filled in at demob from memory — or not at all — the AAR's factual spine is missing.

FEMA's own guidance for the Emergency Management Performance Grant encourages recipients to submit AAR/IPs for tabletop exercises that validate critical plans and for large-scale functional and full-scale exercises. The expectation is that AARs feed something. An AAR built on recollection feeds nothing.

The Improvement Plan Nobody Can Close

The failure mode is not that agencies skip AARs. Most write them. The failure mode is the corrective action that can never be verified as complete.

"Improve resource request turnaround time" is not a corrective action. It's a wish, because nobody knows what the turnaround time was. There is no baseline, so there is no way to demonstrate improvement at the next incident, so the same finding reappears in the next AAR and the one after that.

Compare it to what a documented incident supports: median time from ICS 213 RR submission to resource arrival was 4 hours 40 minutes across the second and third operational periods, against a planning assumption of 2 hours; Logistics was staffed by one person through both periods. That finding has a number, a cause, and an owner. The corrective action writes itself, and next incident you can check it.

The difference between those two findings is not analytical rigor. It's whether the request had a timestamp.

Three Records That Make an AAR Writable

You don't need an evaluator corps on real incidents. You need three things captured as operations run.

Timestamped activity logs. The ICS 214 is the AAR's timeline. Not a summary written at demob — entries created during the operational period they describe, attached to the person and assignment that generated them. This is the single highest-leverage change, and it's also why the 214 can't be reconstructed after the fact without becoming fiction.

Check-in and demobilization times. ICS 211 through ICS 221 gives you resource-level duration, arrival lag, and utilization. Nearly every "we were slow to scale" finding is really a check-in-time finding that nobody could prove.

A decision record tied to the operational period. What objectives were set, what changed mid-period, what was deferred. An operational-period architecture makes this structural rather than something the Planning Section has to remember to preserve.

Capture those three and the hotwash changes character. Instead of asking people what happened, you're asking them why — which is the only question a group of participants is actually qualified to answer.

The Test

Pull your last real-incident AAR. Count the findings that cite a specific time, duration, or count. Then count the ones that begin with "communication between" or "there was confusion regarding."

The ratio tells you whether your agency is learning from incidents or narrating them. Agencies that run ICS in a system where documentation is a byproduct of operations — where the log, the check-in, and the assignment already carry timestamps — write the first kind of finding without extra effort, because the evidence was captured by the work itself.

The incident already told you what went wrong. The question is whether anyone was writing it down.

See how operational records build during an incident →