ADR-NNNN: <short decision title>
- Status: Proposed | Accepted | Rejected | Superseded by ADR-NNNN
- Date: YYYY-MM-DD
- Deciders: <role(s) — e.g. Process maintainer, Service owner>
Context
Section titled “Context”The forces at play: what problem or pressure prompted this decision, the constraints that bound it, and what is true today that makes it necessary now. State the problem before any solution. If a decision is being made now but the work is deferred, say so here. No solution yet.
Decision
Section titled “Decision”What we are doing, stated plainly — and, crucially, the alternatives considered and why they were rejected (be fair to them; the rejected options are half the value of an ADR). If this ADR captures a reusable rubric rather than a one-off choice, mark that explicitly. Keep it to the decision; rationale that is really a consequence goes below.
Consequences
Section titled “Consequences”What becomes true once this is in effect:
- Positive: what this buys us.
- Negative / cost: what it costs, the tax we accept, the thing it makes harder.
- Deferred: anything intentionally left undecided or unbuilt, and the trigger that should bring it back (so a future session doesn’t re-derive it from the code).
Status addendum (YYYY-MM-DD): when an
Accepteddecision is fulfilled (carried out, not reversed), append a dated note here rather than opening a new number. Reserve a new ADR for an actual change of direction (which then supersedes this one).