Write an ADR

An ADR (Architecture Decision Record) is the institutional memory of why a choice was made. Six months later when someone asks "why did we pick Postgres over Mongo?", the answer is in the ADR — not in someone's head, not in a Slack thread, not lost.

When to use

• Picking a framework, language, DB, or vendor.
• Defining a service boundary or data ownership.
• Choosing a deploy target.
• Adopting (or removing) a major dependency.
• Setting an org-wide convention (e.g. "all services use OTel").
• Reversing a previous ADR.

When NOT to use

• Implementation detail (variable names, file structure within a service).
• One-off scripts.
• Trivial choices ("which icon library").