Who Owns This Doc? Assigning KB Ownership So Nothing Quietly Rots

Open any article in your knowledge base and ask one question: if this went out of date tomorrow, whose job is it to notice? For most teams, the honest answer is nobody's. The article has an author — the person who happened to write it eighteen months ago — but an author is a historical fact, not a standing responsibility. So the doc sits there, quietly drifting away from reality, and everyone assumes someone else is watching it. Nobody is.

That's the real reason knowledge bases rot, and it's worth being precise about the mechanism, because the usual diagnosis is wrong. People say the wiki is stale because "the team doesn't care about documentation." I've never found that to be true. The team cares. What they don't have is a name attached to each article that says this one is yours to keep true. When something is everyone's job, it is by definition no one's job. Diffuse responsibility is not a culture problem you can fix with a reminder email. It's a design flaw, and it produces the same outcome every time: a base full of articles that are slowly going wrong, with no one accountable for catching the drift.

And drift is expensive in a way that missing content isn't. A gap is honest — the reader searches, finds nothing, and asks a human. A stale article is a trap. The reader searches, finds a confident-looking doc, trusts it, and acts on information that stopped being true in March. The first time that happens, they lose a little faith in the KB. The third time, they stop searching it at all and go straight back to interrupting the person who knows. The base didn't die because it was empty. It died because nobody could tell which parts were still true, and ownership is the discipline that answers exactly that question.

Here's how to install it, in order.

1. Decide which articles actually deserve an owner

You cannot own everything, and pretending you can is how ownership programs die in week two. Most knowledge bases follow a brutal usage curve: a small slice of articles carry almost all the traffic, and a long tail sits unread. Ownership is a scarce, real commitment of someone's attention, so spend it where being wrong has a consequence.

Pull your view counts for the last two quarters and mark the top slice — the articles your team actually relies on. Add anything that isn't high-traffic but is high-stakes: the refund policy, the security runbook, the compliance answer, the onboarding checklist a new hire follows blind. Those get owners. The dead tail doesn't need an owner; it needs an archive. Assigning a human to babysit an article nobody reads just burns the credibility of the whole program.

2. Assign a person, not a team

The single most common way ownership fails is assigning it to a group. "The CS team owns the refund docs." "Engineering owns the runbooks." A team cannot own an article, because a team cannot feel accountable. Everyone on it assumes a teammate has it handled, which is the diffuse-responsibility problem you were trying to solve, wearing a slightly larger hat.

Owner means one name. A specific human who is responsible for that article being correct — not for writing it, not for knowing everything in it, but for making sure it still matches reality and for pulling in whoever does know when it doesn't. If you cannot name the person responsible for an article being true, that article is unowned, whatever the org chart says. Write the name in the article's metadata where any reader can see it, and pick people who actually work near the knowledge, not the most senior person available to be volunteered.

3. Set a review cadence that fits the content

Ownership without a clock is just a name in a field. The owner's core job is to answer, on a schedule, one question: is this still true? How often that question needs asking depends entirely on how fast the underlying reality moves.

• Policies and compliance answers — quarterly. They change without announcing themselves, and being wrong here is the most expensive kind of wrong.
• Runbooks and procedures — after any incident or process change that touches them, plus a floor of twice a year.
• FAQs and how-tos — monthly to quarterly, since they drift as the product and the questions shift.
• Genuinely stable reference material — annually is fine. Don't over-review things that don't move; you'll train owners to rubber-stamp.

Attach the cadence to the article as metadata, separate from "last edited." An article can be edited for a typo and still be substantively wrong. What you want to track is last verified — the last time the named owner looked at it and confirmed it still holds. That date is the honest signal of whether a doc can be trusted.

4. Make ownership and staleness visible

Ownership only changes behavior if people can see it. Put the owner's name and the last-verified date on the article itself, in plain sight. Two things happen. Readers get a trust signal — "verified by Dana six weeks ago" is worth more than a polished layout. And owners feel the mild, productive pressure of having their name attached in public, which is most of what makes the commitment real.

Then surface the staleness at the base level, not article by article. You want one view that answers: which owned articles are past their review date, and who owns each? That list is the entire operating rhythm of a healthy KB. Without it, staleness is invisible until a reader trips over it. With it, staleness has a name next to it before anyone gets burned.

Where the tooling earns its keep

Everything above is a discipline, not a product, and you can run it by hand in a spreadsheet. The place a tool changes the math is the watching. Tracking last-verified dates across hundreds of articles, knowing which ones are overdue, and remembering to nudge the right owner at the right time is exactly the tedious background work that quietly falls off a busy person's plate — which is how ownership programs decay back into the graveyard they were meant to prevent.

This is the part KnowledgeByDesign is built to carry. Governance is a first-class feature: every article can carry a named owner, so accountability is a property of the doc rather than a line in some side document. And the base is designed to be self-cleaning — it watches for staleness and prompts the owner to review when an article is due or looks like it's drifted, instead of waiting for a reader to discover the rot. The human keeps doing the only part that needs judgment: deciding whether the article is still true and fixing it if it isn't. The system does the remembering. That division is the whole point — ownership stays honest because nobody has to hold the review calendar in their head.

The bottom line

Knowledge bases don't rot because people are careless. They rot because responsibility is spread so thin it evaporates, and a doc with no owner has no one to catch it going wrong. The fix is unglamorous and it works: decide which articles matter enough to own, put one human name on each, give every owned article a review cadence that fits how fast it moves, and make ownership and staleness visible so accountability isn't theoretical. Do that, and staleness stops being a silent leak. It becomes a task, with a name attached, caught before a reader ever trusts the wrong thing — which is the only version of a knowledge base worth having.