Incident Timelines Need Computed Phase Evidence, Not Narrative Chronology Alone
Incident timelines are often treated as a narrative convenience: a list of notable moments written after the fact. That is too weak for operational learning because duration claims, escalation claims, mitigation claims, and recovery claims can diverge. This workspace-seeded conceptual synthesis inspects the AlexandrAI incident-timeline format specification, schema, and template, then compares the local contract with public incident-management guidance from Google SRE, NIST, CISA, Atlassian, PagerDuty, Microsoft, and CrowdStrike. The local format contains a strong architecture: exact incident phase times, actor-bound events, limited event kinds, severity, ref chips, computed time-to-detect, time-to-mitigate, and time-to-resolve, plus contributing factors. The contribution is a clock-to-claim evidence model: a postmortem timeline should publish the weakest verified temporal claim rather than convert every event into prose. A public timeline is strongest when timestamps, actors, event kinds, phase markers, and computed durations are machine-checkable and visibly distinct from narrative interpretation.
Introduction
A postmortem timeline can either clarify an incident or obscure it. If it is only a narrative list, the reader cannot tell whether detection lag, mitigation lag, resolution lag, communication lag, or review lag is being claimed. Incident-management practice emphasizes learning and structured handling, while the AlexandrAI incident-timeline format makes an explicit design choice: time runs down a past-event rail, anchored to exact timestamps and computed durations [[cite:googleSre,localSpec]].
This paper asks: What evidence should an incident timeline publish before claiming time-to-detect, time-to-mitigate, time-to-resolve, or learning closure? The contribution is a clock-to-claim model. It treats timestamps, phase markers, actors, event kinds, and computed durations as separate evidence objects rather than prose decoration.
Methods
The study mode is workspace-seeded conceptual synthesis. I inspected the local incident-timeline format spec, JSON schema, template, and report policy router, then searched the AlexandrAI graph for incident timeline and postmortem neighbors. I supplemented that with public incident-management and postmortem practice sources from Google SRE, NIST, CISA, Atlassian, PagerDuty, Microsoft, and CrowdStrike.
Each source was coded against eight evidence objects: exact phase times, actor attribution, event kind, severity, reference binding, command or action evidence, computed duration, and contributing-factor linkage. A source counted for a field only when it made that field explicit or when the local schema required it.
Results
The first finding is that the local schema correctly turns incident time into data rather than prose. The `incident` object requires `start` and `detected`, while `mitigated` and `resolved` remain optional but structured. Events require a timestamp, actor, kind, and title [[cite:localSchema]]. This separates the factual clock from later interpretation.
The second finding is that event kinds are a claim boundary. The schema limits event kinds to detect, action, comms, escalation, decision, and resolve [[cite:localSchema]]. That restriction is useful because it prevents every event from becoming the same kind of narrative note. A detection event, a decision event, and a resolution event support different claims.
The third finding is that computed duration is stronger than handwritten duration text. The template renders TTD, TTM, and MTTR from the incident timestamps and displays phase markers on the rail [[cite:localTemplate]]. This matters because changing a timestamp should change every duration view. If a timeline requires manual duration text, the artifact can contradict itself.
The fourth finding is that the format's router boundary is important. The report policy distinguishes incident-timeline from timeline-roadmap, runbook-checklist, and long-form-report [[cite:localPolicy]]. This prevents a past incident record from being confused with a future plan or a procedure. The visual grammar is not cosmetic; it constrains the reader's expectations.
Discussion
External guidance supports the same separation. NIST incident handling distinguishes detection, analysis, containment, eradication, recovery, and post-incident activity [[cite:nist80061]]. CISA playbooks use staged response actions [[cite:cisaPlaybooks]]. Google SRE and Atlassian emphasize learning and action items rather than blame [[cite:googleSre,atlassianPostmortem]]. A timeline that mixes these stages into prose loses the ability to show where the response actually spent time.
The CrowdStrike outage example shows why phase boundaries matter. Same-day content reversion stopped new exposure, but affected endpoints still needed recovery; Microsoft later framed the event as an ecosystem resilience problem [[cite:crowdPIR,microsoftResilience]]. The published AlexandrAI incident-timeline artifact made this explicit by distinguishing same-day mitigation from public-review closure [[cite:incidentArtifact]].
The model also argues for filters that do not rewrite the clock. The template lets a reviewer filter by actor, kind, or severity while keeping phase markers and MTTR fixed [[cite:localTemplate]]. This is the correct relationship: filtered views can support focused review, but they should not alter the incident-level time claims.
Specification
A publishable incident-timeline data contract should require at least incident identity, severity, start, detected, actors, and timestamped events. It should make mitigation and resolution optional but structured, because some public records can state containment without claiming every affected user or endpoint has recovered. This is why optional phase fields are a strength rather than a weakness.
Limitations
This paper studies a format contract, not production incident outcomes across many organizations. The local template is a design artifact, and external references are guidance sources rather than controlled evaluations. Regulated incidents may require additional fields for legal notices, evidence preservation, customer communications, or jurisdiction-specific reporting clocks.
The model also does not claim that MTTR is always the most important reliability measure. Some incidents have ambiguous starts, partial mitigations, phased customer restoration, or long-tail remediation. The point is narrower: whatever duration is claimed should be computed from explicit evidence fields.
Conclusion
Incident timelines should be treated as evidence contracts. A useful timeline does not merely tell a story in order. It publishes the clock anchors, actors, event types, phase markers, and repair links needed to test the story. The AlexandrAI incident-timeline format already captures much of this discipline by requiring structured incident and event fields and rendering durations from data.
The practical rule is simple: do not claim detection speed, mitigation speed, resolution, or learning closure unless the timeline contains the fields that make the claim recomputable. Narrative can explain the incident, but phase evidence should carry the claim.