Emergency After-Action Report

intent

turn evaluator observations, hotwash notes, controller logs, and participant feedback into a HSEEP-aligned draft after-action report and improvement plan (AAR/IP) for one exercise or one real-world incident. use this skill when an emergency manager, exercise planner, lead evaluator, healthcare-coalition staffer, public-health preparedness planner, campus or utility safety officer, or incident commander needs to scope an AAR, intake evidence against exercise evaluation guides and core capabilities, assign four-level core-capability ratings (performed without challenges / with some challenges / with major challenges / unable to be performed), identify strengths and areas for improvement with root-cause analysis, and produce a draft AAR/IP with an improvement plan matrix of SMART corrective actions mapped to capability elements (POETE), responsible organizations, points of contact, and start and completion dates. the AAR/IP is for exercise director or incident commander review and sign-off only, never for participant distribution or publication.

inputs

Framework and Guidance

• Homeland Security Exercise and Evaluation Program (HSEEP) current edition (default; user can specify alternate framework)
• FEMA National Preparedness Goal Core Capabilities List (default; user provides alternate capability list if exercise targeted non-FEMA framework, e.g., healthcare-coalition capabilities)
• Exercise Evaluation Guides (EEGs) for each capability in scope (user provides or skill logs as unresolved information)
• Incident Action Plans (ICS-201, ICS-202, ICS-204, ICS-209) and operational-period documentation for real-world incidents

Exercise or Incident Metadata

• AAR type: exercise (Seminar, Workshop, Tabletop, Game, Drill, Functional, Full-Scale) or real-world incident
• exercise or incident name, start date, end date, duration, sponsor agency, participating agencies and organizations
• mission area(s) (Prevention, Protection, Mitigation, Response, Recovery)
• threat or hazard type (natural, technological, human-caused) and scenario summary (3-6 sentences)
• exercise objectives (with measurable terms) or incident objectives (from IAPs) mapped to core capabilities and critical tasks

Evidence Inputs (from user or user's team)

• evaluator observations: time, location, core capability, capability target, critical task, observed performance, strength or area-for-improvement tag, evaluator name
• hotwash discussion notes and themes (anonymized)
• participant feedback forms (PFFs) and after-exercise surveys (anonymized; no individual names or small-agency identifiers that could disclose identity)
• controller and MSEL data: injects delivered vs. delayed vs. not delivered, controller actions, unanticipated player branches, safety incidents (exercises), or ICS planning artifacts, resource orders, mutual-aid activation, EMAC, vendor-contract activation (real-world incidents)

Classification and Handling Metadata

• distribution level: Public, FOUO, CUI, LES, or organization-specific restricted classification
• intended audience: sponsor leadership, participating agencies, public release, regulatory filing, or combination
• grant or accreditation drivers: HSGP, UASI, SHSP, EMPG, PHEP, HPP (affects required appendices and compliance annotations); EMAP, CMS, Joint Commission (accreditation requirements)

External Connections and Credentials

• no external APIs required; all data is provided by user or user's team during session
• if user wishes to pull exercise metadata from a planning system (e.g., SharePoint, incident-management system), confirm system name and access credentials outside this skill (pass data to skill as text or table)

Edge Cases and Constraints

• empty or insufficient evidence: if one or more core capabilities have no observations, log as unresolved-information item and rate as "Not Rated , insufficient evidence"
• incomplete or missing EEGs: log critical-task names as unresolved and continue with available data
• conflicting observations: if two evaluators observe the same critical task with opposite conclusions, log both and ask user for arbitration or clarification
• participant feedback volume: if more than 20-30 themes emerge from hotwash and surveys, group by core capability and ask user to identify top 3-5 priority themes per capability to keep analysis manageable
• late corrective-action ownership confirmation: if a responsible org has not confirmed a corrective action by end of session, default to "Proposed" status and flag for user follow-up before sponsor sign-off

procedure

follow these phases in strict order. do not assign core-capability ratings until evidence intake (phase 2) is complete. ask one question at a time during all intake phases; do not present multi-question forms.

phase 1: scope the AAR

step 1: confirm AAR type and drivers

ask the user (in separate questions, one at a time):

1. is this for an exercise or a real-world incident? if exercise, which HSEEP type: Seminar, Workshop, Tabletop, Game, Drill, Functional, or Full-Scale?
2. who is the sponsor, and which jurisdiction(s) or organizations are involved (primary sponsor, partner agencies, geographic scope)?
3. is HSEEP compliance required by a grant (HSGP, UASI, SHSP, EMPG, PHEP, HPP)? is accreditation required (EMAP, CMS, Joint Commission)? this affects required appendices and compliance language.
4. what is the classification or handling level for this AAR: Public, FOUO, CUI, LES, or organization-restricted? capture handling caveats early so they flow through every section.
5. who is the audience: sponsor leadership, participating agencies, public release, regulatory filing, or multiple audiences?

input: user responses to each question above. output: confirmed AAR type, sponsor, jurisdictions, compliance drivers, classification level, and audience list captured in a text summary.

---

step 2: capture exercise or incident metadata

ask the user to provide (in separate prompts, one field at a time):

Field	Examples
exercise or incident name	"Operation Steady Coast 2026", "Riverside Wildfire, 2026-04-12"
dates (start, end, duration)	"2026-05-10 to 2026-05-12, 2.5 days" or "2026-04-12 to 2026-04-18, 6 operational periods"
sponsor agency	lead agency (e.g., FEMA Region 1, state health department)
participating organizations	list all participating agencies, healthcare providers, utilities, NGOs, contractors
mission area(s)	Prevention, Protection, Mitigation, Response, Recovery (select all that apply)
threat or hazard	natural (flood, hurricane, earthquake), technological (HAZMAT, power outage), human-caused (active shooter, terrorism), or combination; include specific hazard name
scenario summary	3-6 sentences: what happened or was simulated, escalation arc, if multi-operational-period, note key transitions

input: user-provided metadata fields, one per user response. output: metadata summary table with all fields populated; mark any missing field as "TBD , awaiting user input" and continue.

---

step 3: capture exercise objectives and core capabilities

ask the user: "what were the exercise objectives (or, for a real-world incident, what were the incident objectives from the operational IAP)?"

for each objective user provides, ask:

1. restate this objective in measurable terms (what does success look like?).
2. which core capability or capabilities does this objective target? (user selects from FEMA list or provides alternate list).
3. what capability statement (capability target) applies? (user provides or you retrieve from FEMA core-capabilities list).
4. what critical tasks did the exercise evaluation guide (EEG) define for this capability? (user provides EEG reference or task names, or logs as unresolved if EEG is unavailable).

input: exercise or incident objectives, core capabilities, capability statements, critical tasks. output: objective-to-capability mapping table:

objective #	objective (restated, measurable)	core capability	capability statement	critical tasks (from EEG)	EEG source
1	...	...	...	...	...

rule: do not proceed to phase 2 until at least one objective is mapped to at least one core capability with at least one critical task named (or logged as unresolved).

---

phase 2: evidence intake

step 4: log evaluator observations (EEG-based)

ask the user: "provide evaluator observations one at a time. for each, tell me: time or operational period, location or function, core capability, capability target, critical task, what you observed (the performance), and was this a strength or an area for improvement?"

for each observation, populate:

obs #	time	location / function	core capability	capability target	critical task	observed performance	strength / AFI	evaluator
1	14:30	Command Center	[capability name]	[statement]	[task name from EEG]	[specific behavior or outcome]	Strength or AFI	[name]

rules:

• critical task must be one of the tasks listed in the EEG for the targeted core capability. if user has not provided EEGs, ask user to provide task names or log this as an unresolved-information item.
• observed performance must be specific and grounded in a concrete action or result, not generic praise or vague criticism.
• strength / AFI is a binary tag at the observation level. do not assign core-capability ratings yet; those come in phase 3 after evidence is aggregated.

input: evaluator observations (one at a time). output: observation log table with all fields populated for each observation provided. if critical task is missing and EEG is not available, note "Task name unresolved , EEG not provided" in the table and continue.

---

step 5: log hotwash and participant feedback

ask the user: "share themes from hotwash discussions, participant-feedback forms (PFFs), and after-exercise surveys. for each theme, tell me: what is the theme, where did it come from (hotwash / PFF / survey), how frequently or widespread was it, which core capability does it relate to, and can you paraphrase a sample comment (anonymized, no names or agency-only identifiers)?"

for each theme, populate:

theme	source (hotwash / PFF / survey)	frequency / volume	linked core capability	sample quote (anonymized)
staffing delays at logistics	hotwash	3 out of 8 agencies mentioned	Organization, Resource Logistics	"we waited 45 minutes for supply requests to be processed"

rules:

• anonymize all sample quotes: no individual names, no agency-specific identifiers if the agency is small enough that an identifier could disclose an individual's identity.
• group related themes if more than 20-30 distinct themes emerge; ask user to identify top 3-5 priority themes per capability to keep analysis tractable.
• if a theme does not clearly link to a core capability, ask user: "which capability element (from the FEMA list or sponsor list) does this relate to?" and update the table.

input: hotwash and participant feedback themes (one theme at a time). output: hotwash-and-feedback theme log with all fields populated. themes are later aggregated by core capability in step 7.

---

step 6: log controller and MSEL data

for exercises: ask the user: "share MSEL injects (message schedule of events and list), controller actions, and any unanticipated player branches that affected evaluation. for each, tell me: the inject or action, was it delivered as planned / late / not delivered, the time or exercise period, any controller notes or branches that resulted."

populate:

MSEL inject or controller action	planned delivery time	actual delivery	delivered / late / not delivered	effect on evaluation or play	controller notes
activates unified command	09:00	09:15	late	[capability affected]	participants delayed 15 min; discovered comms issue

ask separately: "were there any safety incidents during the exercise, even minor ones? (cuts, trips, illness, system outages, etc.)"

if user reports safety incidents, log each separately with time, nature, severity, and mitigation applied.

for real-world incidents: ask the user: "share operational-period planning artifacts (ICS-201, ICS-202, ICS-204, ICS-209 from the periods you are evaluating), resource requests (submitted, filled, denied, pending), mutual-aid or EMAC activations, or vendor-contract activations. for each, tell me: what was the resource or artifact, what was the status, and was there any delay or barrier?"

populate:

planning artifact or resource request	artifact type (ICS form, resource order, MOU, etc.)	status (requested / filled / denied / pending)	date submitted / completed	agency requesting	primary provider	any delays or barriers
40 personnel, Type 1 incident management team	ICS-209 resource request	filled	2026-04-13	state emergency office	FEMA	6-hour delay due to out-of-state availability

input: MSEL injects, controller actions, safety incidents (exercises), or ICS artifacts and resource requests (real-world incidents). output: MSEL/controller/ICS log with all fields populated; safety incidents listed separately with severity and mitigation. if controller logs or ICS artifacts are voluminous, group by operational period and ask user to highlight top 5-10 most relevant entries per capability.

---

step 7: build the observation-to-capability crosswalk

aggregate steps 4, 5, and 6 into a per-core-capability evidence list. ask the user: "review the observations, themes, and controller data. for each core capability we are evaluating, what is the capability target, what strengths did we observe, what areas for improvement did we observe, and are there any unresolved questions or gaps in the data?"

populate:

core capability	capability target(s)	strength observations (obs #, theme, or MSEL note)	AFI observations (obs #, theme, or MSEL note)	unresolved questions or data gaps
command and management	establish and maintain incident command	Obs 1, 3 (clear incident commander, unified command activated)	Obs 2, Hotwash Theme "staffing delays" (logistics delays in fulfilling requests)	EEG critical tasks not provided; need to map to planning, organization, or training gap

rules:

• for each in-scope core capability, there must be at least one observation (strength or AFI) tied to it. if a capability has no observations, log it as an unresolved-information item with the reason (e.g., "no evaluator tasked to this capability", "exercise did not stress this capability", "evaluators did not document observations").
• if a capability has only AFI observations and no strengths, note this in the analysis phase (step 9); it will inform the rating.
• unresolved questions are data gaps (e.g., missing EEG, unclear root cause, conflicting observations). flag these for follow-up in step 9 or 10.

input: user review of observations, themes, and controller data aggregated by core capability. output: observation-to-capability crosswalk table with all capabilities in scope populated with at least one observation (strength or AFI) or marked as unresolved. do not proceed to phase 3 until this table is complete.

---

phase 3: rate and analyze

step 8: apply the core-capability rating rubric

for each core capability in scope (from step 7 crosswalk), ask the user: "based on the observations we logged for [capability name], what rating do you assign: P (performed without challenges), S (performed with some challenges), M (performed with major challenges), U (unable to be performed), or do we have insufficient evidence?"

present the rubric:

code	rating	definition
P	Performed without Challenges	the capability target was achieved; critical tasks were performed in a manner that achieved the objective.
S	Performed with Some Challenges	the capability target was achieved, but with some challenges affecting one or more critical tasks.
M	Performed with Major Challenges	the capability target was achieved, but with major challenges affecting one or more critical tasks.
U	Unable to be Performed	the capability target was not achieved.

rules for assigning a rating:

• the rating must be supported by at least one observation in the step-7 crosswalk. if user cannot cite evidence, do not assign a rating; mark as "Not Rated , insufficient evidence" and explain in analysis.
• a capability with predominantly AFI observations cannot be rated P, regardless of overall mission outcome. if AFI observations outnumber strengths, the minimum rating is S.
• if the sponsor uses a different scale (e.g., 1-5, "exceeds / meets / approaches / does not meet"), preserve the sponsor's label and add a HSEEP-rubric crosswalk column in the analysis section.

input: user-provided rating for each core capability, supported by reference to step-7 observations. output: core-capability rating table:

core capability	rating	supporting observations (step-7 reference)
command and management	S	Obs 1, 3 (strengths: clear IC, unified command); Obs 2, Hotwash Theme 1 (AFI: logistics delays)
[next capability]	[rating]	[references]

---

step 9: analysis of core capabilities

for each core capability in scope, write a structured analysis. ask the user (or draft based on step-7 data and user refinement): "for [capability name], tell me what the key strengths were, what did not work well (areas for improvement), and for each area for improvement, why did it happen (root cause)?"

for each capability, populate this template:

### Core Capability: [name]
**Capability Target:** [statement from step 3]
**Critical Tasks Evaluated:** [comma-separated task names from EEG]
**Performance Rating:** [P / S / M / U / Not Rated]

#### Strengths
1. [Observation] ,  [Evidence: Obs # / hotwash theme / controller log]
2. [Observation] ,  [Evidence]

#### Areas for Improvement
1. **Issue:** [what happened or did not happen, specific and grounded]
   **Reference / Standard:** [EEG critical task / plan / SOP / regulation / IAP step the issue is measured against]
   **Root Cause:** [from 5-whys or barrier analysis; must reach the underlying reason, not the symptom]
   **Capability Element (POETE):** [Planning / Organization / Equipment / Training / Exercises]
   **Recommendation (preview):** [one-sentence preview of the corrective action that will address this]

2. **Issue:** [next AFI]
   ...

rules:

• every strength must be grounded in a specific observation (e.g., "Obs 1 documented that the incident commander established a unified command structure at 10:00 without delays"), not generic praise.
• every AFI must reach root cause. ask "why" at least 3-5 times (5-whys method) or use barrier analysis (what blocked execution of the critical task?). do not stop at "we did not have enough staff" without asking why staffing was inadequate (was it a planning gap, a training gap, an availability issue, a coordination failure, etc.). capability-element tagging (POETE) forces this discipline.
• capability-element tagging is mandatory. each AFI is tagged Planning (did the plan or procedure fail?), Organization (was there a coordination or authority gap?), Equipment (was equipment missing, broken, or inadequate?), Training (did personnel lack skill or knowledge?), or Exercises (was this capability never drilled, or drilled under unrealistic conditions?).
• if an AFI cannot be fully analyzed in this session (e.g., EEG missing, conflicting observations), note "Further analysis required , [reason]" and flag as unresolved.

input: user-provided strengths and AFIs with root-cause reasoning for each core capability. output: analysis section (one subsection per core capability) with strengths, AFIs, root causes, POETE tags, and preview recommendations. if the user provides limited narrative, draft the analysis based on step-7 observations and ask user to refine or correct.

---

step 10: internal consistency check

before phase 4, ask the user: "let me review our analysis. [read back: every exercise objective from step 3 has an analysis section, yes?] [every rating is backed up by at least one observation we logged, yes?] [every area for improvement has a root cause and a POETE tag, yes?] [every strength is tied to a specific observation, not just general praise, yes?]"

go through the analysis document and:

• confirm every objective (from step 3) has a corresponding analysis section for its core capability.
• confirm every rating (from step 8) has at least one cited observation from step 7.
• confirm every AFI (from step 9) names a root cause and a POETE tag; if any AFI lacks either, ask user for clarification or re-draft.
• confirm every strength references a specific observation number, hotwash theme, or controller log, not generic language.

input: user confirmation or corrections. output: revised analysis sections incorporating corrections; unresolved items flagged for escalation to sponsor review.

---

phase 4: improvement plan and final packet

step 11: draft corrective actions (SMART)

for every AFI in step 9, ask the user: "for this issue [state the AFI], what is the corrective action? what will we do, who will do it, by when, and how will we know it is done?"

for each corrective action, populate:

| CA # | core capability | capability element (POETE) | issue | corrective action | primary responsible org | org POC (name, email, phone) | start date | completion date | status |
| 1 | command and management | Organization | logistics delays in fulfilling supply requests | develop and test a resource-request flow diagram and streamline multi-agency resource-order process via an inter-agency task group; deliver revised SOP by [date] | logistics branch, county emergency office | jane.doe@county.gov, 555-1234 | 2026-06-01 | 2026-09-01 | Proposed |

rules:

• SMART: Specific (name the action and the deliverable artifact), Measurable (name the evidence of completion: a revised SOP, a training, a test, a memo, etc.), Achievable (within the responsible org's authority and resources), Relevant (tied directly to the AFI and the core capability, not a tangential improvement), Time-bound (concrete start and completion dates, not "ASAP" or "pending").
• never assign a corrective action to an organization without the user's confirmation that the organization has agreed or that the action will be formally proposed to them in an AAR conference after sponsor sign-off.
• default status to "Proposed" until the user marks otherwise (e.g., "Committed", "In Progress", "Completed"). if ownership is uncertain, keep status "Proposed" and flag for follow-up.
• avoid stacking unrelated actions in one row. one row = one specific action. if a single AFI requires multiple actions (e.g., revise an SOP, train personnel, procure equipment), create separate rows.
• if a corrective action requires updating or creating an artifact (EOP, SOP, MOU, training plan, equipment cache, comms protocol, etc.), name the artifact explicitly in the corrective action column.
• link each corrective action to the AFI it addresses by referencing the AFI number or issue statement.

input: user-provided corrective actions (one per AFI), with specifics on action, responsible org, POC, dates, and status. output: improvement plan matrix (table) with all fields populated for each corrective action. if a responsible org has not confirmed ownership by end of session, default to "Proposed" status and flag for user follow-up before sponsor sign-off. do not present the matrix without the supporting AFIs (step 9) above it.

---

step 12: lessons learned

ask the user: "beyond the specific issues in our improvement plan, what are 3-8 durable lessons learned from this exercise or incident? these are insights that apply beyond your jurisdiction, that another agency in a similar situation could learn from."

for each lesson, ask: "what is the lesson, and what is the evidence or context that supports it?"

populate:

## Lessons Learned

1. [Lesson statement] ,  [supporting evidence or context]
2. [Lesson statement] ,  [supporting evidence or context]
...

rules:

• a lesson learned is a generalized insight, not the same as an AFI. "we need to update our resource-request SOP" is an AFI; "lack of a standardized resource-request process creates delays that cascade through multi-agency response" is a lesson learned.
• lessons learned should be transferable: if another agency or jurisdiction ran the same exercise, they would benefit from knowing this insight.
• ground each lesson in evidence (an observation, a theme, a controller action, or a pattern across multiple incidents).

input: user-provided lessons learned (3-8 statements with supporting context). output: lessons-learned section with 3-8 entries, each grounded in evidence. if the user provides fewer than 3 or more than 8, ask: "would you like to consolidate or expand the list to ensure the most important insights are captured?"

---

step 13: executive summary

ask the user: "let me draft a one-page executive summary. it will cover the exercise name, type, dates, sponsor, scope, threat or hazard, scenario summary, mission areas and core capabilities, overall performance, number of corrective actions, and major themes from lessons learned. does this align with what your sponsor expects?"

draft and present an executive summary covering:

• exercise or incident name, type (Tabletop, Drill, Full-Scale, etc.), dates, sponsor, jurisdictions.
• threat or hazard (natural, technological, human-caused) and scenario summary (2-3 sentences).
• mission area(s) exercised (Prevention, Protection, Mitigation, Response, Recovery) and number of core capabilities evaluated.
• performance synopsis: distribution of ratings (e.g., "3 capabilities rated P, 5 rated S, 2 rated M, 0 rated U") without inflating or overselling results. note major themes from strengths (e.g., "command structure was clear and responsive").
• number of corrective actions and distribution by capability element