engineering-decision-recordlisted

# Architecture decision record ## Purpose Two failures recur. A decision gets made in a meeting, nobody writes down what was rejected, and six months later the team relitigates it with worse information. Or an ADR is written as an advertisement for the chosen option: alternatives listed only to be dismissed, no cost admitted. This skill produces records that survive both — a record whose value is that it tells you what would have to change for the decision to be reversed. ## Prerequisites - **Inputs:** the decision being forced and what triggers it now; the constraints that are genuinely fixed (deadline, existing systems, team skills, regulatory obligation); at least two options that a competent engineer would defend. - **Access:** whoever holds the authority to accept the decision. An ADR nobody can accept is a proposal, and should be labelled Proposed, not Accepted. If only one option exists, this is not a decision — it is a constraint. Record it as context somewhere else and stop. ## Procedure 1. **Write the forcing function first.** One paragraph: what is true now that makes this decision necessary this quarter? "We should think about our database" is not a forcing function. "Write throughput on the primary is at 70% of capacity and growth projects it to 100% within two quarters" is. An ADR without a forcing function is usually premature and will be overtaken. 2. **State the constraints separately from the preferences.** A constraint is some