Your Internal Knowledge Base Decays Without Pruning

An internal knowledge base is not an asset that grows. It is a garden that dies if you stop weeding it. Every doc you write starts decaying the moment the system it describes changes. Add more docs without deleting stale ones and you do not get more knowledge, you get more noise, and noise is worse than nothing because it actively misleads. A wrong doc that looks authoritative sends people down the wrong path with confidence. The knowledge base compounds only if pruning is a habit, not a someday.

I keep a lot of written knowledge across the portfolio, playbooks, ADRs, setup guides. The hard-won lesson is that the volume is not the value. The freshness is. A small, current knowledge base beats a large, half-rotten one every single time.

Why more docs makes things worse, not better

The naive model is that knowledge accumulates: write it down, it is captured, done. Reality is the opposite. Systems change. The doc does not change with them unless someone changes it. So the default trajectory of any doc is toward being wrong. A knowledge base that only grows is a knowledge base whose average accuracy is falling.

When accuracy falls, trust falls with it. People get burned by a stale doc once or twice and then they stop trusting the whole base. Now nobody reads it, which means nobody fixes it, which means it rots faster. You have built a monument to knowledge that no one uses. This is the exact failure mode I warned about in self-serve docs for an internal platform: docs are only worth having if people trust them, and trust dies with the first confidently wrong page.

A wrong doc is worse than a missing one

This is the core of it. If a doc does not exist, you know you have to go figure it out, and you approach the task with appropriate caution. If a doc exists and is wrong, you follow it and get burned, because you had no reason to doubt it. Confident misinformation is more dangerous than an honest gap. So the goal of maintaining a knowledge base is not maximum coverage. It is maximum trustworthiness. Better to have ten docs you can bet on than a hundred you have to second-guess.

This is why I would rather delete a doc I am unsure about than leave it up with a shrug. A deleted doc costs someone a lookup. A wrong doc costs someone an outage.

Build pruning into the workflow

Pruning does not happen in dedicated cleanup sprints, because those never get scheduled. It happens at the point of use, the same way playbooks stay current by being edited every time they are run.

• Fix on read. When you open a doc to do a job and a step is stale, fix it before you close the tab. The person using the doc is the person who just learned it is wrong. That is the cheapest possible moment to correct it.
• Date and owner on every doc. A doc with no last-reviewed date and no owner is an orphan. Orphans rot. Stamp both so staleness is visible and accountability is clear.
• Delete aggressively. If a doc describes a system that no longer exists, delete it. Do not archive it into a folder where it can still surface in search and mislead someone. Gone is better than buried.
• Prefer few, deep docs over many, shallow ones. The more surface area, the more that can rot. Consolidate. One current guide beats five overlapping half-guides that contradict each other.

Tie docs to the thing they describe

The best defense against decay is proximity. A doc that lives next to the code or the system it describes gets updated when that thing changes, because the person changing it is right there. A doc that lives in a separate wiki, far from the code, is easy to forget. This is why I keep ADRs and playbooks close to the foundation they explain rather than in a distant documentation silo. Distance is decay.

When the knowledge lives with the thing, updating the thing and updating the knowledge become one action instead of two, and the second action is the one people always skip.

The metric is trust, not volume

Do not measure your knowledge base by how many docs it has. Measure it by whether people reach for it first or ask you directly instead. If people bypass the docs and come straight to you, the base has lost their trust, and volume is not the fix. Pruning is. A knowledge base you can trust is a compounding asset, because every job gets faster. A knowledge base you cannot trust is a liability that grows every time you add to it.

I keep the portfolio's knowledge in the same project memory the build system reads at Bootspring, and I treat deleting a stale entry as being as valuable as writing a new one. Weed the garden. A small, current, trusted knowledge base is worth more than a vast rotten one, and the only way to keep it small and current is to prune it on purpose.