Decisions Get Records
Core Concept
Every non-trivial decision gets a written record. Format: Context, Decision, Why, What We Rejected, Consequences, Links. This creates an auditable trail of reasoning that future sessions (or future people) can trace.
The Pattern
You make a decision in conversation. It feels obvious at the time. Weeks later, someone (or you in a future session) asks “why did we do it this way?” and nobody remembers the reasoning. Worse: the context that made the decision right has changed, but nobody knows what the original context was, so they can’t evaluate whether the decision still holds.
ADRs (Architecture Decision Records) solve this by capturing the decision AND its reasoning at the time it’s made — not retroactively when memory has faded.
Where I’ve Seen It
- Show Notes (Feb 2026): Three ADRs recorded in 14 sessions —
001-pick-show-notes(why this product),002-transcript-caching(cost optimization),003-phase1-to-phase2(moving to product test despite 0/12 pain confirmation). Each one captured context that would have been lost. ADR-003 is especially valuable: the reasoning for moving to Phase 2 despite failing Phase 1 validation was nuanced (JTBD pivot, non-consumption jobs can’t be validated through conversation). Without the record, future sessions would see “moved to Phase 2 despite 0/12” and think it was reckless. - OrangeQC: ADRs for architectural decisions are part of the turnaround playbook.
The Countermeasure
- Record at decision time, not later. The reasoning is freshest when the decision is made.
- Include what was rejected and why. This prevents revisiting settled questions.
- Link to the evidence. Connect the decision to the data, conversations, or analysis that informed it.
- Keep it concise. A decision record that takes 30 minutes to write won’t get written. 5-10 minutes is the target.
Related Patterns
- Scan-Before-Deciding — Scan thoroughly before deciding; record what you decided
- Validate-Before-Building — Validation data feeds decision records