The decision nobody recorded

Here's a scene that has happened, in some form, at nearly every engineering org that has existed for more than a year. A new hire — sharp, diligent, doing exactly what you'd want a new hire to do — opens the codebase, finds something that looks obviously wrong, and asks in Slack: "hey, why don't we just cache this?" And somewhere in the building, one or two people who were in a standup eleven months ago quietly sigh, because they already had this conversation, they already decided against it, for reasons that made complete sense in the room that day — and the reasons live nowhere except in their memory, which means the conversation is about to happen again, from scratch, at full cost, as if it had never happened at all.

This is not a training problem. It's a recordkeeping problem, dressed up as an onboarding problem, dressed up as a communication problem, all the way down.

Decisions are the most expensive claim type and the least protected

Go back through this series' catalog of what gets said in a standup — commitments, predictions, blockers, risks — and notice that decisions are structurally different from all of them. A commitment resolves against a commit. A prediction resolves against telemetry. A decision, once made, doesn't just describe the future — it closes off a set of alternatives that somebody might otherwise revisit, and it's supposed to stay closed, or at least stay closed until someone deliberately reopens it with a good reason. "We're dropping the Redis cache" is a claim about the future the same way "I'll ship this Thursday" is — but unlike the Thursday claim, its entire value depends on people, months later, who weren't there, being able to find out that it was made, by whom, and why.

And it is, almost universally, the least protected claim type in the entire meeting. A commitment survives because someone eventually opens a PR against it. A blocker survives, however imperfectly, because someone keeps mentioning it until it's resolved. A decision, once spoken, has nothing forcing it to leave any trace at all — no PR, no ticket, sometimes not even a Slack message — unless somebody, on their own initiative, decides to write it down. Most days, nobody does, because writing it down feels like extra work for a decision that, in the room, felt completely obvious.

"Completely obvious" is doing a lot of work in that last sentence, and it's worth pulling apart, because it's the exact reason decisions go unrecorded more than any other claim type. A commitment feels provisional even as you say it — everyone in the room implicitly understands Thursday might slip, so nobody's surprised when it needs to be checked later. A decision, by contrast, is spoken with the finality of a fact already settled: "we're dropping the cache" doesn't sound like a claim awaiting verification, it sounds like something that has already happened. That felt finality is precisely what makes it feel unnecessary to write down — and precisely what makes the eventual re-litigation so expensive, because everyone arguing about it six months later will bring the same false sense that their version is simply the settled fact, with nothing to check it against but a room full of competing certainties.

The discipline that exists, and mostly doesn't get used

The software industry actually solved this problem, in writing, over a decade ago, and the solution never needed to be complicated. In 2011, Michael Nygard published a short, now-influential post called "Documenting Architecture Decisions," proposing what became known as the Architecture Decision Record, or ADR: a short, immutable document per significant decision, capturing the context that led to it, the decision itself, and the consequences — filed and kept, even after the decision is later superseded, precisely so the superseding decision has something concrete to point back at and argue against. Nygard's insight wasn't that decisions needed more ceremony. It was the opposite — that a lightweight record, written once, at the moment of decision, beats an elaborate document nobody keeps updated, because a short record is the only kind that survives.

The research backs up why this matters as much as it does. Antony Tang, Muhammad Ali Babar, Ian Gorton, and Jun Han surveyed the state of architecture design rationale — the reasoning behind a decision, as distinct from the decision itself — and found rationale capture chronically underused across the industry, for reasons that will sound familiar: it's seen as extra overhead in the moment, its payoff is deferred to a future nobody's incentivized to plan for today, and the people best positioned to write it down are also the busiest people in the room. Their survey makes the case that this isn't a minor documentation gap — rationale, once lost, has to be reconstructed, expensively, by inference and interview, every single time it's needed and wasn't written down. Which is precisely the scene at the top of this post, playing out at your company, right now, in some Slack thread you haven't seen yet.

An ADR isn't paperwork. It's the only thing standing between "we decided this for good reasons" and "we vaguely recall deciding this, we think, probably in the spring."

Why the standup version never gets written down, even at teams that use ADRs

Here's the gap that Nygard's own proposal doesn't quite close, and it matters specifically for a series about standups. ADRs work beautifully for the decisions that already feel important enough to warrant a document — the framework migration, the database choice, the API versioning strategy. Nobody skips writing those down, because everybody already agrees, going in, that they're the kind of decision that deserves a document. The decisions that vanish are the ones that don't feel that significant in the room where they're made: "we're dropping the Redis cache," said in passing, in fifteen seconds, in a standup that has six other things to get through. Nobody's going to open a design doc template for that. It doesn't feel decision-shaped. It feels like an update. And that's exactly the category of decision this post is about — not the ones your process already protects, but the ones too small-sounding to trigger the process at all, which is most of them, which is why the new hire's question keeps happening.

What a standup decision actually needs to survive

Not much, which is the whole point. A decision made out loud in standup — "we're dropping the Redis cache" — needs exactly three things to survive being re-litigated by someone who wasn't there: who said it, when, and against what evidence it should be checked later. Not a design doc. Not a meeting. Just the claim, kept the way the earlier parts of this series argued every claim should be kept — verbatim, attributed, dated — plus, specifically for a decision, the thing that makes it different from a commitment or a prediction: it stays open to being resolved two ways, not one. A decision "resolves" either when a later commit actually carries it out (the cache really did get dropped), or when a later, explicit decision reverses it — and either resolution is worth just as much as the other, because a reversed decision made in full view of the first one is a healthy correction, while a silently ignored decision that nobody remembers making is just the same argument, waiting to happen again.

A thought experiment: the decision as a receipt

Think of a decision claim the way you'd think of a store receipt. Nobody keeps every receipt forever out of paranoia — they keep it because on the rare occasion something is returned or disputed, the alternative to having the receipt is an argument based entirely on two people's competing memories of a transaction from four months ago, which is a genuinely bad way to resolve anything, and everybody intuitively knows this the moment they're standing at customer service without one. A decision made in a standup, unrecorded, is exactly that situation, except the "return" — the moment someone questions the decision — often doesn't happen for months, by which point the two most relevant memories have each independently drifted (per two parts back in this series) toward whatever's easiest to defend today.

The fix was never more meetings about decisions. It's treating the decision the way this whole series has argued every checkable sentence deserves to be treated: kept, attributed, dated, and left waiting for the evidence — a commit, or a later decision — that eventually says whether it held. The new hire's question isn't the problem. The problem is that answering it, honestly, currently requires someone's memory instead of a receipt.