TL;DR
AI can organize an incident review, but the transcript is not the incident record.
Build the postmortem draft in six evidence lanes:
verified timeline → impact → contributing conditions → response analysis → corrective actions → unresolved questions
Every material statement should carry a recoverable source and one of four states: OBSERVED, REPORTED, INTERPRETED, or UNRESOLVED. Link timeline entries to logs, metrics, status updates, tickets, or other approved records. Do not infer root cause, severity, customer impact, ownership, deadlines, or completion from the meeting conversation.
This is a workflow for the review meeting and its draft packet. It does not replace incident response, monitoring, forensics, an incident commander, or the organization's approved system of record.
Why an incident transcript is not a postmortem
An incident review often contains a useful reconstruction, but it also contains memory gaps, corrections, competing explanations, and statements made before every system has been checked. A fluent summary can erase those differences.
Three failures are especially costly:
Conversation order becomes event order. People discuss the same alert several times and jump backward in time. Transcript position is not a canonical timestamp.
A plausible mechanism becomes root cause. A hypothesis repeated confidently is still a hypothesis until the evidence and responsible reviewers support it.
Discussed remediation becomes committed work. A suggested fix is not assigned, scheduled, verified, or complete merely because it appeared in the meeting.
Google's SRE postmortem guidance recommends a detailed timeline, a complete impact assessment, sufficiently detailed root-cause analysis, reviewed action items, broad learning, and tracked follow-through. PagerDuty's postmortem process asks reviewers to recap the timeline, detection, customer impact, and action items; its postmortem template asks for links to the tools or logs behind timestamps. These sources support evidence and follow-through as operating principles; the six-lane packet and four state labels below are this article's proposed method.
Set the evidence boundary before the meeting
List the sources the draft may use. Depending on policy and incident type, that may include:
- monitoring graphs and alert history;
- application, infrastructure, audit, or deployment logs;
- incident-channel messages and status updates;
- change records, tickets, runbooks, and rollback notes;
- support reports and approved customer-impact evidence;
- the reviewed incident transcript and meeting notes.
Treat the transcript as one source among several. It can help locate claims and questions, but it should not outrank timestamped operational evidence.
Use four evidence states
Label material claims before polishing prose.
| State | Meaning | Example |
|---|---|---|
| OBSERVED | Directly supported by an approved artifact | Error-rate graph crossed the documented threshold at 14:07 UTC |
| REPORTED | Stated by a person or team, not independently verified in the packet | Support reported failed checkouts in two tickets |
| INTERPRETED | A reviewed explanation derived from evidence | The retry storm likely amplified database load |
| UNRESOLVED | Evidence is missing, conflicting, or still under investigation | First affected request is not yet established |
These labels are not confidence scores. They show what kind of support a reader should expect and where more work is required.
The six-lane incident review packet
1. Verified timeline
Normalize events to one time zone and link every material row to its source.
| Time | Event | Evidence state | Source | Correction or gap |
|---|
Preserve uncertainty instead of inventing exact timestamps. If a participant says “a few minutes later,” record the statement as REPORTED until a log or timestamped record resolves it. Keep detection time, response start, mitigation, recovery, and verification distinct.
2. Impact
Describe only what the available evidence supports.
| Dimension | Evidence-backed record |
|---|---|
| Users or systems affected | Scope, segment, geography, or service, with unknowns |
| Failure mode | What users or operators experienced |
| Start and end | Verified bounds or explicit uncertainty |
| Quantity | Approved metric and query definition |
| Business or safety effect | Owner-reviewed statement, if available |
Do not turn anecdotal reports into total customer impact. Do not assign severity from tone, attendance, or meeting length. Use the organization's approved severity decision and cite where it was made.
3. Contributing conditions and causal hypotheses
Separate facts from explanations.
| Condition or hypothesis | State | Supporting evidence | Contradicting evidence | Reviewer | Next test |
|---|
A blameless postmortem examines systems, safeguards, incentives, information, and operating conditions instead of reducing a failure to a person's mistake. Google SRE treats blameless behavior as central to a healthy postmortem culture and reliable-system learning, while still requiring concrete follow-up and accountability for action items.
Reserve “root cause” for the conclusion accepted under your incident process. Complex incidents may have several contributing conditions, and some causal questions may remain unresolved after the first review.
4. Response analysis
Review how the system and team detected, understood, communicated, mitigated, and verified the incident.
| Stage | What happened | Evidence | Helped | Hindered | Follow-up |
|---|
Ask operational questions: Which signal first detected the problem? What delayed recognition? Which runbook step worked? What made mitigation safer or slower? How was recovery verified? This is a review of the response path, not a scorecard for individual performance.
5. Corrective actions
Convert approved follow-up into verifiable work.
| Action | Type | Owner | Tracker | Review date | Done condition | State |
|---|
For this packet, useful action types include prevent, mitigate, detect, and respond. An action needs an accountable owner, a destination in the team's system of record, and a done condition that can be checked. PagerDuty's postmortem template routes action items into tracked tickets and covers prevention, preparedness and mitigation, communication, and process improvements.
Do not assign an owner because one person volunteered an idea. Do not create a due date from urgency language. Do not mark work complete from a meeting update without checking the approved tracker or artifact.
6. Unresolved questions and follow-up evidence
Close the packet with the questions that could change the explanation, impact assessment, or action plan.
| Question | Why it matters | Evidence needed | Owner to consult | Checkpoint |
|---|
An unresolved question is a valid output. Hiding it behind confident prose makes the postmortem less useful and harder to correct.
A worked example
Suppose a deployment is followed by elevated request latency and a partial checkout failure. During review, the team says a new retry policy “probably caused” database pressure. A monitoring graph shows latency rising at 14:07 UTC, the deploy record shows completion at 14:02, and rollback completion is logged at 14:31. The database saturation graph is missing for the first ten minutes.
The draft should not state that the deployment caused the incident. A precise packet might record:
| Lane | Reviewed entry |
|---|---|
| Timeline | OBSERVED: deploy completed 14:02; latency threshold crossed 14:07; rollback completed 14:31 |
| Impact | OBSERVED: partial checkout failures in the measured region; total affected users UNRESOLVED |
| Contributing conditions | INTERPRETED: retry behavior may have amplified load; early saturation evidence is missing |
| Response | REPORTED: rollback was selected after the retry change was identified; decision source needs linking |
| Corrective action | Proposed load-test coverage remains unassigned until the service owner accepts it |
| Unresolved question | Did saturation begin before the new retry policy became active? |
That version is less dramatic and more useful. It preserves what the team knows, what it thinks, and what must still be tested.
Copyable prompt for a draft postmortem
Use this only with authorized incident sources:
Prepare a DRAFT incident review packet from the supplied source set. Return six sections: verified timeline, impact, contributing conditions and causal hypotheses, response analysis, corrective actions, and unresolved questions. Label each material statement OBSERVED, REPORTED, INTERPRETED, or UNRESOLVED. Include a recoverable source for every timeline, impact, and causal claim. Preserve contradictions and missing evidence. Do not infer root cause, severity, customer impact, owner, due date, approval, or completion from the transcript. Do not assign blame. Keep proposed actions separate from accepted tracker items. Label the output DRAFT FOR INCIDENT REVIEW.
Review it in this order:
1. The incident owner verifies scope, severity decisions, and the canonical timeline. 2. Service and evidence owners verify operational claims and causal analysis. 3. Support, communications, security, legal, or privacy owners verify their sections when relevant. 4. Action owners accept the tracker items and done conditions. 5. The authorized publisher approves the final internal or external record.
NIST SP 800-61r3, published in April 2025, treats lessons learned as part of continuous cybersecurity incident-response improvement and describes after-action reporting as a record of the incident, response and recovery actions, and lessons learned. It does not prescribe this meeting-note format.
Where Shadow fits
Shadow's current Help documentation describes local meeting capture, transcription, speaker diarization, meeting Markdown, and available media in the local vault. The meeting view brings together the recording, transcript, notes, available screenshots, Skills, and Ask; saved audio can be played from transcript timestamps. A detected Speaker remains a meeting-local voice group until reviewed and assigned.
A configured Meeting Skill can draft a structured incident-review result after processing. Supported Skills can save Markdown or send a result to a configured webhook. A webhook is a transport, not proof that an incident tracker accepted, approved, or completed an action.
Shadow's current Help documentation does not describe automatic ingestion of monitoring data, logs, status pages, or incident tickets. It does not describe automatic reconstruction of a canonical timeline, determination of root cause, severity, or customer impact, creation or closure of tracker items, or publication of an external incident report.
When Smart Screenshots are enabled, captures can preserve changing visual context locally while Listening is active and a target is available. A screenshot of a dashboard is not a substitute for the underlying metric, query, time range, or retention policy.
Review privacy and data leaving your Mac before using external AI, Ask, sharing, or webhooks. Obtain the required recording consent before capture. Incident records can contain credentials, customer data, vulnerabilities, and privileged discussion, so exclude material that is not authorized for the selected processor or destination.
What is real, what is interpretation, and what is unproven
Real now
- Established incident-response guidance supports evidence-linked timelines, impact assessment, learning, and tracked follow-up.
- Shadow currently supports reviewable local meeting records plus optional Skill output under documented privacy and routing boundaries.
- Meeting statements still need reconciliation with the organization's canonical incident sources.
Interpretation
- The six-lane packet and four evidence states are this article's proposed review method.
- Separating observed, reported, interpreted, and unresolved statements can make the correction path visible.
- A typed action table can expose proposals that lack an owner, tracker, review date, or done condition.
Unproven
- This article does not claim the packet reduces incident duration, recurrence, or review time.
- It does not claim meeting transcripts establish root cause, severity, or total customer impact.
- It does not claim Shadow automatically investigates incidents, verifies operational evidence, updates trackers, or publishes postmortems.
Measure the workflow across five reviews
| Check | Question |
|---|---|
| Source coverage | What share of material timeline and impact rows have a recoverable source? |
| Correction rate | Which claims changed after evidence-owner review? |
| State precision | Were observations, reports, interpretations, and unknowns kept separate? |
| Action acceptance | Which proposed actions became accepted tracker items? |
| Closure proof | Did completed actions include the required verification artifact? |
| Question carry-forward | Did unresolved questions reach a named checkpoint? |
Do not report faster resolution or fewer incidents unless your own operational data supports it. The immediate quality test is simpler: can a reviewer recover the evidence, see the uncertainty, and verify the follow-up?
If this workflow fits your incident-review process, download Shadow and test one draft from an authorized review meeting. Keep it in draft until the operational, impact, action, and publication owners have approved their sections.
Sources and verification date
This article was researched and verified on October 6, 2026.