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.

The hotfix rule is structural: continuous integration re-runs the record step and fails on any divergence, so no content change ships without re-hashing. If the step is removed, record lines and the verify button do not render at all.

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; the canonical copy will publish with the donmai.dev docs appendix and demonstrate against donmai.dev'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.

The Rensei platform writes every event to an Ed25519 hash-chained audit trail signed with per-workspace keys. The verification protocol and per-workspace key discovery endpoints are published at /.well-known/audit-keys.json, so chain integrity can be checked without trusting Rensei.

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.

The chain proves tamper-evidence and completeness, not ground truth at capture, which is why decision records bind model version, prompt, context, and policy ruling.