I spent my career on the publishing side, and only recently started building software. The code world handed me machinery the marketing world never had: branches, diffs, the ability to roll back to any earlier state, a build that broke the moment a dependency shifted underneath me. None of it was optional. Shipping software without that scaffolding would have been malpractice.
Then I looked back at the archive of posts I had spent years publishing, every one of them resting on numbers I had pulled from somewhere. Not one of those numbers had ever had version control for knowledge: no history, no diff, no earlier version to return to. The discipline I had just met in code turned out to be the thing missing from the work I had done all along.
The reason the gap hides so well is that publishing borrows none of the words that would expose it. We research, write, publish, and move on, and we call the result a finished post. In software, shipping something you never patch again has a name. Negligence.
Your Archive Is a Codebase With No CI
Version control for knowledge means treating every published claim like a tracked file: each cited source is a watched dependency, every figure keeps a history you can open, and a change in a cited source is what triggers the review.
Look at your published archive the way you would look at a repository. It has a history, even if nothing renders it. It has dependencies, because every post leans on facts it imported from somewhere. And it is running in production, served to readers every day, long after anyone last opened the file. A repository in that state has one thing yours does not: someone watching the build.
This is the part the content side never quite names. A blog post is a system with live inputs, and articles are software in every way that matters to maintenance: composed of parts, dependent on things outside themselves, and prone to breaking when those things move. Content as code already brought version control and continuous delivery to how a post is authored and shipped, and stopped there, never reaching the facts the post depends on once it is live. The premise that published data goes out of date is settled, and every data point is a claim that was true on the day you wrote it and is only assumed true after. The open problem is the one almost no one has built for: the discipline software spent four decades assembling to keep a changing system alive.
Consider a single claim, the kind that reads "72% of marketers use AI." Imagine that in 2024 it was one number, in 2025 a higher one, in 2026 higher still. Your page still shows the 2024 value while the world behind it has moved on, and nothing in your stack knows the difference. That is a missing version history.
Your Post Has a Dependency Graph Nobody Is Watching
Here is the question that makes the gap concrete. Your last data-backed post cited a vendor survey, a Gartner figure, a census table, and a competitor's pricing page. When one of those four numbers changed, who told you?
The answer, almost always, is no one. Content has dependencies the same way code does: a post that cites four outside sources has imported four packages, and not one of them is pinned to a version. They can change upstream whenever their owners decide, with no notification reaching you, and the claims resting on them go wrong with no signal. Your post has a dependency graph, and nobody is watching it build-break.
Unpinned Imports Are How the Bug Ships
Every engineer who has written numpy==1.2 understands why the pin is there. You pin a dependency so a silent change upstream cannot break your build without your say-so. A citation is the same kind of import, except a publisher pins nothing. The number gets pasted in, the post ships, and the link between your claim and its source is never version-checked again. An unpinned import is a citation with no version, and it is how the wrong number ends up in front of a reader.
We measured what these unwatched graphs look like at rest. In a scan of 6,751 data claims across 938 SaaS blog posts, 73% of the claims were borrowed, restated from someone else's research, and 70% of those borrowed claims carried no link a reader could follow back to the source. The blog claim attribution study is a portrait of a corpus full of imports with no lockfile. And the aging shows: across the 751 posts that make at least one data claim, 177 carry numbers two or more years out of date, almost a quarter of them, as the state of content decay gets worse the longer a post sits unmaintained.
A package manager watches its dependencies because a version bump upstream is not a hypothetical. Publishing has the same exposure and almost none of the tooling. The first move version control for knowledge makes is to treat every external source a post cites as a dependency under watch: each cited URL becomes a monitored page, checked for whether it is still alive and when it last changed. The limit matters, and it is worth stating plainly.
Monitoring tells you the page you depended on is gone, or that it last changed after the day you cited it. It does not read the new page and confirm the number moved. The signal is the same one a build server gives you when a dependency shifts: something you imported is no longer what it was when you shipped, and the claims resting on it are now worth a second look.
Your Own Numbers Are a Dependency Too
Everything so far points outward, at the sources you imported. The graph runs the other direction as well. Publish a study packed with original figures and cite those numbers across your own back catalog, and you have become the upstream: one canonical number that a dozen of your own posts now depend on. Revise the study, and every page still showing the old figure has fallen out of sync, the same breaking change a version bump pushes to everything downstream of it.
Software solved this by never copying the value in the first place. You define it once, give it a single source of truth, and every reference resolves back to that one definition, so a change lands everywhere at once. Publishing pastes instead, which is how one number comes to live in 20 posts that each drift on their own schedule.
Version control for knowledge restores the single definition after the fact. You mark one claim as the source of truth, and every other place that number appears becomes a tracked reference to it, each reading in sync or drifted against the canonical value, with the gap shown as a diff. When the source-of-truth number moves, the posts that fell behind surface as a list, every one flagged against the figure it was supposed to match.
The Software-to-Knowledge Map
Once you see one citation as an import, the rest of the mapping falls into place, and it is literal rather than clever. A git log shows every prior state of a file. A claim's history shows every prior wording and value of a number, current to stale to fixed, with the before and after set side by side when a correction lands. That is the first row.
Take another. A production bug is code that runs without throwing an error while doing the wrong thing, which is exactly what a stale claim is. It renders cleanly, the page looks fine, and the reader takes the number at face value while the source behind it has already moved. Nothing flags it, because nothing is watching. The table holds five more rows, and every one is this literal.
Read the table and the analogy stops being a comparison. It becomes a list of the maintenance machinery software takes for granted and publishing never built. Content and code share one maintenance problem, and software is the field that already solved it.
A Refresh With No Claim-Level Diff Is a Deploy With No Changelog
The usual objection arrives here: I already refresh my content on a schedule, so I am covered. A scheduled refresh is real work, but watch what it produces. You open the post, bump the date, add a paragraph, and republish.
The version number moved. Nothing tells you which claims changed, or whether any did. A content refresh with no claim-level diff is a deploy with no changelog.
That gap has a name once it accumulates. Every unrevisited post carries a running balance of claims that were true at publish and have drifted since, and the interest compounds the longer the back catalog grows. The arithmetic of how that balance builds is its own subject; the short version is that content debt is what you owe when the dependency graph goes unwatched. A changelog is the thing that would have told you the bill was growing, and a scheduled refresh has never produced one.
Git for Claims, Made Literal
This is a real problem, and the fair question is whether it is solvable or just a sharper way to describe the pain. The answer is that the machinery already exists, and the easiest way to believe it is to open a published claim and find that it already has a commit log.
Version control for knowledge keeps a public history for every claim it tracks: when the number was first verified, each time it was re-checked and held, and the moment it was flagged stale because the source under it moved. The claim carries its own timeline the way a file carries git log, and the entries are dated events, not a vague "last updated" stamp. Where a correction has been made, the history shows the prior wording beside the new one, the same shape as a diff. Nothing in that record is discarded when a claim changes, which is what makes rollback a direction the history already supports rather than a button you press. Underneath sits the other half of the logs: the citation provenance chain behind the number, the trail back through whoever it was sourced from, hop by hop, traced the way citation chain monitoring walks a claim to its origin.
The reason this matters is what we found when we walked those chains ourselves. When we followed 1,469 verified citations to their source, only 15.0% reached the primary that first reported the number. That figure is the one I keep coming back to. The other 85% were imports whose origin no one had checked since the day they shipped. A commit log for a claim is what turns that from an invisible risk into a record you can read.
Here is one of those logs on a live claim, its events stacked newest first.
The Pipeline Stops at a Review Gate You Approve
Continuous integration earns its keep by being the thing that runs without you and then refuses to deploy on its own. The prose equivalent works the same way. When a monitored source moves and a tracked claim goes stale, living content infrastructure does not silently rewrite the web. It assembles the correction and routes it into a review queue, where you approve, edit, or reject it.
I drew that line deliberately. The embeds you control and the variants you authored can update on their own, because those are yours to move. A page you do not own gets flagged with a suggested fix and waits.
The pipeline stops at a review gate you approve.
That boundary is the entire trust model: the system can find the build-break and stage the patch, but a human still signs the deploy onto anything a reader will see.
How Your Team Finds Out a Source Changed
All of this rests on one habit publishing never standardized: noticing when a cited source moves. How you discover that is the difference between a watched dependency and an assumed one.
A post that cites a vendor survey, a Gartner figure, and a census table is importing three packages that can version-bump in production. They will change. Whether that surfaces as a flagged claim or a reader complaint comes down entirely to how you find out.
Every answer except the last one describes a repository with no continuous integration: a dependency graph that only gets checked when something has already broken in front of a reader.
A source you cited and never opened again is pinned to a version that may no longer exist. The gap between what your post says and what the source now reads widens every quarter you do not check, and nothing about the page tells you it has opened.
Version Control for Knowledge Is the Missing Layer
This is knowledge maintenance: keeping the claims inside a published post true as their sources move. It sits above page management and content refreshes the way dependency management and continuous integration sit above editing a single file. Version control for knowledge is the infrastructure that makes the discipline practical, where every published claim carries a history you can open and every cited source is a dependency something is finally watching. The frame routes through ideas the corpus already names, living content for the parts that update themselves and content maintenance infrastructure for the stack underneath, but the contribution here is the spine that connects them.
Treating content like software becomes literal once the claims carry their own history. Naming the discipline is most of the work. Once the archive reads as a codebase, the absence of version control stops looking like a fact of publishing and starts looking like a gap that someone will close.
What You Stop Maintaining by Hand
Software spent four decades answering one question: how do you keep a changing system alive without rebuilding it every morning. The answer was to build the machinery that watches the system after it ships, so a person is not the only thing standing between a broken dependency and a user. Publishing is only now discovering it has the same question, and it has been trying to answer it by hand.
You can keep doing that. You can re-read the archive on a calendar and hope to catch what moved. Or you can let the claims carry their own history, let the cited sources be watched the way dependencies are watched, and spend your attention on the corrections that need judgment. The fastest way to see which of your own posts are running on aging data is to point a scanner at them: the Content Health Scanner reads a URL and surfaces the claims whose sources have moved underneath them, no login required.
Once version control for knowledge gives a claim its own version history, the strange part is not that you would track it. The strange part is that you ever shipped the post without it.