There's a principle in physics called entropy. It says that systems naturally progress from order to disorder. Everything tends toward chaos.
Your organization's knowledge is no exception.
Without active intervention, your documentation will get worse. Not slowly. Measurably worse. Articles will become outdated. Contradictions will accumulate. Gaps will expand. The quality will decay even if no one touches it.
This isn't a management failure. This is physics. Entropy is the default state. Order requires work.
Understanding this changes how you approach knowledge management.
Entropy in Action
I saw this play out at Microsoft. We had a comprehensive knowledge base. Well-structured. Good coverage. Then we didn't actively maintain it.
Eighteen months later: - 40% of articles hadn't been reviewed in over a year - Multiple articles contradicted each other on the same topic - Product changes had made 20% of the content outdated - New product features had no documentation at all - Search results were increasingly unreliable because the index included stale and current information side-by-side
The knowledge base hadn't been abandoned. It just hadn't been actively maintained. And entropy did its work.
The documentation didn't get worse because we stopped writing. It got worse because we stopped fighting entropy.
Why This Happens
Knowledge decays for predictable reasons:
Time moves forward, documentation doesn't. You release a product feature. Someone writes an article. Six months later, the feature changes. The article is now partially wrong. Two years later, the feature has evolved three times. The article is mostly wrong. But it still ranks in search results.
Context gets lost. Someone writes a process article. They understand the "why" deeply. Over time, that person's knowledge becomes institutional memory. When they leave, the article remains but the context is gone. New people read it and misinterpret it.
Systems change, but knowledge doesn't. You migrate to a new tool. You update some articles. Others slip through. Now you have hybrid documentation: some current, some not. Readers don't know which is which.
Duplicate knowledge accumulates. Person A writes an article about troubleshooting X. Person B, not finding it, writes their own version. Now there are two articles, slightly different, both ranking in search. Which one is current? Both? Neither?
Standards drift. Early articles were structured one way. You establish new standards. You don't retrofit the old articles because that's tedious. Over time, your knowledge base becomes a patchwork of competing formats, metadata schemes, and quality levels.
None of this requires negligence. It's just entropy. Systems tend toward disorder.
The Cost of Knowledge Entropy
Don't mistake this for a minor problem. Entropic knowledge is expensive.
Confusion costs time. Employees searching for answers find contradictory information. They spend time figuring out which is correct. Or they make decisions based on outdated information.
Trust erodes. If someone finds one article that's clearly outdated, they stop trusting the system. "Maybe this one is wrong too." The knowledge base becomes a liability instead of an asset.
New people stay slower. Onboarding takes longer when the knowledge they're learning from is fragmented and outdated. You can't scale without reliable infrastructure.
Decisions degrade. Organizations make decisions based on incomplete or contradictory information captured in their knowledge bases. Bad data in, bad decisions out.
Quality suffers. If your support team is working from outdated articles, they're solving problems the wrong way. If your sales team is using obsolete product information, they're misrepresenting what you sell.
The Second Law of Thermodynamics Applied to Documentation
The second law of thermodynamics states: in a closed system, entropy always increases.
Your documentation is a closed system if you don't actively manage it. The entropy increases. Always.
The only way to fight entropy is to do work. Constantly. Systematically.
You can't do it once. You can't do it occasionally. You have to do it structurally, which means:
Build it into your processes - Articles get reviewed on a schedule (not ad-hoc) - Ownership is explicit so someone is responsible - Changes to products/processes trigger documentation updates automatically - Outdated content gets flagged and removed
Measure it - Track freshness: when was each article last reviewed? - Track accuracy: are support tickets citing outdated documentation? - Track completeness: what percentage of your systems/processes are documented? - Track utility: what's being accessed vs. what's not?
You can't fight what you don't measure. The moment you stop measuring freshness, entropy wins.
Resource it Fighting entropy costs time and attention. If you don't allocate resources (people, time, tools) to maintenance, you've already lost. This isn't optional. This is the cost of having a functional knowledge system.
The VMware Model: Entropy as a Design Constraint
At VMware, we assumed entropy from the beginning. We didn't build a knowledge system and hope it stayed good. We built a system to fight entropy structurally.
Ownership with accountability. Every piece of knowledge had an owner. That owner reviewed it quarterly. If they didn't, the system flagged it. After a year of no review, the article went into "stale" status (lower ranking, warning label).
This wasn't about blame. It was about making entropy visible and assigning someone to fight it.
Continuous feedback loops. We tracked: What's being accessed? What's being searched for but not found? What's being accessed but rated "not helpful"? These signals told us where entropy was winning.
High-traffic articles that got poor ratings? Something was outdated or wrong. We'd revisit them. Articles that never got accessed? Maybe they were redundant or badly organized. We'd consolidate or remove them.
Structured review cycles. High-traffic articles (accessed 1000+ times/month) got reviewed monthly. Medium-traffic got quarterly. Low-traffic got annual review. Articles that hadn't been reviewed in a year were automatically downranked and flagged.
This sounds bureaucratic. It wasn't. It was the minimum structural overhead required to fight entropy.
Metadata as a weapon. We tagged articles with: product version, last review date, owner, status (current/stale/deprecated). When a product update happened, we could identify all affected articles. When someone left, their replacement could pick up ownership cleanly.
Metadata solved the "context gets lost" problem. Future people had a clear trail of who decided what and when.
Blizzard: Entropy in Fast-Moving Environments
At Blizzard, we faced a different entropy challenge. The game updates constantly. Patches every few weeks. Content changing faster than we could document it.
The traditional approach would fail: "document everything carefully and maintain it." Impossible at that pace.
So we fought entropy differently:
Accept that some entropy is inevitable. We distinguished between critical knowledge (must stay current) and contextual knowledge (can become outdated gracefully). We resourced the critical knowledge heavily. The contextual knowledge got tagged with "as of patch X" so readers knew the vintage.
Build feedback into gameplay. Players tell us when documentation is wrong. That's our entropy detector. When an article gets flagged as incorrect, someone reviews it within 24 hours.
Automate what we can. Patch notes are automatically linked to affected documentation. Skill descriptions are pulled from the game data, not hand-written (so they never get out of sync). Version information is automatic.
Prune aggressively. Old patch documentation gets archived, not left in the active knowledge base. This sounds harsh, but it's the only way to fight entropy at scale. You can't maintain infinite documentation. You have to choose what matters.
The Real Question
When you build a knowledge system, ask yourself: Am I prepared to fight entropy?
Not occasionally. Not when things get bad. Structurally. Continuously. Systematically.
If the answer is no, don't build a knowledge system. You'll just build an expensive pile of lies that erodes trust and makes decisions worse.
If the answer is yes, then you need: - Clear ownership - Regular review cycles - Measurement systems - Resource allocation - Automated help where possible - Ruthless pruning of what doesn't matter
The Uncomfortable Truth
Most organizations lose the entropy fight. They build a knowledge base with initial excitement. Maintenance starts strong. Then it becomes a maintenance burden. They cut the resources. Entropy accelerates. Quality collapses. They blame the tool and try a new platform.
The new platform has the same problem six months later.
The entropy doesn't come from the tool. It comes from not understanding that knowledge requires active work to stay good.
You can't coast on good documentation. You have to actively fight entropy.
The Bottom Line
Your documentation is getting worse right now. Not because you're failing. Because entropy is winning.
The question isn't whether to fight it. It's whether you're willing to do the structural work required to actually win.
If you are, entropy becomes manageable. If you aren't, your knowledge base becomes a liability.
Choose accordingly.