How provenance works

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 want to know whether a page was written by a person or generated, how current its facts are, or what the labels at the top of every page actually promise.

Every page here records how it came to exist. The label is not the feature; the audit trail is.

The split

AI maintains the volatile layer. The human writes the conceptual layer.

That division is not a hedge about what models can do. It follows from what each part is.

The volatile layer is a set of facts with sources. Correctness is checkable there. The work is keeping up with change.

The conceptual layer is explanation and sequencing. It includes the choice of which wrong mental model to name first. Correctness there is a judgment about a reader.

Generated content is allowed everywhere the eval suite can check it, and nowhere it cannot.

The authored states

Recorded in frontmatter, validated at build time. An unlabeled page fails the build.

human — written by a person.

generated-checked — generated, then verified by the eval suite against pinned sources.

generated-reviewed — generated, then read and approved by a person.

The runtime states

Produced while a reader is on the page, by the helper that arrives in change 0004.

They are never valid in frontmatter, and the build rejects them there. A runtime label on a stored page would claim it was checked. It was made for one reader, once.

generated-live — produced on the fly and not pre-checked. Labeled wherever it appears, including in anything the reader exports.

cached-demo — a pre-generated example served when live generation is unavailable, so the feature stays demonstrable without spending. Distinct from live output, and never presented as it.

Two verifications, not one

A person reading a page and a program checking it are different claims, and each page carries both.

verified_human is when somebody last read the page against its sources. It is the claim a reader is weighing when they decide whether to trust a sentence, and it is what staleness is measured against.

verified_eval is when the suite last confirmed the page's volatile values and structure. It runs nightly. Measuring staleness against it would mean no page is ever stale, which is a threshold that never fires.

They were one field until a scheduled run overwrote human review with eval suite across thirty-six pages. Every page then claimed a person had checked it that morning, when what had happened was that a program checked the parts a program can check. The write-back now writes only the machine field, because a program cannot report that a person read something.

Last verified

Each page carries the date it was last checked and by what. A page that has never been verified says so rather than showing the build date, which would make everything look freshly checked seconds after every deploy.

Verification is written back only by the scheduled eval run on the default branch. A run against a pull request never writes, so the date records a real check rather than the side effect of someone opening a branch.