Why Company Wikis Don't Preserve Decision Context

A wiki's whole design point is that a page reflects current, correct state. That's a genuine strength — it's why wikis are good at runbooks, onboarding docs, and "how does X work." It's also exactly why a wiki quietly erases the reasoning behind decisions over time, and it's worth being specific about the mechanism, because it isn't neglect. It's the format working as intended.

When something changes, the correct wiki behavior is to edit the page in place — update the current value, remove what's no longer true. That's the right move for documentation. It's the wrong move for a decision, because a decision isn't a fact about the present; it's a record of a choice made at a specific moment, under specific constraints, that may no longer apply. Editing "we use vendor X" to "we use vendor Y" the day you switch is correct documentation practice and simultaneously destroys the entire record of why X was chosen in the first place, since there was rarely a separate page for that reasoning to live on.

Even when a team is disciplined enough to create a dedicated "Decisions" page, it inherits the wiki's editing model: someone can (and eventually will) edit it later "for clarity," subtly rewriting the original reasoning with hindsight-informed language that makes the original decision look more obviously correct — or more obviously wrong — than it actually was in the moment. A wiki page has no built-in concept of "this described a specific point in time and shouldn't be edited to reflect what we know now." A decision record does.

None of this is an argument against wikis — they're the right tool for what they're for. It's an argument for keeping decisions somewhere with a different editing model: append, don't overwrite; track status and outcome over time rather than silently updating the original entry. See how that plays out concretely in Decision Memory vs Confluence and Decision Memory vs Notion.