Decision Context Capture
Recording the situation, constraints and forces that made a decision reasonable, so that later readers can judge whether it still applies.
The decision itself is the least valuable part of an architecture decision record. The context is what future readers need, because the question they are asking is not "what did we decide" but "does that reasoning still hold?"
A record that says "we chose PostgreSQL" is nearly useless. One that says "we chose PostgreSQL because the team had operational experience, the workload was relational, we needed strong consistency for payments, and the projected volume was well within a single instance" can be evaluated: three years later the volume assumption may have changed and the others may not.
The sections that carry the weight: context — the forces, constraints and assumptions at the time; options considered and why each was rejected, which is what prevents the same debate recurring every eighteen months; consequences, including the negative ones accepted; and status, so a superseded decision is visibly superseded rather than quietly wrong.
Practical rules: keep them in the repository and versioned with the code, keep them short (one or two pages — long ones are not written and not read), and never edit a decision — supersede it with a new record that links back, so the history of reasoning is preserved.
Write one for decisions that are expensive to reverse. Writing them for everything devalues the practice.