Runbooks that update themselves after each incident.

The problem​

Postmortems were the team's most expensive document and their most ignored one. Each one took an afternoon to write, sat in a folder no on-call engineer opened during an incident, and became misleading the moment the underlying system shifted. Six months in, the runbook said one thing; the postmortems said another; the team trusted neither.

The teams who needed postmortems most — the ones whose memory was being rotated out by hiring and reorg — got the least value from them. By the time a recurring incident hit, the engineer who had written the relevant postmortem was on a different project. The document remained; the context did not.

The approach — the runbook is the codex​

The team stopped treating the runbook as a static document and started treating it as a living cluster of gnoses. Each postmortem now produces a small dated cluster — three to ten gnoses, each carrying confidence and references — that gets validated against the existing codex on publish.

Three constraints shape the workflow:

• Capture happens during the review, not after. The team writes gnoses in the same meeting they conduct the review. The platform's sync resolution means out-of-order edits land cleanly.
• Aletheia validates against the live runbook. When a new gnosis contradicts a stored one — different recovery window, different blast radius, different remediation — the platform surfaces the conflict and asks which one is now true.
• Retrieval happens before the next incident. The on-call dashboard surfaces the relevant cluster the moment a similar pager fires. The on-call engineer reads the codex, not their colleague's memory.

We used to write postmortems for our future selves. We never read them. Now the platform reads them for us — and tells us when our future self disagrees with our past self.

ALAnders L. — SRE lead, infra_core

Shape of a postmortem cluster​

A cluster is the smallest unit a future incident can retrieve. It typically contains a top-level gnosis describing what happened, two or three describing the recovery actions taken, one capturing what the team learned about the system that the runbook had wrong, and — when the review surfaces them — gnoses that supersede prior runbook claims.

Each gnosis carries the incident's op_id as a reference. Every retrieval of the cluster, weeks or months later, traces back to the incident that produced it. There is no separate "incident archive" — the codex itself is the archive.

Operations & telemetry​

The full review-to-publish cycle records as one operation. Conflicts surfaced by Aletheia are themselves logged events, not silent edits.

Outcomes after two quarters​

• 2.4×
  MTTR fell on the second cycle of every incident class.

  Incidents that recurred after the first postmortem resolved in under half the prior baseline. The next on-call retrieved the prior cluster before opening a runbook tab.

• −63%
  Repeat-class incidents per quarter.

  Aletheia surfaced contradictions between the live runbook and the new postmortem in 39% of cases — most were stale procedures the team had been running on muscle memory.

• 47
  Runbook amendments shipped per quarter.

  Each amendment was traceable to the incident that prompted it. Ops review meetings stopped being archeology sessions.

• 100%
  Of new incidents now retrieve their related cluster on open.

  The previous baseline (manual lookup) stood at 32%. Most of the lift came from making retrieval the default, not training people to remember.

Implementation playbook​

Four decisions worth making early when you wire incident review into Gnostikon.

1 · Make the review meeting the capture surface.​

Don't ask engineers to "transcribe" the meeting later. The platform's offline-first capture means a laptop with a flaky connection still produces validated gnoses. Capture happens once, during the review.

2 · Pin an operational_safety ethos for the on-call scope.​

Operational gnoses are not the same as research gnoses; they need stricter validation, denser references, and shorter confidence half-lives. A dedicated ethos makes that explicit, and the platform enforces it.

3 · Treat Aletheia conflicts as the agenda for the next review.​

When the platform surfaces a conflict between a new postmortem and a stored runbook, that contradiction is the most valuable input to the next on-call rotation. Pull it into the next review's agenda, not into a backlog.

4 · Retire gnoses on a schedule, not on intuition.​

Operational truths decay. Pin a confidence half-life on the operational ethos and let the platform downweight gnoses past their freshness window. Retired gnoses do not vanish — they are revisable, replaceable, and audit-traceable.