Continuously updated evidence from the software itself

The questionnaire arrives and nobody trusts the answer

A customer's security team sends over a diligence pack. Somewhere in it are questions your documentation should already answer: what the system exposes, what it talks to, what third-party components it pulls in, how data moves through it.

What happens next is familiar. An engineer opens the architecture page, reads two paragraphs, and says some version of "this is from before the split." The answers get reconstructed by hand, from the code, by the people least able to spare the afternoon. Then the reconstruction is pasted into a form and never merged back into the docs, so the next review starts from the same place.

The underlying problem isn't that nobody wrote it down. It's that what was written down has no connection to what shipped. Prose in a repository can describe anything. It stays word-for-word identical whether the system still behaves that way or not.

Documentation became an input, not just an output

There's a newer reason to care, and it has nothing to do with questionnaires.

Coding agents read documentation and act on it. An agent that reads your reference page and writes client code against an endpoint that no longer accepts that parameter has just turned a stale doc into a defect — and, in the other direction, natural-language instructions sitting in a file an agent loads are instructions the agent may follow. The industry spent a decade learning to verify what goes into a build. Documentation is now a machine-consumed input to that build, and almost nobody verifies it.

Which is the structural argument for deriving documentation rather than authoring it. Hand-written prose cannot be checked against anything — there is no reference to compare it to. Content derived from source has one by construction.

What derivation gives you that authoring doesn't

• Coverage measured against the real surface. Generation starts from what the code actually exposes, so the gap between documented and existing is a number rather than a hunch. Undocumented interfaces are the ones that don't get reviewed, threat-modelled, or rate-limited.
• Examples executed, not asserted. Documented commands and API calls are run against your live deployment and mismatches are reported. A quickstart that no longer works is a security problem too — it's the page that teaches people the wrong authentication flow.
• Regeneration on every push. The description can't age independently of the system, because nothing is holding it still. There is no interval during which the docs quietly become fiction.
• Provenance on the page. Generated pages carry their origin in frontmatter — code-derived, validation-filtered — so a reviewer can tell at a glance which content was mechanically derived and which was written by a person. "Who wrote this and when" is the first question any assurance process asks about a document.

The gaps worth looking for

Once documentation is compared against source rather than against its own last revision, a specific class of discrepancy becomes visible. These are worth checking on any codebase, whatever tooling you use:

• Surface in the code but not in the docs. Endpoints and options that exist and ship but were never written up. Nobody reviews what nobody knows is there.
• Surface in the docs but not in the code. The reverse, and increasingly expensive now that agents write client code against documented interfaces.
• Permissions that disagree. The code enforces a scope the page omits, or the page promises one the code never checks.
• Exposure that disagrees. The page says internal; the router says otherwise.
• Credentials in examples. Real keys and tokens pasted into sample requests, which is common and trivially harvestable once published.
• Install snippets pinning old versions. A documented version with a known advisory is a supply-chain instruction your readers follow.
• Missing security-relevant sections. No authentication notes, no rate limits, no error semantics, no data-handling description — the absences a reviewer reads as risk.

What this looks like in practice

1. Connect the repository and generate. The first pass is the interesting one: the delta between what exists and what was documented is a direct measurement of how much of your current description is still true.
2. Read the coverage figure as a surface-area number, not a docs-quality score. It tells you how much of what you ship has been written down at all.
3. Fix what the executed examples flag. These are the fastest wins and usually the most embarrassing.
4. Keep authored content authored. Threat models, trust boundaries, and design rationale aren't derivable from source. They belong in the same place, written by people, and they survive regeneration.
5. Point reviewers at the published docs rather than rebuilding answers per questionnaire. The page is current because it regenerates, not because somebody remembered to update it before the call.

What this isn't