To document decisions so people actually find them, stop writing them into pages nobody reopens and start putting them in a record you can query by question, with a named author on each one. The failure is not that teams forget to write decisions down. They write them down constantly. The failure is that the writing is shaped for the moment it is created, not for the person who will need it six months later.
A decision you cannot retrieve when you need it is functionally undocumented. It exists, technically, in a doc or a thread somewhere, but if finding it takes longer than just asking around, people ask around. So the question is not "did we write it down," it is "can someone get the answer by asking a plain question," and most documentation fails that test.
Why does write-once documentation fail?
A write-once doc is a page someone creates at the moment of a decision and rarely opens again. It fails for a reason that has nothing to do with effort: it is organized by where it was written, not by what someone would later ask.
Think about how the decision gets stored. It goes into a project doc, or a meeting note, or a Slack thread, filed under the date and the context of that week. Now think about how someone retrieves it months later. They do not remember the date or the meeting. They have a question: "why did we drop the legacy endpoint." There is no path from that question to the page, because the page was filed by origin, not by question. The information is present and unreachable at the same time.
The second failure is anonymity. A write-once doc often records what was decided but not who stood behind it, so when the decision goes sideways there is no one to ask. A decision without a named owner is just an opinion that happened to win, and it carries no accountability into the future.
We covered a related version of this in stop losing decisions in Slack. The channel is a worse version of the write-once doc: it captures everything and surfaces nothing, because it has no way to connect a question to the one message that answers it.
What does it mean to query a decision by question?
A queryable decision record is one you can ask a plain question and get back the specific decision that answers you, with its author and reasoning attached. Querying by question is the difference between a search box and an answer.
Search returns documents that contain your words. If you search "legacy endpoint" you get every page that mentions it, and you still have to read through them to find the decision. Querying returns the decision itself: who made the call to drop the endpoint, when, and the constraint that forced it, in that person's own declared words. You ask the way you would ask a colleague, and you get a colleague's answer without interrupting one.
This works because the record is organized around the question, not the origin. It does not matter that the decision was made in a Tuesday meeting and mentioned later in a PR. What matters is that when someone asks "why did we choose Postgres," the record connects that question to the engineer's recorded reasoning. The filing problem disappears because there is no filing, only asking.
Why does every decision need a named author?
Because a decision is only trustworthy when you know who vouched for it. The named author is what tells you the entry is a real decision someone made, not a draft, a suggestion, or a paraphrase a tool produced.
There are two steps here, and keeping them separate is the whole trick. The first is making work discoverable: a person's updates, commits, and notes are auto-indexed so the system knows where the relevant material lives. This part is automatic and quiet, and it does not ask anyone to write more than they already do. The second step is declaring, where a person vouches for an answer as their own. Indexing makes the work pointable; declaring is the moment someone says "yes, this is my decision, you can quote me on it."
That declared, named answer is what people can trust later. When the record returns a decision, it returns whose decision it was, so the asker knows who to follow up with and the author stays accountable for the call they made. Nobody is left holding a choice that has no owner.
What happens when no decision exists?
The record says so, plainly, and that is one of its most useful features. If someone asks about a choice the team never actually made, the honest answer is "no record," not a confident guess assembled from nearby text.
A clear "we never decided that" saves people from acting on something that was never true. It tells you the question is still open and points you to the person who would own the answer, which turns a dead end into a next step. A documentation system that always produces an answer, even when no decision exists, is worse than one that admits the gap, because it manufactures false certainty. The refusal is information, and a good record treats silence as a feature rather than a failure.
How do I set this up on my team?
Build the habit around the decision moment, not a separate documentation chore. When a call gets made, the owner declares it: a short statement of what was decided and why, in their own words, with their name attached. Keep it where the team already works so it does not become a doc nobody opens, and let auto-indexing handle the rest of the context so the only added step is the declaration itself.
Then resist the urge to reorganize the storage. The goal is not a better folder structure, it is a record you ask questions of. If your team is also rethinking how it captures work day to day, our list of the best async standup tools for 2026 covers which tools keep the decision queryable and which only summarize the status.
You can see the full path, from making a person's work discoverable to declaring a decision to querying it later, in how StandIn works.
Frequently Asked Questions
What is the best way to document a decision?
Record what was decided and why, in the decider's own words, with their name attached, somewhere you can query later by plain question rather than by date or folder. The author and the queryability are what make it findable.
Why can't people find decisions even when they are written down?
Because the writing is filed by where it was created, not by what someone would later ask. There is no path from a question like "why did we choose this" to a page filed under a meeting date.
What is the difference between searching and querying a decision?
Search returns documents that contain your words and leaves you to read them. Querying returns the specific decision that answers your question, with its author, date, and reasoning attached.
Does StandIn write the decision record for me?
No. It answers only from records you declared, in your own words. It never generates a decision in your name. If you have not stood behind an answer, it points the asker to you or says there is no record.
What if a decision was never actually made?
The record returns "no record" instead of guessing. That tells you the question is still open and shows who would own the answer, so you do not act on a decision that never existed.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to retire your daily standup?
Distributed teams use StandIn to start every shift with full context, no standup required. Engineers publish a 60-second brief. The next shift wakes up knowing exactly what to work on.