You recommended Option B over Option A using a documented trade-off analysis, but six months later a director asks 'why didn't we just do Option A, it looked cheaper?' What should your original rationale document have contained so this question is easy to answer, and what's commonly missing from real-world rationale write-ups?

## What a rationale has to do A well-written rationale for a solution decision does more than record the final answer -- it needs to reconstruct, for a reader with no memory of the original discussion, why that answer was correct given what was known and valued at the time. The most reliable structural pattern for this, borrowed from the **Architecture Decision Record (ADR)** format, has four parts: 1. **The context** -- what problem was being solved, and under what constraints and assumptions. 2. **The options** that were genuinely considered. 3. **The decision** that was made. 4. **The consequences** -- both the benefits gained and the costs or risks explicitly accepted by choosing this path over the alternatives. Critically, this means documenting the losing options in real detail, not just the winner: for each rejected option, the write-up should state specifically why it lost, not just that it did. ## Why the 'why not' is the load-bearing part This matters because the mechanism by which trust in a decision erodes over time is almost always the same: months or years later, someone unfamiliar with the original trade-off notices the surface-level fact that a rejected option looked cheaper, simpler, or more familiar, and asks why it wasn't chosen. If the original rationale only describes the winning option, the person defending the decision has to reconstruct the comparison from memory, which is unreliable, inconsistent across retellings, and looks evasive even when the original reasoning was sound. A rationale document that already states, in writing, exactly why the cheaper option lost -- for instance, that its lower upfront cost was outweighed by a higher total cost of ownership, or that it silently violated a constraint, or that it depended on an assumption the team judged too risky -- turns that later question into a five-minute lookup instead of a stressful, memory-dependent defense. ## Total cost of ownership versus upfront cost **Total cost of ownership (TCO)** versus upfront cost is one of the most common reasons a seemingly more expensive option is actually the right call, and it's also one of the most common gaps in weak rationale write-ups. Upfront cost captures only the cost to build; TCO also includes: - ongoing operational load - licensing and support fees - the cost of hiring or training staff with the relevant skill - the accumulating cost of technical debt if the cheap option doesn't scale cleanly - the cost of migrating away from it later if it hits a ceiling A self-hosted open-source database might look free next to a managed offering, but if it requires a dedicated on-call rotation and a specialist the team doesn't have, the managed offering can easily be cheaper over a three-to-five-year horizon -- a comparison that's invisible if the rationale only states the sticker prices. ## The revisit trigger Beyond documenting the 'why not,' a durable rationale should state a **revisit trigger**: the specific condition under which the decision should be actively reconsidered, rather than left to drift indefinitely or be silently overridden by whoever is impatient enough to push back hardest. Without this, decisions tend to fail in one of two directions: - they either get treated as permanently settled long after the conditions that justified them have changed - or they get relitigated repeatedly by whoever disagreed with the original call, since there's no documented threshold distinguishing 'this is worth reopening' from 'this was already decided and nothing material has changed' ## The most common failure in real organizations The most common failure mode in real organizations is that the rationale exists only informally -- in a meeting, a slide deck that later gets deleted or lost, or a chat thread that scrolls out of searchable history -- rather than in a durable, version-controlled location alongside the code or in a team's architecture repository. This failure compounds badly when it coincides with staff turnover: if the original author has since left the company and the only record was a slide deck, nobody can reconstruct the reasoning at all, and the organization is left either blindly trusting a decision it can't evaluate or re-doing the entire analysis from scratch under time pressure, often while the original constraints have already changed. ## A worked scenario A concrete scenario: a team chooses a managed cloud database over a cheaper self-hosted alternative and writes an ADR stating the self-hosted option was rejected specifically because it would require an estimated 15 hours/month of additional on-call operational work at the team's current staffing level, equivalent to roughly $40,000/year in effort, which alone exceeded the price difference between the two options -- plus a stated assumption that the team's headcount would not grow enough in the next 18 months to absorb that load, with a note that the decision should be revisited if headcount doubles. Eighteen months later, when a new director asks why the 'cheaper' option wasn't chosen, the answer is a two-minute pointer to a specific, quantified, still-valid piece of reasoning rather than a scramble to recall or re-derive it.