I published for years before I ever built software, and the first thing the code world handed me was tooling the marketing world had never mentioned: a history for every file, a version pinned to every dependency, a build that failed the moment something shifted underneath it. Nobody there treated any of that as optional. Then I turned around and looked at my own archive, years of posts, each one resting on numbers pulled from somewhere else, and none of it had version control for knowledge in any form. No history. No diff. No earlier state to return to.
The gap stays hidden because publishing never adopted the vocabulary that would expose it. You research, you write, you publish, you move on, and everyone calls the result a finished post. Software has a word for shipping something you never patch again. Negligence.
Your Archive Is a Codebase
Version control for knowledge treats every published claim like a tracked file. Each cited source becomes a watched dependency. Every figure keeps a history you can open. A change in a cited source is the event that triggers the review.
Your archive already behaves like a repository, whether or not anything renders it that way. It has a history. It has dependencies, because every post imports facts from outside itself. And it runs in production, served to readers every day, long after anyone last opened the file. A real repository in that state would have one thing yours lacks: somebody watching the build.
A blog post is a system with live inputs. It's assembled from parts, it depends on things beyond its own boundaries, and it breaks when those things move. The content-as-code movement carried version control and continuous delivery into how a post gets authored and shipped, then stopped at the publish button, never reaching the facts the post depends on once it's live. That published data ages is settled ground. Every data point is a claim that was true the day you typed it and only assumed true after. What nobody built is the maintenance layer, the discipline software spent four decades assembling to keep a changing system alive.
Take a single claim, something like "72% of marketers use AI." Say the survey behind it found one number in 2024, a higher one in 2025, higher again in 2026. Your page still renders the 2024 value while the world behind it keeps moving, and nothing in your stack can tell the difference. That's a file with no version history.
Every Citation Is an Unpinned Import
Here's the question that makes it 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 moved, who told you?
For almost every team the honest answer is nobody. Content has dependencies exactly the way code does: a post citing four outside sources has imported four packages, and none of them is pinned. Their owners can change them upstream whenever they like, no notification reaches you, and the claims resting on them go wrong without a signal.
Anyone who has typed numpy==1.2 knows what the pin buys. Upstream can't change under you without your consent. A citation is the same kind of import with the pin left off. You paste the number, the post ships, and the link between your claim and its source never gets version-checked again. That unpinned import is how the wrong number reaches a reader.
The corpus data shows what these unwatched graphs look like at rest. A scan of 5,034 data claims across 961 SaaS blog posts found 65.5% 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 describes a dependency graph with no lockfile anywhere in it. The aging shows too: of the 711 posts that make at least one data claim, 142 carry numbers two or more years out of date, one in five, and the state of content decay worsens the longer a post sits unmaintained.
A package manager watches its dependencies because upstream version bumps happen constantly. Publishing carries the same exposure with almost none of the tooling. So the first move is mechanical: treat every URL a post cites as a dependency under watch, each cited page checked for whether it's still alive and when it last changed. That signal has a limit worth stating plainly.
Monitoring tells you the page you depended on is gone, or that it last changed after the day you cited it. Reading the new page and confirming the number actually moved is still review work. What you get is the same alert a build server raises when a dependency shifts: something you imported is no longer what it was when you shipped, and the claims sitting on top of it deserve a second look.
Your Own Numbers Are Upstream Too
The graph runs in both directions. Publish an original study and cite its figures across your own back catalog, and you've become the upstream: one canonical number with a dozen of your own posts downstream of it. Revise the study, and every page still showing the old figure falls out of sync, the same breaking change a version bump pushes to everything below it.
Software's answer was to stop copying the value at all. Define it once, give it a single source of truth, and let every reference resolve back to that one definition, so a change lands everywhere at the same moment. Publishing pastes, 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 the number appears becomes a tracked reference, each shown in sync or drifted against the canonical value, the gap rendered as a diff. When the canonical number moves, the pages that fell behind surface as a list, each flagged against the figure it was supposed to match.
The Software to Knowledge Map
Once one citation reads as an import, the whole mapping locks into place, and it's literal rather than clever. 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 side by side when a correction lands. That's the first row.
Bugs map just as cleanly. A production bug is code that runs without throwing while doing the wrong thing, which is a precise description of a stale claim: the page renders fine, the reader takes the number at face value, and the source underneath moved months ago with nothing watching. The table holds five more rows, each one this direct.
Read down the third column and the analogy turns into an inventory: seven pieces of maintenance tooling software takes for granted, none of them ever built for prose. Content and code share one maintenance problem, and software already solved it.
A Refresh Is a Deploy Without a Changelog
The usual objection lands here: you already refresh content on a schedule, so you're covered. A scheduled refresh is real work, so look closely at what it produces. You open the post, bump the date, add a paragraph, republish. The version number moved, and nothing recorded which claims changed, or whether any did.
Let that pattern run for a few years and the gap earns a name. Every unrevisited post carries a balance of claims that were true at publish and have drifted since, and the balance compounds as the catalog grows. Content debt is what accrues while nobody watches the graph, and a changelog is exactly the artifact that would have shown the bill growing. No scheduled refresh has ever produced one.
Git for Claims
The fair question about all of this is whether it's buildable or just a sharper way to describe the pain. The shortest proof is a published claim that already carries a commit log.
Every tracked claim keeps a public history: the date its number was first verified, each re-check that held, the moment it went stale because the source under it moved. The entries are dated events, a real log rather than a vague "last updated" stamp, and wherever a correction landed, the prior wording sits beside the new one in the shape of a diff. The history discards nothing when a claim changes, which is why rollback comes free: the earlier state is always still there. Beneath the log runs the other half of observability, the citation provenance chain behind the number, traced hop by hop the way citation chain monitoring walks a claim back to its origin.
Walking those chains is what made the whole layer feel urgent. When we followed 1,006 verified citations to their source, only 17.2% reached the primary that first reported the number. The other 83% were imports whose origin nobody had checked since the day they shipped. A commit log per claim turns that from an invisible risk into a record anyone can read.
Above is one of those logs on a live claim, newest events first.
The Review Gate
Continuous integration earns trust by running without you and then refusing to deploy on its own. The prose equivalent works the same way. When a monitored source moves and a tracked claim goes stale, the system assembles the correction and routes it into a review queue, where you approve, edit, or reject it.
The line sits exactly where ownership sits. Embeds you control and variants you authored update on their own, because those are yours to move. A page you don't own gets a flag and a suggested fix, and waits. The system finds the build break and stages the patch; a person signs every deploy a reader will see.
How You Find Out a Source Changed
All of this rests on one habit publishing never standardized: noticing the moment a cited source moves. How that news reaches you is the whole difference between a watched dependency and an assumed one.
A post that cites a vendor survey, a Gartner figure, and a census table has imported three packages that can version-bump in production. They will change. What varies from team to team is how you learn about it.
Every answer except the last describes a repository with no continuous integration, a dependency graph that only gets checked after 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
The discipline underneath has a name: 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, a layer where every claim carries an openable history and every cited source has something watching it. Living content covers the pieces that update themselves, and content maintenance infrastructure names the stack underneath; the spine connecting them is the claim-level history.
What You Stop Doing by Hand
Software spent four decades on a single question: how do you keep a changing system alive without rebuilding it every morning. Its answer was infrastructure that keeps watching after the ship date, so a person is never the only thing standing between a broken dependency and a user. Publishing faces the same question and has been answering it with rereading and memory.
You can keep doing that, working through the archive on a calendar and hoping to catch what moved. Or you can let each claim carry its own history, put the cited sources under watch, and spend your attention on the corrections that need judgment. The fastest way to see which of your posts run on aging data is to point a scanner at them: the Content Health Scanner reads a URL and lists the claims whose sources have moved underneath them, no login required.
Your code has had a watcher from the day it first shipped. Your claims have been in production for years without one.