# Incident diagram review worksheet

A diagram supports the incident record. It does not establish root cause, implement a fix or replace a postmortem.

## Confirm observations

| Time | Observation | Evidence reference | Confidence / unknowns |
| ---- | ----------- | ------------------ | --------------------- |
|      |             |                    |                       |
|      |             |                    |                       |
|      |             |                    |                       |

Use authorized evidence only. Avoid credentials, customer-identifying information and private context your review audience should not access.

## Map what happened

- Identify the affected flow, its boundary and the observed failure.
- Separate observations from hypotheses explicitly.
- Ask the service owner to verify the source and diagram.
- Retain the incident version before representing a future design change.

Example input:

```text
@Arialine map the confirmed checkout incident: payment succeeded, fulfillment failed, manual retry completed. Mark the worker failure cause as unknown.
```

## Review proposed prevention

| Proposed change | Owner | Implementation reference | Verification |
| --------------- | ----- | ------------------------ | ------------ |
|                 |       |                          |              |

Request a separate addressed diagram change. Review and apply the proposal if that channel uses proposal mode. A new diagram version is not a deployed fix.

## Publish the learning

Keep impact, contributing factors, unresolved questions and reviewed follow-up actions in your normal incident record. Reference the checked diagram version and source discussion. Retain the original Markdown if you convert a write-up to Slack Canvas; conversion does not create two-way synchronization.

Workflow: https://arialine.app/use-cases/incident-postmortems
Reference: https://sre.google/sre-book/postmortem-culture/