Inspect before downloading
See what is inside
These previews come from the published bundle files, so you can judge the method and writing before using it.
Deliverable guide
Incident Postmortem Report source-backed Guide
Defines source-backed incident learning and corrective action, evidence handling, and action boundaries.
Read the fileOverview
Incident Postmortem Report overview
Use this bundle to prepare source-backed incident learning and corrective action analysis and a reviewable incident postmortem report.
Read the fileWorkflow
Incident Postmortem Report source-backed triage
1. State the requested decision or artifact. 2. Inventory evidence: incident scope, severity, dates, systems, and stakeholders, timestamped timeline and source records, user, business, data.
Read the fileQuality rubric
Incident Postmortem Report source verification check
Check that responses: - answer directly using the required visible sections - name authoritative source categories and local evidence - separate verified, provided, assumed, and missing.
Read the fileIs this bundle right for your task?
Who it is for
- People drafting, reviewing, approving, or relying on Incident Postmortem Report
- Teams working in Software, Information technology, Operations
When to use it
- An Incident Postmortem Report draft needs a clear purpose, audience, evidence base, structure, and approval path.
- An existing draft needs unsupported claims, missing sections, unresolved decisions, and reviewer comments addressed.
What you need to provide
- The document purpose, audience, source evidence, required sections, constraints, approvers, and intended decision or action.
- Existing drafts, templates, policies, examples, terminology, and review criteria that the output must follow.
Tasks and expected outputs
Questions it helps answer
- Prepare an incident postmortem report without fabricating local facts.
- Separate verified, provided, assumed, and missing evidence.
- Produce a review-ready recommendation with explicit verification and approval boundaries.
What it helps produce
- incident postmortem report
Practical example
Use it with an agent
Load the bundle as context, provide the evidence named above, then adapt this example to your situation.
Provide the document purpose, audience, source evidence, required sections, constraints, approvers, and intended decision or action. Ask the agent to draft or review Incident Postmortem Report and return incident postmortem report with material claims tied to evidence and assumptions, open questions, reviewers, and approval gates marked. Begin with sre.google — Sre Book / Postmortem Culture, then confirm that the reference is current and applicable. Inspect Incident Postmortem Report source-backed Guide before drafting.
Context path: bundles/deliverables/incident-postmortem-report
What the bundle includes
Frameworks
- source-evidence matrix
- incident learning and corrective action review matrix
- qualified-review gate
Evaluations
- Incident Postmortem Report source verification check
Sources used to build this bundle
These are the public references behind the role definition and operating guidance. The bundle does not replace current documentation or evidence from your site.
Limitations and safe use
Do not use this for
- Publishing, approving, or acting on a draft before its material claims, source evidence, owners, and approval gates have been reviewed.
Known limitations
- Use the cited official, originator, standards, or professional sources for general incident learning and corrective action context; local facts, records, values, states, and permissions require inspected evidence.
- Task-specific work requires current evidence for incident scope, severity, dates, systems, and stakeholders, timestamped timeline and source records, user, business, data, security, and service impact, detection, escalation, mitigation, recovery, and communication evidence, trigger, contributing conditions, control gaps, and uncertainty, and corrective actions, owners, priorities, due dates, verification, and closure evidence.
- Do not infer timeline event, impact, root or contributing cause, individual intent, remediation effectiveness, and closure status.
Safety notes
- Minimize personal, customer, employee, financial, credential, security, and other sensitive data.
- Require explicit confirmation before assigning blame, making legal, security, employment, or public claims, closing actions, or publishing the report without accountable review.
- Route legal, privacy, security, compliance, financial, employment, safety, and other qualified judgments to accountable reviewers.