When Two Docs Disagree: Picking a Single Source of Truth

The new hire does everything right. She searches the knowledge base before asking, finds the page on processing refunds, and follows it. Three weeks later she's corrected in front of a customer issue — because there's a second page on processing refunds, written eight months after the first, with a different threshold and one added approval step, and the veteran correcting her found that one. Both pages are well-written. Both look official. Neither mentions the other. And the organization now runs two refund policies, distributed by search ranking.

One wrong document is a bad day; two plausible documents are structurally worse, because a wrong doc eventually collides with reality and gets fixed, while dueling docs just quietly sort your team into camps — each confidently sourced, each half wrong, discoverable only at the moment of collision. Forks like this aren't authored by carelessness. They're authored by helpfulness: someone couldn't find the original (or found it stale), wrote a better one, and never knew they were creating a rival. Which is why the fix is a rule and a habit, not a cleanup sprint.

The canonical rule: one question, one home

The rule is one sentence: every question has exactly one page that answers it, and every other mention points there. Not one page per team, not one per tool, one per question. The moment two pages answer the same question, one of them is canonical and the other is a redirect — there is no stable third state, because “they mostly agree” is just “they disagree” waiting for the next edit. Deciding which page wins takes five minutes and three tie-breakers, in order: which reflects what the team actually does today (verify with whoever does the work — not whoever wrote either doc); which has an owner who'll stand behind it; which is findable under the words people actually search. Age breaks no ties — newer is not truer, and neither is prettier.

Merge honestly before you demote

The losing doc usually exists because the winner had a gap — that's why someone wrote it. So the merge isn't a deletion; it's an audit: walk the loser paragraph by paragraph and either carry the difference into the canonical page, or explicitly decide it's wrong, with the person who owns the process in the room (a page's owner ruling on their own rival is how the fork war starts). The differences are the valuable part — each one is either a missing update, an undocumented exception, or a genuine open question about how the process works, and the third kind, per the working rule everywhere else: a conflict the docs can't settle is a question for the process owner, not a coin flip by whoever's editing.

Tombstone the loser — don't delete it

Deleting the losing page feels clean and breaks everything quietly: bookmarks die, links from old tickets 404, and the searcher who used to find the wrong answer now finds nothing, which reads as “undocumented” and seeds fork number three. The loser becomes a tombstone: title intact (it holds the search terms that made people find it), body replaced with one line — “This page has been merged into [canonical link] as of [date]. That page is the source of truth.” — and, where the platform allows, a hard redirect. The tombstone keeps doing the one job the old page did well — being findable — while pointing all that traffic at the truth. Retire the tombstones themselves on a slow cycle, a year or more, once inbound links have died of natural causes.

The habit that prevents the next fork: link, don't copy

Forks are born in the moment someone pastes a chunk of one doc into another — an onboarding guide that copies the expense steps, a team page that copies the deploy checklist. Every copy is a fork with a delay on it; the source gets updated, the copy doesn't, and eighteen months later you're back at the refund problem. The habit is the same one that governs chat answers: link, don't retype. A doc that needs to reference another process embeds the link and one orienting sentence, never the steps. This is also the honest fix for the “our team's version” page — if a team genuinely needs a variant, the canonical page hosts the variant as a section, where the next editor can see both and keep them true together. And when you find a fork in the wild — answering a question in chat and noticing two candidate pages — that's the same tripwire as any hygiene find: fix it now while both pages are open, not in the audit you'll schedule and skip. Five minutes at discovery beats an afternoon in Q3.

The bottom line

Two plausible docs are worse than one wrong one: the wrong one eventually gets caught, the duel just distributes confident error by search ranking. One question, one home; merge the differences with the process owner instead of steamrolling them; leave a tombstone that redirects the old page's findability at the truth; and starve future forks with link-don't-copy. None of it is a project — it's a five-minute protocol run at the moment of discovery, which is the only time anyone actually has both pages open.

— Tom