Decision Lifecycle Management

Decisions have lifecycles. They are proposed, accepted, implemented, and eventually superseded or deprecated. An ADR practice that ignores the lifecycle produces a catalog of decisions with no indication of which ones are still active. The engineer reads ADR-015 — "use MongoDB for the analytics store" — without knowing that ADR-038 superseded it with "migrate to PostgreSQL with TimescaleDB." Lifecycle management prevents this by making the status of every decision visible.

1. Status Transitions Five statuses: Proposed (under review), Accepted (approved and active), Implemented (built into the system), Superseded (replaced by a newer decision), and Deprecated (no longer relevant because the system it governed was decommissioned). Every ADR shows its current status and the date of the last transition.
2. Supersession Protocol When a decision is replaced, the original ADR is updated to status "Superseded by ADR-XXX" and the new ADR references "Supersedes ADR-YYY." The link is bidirectional. The reader can follow the chain forward from the original decision to the current one, or backward from the current decision to the original reasoning.
3. Review Triggers Every ADR includes conditions that would justify revisiting the decision. "Review if data volume exceeds 5TB." "Review if the vendor discontinues the community edition." "Review at the 18-month mark regardless." Review triggers make decisions adaptive — they invite reconsideration when conditions change instead of remaining permanent by inertia.