Every page proves what it rendered.

For each chapter section marked data-record-scope, the build step takes the text content of the rendered chapter plus, in DOM order, a token [href:{target}] for every link and a token [img:{src}|{alt}] for every image in scope. Subtrees marked data-record-ignore are excluded: specimen islands, build-fetched counters, the record lines themselves, and anything else whose value derives from the record system and would otherwise hash its own output. Hidden animation overlays are excluded the same way, so the verifier reads canonical text, never an animation layer.

The collected text is Unicode NFC-normalized, zero-width characters are stripped, whitespace is collapsed, and the result is trimmed. Link and image targets that resolve inside this site reduce to their root-relative form, with the per-deployment cache token (dpl) the optimizer appends dropped so the record is deployment-independent; external targets stay absolute. A swapped href inside a record scope therefore breaks the chain: covering attributes closes the rewritten-link hole that text-only hashing leaves open.

The claim is scoped to what is proven: the prose, links, and figures of the page. Scripts and styles are not covered, which is why no page here claims to hash "the page".

The genesis record is the hash of the page's doc-strip line, the one printed under the navigation. Each chapter record then commits to the document id, its chapter index, the previous record, and its canonical content:

genesis  = SHA-256("DOC {id} · {title} · REV {rev}")
rec_n    = SHA-256("{docId}/{nn}" + "\n" + prev_hex + "\n" + canonical_nn)
pageHash = SHA-256(rec_01 + rec_02 + …)   // lowercase hex, concatenated

The build step (scripts/build-records.mjs) computes the chain from the built HTML, renders it into the chapter footer record lines, and mirrors it in an inert JSON manifest embedded in the page (<script type="application/json" id="page-records">). The canonicalization module the build runs is byte-identical to the one the in-browser verifier runs.

Every build recomputes the chain from the built HTML and fails on any divergence, so a published page and its records cannot drift apart.

VERIFIED.The chain re-derived from the document in your browser matches the built record, and the record's internal linkage holds. The verifier flashes each record line and prints a summary you can screenshot.

MODIFIED IN BROWSER. The text in your browser differs from the built record. Common causes: in-browser translation, Grammarly, ad-block cosmetic filters, Dark Reader, or an enterprise DLP extension. When this happens the verifier re-fetches the served document, parses it inert so scripts never execute, and recomputes. If the served copy verifies, the difference lives in your browser environment, and the document the server sent is intact, which is the point of the chain. Re-check in a private window or via view-source.

CHAIN BREAK. The served document itself fails recomputation. This state is reserved for real divergence between what was built and what is being served, and it names the first record that broke.

The verifier source is MIT licensed and runs against this site's own pages.

One limit, conceded: the verifier detects in-browser modification; it is not an anti-clone or authenticity proof. The manifest ships with the page and the build script is public, so a faithful clone of both verifies green on any origin.

Entries produced by the current append path are written to a hash-linked trail and carry per-workspace Ed25519 signatures. Retained history can include legacy unsigned entries. The verification protocol and key catalog explain the workspace-scoped key-discovery path. The redacted signed sample supplies one entry, its public key URL, and an offline verification command. Signature presence and verification are distinct: signed material is not verified until the published checks succeed.

Signing posture, stated plainly: signatures are made over pre-hashed payloads, and payload canonicalization follows JCS, whose IEEE 754 float serialization boundary is inherited by anything that signs JSON. Key rotation is currently a metadata operation; re-signing historical chain segments is on the roadmap. Customer-held keys and HSM support are on the on-prem roadmap. The same disclosures appear on the security page, next to the keys.

Successful verification establishes tamper-evidence for the entries supplied and linkage within that retained segment. It does not establish capture or full-history completeness, continuous monitoring coverage, truth at capture, or whether records outside the segment existed. External timestamp anchoring is not part of this published proof.