How to Document Decisions: The Definitive Practical Guide
How to document decisions: capture seven fields for every significant decision — the question, the options considered, the arguments for and against, the decision itself, the rationale, the owner, and the review date. The role frameworks (RAPID, DACI, RACI) assign who decides; a decision record preserves what was decided and why. Engineering solved this in 2011 with Michael Nygard's Architecture Decision Records; the same lightweight practice works for any team: write the record when the decision is made, keep it in one searchable place, and give it a review date so outcomes can be compared against the reasoning.
Most teams document tasks meticulously and decisions not at all — which is why settled questions get re-argued every quarter. The fix is a lightweight decision record, and this is the complete practice:
- Roles ≠ records. RAPID, DACI and RACI tell you who decides; none of them preserves what was decided and why. You need both halves.
- Seven fields — question, options, arguments, decision, rationale, owner, review date — cover everything a future reader needs (this template is ours; steal it).
- Write it when the decision happens, in one searchable home, one record per decision — not buried in minutes, chat threads or slide decks.
- The record is what turns decisions from one-time events into an asset your organization can learn from.
Eleven months ago your team spent three meetings choosing between building the integration in-house and buying it. People came prepared. Somebody made a spreadsheet. The discussion was genuinely good — concerns were raised, trade-offs weighed, a call was made. Then everyone went back to work.
This week a new engineering lead joined, looked at the integration, and asked the reasonable question: "Why didn't we just build this ourselves?" And the honest answer available to anyone in the room was: nobody remembers exactly. So the question is open again. The three meetings are about to happen again — with less information than the first time, because the person who made the spreadsheet left in March.
Nothing about that story is unusual, and that is the problem. Teams that would never lose a task lose decisions constantly, because tasks have a system and decisions have a vibe. This post is the complete, practical fix: what to write down, the seven fields that matter, the frameworks worth borrowing from, and the habits that make the practice stick.
Your task tracker knows every to-do from 2023.
Nobody can say why you chose the architecture you're living with.
The documentation gap in almost every organization
What a Decision Record Is — and What This Post Covers
A decision record is a short, structured document capturing one significant decision: what was decided, what the alternatives were, why this option won, who owned the call, and when you'll check whether it worked. It is written when the decision is made, not reconstructed later, and it lives somewhere the whole team can search.
It is not meeting minutes — a chronological account of a conversation — and it is not a task. Those distinctions matter enough that each has its own post: meeting minutes vs. the decision log covers the document level, and action items vs. decisions covers the task level. This post is the how-to that both of them point back to.
One scope note: significant decisions. Where to hold the offsite does not need a record. Anything you'd hate to re-argue in six months — architecture, vendors, pricing, policy, hiring bars — does. A useful test: if a future colleague could plausibly ask "why is it like this?", the decision qualifies.
What Undocumented Decisions Actually Cost
The costs are mundane, recurring, and mostly invisible because they arrive disguised as normal work. Settled questions get re-litigated — the same debate, staged again, minus whoever held the context. New hires inherit systems whose shape nobody can explain, so they either relearn by breaking things or route every question to the longest-tenured person in the room. And when an outcome goes wrong, there is no way to tell whether the reasoning was bad or the luck was — which means the process never improves.
There is also a sharper edge: accountability. When a decision exists only in memory, its history gets rewritten by whoever retells it — usually in their own favor. A record makes the reasoning inspectable when it matters, which is the foundation of a real decision audit trail. We wrote a short companion piece on the compounding cost itself: the cost of undocumented decisions.
The Frameworks That Already Exist — and the Gap They Leave
You don't have to invent this practice; several serious frameworks touch it. But it pays to notice what each one actually covers, because the most popular ones solve a different problem than the one this post is about.
ADR — Architecture Decision Records (Nygard, 2011)
The engineering world's answer, from Michael Nygard's 2011 essay: one small file per architecturally significant decision — context, decision, consequences — kept in the project repository. ADRs proved that decision documentation works precisely when it is lightweight; the practice spread industry-wide and has a whole ecosystem of templates. It is the closest existing thing to what every team needs. Our practical ADR guide covers the format, the ecosystem of templates, and the reason most ADR practices quietly die — the debate and the record end up living in different places.
DACI — Driver, Approver, Contributors, Informed (Atlassian)
Atlassian's play for decision roles: who drives the decision, who approves it, who contributes, who gets informed. Excellent for unclogging "who actually decides this?" — but a DACI assignment is not a record. Once the decision is made, DACI has nothing to say about preserving the reasoning. If you are choosing between the role frameworks rather than reading about them one at a time, we put RAPID, DACI and RACI side by side with worked examples.
RAPID® — Recommend, Agree, Perform, Input, Decide (Bain)
Bain & Company's registered framework, introduced by Paul Rogers and Marcia Blenko in their 2006 Harvard Business Review article "Who Has the D?". Like DACI, it assigns decision roles — its "D" is the single accountable decider — and it demonstrably speeds up stuck organizations. Also like DACI: it governs the moment of choice, not the memory of it. The three-way comparison sets out where RAPID earns its extra complexity over DACI, and where it does not.
RACI — Responsible, Accountable, Consulted, Informed
The oldest and most general of the role charts, from decades of responsibility-charting practice. Useful for execution clarity across any process; the least decision-specific of the four, and again — a role matrix, not a record. If the four letter-charts are blurring together, our decision-rights guide exists to end the shopping: pick one in five minutes and spend the effort actually running it.
Notice the pattern: three of the four famous frameworks assign roles; only ADR produces a record. Roles and records are complementary halves — RAPID or DACI tells you who has the D; the record preserves what the D decided and why. Most teams that feel "we have a decision process" have adopted a role framework and skipped the record entirely. That is the gap the seven fields below fill. One framework does straddle the line, and it is worth naming because it is the closest thing to a record that a role framework produces: SPADE (Gokul Rajaram, used at Google, Facebook and Square) adds Alternatives and Explain to the roles the others assign — two of the seven fields below, captured in the moment of deciding rather than afterwards. It still organises by decision-meeting rather than by decision, so it is not yet a log; but a team already running SPADE is two fields from one. The short version is the SPADE framework in five letters, and all four role frameworks sit side by side in the decision-rights guide.
What to Capture: The Seven Fields
This is Argumentree's own template — not an external standard, but a synthesis we use and recommend: ADR's record discipline, extended with the two things general team decisions need that architecture decisions get for free (an explicit owner, and a review date). Steal it as-is.
1. The question
What was actually being decided — phrased as the real question, not the topic. "Which vendor for payments?" beats "Payments." A badly framed question is how teams answer the wrong thing precisely. The same discipline applies to goals rather than choices: a Key Result is the question answered in advance, which is why an OKR is better read as a record than a target.
2. The options considered
Every alternative that was seriously on the table, including "do nothing." This is the field that kills the most re-litigation: most re-opened decisions start with "did we ever consider…?" — and the answer is usually yes.
3. The arguments for and against
The pros and cons that were actually weighed, attached to the options they belong to. This is the field almost every template skips and the one with the most value per line — the reasoning is what a future reader needs to judge whether the decision still holds.
4. The decision
The option chosen, stated plainly. One sentence. If this field takes a paragraph, the question field was wrong.
5. The rationale
Why this option won — which arguments were decisive, and which trade-offs were consciously accepted. "We chose X knowing it costs Y" is the sentence that prevents the next person from treating Y as an oversight.
6. The owner
The person accountable for the decision — RAPID's "D", written down. Not the committee: a name. Decisions with no recorded owner become decisions nobody can revisit, amend, or defend.
7. The review date
When you'll check the outcome against the reasoning. This field turns a filing habit into a learning loop — it is the difference between an archive and an asset, and it is the mechanism behind decision intelligence's feedback principle.
A Record You Can Copy
In practice the seven fields fit on half a page. A worked example, compressed:
Question: Build the billing integration in-house or buy Vendor A? · Options: build; Vendor A; Vendor B; defer six months. · Arguments: build = full control but ~2 quarters of roadmap; A = live in 3 weeks, lock-in risk; B = cheaper, weaker EU coverage; defer = blocks two enterprise deals. · Decision: Vendor A, 12-month contract. · Rationale: the two blocked deals outweigh lock-in risk at this contract length; build reconsidered at renewal. · Owner: J. Meyer. · Review: 2027-03 renewal.
That is the whole artifact. Anyone joining the team next year reads it in forty seconds and knows what was decided, what it beat, what it cost, and when it comes back up. Compare that with three meetings' worth of minutes.
A decision without a recorded rationale
is a decision your team will make again.
The Practices That Make It Stick
Templates don't fail; habits do. Four practices separate teams whose decision logs live from teams whose logs die after week two:
Write it in the room
The record is written when the decision is made — last five minutes of the meeting, screen shared — not "cleaned up later." Reconstruction is where rationale dies and where the loudest memory becomes the official one.
One home, searchable
All records in one place the whole team can search — a repo folder, a wiki space, a dedicated tool. A record nobody can find has the same value as no record. Scattered across meeting notes is how it fails today.
One record per decision
Not per meeting. Meetings produce discussion; the record captures the decision, whichever meeting (or thread) it finally landed in. This is the core of the minutes-vs-log distinction.
Actually hold the review
When the review date arrives, spend ten minutes comparing the outcome against the recorded reasoning. Was the rationale sound and the outcome unlucky, or was the reasoning flawed? That distinction — impossible without the record — is how decision quality compounds.
The Common Mistakes
Four failure modes account for most abandoned decision logs:
Recording everything
A log with lunch-order decisions in it trains everyone to ignore it. Significance threshold: would re-arguing this in six months hurt?
Recording only the verdict
"We chose Vendor A" without options and rationale answers nothing a future reader will ask. The reasoning is the payload; the verdict alone is trivia.
Treating it as bureaucracy owned by one person
If one diligent person maintains the log, it dies with their vacation. The writing rotates with decision ownership — whoever has the D writes the record.
No review dates
A write-only log becomes a graveyard with good intentions. The review date is what makes the practice pay for itself visibly, which is what keeps it alive.
"We're Agile — Isn't This Just Documentation Overhead?"
The strongest version of the objection deserves stating properly: documentation has a real cost, most documents are never read, and a team that spends its energy writing about work instead of doing it has made itself slower for nothing. Agile's insight — working software over comprehensive documentation — was a correction to a real disease.
The answer is that the objection targets the wrong artifact. Nygard wrote ADRs for agile teams, on exactly this reasoning: the record is half a page, written once, at the moment the knowledge is free — and its reader is not an auditor but future you, eleven months from now, staring at the integration and wondering why. The cost asymmetry is extreme: five minutes at decision time versus three meetings of re-litigation later. This is the rare documentation that pays for itself in avoided meetings.
The honest caveat: the practice does fail when it is imposed as process theater — mandated fields nobody believes in, records written to satisfy a checkbox. It works when the team has felt the pain it prevents. If your team hasn't lost a decision yet, start with the one log entry for your next significant call and let the first "wait, we wrote this down!" moment sell the habit.
The Diagnostic
Pick any significant decision your team made last quarter. Can a person who wasn't in the room reconstruct — from what's written down anywhere — what the alternatives were and why they lost? If not, you don't have a documentation practice; you have folklore.
How Argumentree Documents Decisions Automatically
Everything above works with a wiki page. The reason we built Argumentree is that the hardest field to capture manually is field 3 — the arguments — because they happen live, in discussion, and writing them down afterward means summarizing from memory. In Argumentree the deliberation itself is structured: the question is explicit, options and their pro/con arguments form a tree, and ratings show which arguments actually carried the decision.
Which means the decision record isn't a document someone writes after the meeting — it is the meeting's own structure, preserved. All seven fields fall out automatically: question, options, arguments, decision, rationale (the winning argument path), owner, and a review date. No transcription step, no memory drift, and the full reasoning stays inspectable for every future reader. See it end-to-end in meeting intelligence. If you want to try the format on a real decision this week, you can start free and document the next one as you make it.
Decisions Are an Asset — If You Keep Them
The difference between an organization that gets smarter and one that stays busy is not intelligence — it is memory. Tasks get done and evaporate; decisions, kept with their reasoning, compound: precedents form, patterns surface, and reviews teach the process to improve itself.
Start smaller than feels serious. Next significant decision: five minutes, seven fields, one searchable home, one review date. When the new engineering lead asks "why didn't we build this ourselves?" — and someone answers with a forty-second read instead of three meetings — the practice will have paid for itself, permanently.
Five minutes at decision time. Three meetings saved eleven months later.
Make the Record the Meeting's Byproduct
Run your next significant decision in Argumentree: structured arguments, automatic decision records, review dates built in.
Sources & Further Reading
- Nygard, M. (2011). Documenting Architecture Decisions. Cognitect.The essay that started the ADR practice — context, decision, consequences, one lightweight file per decision.
- Architectural Decision Records — adr.github.ioThe community home of ADR templates and tooling; evidence of how far the record practice has spread.
- Rogers, P. & Blenko, M. (2006). Who Has the D? How Clear Decision Roles Enhance Organizational Performance. Harvard Business Review, January 2006.The article introducing Bain's RAPID® framework — the canonical treatment of decision roles.
- Atlassian Team Playbook — the DACI play.Atlassian's role framework for decisions: Driver, Approver, Contributors, Informed.
- Bain & Company — Who has the D? (RAPID® overview)Bain's own summary of the framework; RAPID is Bain's registered trademark.
Frequently Asked Questions
What is a decision record?
A short structured document capturing one significant decision: the question, the options considered, the arguments for and against, the decision, its rationale, the owner, and a review date. It is written when the decision is made and kept in one searchable place.
What is the difference between RAPID, DACI, RACI and a decision record?
RAPID, DACI and RACI are role frameworks — they define who recommends, approves, contributes and decides. A decision record preserves what was decided and why. Roles govern the moment of choice; the record preserves its memory. Most teams need one role framework plus a record practice.
Which decisions should be documented?
Significant ones: any decision you would hate to re-argue in six months — architecture, vendors, pricing, policy, hiring standards. A practical test: if a future colleague could plausibly ask why things are this way, record it. Routine operational choices don't qualify; logging everything kills the practice.
What are ADRs (Architecture Decision Records)?
A lightweight engineering practice from Michael Nygard's 2011 essay: one small file per architecturally significant decision, capturing context, decision and consequences, stored in the project repository. ADRs are the strongest proof that lightweight decision documentation works, and the model any team can generalize from.
Who should write the decision record?
The decision owner — the person with the D in RAPID terms. Writing rotates with ownership, which keeps the practice alive when any one person is away and keeps accountability attached to the record.
How is a decision record different from meeting minutes?
Minutes are a chronological account of a conversation, organized by meeting. A decision record is organized by decision, whichever meetings or threads produced it, and it captures options and rationale that minutes bury or omit. The full comparison is in our meeting minutes vs decision log post.
Stop Re-Litigating Decisions You Already Made
Structured deliberation in, complete decision records out — with the reasoning attached and review dates built in.
About Argumentree Team
Decision Science
The Argumentree team is building the collaborative decision-making platform Argumentree. Our mission is to transform how organizations make, document, and learn from decisions.
Related Articles
Disagree with the seven fields?
Argue it where arguments are structured — join the discussion on the Argumentree forum.
Join the Discussion
