The short version
- Most decision log templates capture what and why. The three that matter more: who can change it, when it should be revisited, and what has to be true first.
- Logs stop in March because the writing has no payoff for the writer and the log has a second-destination problem.
- A log with six months of entries and a four-month gap is worse than no log, because nobody knows which period it covers.
- Keep the log short enough that the last twenty entries fit on a screen. That is the version people read.
A decision log is worth having and most implementations fail within two quarters. The template is rarely the reason, though it contributes: standard templates ask for the easy half of the information and omit the half that prevents arguments.
"We have a log. It stopped in March."
The template
| Field | Example |
|---|---|
| Decision | Order events go through the shared queue, starting with checkout |
| Decided by, date | Priya, 27 August 2026 |
| Rejected, why | Queue per service. More operational surface than the volume justifies |
| Changeable by | Priya, or the platform lead |
| Revisit when | Volume passes 5k events a minute, or at the Q1 review |
| Assumes | That ordering guarantees stay per-partition |
Six fields, and it should take under two minutes. If it takes longer, the decision is either bigger than a log entry or the writer is drafting a justification rather than a record.
The three fields most templates miss
Changeable by. The most valuable field in the template, and the one almost always absent. Without it, a reader cannot tell whether they are allowed to reopen the question, so they either relitigate something settled or defer to something that should have been revisited. Naming an owner answers both at once. This is also why decisions keep coming back on teams with good records, as covered in why decisions keep getting revisited.
Revisit when. Most decisions are correct for a set of conditions rather than forever. Writing the trigger converts "we should probably look at this again some time" into a specific condition anyone can evaluate. It also gives the decision a graceful way to expire, which stops a team carrying constraints whose justification disappeared a year ago.
Assumes. One line naming what has to be true for the decision to hold. This is the field that saves the most time later, because when something goes wrong the first useful question is which assumption broke. A decision with a stated assumption can be re-examined in minutes; one without it requires reconstructing the whole discussion.
Why logs stop in March
Two reasons, and both are structural rather than motivational.
The second-destination problem. The decision happened in a thread or a meeting. Writing it into the log is a second act of writing, after the point at which the writer's need has been satisfied. Second writes are where practices die.
And no payoff for the writer. The entry helps a future reader who may never exist. Nobody thanks you for entry 34. So the log gets updated when someone remembers, which means it has gaps, which means nobody trusts the date range, which means nobody reads it, which removes the last reason to update it.
This is why the most durable version of a decision record is not a separate log at all. With StandIn, the decision you write into your brief at the end of the day is what your StandIn answers from while you are off, in your words, with a source under every answer. The writing happens once, at the point of deciding, in the place you were already writing, and it pays the writer back the first time someone would have asked them about it. See how StandIn works.
Keeping it alive
If you do keep a separate log, three rules extend its life considerably.
Only log decisions that are hard to reverse or that outsiders will ask about. Logging everything guarantees abandonment. Keep it short enough that the most recent twenty entries fit on one screen, because that is the version people scan. And review the "revisit when" triggers once a quarter, which is the only maintenance activity that produces visible value and therefore the only one that survives.
Common Questions
What should a decision log contain?
The decision, who decided and when, what was rejected and why, who can change it, when to revisit it, and what it assumes. The last three are the ones most templates omit and the ones that prevent the most future argument.
Where should a decision log live?
As close to where decisions are made as possible. A log in a separate system requires a second write, and second writes are the main cause of abandoned logs. If the team decides in threads, the record belongs in the thread.
Which decisions are worth logging?
Ones that are expensive to reverse, ones that constrain other work, and ones people outside the team will ask about. Everyday reversible choices do not need an entry, and trying to log them is what makes logs collapse.
How do we revive a log that stopped?
Do not backfill. Start from today, keep the template to six fields, and log only significant decisions. A log that is honest about starting in September is trustworthy; one with an invented January is not.
When you're off, your StandIn is on.
It answers your teammates' questions from work you've already done, in your words, with a source under every answer.