Name the decision in one sentence. Start with the verb. "Store notification state in Postgres rather than Redis." Not "Notifications architecture v2." A decision has a subject and an object.
State the forces. Two to four bullets on what's pushing on this call. Volume expected. Read/write ratio. Durability requirement. Team skill. Existing infra. Budget. The forces are the reason the decision is non-obvious; no forces, no ADR.
List the options considered. At least two, ideally three. Each gets a name, a one-line description, and one line on what the system would look like if picked. Do not skip options "we'd never pick" — recording the rejected option is half the value.
Build the tradeoff table. Three or four columns max — pick dimensions that actually matter for this decision, not a generic checklist. Common dimensions: operational cost, latency, durability, team familiarity, reversibility, blast radius on failure. Rate each option on each dimension in plain words (fast, slow; cheap, pricey; reversible in a day). Numbers are fine if you have them; do not invent them.
State the decision and the reason. One sentence for the decision. Two to four sentences for the reason, written as "We picked X because of forces A and B; we rejected Y because it failed dimension Z." The reason ties back to the forces and the tradeoff table. If the reason is "it felt right," the ADR isn't ready.
Run the regret check. Ask: "What would we regret in six months if this is wrong?" Write the failure mode, the early warning sign, and the rough cost of reversing. Small regret cost plus obvious warning sign means you can commit fast. Large regret cost and no warning sign means slow down and prototype before deciding.
Record consequences and follow-ups. Bullet list of work this decision creates: schemas to migrate, libraries to add, tests to write, docs to update. The coding agent reads this list directly.