ADR Lifecycle
The states an architecture decision record moves through — proposed, accepted, superseded, deprecated — and the discipline that keeps the set trustworthy.
A decision record is only useful if a reader can tell whether it still applies. That is what the status field is for, and it is the part most often neglected.
Proposed — under discussion, and circulating it is how review happens. Accepted — in force. Superseded by ADR-NNN — replaced, with a link forward. Deprecated — no longer applicable, with no replacement.
Never edit an accepted decision. Supersede it with a new record that references the old one. The chain of reasoning over time is itself valuable — it shows what changed and why — and editing destroys it while creating uncertainty about what was actually decided.
The practices that keep the set worth reading:
Keep them in the repository, versioned with the code they describe, so they are found by people working on it and not in a wiki nobody opens.
Write one for decisions that are expensive to reverse. Recording every choice devalues the practice and buries the important records.
Keep each to one or two pages. Long records are neither written nor read.
Review them when the area changes, and supersede the ones whose context no longer holds. A set of records that has not been touched in two years is being ignored, which is worse than not having one — because a reader will act on a decision whose assumptions expired.