Decision Rationale Template¶
Template — instantiates Opportunity Cost Surfacing
Records the chosen option, displaced alternative, resource commitment, assumptions, and review trigger in a durable format.
A Decision Rationale Template is the durable artifact that captures an opportunity-cost decision after it is made, in a fixed structure future readers can trust. Its defining move is preservation, not analysis: it does not generate options, select the best forgone alternative, or price anything — it takes what the surfacing work produced and writes it down in named fields (chosen option, the alternative it displaced, the resource committed, the assumptions that justified the trade, who owns it, and when to revisit). The point is institutional memory. Six months on, a reviewer can read the record and distinguish a sacrifice that was accepted knowingly from one that was impulsive or politically concealed — and can check whether the assumptions that made the trade legitimate still hold. It is the mechanism that turns a good decision into an accountable one.
Example¶
A platform team must choose the datastore for a new event-processing service. After enumerating and weighing options, they pick a managed cloud queue over self-hosting an open-source broker. In the old world the decision would live in someone's memory and a Slack thread. Instead they fill a Decision Rationale Template — in this shop, an Architecture Decision Record checked into the repo. Its fields are fixed: Chosen option — managed queue. Displaced alternative — self-hosted broker, which the team genuinely wanted for its lower per-message cost at scale. Resource committed — a recurring cloud bill and vendor lock-in. Assumptions that justified it — throughput stays under the tier where self-hosting wins, and the team lacks ops capacity to run a broker this year. Owner — the service's tech lead. Review trigger — revisit if sustained throughput crosses the crossover volume, or at the next annual architecture review. A year later, traffic has tripled and crossed that line. Because the trigger and its owner were written down, the revisit actually happens instead of the original choice ossifying by inertia — and the record shows the displacement was accepted on assumptions that have now expired.
How it works¶
- Fix the fields, not the content. The template's power is a required structure — chosen, displaced, committed, assumed, owned, revisited — so no decision can be recorded while silently omitting what it gave up.
- Force the displaced alternative into the record. A rationale that lists only why the winner won is incomplete; the field for the forgone option makes the sacrifice part of the permanent account.
- Name an owner and a trigger. Every record assigns who is accountable for the trade and reopening it, plus the condition or date that reopens it — so the artifact has a future, not just a past.
- Store it where reviewers will find it. The record lives in a durable, discoverable place (a repo, a decision log), because a rationale nobody can retrieve is not memory.
Tuning parameters¶
- Field rigidity — how strictly the structure is enforced. Rigid templates guarantee the displaced-alternative and assumptions fields are filled but can feel bureaucratic on small calls; loose ones invite omission of exactly the awkward parts.
- Assumption granularity — how finely the justifying assumptions are logged. Detailed assumptions make later review sharp but take effort and can bury the load-bearing one among trivia.
- Trigger specificity — whether the review trigger is a hard condition ("throughput > X"), a date, or a vague "revisit someday." Specific triggers actually fire; vague ones never do.
- Ownership resolution — a single named owner versus a role or committee. A named person is chaseable; a committee diffuses accountability and lets the revisit fall through.
When it helps, and when it misleads¶
Its strength is accountability over time: it converts a decision into an auditable object, which is precisely what an Architecture Decision Record was invented to do — capture the context, the choice, and the consequences so a later engineer understands why, not just what.[1] Its failure mode is documentation without action — the archetype's named failure — where the opportunity cost is dutifully recorded but the record connects to no gate, trigger, or owner, so it changes nothing and becomes a compliance relic. A related misuse is a template filled in after commitment to retroactively justify a choice rather than to inform it, and templates whose triggers are so vague they never fire. The guarding discipline is to require a specific trigger and a named owner, and to wire the record into a review that actually reopens the decision when the trigger conditions arrive — so the artifact stays a live commitment, not a tombstone.
How it implements the components¶
decision_rationale_record— it is the record: a fixed-field capture of the chosen option, the displaced alternative, the committed resource, and the justifying assumptions, preserved for later audit.review_trigger— a required field states the condition or date that reopens the trade, so the record carries its own future review rather than freezing the first call.decision_owner— a required field names who is accountable for the sacrifice and for acting when the trigger fires, so the record is chaseable rather than orphaned.
It is an artifact, not an analysis: it does not generate or select the alternatives it records (viable_alternative_set, best_forgone_alternative) — those come from Alternative Enumeration Checklist and Attention Budget Audit; it preserves what they produced.
Related¶
- Instantiates: Opportunity Cost Surfacing — the template turns a surfaced opportunity cost into durable, reviewable institutional memory.
- Consumes: Alternative Enumeration Checklist supplies the chosen and displaced options the template records.
- Sibling mechanisms: Alternative Enumeration Checklist · Attention Budget Audit · Calendar Allocation Review · Capital Budgeting Comparison · Policy Alternative Analysis · Portfolio Tradeoff Review · Opportunity-Cost Prompt · Project Kill Criteria
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Decision Rationale Template operates as a non-executable information artifact that externalizes static or prospective structure because it records the chosen option, displaced alternative, resource commitment, assumptions, and review trigger in a durable format.
Independent corroboration: The frozen evidence defines Decision Rationale Template as 'Records the chosen option, displaced alternative, resource commitment, assumptions, and review trigger in a durable format', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Software architecture cohered lightweight decision-record templates preserving context, chosen option, consequences, and review conditions for future maintainers.
Related originating lineages:
- Organizational & Management Science — Governance and project management supplied fields for displaced alternatives, committed resources, ownership, and opportunity-cost accountability.
Review resolution: Software architecture cohered lightweight decision-record templates preserving context, chosen option, consequences, and review conditions for future maintainers.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Nygard, M. "Documenting Architecture Decisions". Cognitect (2011). Nygard's ADR format records context, decision, status, and consequences so future developers can recover the motivation behind an architectural choice. registry ↩