# Incident Postmortems

ZERO commits to publishing redacted postmortems for live-trading incidents that
affect autonomous safety, journal truth, public proof, or operator control.

This is the public trust practice: autonomous systems become credible by showing
their failures, not by pretending they do not have any.

## What Gets A Postmortem

Publish a redacted postmortem for:

- any S0 incident from `/docs/failure-modes-autonomous-loop.md`,
- any safety-gate refusal that prevented a live order bug,
- any journal hash-chain mismatch or missing sequence,
- any live lease failure,
- any public metric or proof correction,
- any cross-operator data or control isolation failure,
- any engine behavior that required emergency operator action.

## Redaction Rules

Redact:

- private keys, wallet secrets, bearer tokens, Supabase service keys,
- exact proprietary thresholds if exposing them enables gaming,
- personally identifying operator details unless the operator opts in.

Do not redact:

- date/time of incident,
- affected component,
- detection path,
- blast radius,
- rollback action,
- whether live capital was affected,
- replay id, journal root hash, and anchor URL when available,
- what test or monitor now prevents recurrence.

## Filename Format

Use:

```text
YYYY-MM-DD-short-incident-title.md
```

Example:

```text
2026-05-04-public-mcp-mutation-refusal.md
```

## Required Sections

Every postmortem must include:

- Summary
- Timeline
- Impact
- Detection
- Root Cause
- Resolution
- What Worked
- What Failed
- Follow-Up Changes
- Tests Added
- Public Artifacts

## Template

Copy `/docs/incident-postmortems/TEMPLATE.md` for every incident.

Every postmortem involving a live decision, refusal, replay anomaly, or journal
anomaly should cite a journal root hash from `/docs/journal-cryptography.md` or
explicitly explain why the root was unavailable.