R
Record evidence
Alerts, logs, deploys, metrics, human notes, and customer reports — each entry requires a non-blank summary and a named, authorized recorder. Nothing is inferred before it's logged.
INCIDENT POSTMORTEMS
Postmortems that
can’t invent
what didn’t happen.
Every root cause, every detection detail, every resolution step is generated from your recorded evidence only. A claim with no citation is marked UNSUPPORTED or dropped — never guessed, never estimated, never assumed.
✓ Every claim cited or removed✓ Publish requires named human approval✓ Full-text search across resolved incidents
LIVE GROUNDING CHECK7 evidence items
E-3
Database connection pool exhausted at 14:32 UTC after a deploy raised worker concurrency without updating the pooler limit.cited: deploy log E-3, metric spike E-5
E-1
On-call rolled back the release at 14:41 UTC, restoring service by 14:44 UTC.cited: incident timeline E-1
UNSUPPORTED
Estimated customer impact: $40,000 in lost revenue.no recorded evidence — claim removed automatically
DRAFT GUARD1 unsupported claim dropped
Removed automatically before this draft could be saved — nothing was added to compensate.
GROUNDED AGAINSTAlertsLogsDeploysMetricsHuman notesCustomer reports
THE GROUNDING PIPELINE
Five steps. No shortcuts.
Each step exists because skipping it would let an unverified claim through. The pipeline is only as trustworthy as its least-checked step, so none of them are optional.
G
Generate a draft
The model drafts the summary, root cause, detection, resolution, contributing factors, and follow-up actions from the recorded evidence only — never from memory, pattern-matching, or assumption.
V
Verify grounding
Every sentence is checked against its citation index after generation, not just requested in the prompt. No valid citation into the evidence list means the sentence never reaches the draft.
H
Human approval
A named approver reviews the draft. The database itself refuses to store a published postmortem without both an approver and an approval timestamp — that guarantee doesn't live in application code.
P
Publish & search
Published postmortems become full-text searchable, so the next incident can surface this one before repeating it. Unreviewed drafts are never returned as prior art.
WHAT THE PIPELINE WILL NEVER DO
Guardrails, not good intentions.
These aren’t writing-style guidelines the model is asked to follow. Each one is enforced after generation, or by the database, so it holds even if the prompt is bypassed.
Invent a cost
Customer counts, revenue lost, and dollar figures are explicitly forbidden in the drafting prompt unless the evidence itself states them.
Enforced in the system prompt and checked again after generationGuess a date
Deadlines, incident start times, and names are never fabricated to fill a gap the evidence didn't cover.
Verified by a property test: output text is always a subset of the model's cited text, plus UNSUPPORTEDPublish itself
A draft cannot become a published postmortem without a named human approver recorded in the same write.
A database constraint, not application logic — it holds even if the API is called directlyVERIFIED, NOT ASSERTED
Tested the way the claim is checked: after the fact.
The grounding pipeline is proven with a property test — the output is always a subset of what the model produced, plus the fixed UNSUPPORTED marker. It cannot add a claim; it can only remove one.
Publish blocked without approverOne postmortem per incident, enforcedBlank authorizer rejected at the schemaUnknown evidence source rejected
ENFORCEMENT LAYEREvidence → Draft → Grounding check → Database constraint → PublishEach arrow is a real gate, not a convention. Two are enforced by PostgreSQL itself.
QUESTIONS
Before you record the first incident.
If something here doesn’t match what you see in the product, that’s a bug — tell us.
For the four required sections — summary, root cause, detection, resolution — an uncited claim is replaced with a fixed marker: "Not established by the recorded evidence." Optional contributing factors and follow-up actions are dropped entirely instead of being replaced. The pipeline can only remove text the model produced; it can never add a claim beyond what's cited.
No. The database enforces it directly: a postmortem with status "published" must have both approved_by and approved_at set, checked by the same constraint that governs the status column. That isn't something application code can be tricked into skipping.
Regenerating a draft deletes only the previous attempt's model-generated actions — anything a human added by hand stays. Redrafting a published postmortem returns it to draft and clears the prior approval, so it can never stay marked "published" while being silently rewritten underneath.
Published postmortems are indexed with PostgreSQL full-text search across their summary and evidence. Search only ever returns published, reviewed postmortems — a draft nobody has approved yet is never surfaced as prior art.
STOP GUESSING WHAT WENT WRONG
Record the evidence.
Let it write the postmortem.
Start recording evidence for your next incident. The draft, the citations, and the guardrails come with it — included with every paid NanoNeuron workspace.
No client access before payment verification.