Part 1 and Part 2 of this series defined AI-ready documentation. This post is about who keeps it that way.

Most product teams don't have an answer to that question. They have an arrangement: engineers update docs when they remember, writers update them when a ticket is filed, and nothing gets retired unless a customer complains. The arrangement holds until the AI assistant starts reproducing old inconsistencies as confident fact.

Maintenance is a discipline in its own right, and the people who know the product best are often the least equipped to do it.

What maintenance actually requires#

Four responsibilities, each of which compounds when ignored.

Tracking change at the system level. Every shipped feature potentially invalidates something in the docs. Catching that requires owning the relationship between product changes and documentation coverage inside the same workflow. In most teams, documentation updates slip because they belong to no one specifically.

Validating against real usage. Fresh-reader validation means running the getting-started flow from scratch, completing an integration using only what's published, and treating "works on my machine" as uninformative. Internal teams rarely do this consistently. Tenure inside a product is the adversary of fresh perspective.

Enforcing structural consistency. The content models built at launch have to hold across every page added afterward. A page written under deadline pressure by a contributor unfamiliar with the model becomes the de facto template for the next contributor. Drift compounds from there.

Correcting drift continuously. Products change. SDK versions deprecate. Protocol upgrades change component behavior. Drift correction isn't a quarterly audit. It's an ongoing job with a forcing function nobody schedules.

Rule: Ownership has to be structural, not assumed.

Why this falls through the cracks#

Teams handle documentation ownership in a handful of ways. Each has a characteristic failure mode:

Engineers own it. Fast feedback loop, but no distance. They know what changed; they can't see what a new reader doesn't understand.
Traditional technical writers own it. Good distance, limited access. They hear about changes after they ship, and validation requires technical depth that the role often doesn't carry.
A DevRel or DX team owns it. The strongest version of this works well. But the role pulls toward external-facing content — talks, demos, advocacy — and away from the unglamorous maintenance work.
A platform or documentation-engineering team owns it. The best structural fit, when it exists. It rarely does outside larger organizations.
Nobody formally owns it. The work fragments across engineering, product, and DevRel. Drift accumulates until something breaks in public.

Most teams live in the last bucket. That's not a failure of effort; it's a gap in the org chart.

Rule: If nobody is accountable for the system as a whole, drift is a schedule, not a risk.

The skill set#

Whoever does this work — internally or externally — needs five things at once:

Engineering fluency. Reads the code, understands what changed, files structured PRs and issues rather than informal feedback.
Documentation systems expertise. Can diagnose why retrieval is failing — broken content model, missing metadata, accumulated drift — not just write clear prose.
User empathy. Runs interviews, watches analytics, tests the docs hands-on against real workflows.
Maintenance discipline. Audits, ownership assignments, retirement processes, update workflows tied to product changes.
Autonomous judgment. Surfaces the most impactful problems without being told. Prioritizes by what's breaking retrieval, not what's loud.

Some people have all five. They're usually senior, usually expensive, and usually already doing something else.

What the role looks like in practice#

Whether the role is internal or external, the shape is the same:

Technical enough to contribute directly — PRs, not just comments
External enough to see the product the way a new reader sees it
Disciplined enough to run the maintenance workflow on a schedule

The work is unglamorous and compounds: user journeys completed, demo apps built, interviews conducted, AI outputs tested against real queries, ownership documented per page, retirement workflows enforced. None of it is dramatic. All of it is what keeps retrieval quality flat-to-improving over time instead of decaying by default.

Documentation doesn't maintain itself#

Consistent AI output requires consistent documentation. Consistent documentation requires someone structurally responsible for it — with the right skills, the right access, and enough distance from the product to see what a new reader or a retrieval system actually encounters.

The question worth asking is who on your team owns this system today, and whether the answer is structural or just assumed.

If the answer is "assumed," we can help figure out what structural looks like.