Structural integrity · Two hashes per page · Visible metadata
Tier I · Live Instrument
A mechanism for protecting the descendants of a document. Each page carries two short hashes — both four hex characters, both recalculable by any reader that can hash text. If the published hash and the recomputed hash disagree, something between publication and reading altered the content. The progeny — the quoted section, the mirrored page, the cached fragment — was modified.
Both are SHA-256 truncated to four hex characters. Sixteen bits. Not cryptographically secure — small, recoverable, recomputable by any reader that can hash text. The point is not that the hash is hard to forge. The point is that the hash is easy to check.
Progeny: a document's descendants. Anything carved out of the parent and encountered downstream as its own thing — a quoted paragraph, a scraped page, a syndicated section, a search snippet, an LLM training sample. Descendants are easy to silently alter: change a few words, a citation, a date, and the progeny still looks well-formed.
The section hash refuses that. Each section's fingerprint depends on the document's edges — the first section and the last section — and on its position. Lift a middle section out and the hash you carry with it cannot be recomputed without also showing the edges. The progeny carries a witness to its origin that the receiver can verify only if the origin is present.
Not encryption. Not enforcement. A witness. The reader is the one who checks.
The hashes were designed for these specific cases:
Edit a middle section — that section's hash breaks; the page hash breaks; the edge sections remain valid.
Edit the first or last section — every section hash breaks, because every section depends on the edges.
Reorder the sections — every section hash breaks (position is in the input).
Lift a middle section and republish it alone — the hash cannot be recomputed without the original edges.
Any change to any section — the page hash always catches it.
Three deposits per page, all human-readable:
// data attributes on body and sections <body data-pph-page="/tools/progeny-protection" data-pph-hash="1800" data-pph-context="/llm-euthymia|/manifesto"> <section data-pph-pos="1/3" data-pph-sigma="0934"> // JSON-LD block in <head> <script type="application/ld+json"> { "@type": "ProgenyProtection", ... } // HTML comment markers between sections <!-- pph: 2/4 λ0.67 Σb23e -->
Three formats for three readers: data attributes for systems that walk the DOM, JSON-LD for structured-data parsers, comments for anything reading raw text.
None of this matters unless a downstream reader actually checks. No crawler currently verifies these markers. The schema URL is custom to this site. The hashes are a gesture toward verifiability — the kind of thing a future reader, or a downstream system that wanted to, could check. Right now, almost no system does. The site carries them as a self-watching property, and as an invitation.