The short version
- A single source of truth works for things that change rarely. It fails for everything else, because maintaining it is unassigned work with no deadline.
- One stale page poisons the whole wiki. After two bad experiences people stop trusting all of it and go back to asking.
- Split the idea. Stable facts get a page. Reasoning gets a decision entry. Current state needs something that updates itself from the work.
- What stays fresh is what people answered this week. Build on that rather than fighting it.
Every growing team arrives at the same conclusion at about the same size: we need one place where things are written down. A wiki is chosen, a structure is agreed, and for a few months it is genuinely good.
What a single source of truth promises
One authoritative place per thing. No conflicting versions, no wondering which document is current, no asking a colleague what the process is.
It is a sound idea and it works well in exactly one situation: information that changes rarely and has an obvious owner. Your expenses policy. Your deploy process. Your security requirements. Those pages are still accurate three years later.
The trouble starts when the same structure is used for everything, because most of what people need to know is not like an expenses policy.
Why it goes stale
Updating a page is unassigned work with no deadline and no visible consequence for skipping it. Compare it to any other task competing for the same hour and it loses every time.
Three specific mechanics.
- The person who changes the thing is not the person who wrote the page. They may not know the page exists.
- Nothing breaks when it is wrong. The cost lands on a colleague three weeks later, disconnected from the omission.
- Nobody is accountable for accuracy. Pages have authors, which is a record of who wrote it once, not who keeps it true.
Assigning owners helps a little and does not solve it, because the owner has the same competing hour. The honest conclusion is that manual freshness does not survive a busy quarter. See why knowledge bases die in month four.
How one wrong page poisons the rest
The compounding failure is about trust rather than content.
Someone follows a page, it is out of date, and they waste a morning. They tell a colleague. Now two people treat the wiki as unreliable, which means they check with a person even when the page is correct, which means they stop noticing when pages are wrong, which means nobody reports them.
Within two quarters the wiki is a place people are told to look and everyone asks instead. The content did not have to be mostly wrong for this to happen. Two bad experiences are enough.
This is why deleting aggressively beats leaving pages up just in case. A small accurate wiki is trusted. A large partly wrong one is not, and an untrusted wiki has negative value because it absorbs the effort that would have gone somewhere useful.
Split it into three
| Kind | Changes | Where it belongs |
|---|---|---|
| Stable facts | Yearly | A wiki page with a named owner and a review date |
| Reasoning | Never, it is a record of a moment | A dated decision entry next to the work, appended not edited |
| Current state | Weekly or daily | Not a document at all |
The middle row is worth pausing on. Decisions do not need maintaining, because they are dated records rather than statements of current truth. A 2024 decision entry is not stale, it is history, and it is still useful. Trying to keep decisions "current" by editing them is what destroys their value. See the decision log template.
What stays fresh on its own
Notice what never goes stale in any company: the answer someone gave this week. It is current because it was produced by the current situation, and it cost nobody a maintenance task.
The problem with those answers is not freshness, it is that they are trapped in direct messages and in people's heads, and they vanish when the person is unavailable.
That is what StandIn is built for. At the end of the day each person spends about ninety seconds on a brief: what moved, what is open, what is blocked, what is next, mostly drafted from the work that already happened. It is not a maintenance task, because it comes from the work rather than being written about it. When someone needs to know where something stands, they ask, and the answer comes from that brief in the owner's words with a source under it. It never guesses, and when the answer is not in the record it says so and names who to ask, which is what a stale wiki page can never do. The third row gets a home, and the wiki can go back to holding the twenty pages it is genuinely good at. See how it works and a system of record for everything except decisions.
Common Questions
Should we still have a wiki?
Yes, and a small one. Twenty accurate pages beat two hundred of uncertain age. Put a review date on each and delete anything nobody will own.
Does moving to a different tool help?
Rarely. Teams migrate every few years and the same decay happens on the new platform, because the cause was unassigned maintenance rather than the software.
What about requiring documentation updates in the review process?
It works where the documentation sits beside the work, such as in a repository. It does not work where the page lives in a separate tool nobody opens during the task.
Can an AI assistant keep it current?
It can summarise what exists and it cannot know what changed if nobody recorded the change. The question to ask of any such tool is what it does when it does not know. See what makes an AI answer trustworthy.
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.