Rubric: provenance labeling

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.

Enforced by check_provenance, and by the build's own frontmatter validation.

The claim

Every published page declares how it came to exist, in a state a reader and an agent can both read, and no page claims a verification that did not happen.

Observable evidence

• The provenance value in each file's frontmatter.
• Whether that value is one of the three authored states.
• Whether a runtime state appears in frontmatter, where it is never valid.
• The last_verified and verified_by values, and whether they are absent.

The pass bar

Every content file carries one of human, generated-checked, or generated-reviewed. No file carries generated-live or cached-demo. An unlabeled file fails the build, not the eval run, so that the label cannot be skipped by someone who did not run the suite.

Ambiguous cases

A page with no verification date. Passes this rubric and renders as never verified. Absence of verification is honest; a page that shows the build date instead would look freshly checked seconds after every deploy, which is the dishonest option and the tempting one.

A human edit to a generated page. The state describes how the current text came to exist, not its history. A generated page a person has rewritten is generated-reviewed if they read and approved it, and human if they wrote what is now there. The distinction that matters to a reader is who is answerable for the words in front of them.

Mixed authorship within a page. Not currently expressible: the state is per file. Section-level provenance is what the MCP provenance query in change 0005 needs, and the gap is recorded here rather than papered over.