Operations Intelligence

Incident Narrative Studio

A drafting tool that turns alerts, deploys, operator notes, and telemetry into plain-English updates and postmortem scaffolds with source references.

Signal into narrative Postmortem scaffolding

Problem

During incidents, teams communicate across chat, tickets, dashboards, and ad hoc notes. That fragmentation slows status updates in the moment and makes postmortems harder because the timeline has to be reconstructed later from scattered sources.

Notes

What it does

Incident Narrative Studio helps operations teams write better during incidents, not just after them. It converts alerts, deploy events, notes, and telemetry references into structured drafts for status updates and postmortem scaffolds.

The emphasis is on speed with guardrails. The system should help a responder communicate clearly without pretending that the generated narrative is automatically correct.

How the workflow works

An incident timeline is assembled from alerts, deploy records, operator notes, and query references.
The system groups those events into a structured sequence of impact, detection, mitigation, and recovery.
Draft updates are generated for different audiences with explicit markers for uncertainty.
A human reviewer edits and approves the text before distribution.
The same timeline feeds a postmortem scaffold so follow-up work starts from a stronger baseline.

Core principles

The timeline is the source of truth

Generated prose should be disposable and editable. The real system of record is the event timeline that ties updates back to evidence.

Uncertainty should be visible

During active incidents, teams rarely know the full story immediately. The product should help responders say what is known, what is suspected, and what is still under investigation.

Communication is operational work

Clear internal and external updates reduce repeated questions, lower confusion, and make the incident itself easier to manage.

Suggested metrics

Time to first stakeholder update
Update frequency during active incidents
Missing timeline events discovered during postmortem prep
Follow-up action completion after incident closure

Impact

Improves incident communication quality and shortens the path from raw operational signals to useful status updates and lessons learned.

Stack

FastAPI
Postgres
Python
OpenTelemetry
Markdown
Jinja2
Background jobs

Technical design

Incident intake pipeline for alerts, deploys, notes, and telemetry snapshots
Append-only incident timeline as the source of truth
Draft generator for internal updates, external updates, and postmortem scaffolds
Human review surface for editing tone, certainty, and audience level
Exports and metrics for update cadence, missing events, and follow-up tracking

Engineering decisions

Treat timeline events as canonical and generated text as editable derivative output
Link to telemetry queries and snapshots instead of pasting raw payloads into documents
Make uncertainty visible through structured language like suspected and confirmed
Default to redacted identifiers and placeholders for people, systems, and regions

Tradeoffs

Automation improves speed, but human reviewers must stay responsible for accuracy and tone
Linking instead of copying data is better for privacy, but it depends on durable query references
Different audiences need different detail levels, so templates need configuration rather than one generic summary

Outcome / impact

Status updates become cleaner and easier to publish under pressure
Postmortems get started faster because the timeline already exists
Reliability teams gain a repeatable loop from incident response into follow-up engineering work