Every team has a decision that gets made twice. Someone asks why the invoices go out monthly, or why those two services were split — and the answer is a shrug and the name of somebody who left. The question gets worked through again from the start, at full cost, and lands somewhere that may or may not be where it landed the first time.
A decision record is the artifact that stops that. It is one of the cheapest documents anyone writes and one of the most consistently skipped.
The definition
A decision record is a short, durable document capturing a single decision: the context that forced it, the options considered, the option chosen, and the consequences accepted. One decision per record. Usually a page or less.
The best-known form is the architecture decision record, or ADR — a numbered file kept in a software project's own repository, versioned alongside the code it explains, in a template of about five parts: a title, a status, the context, the decision, and the consequences that follow.
Nothing about that shape is specific to software. The same document works for a pricing change or a vendor choice. The test is not subject matter — it is whether the document explains a choice to a reader who arrives later holding none of the reasons.
The rejected options are the load-bearing part
Most first drafts are strong on what was decided and thin on what was not. That is backwards.
The chosen option is largely recoverable from reality — look at the system, the contract, or the org chart and read off what was picked. What is not recoverable is the set of alternatives that were live at the time and why each lost. Relitigation is driven not by the answer but by an alternative that looks obviously better to someone who does not know it was considered.
"We chose the managed service" invites "but have you looked at running it ourselves?" — a reasonable question, asked in good faith, costing a week. "We chose the managed service; running it ourselves was rejected because nobody on the team has operated one" answers it before it is asked.
It also tells you when a decision is worth reopening. If the reason an option lost has since expired — the team gained that skill, the price fell — the record hands you the exact sentence that no longer holds. Reopening is cheap and specific; relitigating is the whole argument again with no memory of the first round.
So give every option a status and a reason. Chosen, leaning, open, rejected — one line of why for each. "Open" is a real answer, and recording it stops a future reader from assuming a question was settled when it was only deferred.
Written at decision time, not afterwards
A record written weeks later is a different document wearing the same name. By then you know how it turned out, and hindsight rewrites everything.
Two things go first. Confidence — at the moment of the call you knew whether this was a firm read or a coin flip, and once the outcome is in, every past decision looks obvious. Reversibility — whether you believed the decision could be undone cheaply is a fact about the decision; whether it turned out to be undoable is a fact about the world, and the second overwrites the first if you wait.
Both cost one word at the time and are unrecoverable later. So are the alternatives that felt competitive, which a retrospective account flattens into options nobody could have chosen — precisely the record that fails to prevent the re-argument.
Supersede, never edit
A decision record states what was decided then, not what is true now. Those diverge, and the temptation is to fix the document.
Do not. When the decision changes, write a new record and mark the old one superseded, pointing to its replacement. The old one stays exactly as written — wrong, and readable. Editing in place swaps the historical position for the current one, and the question a decision log exists to answer, which is what changed and when, becomes unanswerable.
That makes a decision log append-only, the same property that makes any written correspondence trail worth keeping. Immutability here is not tidiness; it is the only thing separating a record from a description of the present.
Asking for a decision and recording one are nearly the same document
A request for a decision and a record of one carry the same fields.
A briefing that asks someone to decide has to supply the context, the options with their status and reasoning, the assumptions it rests on, and what is still open — otherwise the recipient cannot answer without a round trip. A record of that same decision needs the context, the options and reasoning, the decision, and the consequences. Everything but one field is shared, which is why writing the request well leaves you most of the record for free.
RelayLink's briefing format is built on that overlap. A package carries a context brief, options considered — each with a status of chosen, leaning, open or rejected plus a why — assumptions marked as stated or inferred, open questions, and decisions, each carrying a confidence of low, medium or high and a flag for whether it is reversible. Set the response shape to decision and the package is a request; the answer comes back on the same thread. Package content is written once and never modified afterwards — no edit, no unsend — so the thread is append-only by construction rather than by agreement.
Two honest limits. RelayLink is not a decision log: there is no search across threads or packages, no folders, no labels, and thread listings show the most recent twenty-five. And threads are two-party, so you get the record of one exchange rather than a group's deliberation — for that, see how open-source projects keep the deliberation and the archive in the same public place.
The next time you ask someone to decide something — a design review, a handover, a budget call — write the rejected options before you write the ask. It is the section that makes the request answerable and the record durable, and the one nearly everyone leaves out. If you would rather have that draft assembled from the session where you already worked the problem through, connect your assistant.