Documentation rots because updating it is nobody’s job

Pull up your team’s wiki and open the page you’d send a new hire first. Somewhere in the first two screens there is a sentence that stopped being true this quarter — a limit that changed, a setting that moved, a feature that shipped out of the “coming soon” list and into the product. You know which sentence, roughly, because you’re the one who knows. Nobody else reading the page can tell.

That last part is the actual problem. A document that is 90% true and gives no signal about which tenth is stale doesn’t deliver 90% of the value — it delivers a reason to double-check everything. Readers learn this fast. A few stale hits and they stop treating the wiki as an answer and start treating it as a lead, which lands them back in your DMs, which was the thing the wiki existed to prevent.

Why rot wins

Documentation rots for structural reasons, and it helps to name them, because none of them are laziness.

Writing happens once, with a burst of intention — a launch, an onboarding push, a quarter with a spare week. Updating has no such moment. It is a background obligation belonging to everyone, which in practice belongs to no one; there is no calendar event, no owner, and no natural trigger that fires when a sentence goes stale. The knowledge, meanwhile, changes in places documents don’t watch: a decision in a meeting, a correction you typed into a Slack thread, a judgment call that has only ever lived in your head. The wiki isn’t in the room for any of it.

So the gap widens quietly. Nothing marks the moment a line goes wrong — the page looks exactly as authoritative on the day it starts lying to people as it did the day it was written. Rot, in other words, is the default trajectory of any document that depends on someone remembering to edit it.

What teams have tried

The industry has real answers here, and it’s worth being fair about them. Docs-as-code brought review discipline to documentation: changes arrive as pull requests, get reviewed, and ship with the release. For API references, where docs can live next to the code that makes them true, this works well. Product knowledge — the judgment, the edge cases, the how-should-they-set-this-up material — mostly doesn’t live next to code, so it never enters that pipeline.

Assigning doc owners and review rotations helps while the energy lasts, which is usually a quarter or two — the rotation is the first thing dropped in a busy sprint, precisely because nothing visibly breaks when you skip it. And the newest answer, AI search over the whole pile, makes stale content easier to find without making it any fresher. A summary of six documents, two of which quietly disagree, inherits the disagreement — we wrote about that failure mode from the answer’s side in An answer you can check.

Each of these attacks part of the problem. None of them changes the underlying mechanic: keeping the document true still depends on a human noticing, remembering, and volunteering.

Reconcile, don’t append

The mechanic we bet on instead: new information should arrive as a proposed edit to what’s already written, not as another document on the pile.

Deputy maintains one briefing, and everything new gets reconciled against it. Hand it a doc and it reads the doc against the briefing — agreements absorbed, contradictions surfaced, genuinely new material drafted into the right section:

The same reconciliation runs on knowledge that never was a document: an answer you dash off in Slack, something you explain at length in a meeting, a correction you speak into your phone. Nothing in that list is a new obligation — it is the week you were already having, with the drafting riding along behind it. Whatever the source, a change lands the same way, as a diff: the stale line struck through, the fresh line beside it, dated. Conflicts get surfaced rather than silently resolved. Nothing lands without your approval, and nothing sneaks in.

The diff is doing the quiet structural work here. It converts “keep the docs updated,” an unowned background duty, into “approve or reject this specific change,” a thirty-second decision that arrives on its own. You stop being the author who must remember and become the editor who gets asked. Editors keep up in a way authors never have.

A document you can still read

One design choice underneath all of this deserves a sentence of defense: the briefing stays a document — sections, prose, a date on every line — rather than dissolving into an embedding index with a chat window on top. Partly that’s for the reader. But mostly it’s for the owner: a briefing you can read end to end is a briefing you can vouch for, and since Deputy speaks only from the briefing, vouching for the document means vouching for every answer it will ever give. A knowledge system you can’t read is a system you can’t stand behind.

Docs rot because updating them is nobody’s job. The fix we’re betting on makes updating them nobody’s job in the other direction — the noticing, drafting, and reconciling happen on their own, and the only part that stays human is the part that should: deciding what’s true.