Module 005 — Claims expire
What happens to a claim when the world that supported it moves on?
Its warrant decays even though its words do not change. Freshness is therefore part of a claim's structure: every claim in this site's registry carries a review window and typed review triggers, and CI fails the build when a window lapses or bound evidence diverges — expiry is mechanical, not aspirational.
01Observed / given
Every registry claim records last_reviewed, review_window_days, and its triggers — executable where CI can watch the bound evidence (remote file at bound ref vs default-branch head; local file by content hash), manual where it honestly cannot.
03Feasible worlds
Between reviews, a claim's true support is unobserved: the bound evidence may have moved, the world may have changed. The registry treats that uncertainty as load-bearing — a stale claim is not false, it is due: "a fired trigger or an expired window does not make a claim false; it makes the claim's warrant due for re-examination."
04Identification status
The mechanism claim is directly checkable: the verifier source is hash-bound (the executable trigger on SITE-002 fires if it changes without a re-review), and the weekly CI run is public.
05Result or bound
The mechanism is enforced, and its record is stated exactly: no public run has yet shown a trigger firing red — every DESIGN.md edit landed together with its re-review, which is the workflow operating, not the alarm sounding. The v0.4 audit re-reviewed three claims whose evidence or wording had drifted (CC-001, GA-001, SITE-001), and the stranded CC-001 binding was found by manual audit — a divergence class content-hash triggers are structurally blind to, which is why bound commits are now also checked reachable from their repository's default branch in the same CI run.
07Claim envelope
SITE-002
Supported within scope · Owner-verified
This site's claim registry is enforced in CI: verify_claims.py validates schema and bindings, executes the executable review triggers against live evidence, and fails the build when any claim passes its freshness window — on every push and weekly.
- Scope
- The verifier at the recorded content hash, and the public workflow that runs it. The generated-page and figure checks are separate steps in the same workflow (ledger, modules, observatory, figure geometry, internal links).
- Binding
verify_claims.py
Mutable link by design; the local-content trigger below detects edits.- Dimensions
- visibilityPublicprovenanceOwner-verifiedsupport roleSite documentmaturityReleased
- Reviewed
- 2026-08-23 · window 120 days
- Triggers
- executable fires when the verifier changes without a registry re-review
- manual workflow triggers or cadence change
- Non-claims
- a green run verifies registry consistency and quiet triggers, never the truth of any claim's content
- triggers watch file content; semantic drift outside watched files remains a manual review event, and the ledger says so
Rendered from the same registry as the ledger — one source, two views.
08Evidence
SITE-002 — Owner-verified · mutable link by design · reviewed 2026-08-2309Falsifier
A claim past its review window passing the weekly run, or a bound file diverging without failure, falsifies the mechanism claim directly — the CI history is public and would show it.
10Non-claims
- a green run verifies registry consistency and quiet triggers, never the truth of any claim's content
- triggers watch file content; semantic drift outside watched files remains a manual review event, and the ledger says so
- Freshness is not truth — a green run verifies registry consistency and quiet triggers, never the correctness of any claim's content.
11Reproducibility
python scripts/verify_claims.py — runs the same checks locally that CI runs on every push and weekly.
12Next unknown
Semantic drift that leaves bytes unchanged: triggers watch files, not meanings. Which review events can never be made executable?