Wiki root · doc.html project · the record and its shelf

A wiki of witnessed documents

This page is a root document over separate doc.html files. Each shelf entry links a whole document and carries a cross-file witness for it — so the link does not merely point at the leaf, it pins the witnessed section content the leaf held, in order, when the shelf was written.

Every document on this site verifies alone: open any leaf and run either shipped reader (tools/verify.py or tools/verify.mjs) and each of its sections either hashes true to its manifest witness or is refused. What a single file cannot say is how a collection holds together — which documents belong, and whether one of them has been quietly rewritten and re-witnessed since the collection was assembled. That is the root's job, and it needs exactly one new rule:

The doc-pin. Take a leaf document's manifest data-witness values in manifest order, join them with : (ASCII colon), and compute the SHA-256 hex digest of that string. Each shelf entry below carries the result in a data-doc-pin attribute. A leaf whose every section still verifies, in the same order, reproduces the same pin; a leaf whose section content was rewritten — even one whose forger dutifully re-computed every per-section witness — produces a different one, and the mismatch shows here, at the root. (One release shipped this attribute as data-doc-fold; the rule and every value are unchanged — the mechanism was renamed so that fold keeps naming the format's append-and-supersede office. The rule's full specification, doc-pin v1, is the first entry on the shelf below.)

To check an entry yourself: (1) open the linked leaf and run a shipped reader — it must verify every section; (2) copy the leaf's manifest witnesses in order into the list and run: python -c "import hashlib;ws=['<w1>','<w2>'];print(hashlib.sha256(':'.join(ws).encode()).hexdigest())" — replacing '<w1>','<w2>' with the witnesses, one quoted entry per manifest line; (3) compare against the entry's data-doc-pin. One reader run and one hash utility — nothing else. Two shipped companions automate all three steps for the whole shelf, in two languages, delegating every document verdict to the shipped readers: python tools/verify_wiki.py documents/wiki.doc.html or node tools/verify_wiki.mjs documents/wiki.doc.html. Each prints the verified list — every entry it checked, with its full pin — so the run hands back exactly the object it certified.

What this binds, and what it cannot. The doc-pin is tamper-evident, never tamper-proof: it catches any change to a leaf's witnessed section content after this shelf was written, including a full re-witness of the leaf. It binds only that content, in manifest order: bytes a section witness does not cover — section id attributes, the manifest's own link text, page chrome outside sections — can change without moving the pin (an id rename is not silent in practice, since it breaks this root's own links into the leaf, but the pin itself does not see it). It also cannot date a leaf, cannot say a leaf is the latest recension, and is itself only as fixed as this root document — which carries its own per-section witnesses and is pinned, like everything here, by the repository's public history. One further boundary belongs here in ink: the companions certify this shelf as serialized — that carrier-shaped entries occur in this page's source bytes, that each named leaf verifies, that each recomputed pin matches — and they emit the exact list they checked. Whether the page a reader is looking at presents each of those entries as a live link is not something the companions check; comparing their emitted list against the shelf below is the reader's own step, by design. The attribute is named data-doc-pin, not data-witness, deliberately: a witness attests one section's inner bytes; a pin attests a whole document's witness set. Different claims carry different names.

The shelf · each entry names one whole document; its doc-pin binds the leaf's ordered witnessed section content

The shelf

The shape

The Wiki Shape: A Root of Witnessed Documents (9 sections) The specification of the shape this page instantiates: the parts, the doc-pin v1 rule, the resident-map reading mechanism, the receipts with their bounds, and authoring guidance for building your own — with the shipped two-language verifiers documented in-band.

The record

The evidence: what has actually been shown (9 sections) The project's results, read by question — scale and proof of read, cost and limits, what remains unproven — with the prior-art library and lineage on the same page. The claims and their limits are kept together; start here if you want receipts before essays.

The essays

Design essays from the project's writing room, each carried as written in public recension — a whole essay per document, with its provenance and a dated postscript where a later run answered a question the essay left open. The first two are a deliberate pair: the thesis, and the project's own rebuttal of it.

A Habitat Made of Text: Toward a Document Built for Two Runtimes (11 sections) The "why" essay: what a document is for when its reader is a mind made of text — one artifact for two runtimes, a deterministic parser for permanence and a probabilistic model for meaning. The most accessible door into the project.
The Reader Has No Conscience: A Counter-Receipt on the Two-Runtime Document (9 sections) The reply, written from the runs: navigation held, and the reader misattributed what it found — the seam neither runtime guards. The project arguing with itself, in public, with the numbers on the table.
The File Is the Message (8 sections) The dev-native argument: the browser was always the engine, GET and POST are enough, and a document is not a caller — a document is a request, and the successor document is the response.
The Format Is Smaller Than It Looks: doc.html, Seen Whole (10 sections) The synthesis: the kernel stated in a breath, three offices, five laws each paid for by a run. Read this for what the format IS, whole, without the history.
The Format Among Its Ancestors: The Confluence, the Seam, and What It Must Still Build (9 sections) The honest positioning: a confluence, not an invention — three lineages joined, the price of the join named, and the one corner still empty. The lineage backbone behind the library shelf.
The Wiki That Witnesses Itself (12 sections) The probe behind this page: a real markdown LLM-wiki ported to witnessed leaves under a pinning root, and what the format makes intrinsic that markdown leaves a bolt-on — the shape's claims earned, bounded, and reviewed before they were published. The story behind the specification above.

The founding record

doc.html — the agent-addressable document format, demonstrated by itself (25 sections) The founding record: the original doc.html corpus — the meta-document of how the format works, carrying the research that inspired it. It is where the format came from, kept whole rather than summarized. Historical where it disagrees with SPEC.md, which is normative.

About this file · colophon

About this file

This is a doc.html — a single, self-describing HTML file. The <nav id="manifest"> at the top of the body lists every section in this document; each entry's data-witness is the SHA-256 (hex) of that section's raw inner bytes, so any reader can verify any section with the file alone — no server, no JavaScript, no tooling. The full format definition is SPEC.md, carried in the format's own body as SPEC.doc.html.

Author: Georges Casseus (Ndoto Studios) · License: CC0 1.0 (public domain) · Built: 2026-08-01