Read the record before deciding the next action
The fictional Dispatch service has a proposed rollback limited to one canary. Before execution, the record must establish data compatibility and authorization for that exact proposal and scope. After execution, two separate outcome checks cover user requests and the older backlog. These are supplied exercise rules, not a universal incident policy.
The sequences deliberately omit evidence or introduce a contradiction. One has approval without execution. Another has a timed-out execution response, which leaves the destination state unresolved. A later failed backlog check can overturn an earlier passing fixture. Read only the events currently revealed before choosing the next step.
Replay a synthetic decision record
no proposal
No action is proposed in the record.
No events have been read yet. Advance the record to see which claim becomes supported.
Reproduce the replay
Download both files into one directory and run them with Python 3. The script reads JSON and prints a state and reason for each sequence. It executes no operational command and calls no external service.
Download the replay script · Download the ten synthetic sequences
python3 incident_replay.py incident_cases.json --self-test
python3 incident_replay.py incident_cases.jsonWhat the replay checks
Authorization must match the current proposal identifier and scope. An execution record must follow matching authorization and the required passing preconditions. Command acceptance still leaves required service outcomes unverified. A timeout requires reconciliation rather than an automatic retry. A verification event updates the recorded outcome, so a later contradiction remains visible instead of being discarded.
The fixtures include withheld compatibility, an unapproved proposal, approval without action, unauthorized execution, command acceptance, an unknown execution result, partial recovery evidence, complete fixture evidence, a later contradiction and a scope mismatch. Expected states are included beside the inputs. The self-test checks those expectations against the replay implementation.
Use the exercise to improve a real record
Have another responder read a sanitized record with one consequential result withheld. Ask which claim is still unresolved, who can resolve it and which action must wait. Then supply the result and see whether the justified next step changes. This tests the record’s usefulness; it does not establish that the real mitigation is safe.
The parser trusts the synthetic event facts. It does not authenticate people, validate a real permission system, prove compatibility or independently observe recovery. Real incidents need the service’s actual policy, authorization path and independent evidence. A chronological JSON file cannot create any of them.
Use the runbook builder for an operational procedure, the timeline calculator for timing, and the mitigation-authority guide for the decision boundary.
Sources and provenance
The exercise applies the site’s approved distinction between coordination, production authority and verified outcomes. Google’s incident-response workbook supports coordinated responsibilities and a shared working record. The scripts and fixtures were tested locally. Dispatch, its canary, people and event results are constructed teaching material, not a real incident.