Decision Narrative

The conclusion is the least valuable part of a decision record. The reader's question is almost always "does this reasoning still apply?", and only the context answers it.

What to write, and how:

The forces, specifically. Not "we needed a database" but "the team had operational experience with PostgreSQL, the workload was relational, payments required strong consistency, and projected volume was well within a single instance". Three years later a reader can check each of those independently.

The options rejected and why. This is the section that prevents the same debate recurring every eighteen months, and it is the section most often omitted. Record what was attractive about the rejected option as well as what ruled it out — otherwise the record reads as advocacy and is distrusted.

The consequences accepted, including the negative ones. A record listing only benefits is not a decision record; it is a justification.

Assumptions with expiry conditions — "this holds while volume stays below X" — which turns the record into something that can be revisited on a trigger rather than on someone's memory.

Practical constraints: one or two pages (long records are neither written nor read), in the repository with the code, and never edited after acceptance — supersede instead, so the chain of reasoning over time is preserved.