Skip to content

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>

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.

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.

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 Accepted decision 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).