Living documentation

Written by a person. Last read by a person on 2026-09-04, 4 days ago. Its facts were checked by the eval suite on 2026-09-07.

You are deciding whether this documentation is worth your time, you have been sent here as a work sample, or you want to see what a page that checks its own claims actually looks like.

This is a documentation system that demonstrates its own claims rather than describing them.

Documentation goes stale quietly. A page that was correct when it was written keeps looking correct long after the thing it describes has moved, because nothing about a wrong page looks wrong. The usual answer is discipline, which works until the person holding the discipline is busy.

The answer here is structural. Facts that change when something upstream ships live in one place, and prose references them rather than repeating them. A build fails when prose contains a value it should have looked up. Every page records what state it was authored in and when it was last checked against reality, and says so to the reader rather than keeping it in a spreadsheet.

What is here now

The machinery, and two documents it serves.

A runbook for people who have to use GitHub and do not write code, which leads with the mental model rather than the buttons, because the fear is not caused by not knowing the commands.

Plus one workflow of the Claude API, documented properly: streaming, with the error handling, retries and rate-limit backoff that decide whether it survives contact with a real network. Every API fact on those pages is verified against Anthropic's live documentation, dated, and re-checked weekly by a watcher that opens an issue when a value it holds stops being true.

Alongside them, 14 leadership documents answering one invented scenario: a capability gap at a 5,000-person company, carried from the survey through the strategy, the procurement and the scaling to an executive readout.

They are here rather than in a PDF for the same reason everything else is. A strategy document, a statement of work and a budget model all quote the same figures, they disagree, and the disagreement is found in the room by the person being asked for money. The whole set reads on one page if you would rather not click.

The rest is written down in the open, in openspec/, before any of it is built.

The retry ceiling, as a worked example

This site caps retries at 5 attempts, backing off from 1 second and multiplying by 2 each time.

Those three numbers are not written in this paragraph. They are read from data/volatile.yaml at build time, and the same keys will be read by the live demo when it exists, so the documentation and the running system cannot drift apart. Change a value, rebuild, and this sentence changes with it.

The same goes for names. This site is called Living Documentation, and that string is a volatile key too, so renaming it in one file renames it everywhere it is written rather than everywhere someone remembered to look.

What the check can and cannot catch

Write a volatile value into prose by hand and the eval suite fails the build, naming the file, the line, and the key you should have used instead.

A value long enough to be distinctive is matched wherever it appears. A short one is matched only when the surrounding paragraph names its concept, so a hardcoded retry ceiling in a paragraph about retries is caught while the same digit elsewhere is left alone. Flagging every occurrence of a digit would be noise, and a check that cries wolf is one people learn to skip.

That is a trade, not a solution, and the rubric states which way it goes wrong: an unrelated number in a paragraph that does discuss the concept gets flagged. A false positive is visible and someone fixes it. A missed stale value is not, and nobody does.

Staleness

Content is considered stale after 30 days without verification. The indicator at the top of every page reports its own state, including when a page has never been verified at all, which is the case worth surfacing and the easiest one to hide.