The Incident Record

Before the detail — Decision: keep one document per incident, with every determination and every corrective action inside it. Outcome: a regulator, a contracting officer, and next quarter’s on-call engineer can each open the same file and find what they need. Artifact: the incident record, validated by a checker before it closes. Status of what follows: common baseline; the specific sections named here are binding wherever this training’s record template is adopted.

Prompt first: draft the skeleton, mark every gap

Here are the tickets, chat excerpts, and status-page updates from a
recent incident we never wrote up formally [paste, redacting names
if needed].

Draft an incident record skeleton with these sections, in this
order:
  1. State (timestamped transitions through: detected, declared,
     mitigated, resolved, reviewed - or dismissed)
  2. Impact (who could not do what, for how long)
  3. Timeline (monotonic, one row per event or decision)
  4. Decisions under uncertainty (what was known, what was assumed,
     who decided)
  5. Regulatory determinations (leave blank if none were made -
     do not guess one)
  6. Reporting clocks (leave blank if none apply)
  7. Communications log (audience, recipient, sent time, signer,
     next-update promise)
  8. Evidence preserved (artifact reference, captured_at, custodian,
     preservation duty or none), plus trace and release-record
     identifiers when AI Assurance 6.2 hands them over
  9. Mitigation (what stopped the impact)
  10. Corrective action register (owner, due date, verification
      criterion, closure evidence - leave open items as "open")

Pull only what the pasted material actually supports. Where a
section has no source material - a determination nobody recorded
making, a clock nobody named - write MISSING rather than inventing
a plausible-sounding entry.

Tickets and chat logs already contain most of a timeline; what they never contain is a clean determination entry or a verification criterion, because nobody was asked for one in the moment. The prompt surfaces those gaps as MISSING rather than filling them with something that reads well.

One document, ten sections

The incident record is not a ticket, a postmortem, and a compliance memo stapled together — it is one file with ten sections. Meridian’s filled example, INC-2026-041 (a FieldDesk connection-pool leak that put field crews on radio for 27 minutes), is explicitly NON-PRODUCTION and fictional, and shows what each section holds in practice.

Section 1, State, is a table of timestamped transitions — the lifecycle field, covered on its own below. Section 2, Impact, is written before the cause: who could not do what, for how long, written down before anyone starts explaining why. Section 3, Timeline, is monotonic and append-only: INC-2026-041’s fifteen rows run from the 14:15 deploy on 2026-08-18 to the 16:30 review on 2026-08-21, three days later; equal timestamps are permitted, but rows must never go backward. Section 4, Decisions under uncertainty, records what was known and what was assumed at the moment of each call — INC-2026-041 flags its own 14:33 rollback decision as “the one worth arguing about in review,” because the commander chose rollback over a heap dump that the record estimates would have kept crews on radio about four more minutes; a tabletop run adds its own incident-commander handoff sub-table here too (outgoing, incoming, acknowledged at, open items handed over) — 3.3 owns the handoff itself. Section 5, Regulatory determinations, and section 6, Reporting clocks, are covered below. Section 7, Communications log, lists every notice that left the incident — audience, recipient, trigger family, rule source, signer, artifact, next-update promise — and an external row to a regulator, agency, or contracting officer must resolve that source. Section 8, Preserved evidence, names what was captured, when, by whom, and whether an instrument required it or someone chose to keep it. Section 9, Mitigation, names what stopped the impact and points at a change reference rather than re-explaining rollback mechanics that belong to a different training. Section 10, Corrective action register, is the one list of follow-ups the record keeps — in INC-2026-041 every closed action carries evidence a reviewer can open, and the open action states its closing condition rather than a vague “in progress” — and it carries a postmortem-trigger check completed before the record moves to reviewed.

A Timeline or Decisions-under-uncertainty row an assistant drafted carries one more thing: a compact ai_drafted: draft_id=<id>; evidence_referenced=<what it read>; verifier=<human>; verified_at=<UTC instant>; accepted_changes=<what changed, or "none"> marker on that row, naming what was AI-drafted and who verified it — one of the record’s promises since Lesson 1.1’s premise. INC-2026-041’s 14:31 timeline row is the worked example: an assistant drafted the reconstruction from sim/replay.excerpt.jsonl#L61-L90 and the alert-test transcript, and j.whitfield verified it five minutes later, correcting the deploy timestamp and the first observed 504. 3.4 owns the assistant’s provenance.

Ten sections, one file, no second document tracking the same facts differently — which is the whole point: a reviewer never has to reconcile two versions of what happened.

The lifecycle field is the state machine, and nothing else is

Section 1’s state field holds exactly the six values Lesson 1.2 introduced — detected, declared, mitigated, resolved, reviewed, or the terminal dismissed — and nothing else. INC-2026-041’s record makes the boundary explicit in its own text: “there is no reporting state,” because a regulatory determination is a dated entry in section 5, never a value the state column holds. A record that tried to say an incident was “in reporting” would describe neither a system state nor a determination; section 5 already records that fact precisely.

A reviewer who finds “reporting” sitting in the state column has found a record that cannot be trusted to say what state the incident was actually in.

What the checker enforces, and what it does not

From scripts/t8-substrate, run python3 incident/validate.py; it exits 0 when the committed artifacts pass and 1 when it finds a validation failure. It enforces the state vocabulary; a nondecreasing timeline, allowing equal timestamps; the four corrective-action fields; and a rule-source key that resolves in sources.json, or n/a/none when no instrument applies.

Four newer rules cover the sections above: an external communications-log row must be complete with a resolving rule source, and every next-update promise must be later than its own timestamp or the literal none (resolved); preserved-evidence rows never predate detection; a handoff needs a different incoming and outgoing name, an acknowledgment no earlier than declared, and a non-empty list of open items (unconfirmed - ... is allowed and reported as a warning); and a record cannot reach reviewed with an incomplete postmortem-trigger check.

python3 incident/validate_selftest.py applies 52 mutations, including a backward timeline and a missing verification criterion — three of them the AI-provenance rule, five the communications log, two preserved evidence, three the handoff sub-table, and two the trigger check. The broader prebuild gate separately tests a clock computed from the wrong trigger family and an emitted record with an unattributed decision. What the validator deliberately does not check is prose quality; it checks the things that are false often enough to be worth a machine’s attention, and leaves judgment to the humans who wrote the record.

What it stores from elsewhere, and what it never re-derives

AI Assurance 6.2 — a separate training in this series — hands off exactly here: when a periodic review of a deployed AI system turns up an answer that harmed someone, that review hands the incident to this training with a trace attached. This record stores only the trace identifier and release-decision-record identifier — the header’s trace_id and release_record_id fields, n/a where neither applies — and AI Assurance 6.2 owns the join between them.

The record supports evidence for IR-4 — the incident-handling control family — and IR-6 — the incident-reporting family. It does not claim to satisfy either. It also supports evidence for IR-8 — the incident-response-plan family.

Where the North American Electric Reliability Corporation’s CIP-008 R4.1 — the report-attribute requirement for covered bulk-electric cyber systems — applies to a High- or Medium-impact system, it calls for functional impact, attack vector, and intrusion level. Sections 2 and 5 store those attributes; the record does not claim every incident is reportable.

Naming what the record supports evidence for, and stopping there, keeps the claim honest: raw material an assessor reads, not a certification this training issues on Meridian’s behalf.

Stop and escalate when validate.py exits 1 on a record someone is about to move to reviewed. A corrective action with no verification criterion, a reporting-clock row with no source, or a timeline that runs backward is not a formatting nitpick the record owner can wave through — it is a finding a reviewer will otherwise make for free, later, with less goodwill. Escalate to the record owner before the state changes, not after.

Key takeaway

The incident record is one document, ten sections, holding the state, the impact, the timeline, decisions under uncertainty, dated determinations, reporting clocks, a communications log, preserved evidence, mitigation, and a corrective-action register with nothing living twice. Its lifecycle field is the same six-state machine Lesson 1.2 introduced, and a regulatory determination is always a dated entry in section 5, never a state. A stdlib validator checks the mechanical things that go wrong often enough to matter, and the record stores the trace and release-record identifiers an upstream AI-assurance review hands off, without re-deriving that review’s own join. Module 2 turns to what starts all of this: the page itself, and what makes one worth answering.

LEADERSHIP DECISION   adopt one incident record format across every
                      service, so a regulator, a contracting officer,
                      and next quarter's on-call read the same shape
                      every time
PRACTITIONER ACTION   fill every section as the incident happens, run
                      the validator before moving a record to
                      reviewed, and cite a source for every clock and
                      determination row
SUCCESS MEASURE       zero records that reach reviewed with a failed
                      validation - an audit finding avoided at the
                      moment it would otherwise first be found