The Page That's Lying to You
Somewhere in your knowledge base, there's a page that is confidently wrong. The wiki format was never designed to prevent this — and most tools still aren't.
Somewhere in your company's knowledge base, there's a page that is confidently, completely wrong. You don't know which one. And unlike a broken build or a failed test, it will never announce itself.
This is the core failure of wikis: stale information looks identical to accurate information. The page describing a process your team abandoned six months ago looks exactly like the page describing the one you're actually following. Both have the same font. Both have the same timestamp. One of them is lying.
What Ward Cunningham actually built
Ward Cunningham launched WikiWikiWeb on March 25, 1995, on the website of his software consulting firm. He'd named it after the Wiki Wiki Shuttle at Honolulu Airport — wiki is Hawaiian for quick. The point was speed: fast to edit, fast to link, fast to be wrong and get corrected.
That last part matters. Cunningham's design philosophy was essentially Socratic: post a wrong answer and someone will correct it faster than they'd respond to a question. The wiki was built for collaborative iteration, not authoritative record-keeping. It was a space for pattern discovery among programmers. A conversation, not a filing cabinet.
Companies got hold of the format and used it as a filing cabinet.
The misapplication
Corporate wikis fail at a rate that would be embarrassing if anyone were measuring. Research consistently finds that nearly half of all content in corporate knowledge bases is outdated at any given time — one figure puts it at 49%. The 1/9/90 rule applies ruthlessly: roughly 1% of wiki users create content, 9% make minor edits, and 90% read (or avoid reading). Nobody is gardening.
The deeper problem is structural. A wiki is optimized for iteration — for knowledge that benefits from being challenged, edited, and refined by many people over time. Authoritative documentation is optimized for trust — for knowledge that needs to be stable, owned, and clearly dated. When you use one format for the other, you get neither. You get a graveyard of pages that used to be right.
The failure is invisible by design. When a team sets up Confluence with good intentions, it works for a while. The setup guides are accurate. The process docs reflect reality. Then knowledge decays in real time while pages sit still. Six months later, someone follows the onboarding guide and wonders why nothing works.
Stale documentation is worse than no documentation, because no documentation is an honest signal. Stale documentation is confident.
Why Wikipedia doesn't rot
Wikipedia is technically a wiki. It's also nothing like a corporate wiki, because of one structural rule: Wikipedia doesn't permit original claims. Every fact must be cited from a third-party source. This means Wikipedia isn't storing knowledge — it's indexing knowledge that exists elsewhere. When the source changes, the article can be updated. There's always an external anchor.
Corporate wikis don't have this. They store original assertions — "our deploy process is X," "this person owns Y" — with no citation, no owner, no expiry date. There's nothing to go stale against.
The other thing Wikipedia has is active, dedicated curation. There are thousands of editors whose primary work is gardening: deleting wrong information, flagging unsourced claims, keeping pages honest. Most corporate wikis have nobody doing this. The person who wrote the page left two years ago. Their email address in the footer is the last trace of them.
Why typed entities don't have this problem
The lesson here isn't "don't use wikis." It's that unstructured prose carries no metadata about its own reliability.
A note that says "Maria works at Stripe" is structurally identical to a note that says "Maria used to work at Stripe." The text doesn't know it's outdated. The same sentence that was accurate in 2022 sits in your knowledge base in 2025 with nothing marking that anything has changed.
A structured person record is different. It has a created_at and an updated_at. It has a company field — a discrete value that can be reviewed, searched, queried. You can ask: show me all person records that haven't been updated in eighteen months. You cannot ask that of a folder of notes.
This isn't a pitch for any particular tool. It's a file format observation. Unstructured prose is opaque to anything that isn't a human reading it carefully. Typed, structured entities are not. You can build maintenance logic on top of them. You can flag what's likely stale. You can see when something was last touched.
The wiki's failure at scale is really a warning about what happens when you use prose to store knowledge that has a shelf life — which is most knowledge. Relationships change. Processes change. Preferences change. The document doesn't.
Ward Cunningham is still active in software communities. He still talks about the wiki as a conversational space, not a documentation archive. He built something for fast, iterative refinement among people who would all read and edit it. The companies that adopted it for HR policies and incident runbooks had something different in mind. That's where things went wrong — not in the technology, but in the assumption about what it was for.
Asgeir Albretsen is the founder of Harbor.