Documentation drift gets described the way financial advisors describe inflation: a slow, abstract erosion that will catch up to you eventually. That framing lets teams postpone the work indefinitely. The reality is sharper, faster, and measurable — and once an AI assistant is reading your docs on behalf of customers, the curve bends from annoyance into liability in a single quarter.

Here is what drift looks like on a curve, why the curve is convex, and what the remediation bill actually reads at each milestone.

The three inputs that set the curve#

Drift is not a feeling and it is not linear. It is a compounding function of three inputs:

Release velocity (R) — shippable product changes per month that touch a docs-relevant surface: API shapes, UI chrome, pricing, permissions, defaults, limits.
Page count (P) — total indexable documentation pages, including reference, guides, tutorials, changelogs, and anything the retrieval layer can see.
Review cadence (C) — the fraction of pages meaningfully audited per month, where "audited" means a human or a well-scoped agent compared the page to current product behavior.

A reasonable first-order model is drift_rate ≈ (R / P) * (1 - C). A SaaS team shipping twenty docs-relevant changes a month across four hundred pages with no review cadence drifts around five percent of pages per month. That number compounds, because the same page rarely breaks twice before it breaks a third thing.

Two assumptions worth naming. First, not every release touches docs — infrastructure work, internal refactors, and experiments under flags usually do not. We count only the changes that alter an observable surface. Second, not every page is equally sensitive. A quickstart that mentions pricing, auth, and a default model is five pages of risk in one URL. A conceptual overview of "what is a webhook" might go two years without needing a comma moved. The formula gives you a fleet average; the distribution is what bites.

Month 3 — the ignorable phase#

Failures sit around one to three percent of pages. Everything is still loosely correct. Nobody has noticed, including the team writing the docs.

What breaks at this stage is small and specific: a pricing tier renamed from "Team" to "Business," a deprecated api_version parameter still shown in a curl example, a screenshot whose sidebar is one release behind. Retrieval still works. The AI assistant occasionally inserts a wrong detail into a summary — a limit that moved from 100 to 250, a default that flipped — but the surrounding answer is directionally right, and the customer does not file a ticket.

On the model side, a well-built retrieval stack is forgiving here. Modern embedding models handle minor factual skew in a chunk by pulling additional context, and a reranker with a recency signal on the frontmatter will usually surface the newer page when a duplicate exists. Forgiving is not the same as correct, but it hides the problem.

Inside the team the refrain is predictable: "We will clean it up after the Q2 launch." That sentence is the first symptom of the month-six knee, not a plan.

Month 6 — the knee#

Failures are now in the eight to twelve percent range. Two or three false-but-confident facts repeat in the AI assistant every week, because the stale chunks have high semantic similarity to common questions and keep getting retrieved.

The failure modes change shape. Sibling pages start to conflict — the migration guide says one thing, the reference says another, and the changelog splits the difference. Deprecated endpoints still rank because they have the most inbound internal links. Onboarding tutorials quietly assume features that shipped after the tutorial was written, so a new user hits step four and finds a button that is not there.

This is the month when customer support changes behavior. Tickets start arriving that quote the assistant verbatim: "Your AI told me X, but when I try it I get Y." Support forwards transcripts back to the docs team. A solutions engineer, burned once on a prospect call, stops trusting the assistant and starts screen-sharing the raw reference. Trust, which took a year to build, begins to erode in weeks.

Retrieval metrics turn before the humans do. A doc set that shipped with answer-accuracy around 92 percent on a fixed eval often drops into the low 80s by month six, and the degradation is not uniform — it concentrates in the twenty or thirty most-asked questions, which is exactly where it is most visible. If you are not measuring this, you will learn it from a customer.

The refrain becomes: "We need someone to own this." Usually that someone does not get hired for another two quarters.

Month 12 — the cliff#

Failures reach twenty-five to forty percent of pages stale or internally conflicting. There is now more than one version of several core concepts living in the docs at the same time. The assistant is confidently wrong on enough queries that sales has quietly stopped pointing prospects at it.

The important shift at twelve months is categorical, not quantitative. You are no longer fixing pages; you are fixing information architecture. The same fact exists in four places — the API reference, a guide, a blog post that got pulled into the docs site, and a changelog entry — and correcting one does not correct the set. Inbound links from integration partners, SDK readmes, Stack Overflow answers, and other vendors' documentation point at URLs you now need to deprecate. Every redirect is a small negotiation with SEO.

For anything built on retrieval, twelve-month drift is structurally hostile. Conflicting chunks with similar embeddings get pulled into the same context window, and the model does what models do — it synthesizes, picks the more fluent passage, or averages them into a plausible hybrid that is wrong in a new way. Frontmatter that once carried clean product_version, last_verified, and status fields is now inconsistent or missing, so the reranker has nothing to break ties with. Agentic workflows that chain three or four doc lookups compound the error at each hop.

The refrain is the expensive one: "We are going to rebuild the docs." Some teams mean it. Others mean "we are going to turn the assistant off," which is the same admission with a smaller budget line.

Why the curve is convex#

Three effects compound, and each one feeds the next.

Internal links outlive the pages they point to. Every stale page generates stale referrers, and the referrers are often in higher-traffic locations — a top-level guide linking into a dusty reference page. One bad page becomes five bad neighborhoods.

Old pages train search, both classical and semantic. Once a page ranks, it keeps ranking until something actively demotes it. Embedding indexes are worse than keyword indexes here: the vector for a two-year-old page does not know it is two years old unless your metadata says so and your retrieval layer actually uses it. Most do not, or do it badly.

And the docs reflect the org. A year of drift is a year of conflicting priorities, reorgs, half-finished migrations, and PM handoffs, all encoded in prose. This is the effect worth sitting with. Drift is not primarily a technical deficit — it is organizational memory that nobody was assigned to curate. The page that contradicts the other page is not a bug; it is a fossilized decision from a quarter when two teams disagreed and shipped anyway. Fixing it requires knowing which team won, which is a conversation, not a commit.

The remediation cost curve#

At month three, a fix is measured in minutes per page. A writer reads the diff, updates the example, bumps the last_verified date, and moves on. Ten pages in an afternoon.

At month six, it is hours per page, because a fix usually requires reading two or three sibling pages to decide which one is canonical, then updating the other two to defer to it. The work is editorial, not mechanical.

At month twelve, it is days or weeks per section. You are reconciling architecture, writing redirects, coordinating with partner-integration owners, and rewriting frontmatter so the retrieval layer can tell new from old. On the engagements we see, the all-in cost of a twelve-month remediation runs roughly five to ten times the cost of the same fixes applied on a rolling basis over the preceding year. That multiple is before you count the revenue impact of a support team that stopped trusting its own docs.

The cheapest intervention nobody funds#

The arithmetic is unforgiving and the intervention is boring. A monthly review cadence of ten percent — one page in ten touched, verified, and re-dated every month — cuts the twelve-month failure rate by more than half in the model and, in our experience, by more than that in practice, because the reviewed pages are usually the high-traffic ones where drift does the most damage.

Ten percent a month is not a heroic program. For a four-hundred-page doc set, it is forty pages a month, or roughly two pages a working day, or one competent technical writer at a fraction of their time, supported by an agent that pre-flags candidates using changelog diffs and retrieval-failure logs. It is the single highest-leverage line item in a docs budget.

It is also the line item that gets cut first, because it does not ship anything. That is the actual thesis of this post: drift is cheaper to prevent than to fix, the coefficient is worse than most teams assume, and the work is unglamorous enough that it only happens when someone is specifically paid to do it. If your docs are feeding an AI assistant that customers and prospects talk to, "specifically paid to do it" is no longer overhead. It is the product.