A decision without a record is a decision you will make again
· 7 min read · by Tan Gravam
The short answer
Record four things for any decision that shapes delivery: what was decided, the options that were rejected and why, who decided, and the condition that would make you revisit it. Recording only the outcome is what causes the same question to be re-argued from zero months later, because the reasoning lived in the heads of whoever was in the room. The revisit condition is the field most often skipped and the one that turns a decision into something you can check rather than defend.
Somebody proposes moving the reporting workload off the legacy warehouse. A senior engineer says "we looked at that last year, it doesn't work because of the audit retention rules". Half the room nods. The other half has joined since.
Nobody can find where that was written down, so the question gets re-argued from zero. Two weeks later the team reaches the same conclusion, for the same reason, at full price.
What gets recorded, and what actually mattered
Decisions do get written down. What gets written is the outcome: "we will stay on the current warehouse". That is the least reusable part.
The outcome is what everyone remembers anyway. What evaporates — and what you needed — is why the alternatives lost, and under what conditions the answer would change. Without those, a recorded decision is indistinguishable from an arbitrary one, and a new person is right to reopen it.
Four fields
What was decided. One sentence, in the terms someone outside the room would use.
What was rejected, and why. The genuinely useful part. Not a survey of everything imaginable — the two or three options actually considered, each with the specific reason it lost. "Rejected: move to the new warehouse — audit retention requires seven years and the new one is configured for two." That sentence is what stops the re-argument, and it is one line.
Who decided. A person. Not for blame — so that the next person with the question knows who to ask, and so that the decision has an address when the conditions change.
What would make you revisit it. The field almost everyone skips, and the one that turns a decision into something checkable rather than defendable. "Revisit if retention drops below three years, or if warehouse cost exceeds X." Now it is not dogma, it is a claim with a trigger — and someone can notice when the trigger fires.
Why the revisit condition changes the culture
Without it, every recorded decision is implicitly permanent, so people defend them. Reopening a decision means arguing that someone was wrong, which is socially expensive, so bad decisions persist and good ones get reopened anyway by people who did not know they existed.
With it, reopening is the process working. "The condition we wrote down has happened" is a neutral sentence anybody can say. That is a meaningful reduction in the cost of changing your mind, which is the thing organisations are usually worst at.
Which decisions deserve this
Not all of them. A record that covers everything gets read for nothing.
The bar worth using: would re-deciding this cost more than an hour? That catches the architectural calls, the scoping choices that changed what a demand is, the build-versus-buy answers, and the "we are deliberately not doing X" decisions — which are the most commonly forgotten and the most expensive to rediscover.
It excludes almost everything else, which is the point. Four fields on twenty decisions a year is a habit. Four fields on everything is a bureaucracy that will be abandoned by March.
Where the record has to live
One rule, learned the hard way by every organisation that has tried this: the record has to sit with the work, not in a separate decision log.
A standalone log is written into and never read out of, because finding the relevant entry requires knowing it exists. Attached to the demand it shaped, it is found by the person who needs it at the moment they need it — they were already looking at that demand, which is why the question came up.
This is the same reason an assumptions list belongs on the demand rather than in a risk register: proximity is what determines whether a record is read.
How DeliverySheet handles it
Decisions are recorded against the demand they shape, with an owner and a status, and unresolved ones have a consequence rather than being decoration: an open key decision reads as "needs discovery" in the commitment verdict, so a demand cannot quietly become ready while a decision it depends on is still open.
They also carry through to the end. The delivery outcome asks what differed from the promise when the result is not clean, and the retrospective requires a written lesson — a verdict alone does not close a demand. That is deliberate: the decisions and the outcome sitting on the same object is what makes the record worth having a year later, rather than a folder of documents nobody opens.
The wider case for keeping planning artifacts honest — three-state readiness, facts versus assumptions, dependencies you don't own — is in the topic overview .
I'm Tan Gravam. I build DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.
$10/month per workspace during the launch period (normally $189), unlimited members, 7-day free trial. I answer the support email myself.
More on planning that stays honest
Read the overview: Planning that stays honest →
- "No known risks" has to be a valid answer
Planning templates that only accept filled-in fields get filled in. The result is a risk register full of fiction, which is worse than an empty one.
- Scope is mostly what you're not doing
An in-scope list describes an intention. The out-of-scope list is what actually holds when someone asks for one more thing in week six.
- The dependency you don't own
Most delivery risk sits in work another team has to do for you — and the usual tracking treats it exactly like work you control.