Skip to content

Decision Record

Document — instantiates Normative Assumption Explicitness

Stores the chosen value assumptions, decision rationale, rejected alternatives, and review triggers so the decision remains accountable over time.

A Decision Record is the durable, append-only memory of one specific decision. Its defining purpose is reconstructability: long after the meeting is forgotten and the people have moved on, someone should be able to open the record and recover which value assumption was chosen, which alternatives were rejected, whose objection went unresolved, and what event should reopen the question. It is an archive, not an argument. It does not persuade an outside audience that the choice was right — it preserves, faithfully and unflatteringly, that the choice was made and on what terms. That distinction is everything: a record that quietly improves the past to look wiser has failed at its one job.

Example

A software product team decides to ship a new activity-summary feature with data-sharing defaulted on (opt-out) rather than off. Rather than let that choice evaporate into a Slack thread, an engineer files a Decision Record in the repository, in the style of an architecture decision record.[n1] It states the chosen value assumption in plain words: for this low-sensitivity signal, adoption and convenience are being prioritized over default privacy. It lists the rejected alternatives with a line each on why they lost: opt-in (killed the feature's usefulness at low adoption), granular per-field consent (too much friction for launch). It captures the dissent verbatim — a privacy engineer's on-the-record objection that "low-sensitivity" was asserted, not tested. And it sets a review trigger: revisit if the data is ever reclassified, or if a regulator or auditor asks.

Two years later a new product manager, facing a complaint, opens the record and finds the whole shape of the original bet — including the objection that turned out to be prescient — instead of guessing what the team must have been thinking.

How it works

  • One entry per decision. Scope each record to a single choice so it stays findable and citable.
  • Capture the four fields. Chosen value assumption, rejected alternatives, unresolved dissent, and the review trigger — with date and owner.
  • Preserve dissent verbatim. Record objections in the objector's words, not the majority's paraphrase.
  • Store where future readers will look. Co-locate the record with the artifact it governs (repo, decision log) so it is found by accident, not archaeology.
  • Append, don't rewrite. Later reversals become new linked entries; the original is never edited to look correct.

Tuning parameters

  • Granularity — per-decision versus per-project records. Finer grain preserves more but multiplies entries.
  • Dissent fidelity — how completely minority objections are captured. Higher fidelity is more honest but more uncomfortable to write.
  • Immutability — strict append-only versus editable. Stricter protects the audit trail; looser is easier to maintain.
  • Storage locality — how close the record sits to the thing it governs, which sets how likely it is to be read at all.

When it helps, and when it misleads

Its strength is that when a decision later fails, reviewers can examine the actual value premise rather than reverse-engineering intent from outcomes — the record turns "what were they thinking?" into a citation. It is the antidote to organizational amnesia around value choices.

Its failure mode is the write-only graveyard: records dutifully filed and never opened, or worse, sanitized into a version that omits the real disagreement so the past looks unanimous. The classic misuse is writing the record after trouble arrives, back-dating a tidy account that launders the decision. The guarding discipline is to write it at the moment of choice, capture dissent in the dissenter's own words, and bind the review trigger to a real monitoring signal so the record can actually summon a re-examination instead of gathering dust.

How it implements the components

  • assumption_record — the document is this component: the durable, reconstructable store of what was assumed, chosen, and contested.
  • competing_norm — preserves the rejected alternatives, each with the terse reason it lost, so the choice stays visibly a choice.
  • review_trigger — fixes the event that should reopen the assumption, and keeps it attached to the record where a future reader will find it.

It remembers a decision but does not build the reasoned public case for it: the argued decision_rationale and cited value_source that make a rule defensible are Policy Rationale Statement's — its hazard twin — and the forensic legitimacy_check that tests whether a neutrality claim holds is Value Audit's. The record remembers; the statement argues.

Editorial Notes

Form Classification

Form family: Record, Log & Register

Rationale: Decision Record operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it stores the chosen value assumptions, decision rationale, rejected alternatives, and review triggers so the decision remains accountable over time.

Independent corroboration: The frozen evidence defines Decision Record as 'Stores the chosen value assumptions, decision rationale, rejected alternatives, and review triggers so the decision remains accountable over time', so its operative form is Record, Log & Register.

Review outcome: Independent reviewer agreement; high confidence.

Origin Attribution

Primary origin: Computer Science & Software Engineering

Origin pattern: Cross-disciplinary synthesis

Present-day reach: Multi-domain

Rationale: Software architecture cohered append-only, versioned decision records that preserve context, choice, rejected alternatives, and consequences alongside implementation.

Related originating lineages:

  • Organizational & Management Science — Governance practice supplied value assumptions, ownership, and institutional-memory use.
  • Philosophy — Normative reasoning supplied explicit value assumptions, competing norms, and the distinction between preserving a choice and proving it right.

Review resolution: Software architecture cohered append-only, versioned decision records that preserve context, choice, rejected alternatives, and consequences alongside implementation.

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.

Notes

[n1] Architecture Decision Record (ADR) — a lightweight, versioned document (popularized by Michael Nygard) capturing one architectural choice, its context, and its consequences, stored alongside the code. A Decision Record borrows the form and points it at value assumptions rather than technical ones.