@333eco/corpus 2.4.2 → 2.5.1

package/README.md

@@ -63,6 +63,7 @@ manufactured on a schedule.
 | `get_document` | one document in full — canonical text, never a summary |
 | `read_documents` | whole documents — a shelf (the `list_documents` filters) or a list of slugs — one content block each, paged by size |
 | `list_documents` | slugs, titles, genres, licences, provenance summaries, **sizes**, and the manifest's completeness counts |
+| `check_passage` | whether a passage is served — verbatim, with the same words, or not — and for a near miss, the nearest served passage and exactly how the two differ |
 | `list_predictions` | the research program's pre-registered predictions, with falsifiers and status |
 | `get_prediction` | one prediction, plus the provenance envelope of the paper that registered it |
 | `get_program` | the program's hard core, chapters, stopping rule and count reconciliation, verbatim |
@@ -128,6 +129,20 @@ route. The server never cuts a document, but a client may, and a cut document re
 complete one. The end is stated in the text, where a cut removes it — not in a field that would
 survive the cut and assert a completeness the text no longer has.
 
+### Checking a quotation
+
+⭐ **A hash tells a machine reader one bit — matched or not — and that bit is nearly useless in the case that
+actually occurs: a quotation that is almost right.** `check_passage` lays a passage beside the corpus and says
+where it is served **verbatim**, where it is served with **the same words** (differing only in punctuation,
+formatting, case or diacritics), or — for a near miss — the **nearest served passage and each difference**: a
+word changed, dropped or added. Every excerpt it returns is the corpus's own bytes; the matching folds, the
+answer never does.
+
+⛔ **It judges the passage, never the person.** No score of the asker, no inference about intent, and the passage
+text is not recorded — a quotation someone checks is their business. The idea is old: a disputed reading was laid
+beside the collection and judged by where it agreed, explicitly not by who recited it (see *The Reciters'
+Protocol* in the corpus).
+
 ### Nothing silently missing
 
 The envelope proves each served document authentic; nothing used to prove that none was
@@ -149,7 +164,7 @@ and the build refuses to emit one that is not — a field must match a *complete
 cell of its source, because a fragment of a cell is still a substring of it.
 
 The program tools appear only when the index carries a program block. An index
-built over a corpus without one advertises four tools, not seven.
+built over a corpus without one advertises five tools, not eight.
 
 ## Resources
 

package/dist/corpus.json

@@ -1,5 +1,5 @@
 {
-  "package_version": "2.4.2",
+  "package_version": "2.5.1",
   "generated_from": [
     "H3/publications",
     "TH/publications",
@@ -3264,13 +3264,13 @@
         "url": "https://creativecommons.org/publicdomain/zero/1.0/",
         "attribution_required": false
       },
-      "text": "> **Claim-scoped by design.** This paper publishes the *claim* and withholds the *spec*. It states what a retrieval response must carry and why, and it does not give endpoint shapes, manifest schemas, transport bindings or tool surfaces. That is not coyness about a trade secret — every primitive here is someone else's, and all of them are public. It is the institution's standing rule that a complete implementable design for something unbuilt is a blueprint rather than a fence, and the ledger half of this paper is unbuilt. Publication protects against being *blocked*, not against being *beaten*.\n>\n> Companion works: *Appreciation as World-Building* (where the property-over-rule argument is made in general), *B-PoH: The Humanity Layer for an AI-Native Internet*, *Buddha AI and the Living Tipiṭaka* (whose §8 asks what makes a canon authoritative; this paper asks the narrower question of what makes a *copy* of it checkable), and *The Borrowable Standard*.\n\n## Preamble\n\nThere is a discourse in the Pāli canon (AN 3.65, the *Kesamutti Sutta*) in which a people called the Kālāmas tell a teacher that many teachers pass through their town, each praising his own doctrine and tearing down the others, and they no longer know whom to believe. The reply they receive is not a better doctrine. It is a procedure: *do not go by report, by tradition, by hearsay, by the authority of texts, by logic, by inference, by appearance, by agreement with a considered opinion, by seeming competence, or because the ascetic is our teacher.*\n\nThe passage is usually read as an invitation to scepticism. Read as engineering, it is something more specific and more useful: it is a refusal to accept a claim **on the strength of the channel it arrived over.** The Kālāmas' problem was not that the teachers were lying. It was that nothing about a teacher passing through town distinguishes one who is right from one who is merely fluent, and the villagers had no instrument.\n\nA language model reading a retrieved document is in the Kālāmas' position, with one difference that makes it worse. A villager can at least walk to the next town and ask. A model takes what the channel delivered, and nothing about a plausible-looking response distinguishes canonical text from a paraphrase, a truncation, a substitution, or an earlier version withdrawn for being wrong.\n\nThis paper describes what a retrieval response would have to carry for that gap to close, and it claims no originality in any of its parts. The primitives are borrowed entire — content addressing from version control, timestamping from RFC 3161 and OpenTimestamps, transparency logs from Certificate Transparency, build attestation from Sigstore and in-toto. What is new, so far as we can establish, is the composition and its target: **the retrieval boundary between a corpus and a machine reader, at the moment of citation.**\n\nWe publish it defensively, under CC0, so that nobody may enclose it.\n\n## Prior-Art and Non-Assertion Statement\n\nThis document is dedicated to the public domain under CC0 1.0 Universal. Its purpose is to establish prior art. The author and HeartBank® will not seek patent on any mechanism described here, in any jurisdiction, at any time.\n\nThe building blocks are prior art already, and we name them precisely so that no reader mistakes our composition for a claim over the parts:\n\n- **Content addressing** — identifying a byte sequence by its cryptographic digest. Ubiquitous; Git, IPFS, and most package managers' integrity fields.\n- **RFC 3161 Time-Stamp Protocol** — a trusted authority's signed assertion that a digest existed before a moment.\n- **OpenTimestamps** — aggregation of digests into a Merkle tree whose root is committed to the Bitcoin blockchain, converting an authority's assertion into a proof-of-work-anchored one.\n- **RFC 6962 / RFC 9162, Certificate Transparency** — append-only Merkle logs with signed tree heads, inclusion proofs, consistency proofs, and gossip among independent monitors.\n- **Sigstore, Fulcio, Rekor** — keyless signing with short-lived certificates and a public transparency log of signatures.\n- **SLSA and in-toto** — attestation formats binding an artifact digest to the build that produced it.\n- **W3C PROV-O, PREMIS** — provenance vocabularies for describing derivation and custody.\n- **LOCKSS, Memento (RFC 7089), Software Heritage** — replication and temporal access to published works.\n- **C2PA / Content Credentials** — signed provenance manifests bound to media assets, addressing capture-and-edit chains for images, audio and video.\n- **DOI and DataCite** — persistent identifiers with resolution and metadata.\n- **SCITT (RFC 9943) and COSE receipts (RFC 9942)** — signed statements registered in a transparency service, receipts issued to the registering party, and newer-version and end-of-life statements.\n- **Software Heritage SWHIDs** — intrinsic identifiers that can qualify a sub-part of an archived object.\n- **The Model Context Protocol** — a published, open protocol for supplying context and tools to language models.\n\n**We assert no rights over any of these.** The claim in §9 is deliberately narrow, and it is smaller than the paper that surrounds it.\n\n## Abstract\n\nA retrieval system that supplies text to a language model is, at present, an authority. It says *here is the passage*, and the model has no instrument with which to disagree. The failure this produces is not usually fabrication — it is quieter: a superseded version served as current, a truncation that inverts a qualified claim, a paraphrase that drifts, or a substitution somewhere between the corpus and the context window. Each of these produces a citation that is confidently wrong and locally unfalsifiable.\n\nWe describe **provenance-carrying retrieval**: a response format in which every served document is accompanied by an envelope binding it to (a) a cryptographic digest **of a named, fetchable source**, (b) at least one **independent time anchor**, and (c) where one exists, a **citable identifier**; together with an explicit statement of what the digest covers and a runnable instruction for checking it.\n\nThe composition has one structural consequence, and it is the paper's centre. **It inverts the trust burden.** Ordinarily a retrieval server asks to be believed and the reader may, at best, decline. A response that carries the means of its own falsification asks to be *checked*, and a reader who declines to check has made a choice rather than suffered a limitation.\n\nWe then generalise. The same envelope applies to an **append-only log**, and there the generalisation is sharper than the original: for a log, the proof structure *is* the entire public payload. A ledger's transparency surface can be served in full — signed tree heads, inclusion proofs, consistency proofs, the published scoring function — while its *contents* are never served at all. This is not a diminished version of document retrieval. It is the complete version for that object, and it is what lets a transparency claim be verified continuously by machine rather than asserted periodically by an institution.\n\nWe state honest limits at length. The mechanism does not establish truth, authorship, or good faith. It establishes only that the bytes you were handed are the bytes that were anchored, and that they were anchored before a certain moment. Every other virtue must be argued separately.\n\n## 1 · Why this problem is the institution's problem\n\nThis institution has spent five years building a corpus whose stated audience is not primarily human.\n\nThe research corpus — mechanism papers, defensive publications, institutional positions — is written for an autonomous successor who does not exist yet, on the understanding that specifications decay and reasoning does not, and that a machine which inherits a set of refusals without the arguments that produced them will keep the refusals it does not understand and drop the ones it does. Density is up, hand-holding is down, honesty is up. It is a strange way to write, and it is deliberate.\n\nAn institution that writes for a machine reader eventually has to ask how the machine reads. The answer, currently, is: over a channel, on trust. The corpus is served as web pages, as a machine-readable index, and now over a retrieval protocol — and at every one of those boundaries the reader takes what it is given. Having taken care that a successor inherits reasoning rather than conclusions, we would be careless to hand that reasoning over a channel in which a single stale copy is indistinguishable from a current one.\n\nThere is a second reason, and it is less comfortable. **We have the anchors already.** Every document in the corpus carries a digest committed to a public blockchain and countersigned by independent timestamp authorities, because the defensive-publication strategy required provable dates long before anyone was retrieving anything. That apparatus was built for a legal purpose. It turns out to be the exact material a retrieval envelope needs, and having it sitting unused behind a website while serving the same documents on bare trust is the kind of waste that is invisible until it is named.\n\nThe third reason belongs to a claim we make elsewhere. The institution's durable advantage has been argued to be **the provable age of a record and the canonical standing of a reading of it**, rather than any secret. If that is true, then a surface which lets an outside party *check* the age is not a giveaway. It is the argument, made in the only form that does not require taking our word for it.\n\n## 2 · Background and prior art, engaged generously\n\nThe literature this paper stands on is mature, and none of it is ours.\n\n**Software supply chain.** The last decade of supply-chain security produced the closest analogue to what we describe. SLSA defines levels of build integrity; in-toto defines attestations linking artifacts to the steps that made them; Sigstore issues short-lived certificates bound to workload identity and records signatures in Rekor, a public transparency log. The mature form of the idea is: *do not ask whether you trust the publisher, ask whether the artifact's digest appears in a log you can audit.* That is precisely the move this paper transposes. **The difference in target is the whole of our contribution:** supply-chain attestation binds a *build* to a *source tree*; we bind a *retrieved passage* to a *published document*. The consumer differs too — a package manager verifies once at install; a language model verifies at the moment of quotation, which is a different moment with different failure modes.\n\n**Certificate Transparency.** RFC 6962 and its successor establish the design pattern for public append-only logs: Merkle tree structure, signed tree heads, inclusion proofs for individual entries, consistency proofs between heads, and gossip among independent parties to detect a log presenting different views to different observers. CT is the direct ancestor of §8 and we claim nothing over it. The observation we add there is narrow and, we believe, unstated: **a CT log never deletes an entry, and a ledger of human conduct must be able to release.**\n\n**Archival provenance.** PREMIS and W3C PROV-O give vocabularies for custody and derivation; LOCKSS gives replication; Memento gives temporal access; Software Heritage gives durable archival of source. The archival community has thought about this longer and more carefully than the machine-learning community has, and their conclusion is one we adopt: **provenance is metadata about a specific byte sequence, and loses its meaning the moment the byte sequence is normalised, re-encoded, or excerpted without saying so.** §4's insistence on naming *what the digest covers* is theirs, not ours.\n\n**Content Credentials (C2PA).** The nearest adjacent work. C2PA binds signed provenance manifests to media assets, recording capture device, edits, and chain of custody, and it is being deployed against synthetic-media risk. Two differences matter. C2PA's threat model is *the deceptive edit* — an image altered to mislead — and its manifests are typically embedded in the asset, though the specification also allows external ones. Ours is *the stale or truncated retrieval*, which involves no adversary at all and usually no edit: the most common failure is an honest system serving an old version. And our envelope travels with a retrieval *response* rather than with an asset, because the artifact is prose that will be quoted in fragments. What travels is a pointer to bytes that can be re-fetched.\n\n**Retrieval-augmented generation.** The RAG literature is large and largely concerned with *relevance*: chunking, embedding, reranking, whether the retrieved passage answers the question. Verification appears in that literature as *attribution* — did the model's output follow from the retrieved context — which is a question about the model's faithfulness to its context. **We are asking the prior question: was the context itself what it claimed to be.** A perfectly faithful model grounded in a superseded document produces a confidently wrong citation, and no amount of attribution scoring detects it, because the model was faithful. The exceptions are named here. *Proof-Carrying Answers* (Shukla & Joshi, ACSAC Workshops 2025) has every retrieved chunk carry a hash, a signature and a Merkle proof verified before the answer admits it — the nearest prior work, and the difference is the named fetchable source, the anchor independent of the signer, and the scope statement. SCITT (RFC 9943) gives a transparency service newer-version and end-of-life statements, which is what would give §13.1's staleness row a source-side answer. Software Heritage's SWHIDs qualify a sub-part of an archived object, which is the scope obligation done at the identifier.\n\n**The Model Context Protocol.** MCP standardises how context and tools reach a model. It is the transport this work happens to use and is orthogonal to the claim: nothing here depends on MCP, and the envelope would apply unchanged to any retrieval interface. We name it because it is the surface on which the idea is most likely to be re-invented, and because a published protocol is where enclosure attempts land.\n\n## 3 · The asymmetry: what a machine reader cannot do\n\nA human scholar handed a suspicious quotation has recourse. They can find another edition, ask a colleague, check the pagination, notice that the prose does not sound like the author, or walk to a library. Most of this recourse is not procedural. It is the accumulated redundancy of being embedded in a world that contains the document in more than one place.\n\nA model has none of it. Its entire epistemic access to the document is the string in its context window. This produces four failure modes, and it is worth separating them because they have different frequencies and different fixes:\n\n```\n  FAILURE                WHAT IT LOOKS LIKE            DETECTABLE FROM THE TEXT?\n  ─────────────────────────────────────────────────────────────────────────────\n  Staleness              a superseded claim, cited     no from the text alone —\n                         as current                    it reads as correct because\n                                                       it once was; YES by fetching\n                                                       the named source (staleness\n                                                       OF the source: no)\n\n  Truncation             a qualified claim served      no — the qualification is\n                         without its qualification         simply not there\n\n  Paraphrase drift       a summary presented as        sometimes — if the reader\n                         canonical text                    has seen the original\n\n  Substitution           different text served under   no — by construction\n                         a correct-looking identity\n```\n\n**Staleness is the common case, and it is the one the field under-weights.** The literature is preoccupied with adversarial substitution, which is rare and requires an attacker. Staleness requires nobody: a corpus is revised, a cache is not invalidated, and a server continues answering correctly-shaped questions with text that was true last quarter. In our own estate we have watched four repositories sit three versions behind a shared layer while every integrity check reported green — because each was internally consistent, and *integrity is not currency.*\n\n⚠️ **And a stale document is worse than an absent one in exactly the situation this paper addresses**, because it is checkable and the check passes. An envelope computed over the served bytes will verify perfectly against those bytes. The reader is given every reason to believe, and no mechanism to discover it is quoting a withdrawn claim. **This is the failure that makes the naive version of our own idea dangerous**, and §4 is shaped around it.\n\n## 4 · The mechanism, stated as a claim rather than a specification\n\nA response carries, alongside the text, an envelope with four obligations. We give the obligations and not their encoding.\n\n```\n  ┌─────────────────────────────────────────────────────────────────┐\n  │  SERVED TEXT            the passage, verbatim                    │\n  ├─────────────────────────────────────────────────────────────────┤\n  │  ENVELOPE                                                        │\n  │                                                                  │\n  │   1. DIGEST      a cryptographic hash                            │\n  │   2. SCOPE       an explicit statement of WHAT the digest         │\n  │                  covers — and whether that is the served text     │\n  │   3. LOCATION    a fetchable address for the covered bytes        │\n  │   4. ANCHOR      ≥1 independent commitment that the digest        │\n  │                  existed before a stated time — or an explicit    │\n  │                  statement that none exists; never silence        │\n  │                                                                  │\n  │   +  IDENTIFIER  a citable persistent id, where one exists        │\n  │   +  LICENCE     terms, and any attribution actually owed         │\n  │   +  INSTRUCTION the command that performs the check              │\n  └─────────────────────────────────────────────────────────────────┘\n```\n\nFour of these are load-bearing in ways that are easy to get wrong.\n\n**Scope is the one everybody omits, and omitting it is fatal.** A served passage is very rarely byte-identical to the artifact that was anchored: the artifact has front matter, or a wrapper, or an encoding, and the passage is a body, an excerpt, or a rendering. If the envelope does not say so, a diligent reader hashes what it was given, fails to reproduce the digest, and concludes the corpus is lying — punishing exactly the reader the mechanism was built for. **The envelope must state whether the digest covers the served text, and when it does not, it must say what it does cover.**\n\n**Location converts an instruction into an instruction.** An envelope that says *compare this digest to the source file* without naming the file is not a procedure; it is a gesture at one. The covered bytes must be fetchable by the reader, which in practice means the source is published somewhere durable. This is a real constraint and it excludes private corpora from the strong form of the claim.\n\n**The anchor must be independent of the server.** A digest signed by the same party that served the text establishes nothing that party's word did not already establish. Independence is what makes the anchor evidence, and it admits several forms — a blockchain commitment, an RFC 3161 authority, a transparency log, a third-party archive — which are usefully combined, because they fail differently. A timestamp authority can be compromised; a blockchain cannot be reorganised at depth without a cost that scales with the chain's proof of work; a transparency log can be audited by parties who do not trust its operator.\n\n**The instruction is not decoration.** Publishing a digest and expecting the reader to know what to do with it assumes a reader who already knows. Carrying the exact command collapses verification from a research project to a paste, and — this is the part that matters — it means the claim in the envelope is itself checkable, rather than a sentence the reader must take on faith. *The envelope should not ask to be trusted about trust.* Illustratively, for a source published as a file — fetch it, hash it, compare, then verify the anchor:\n\n```\ncurl -sL <location> | sha256sum      # compare with the envelope's digest\nots verify <location>.ots            # the OpenTimestamps anchor\n```\n\nThe encoding of the instruction is not specified here; the example is what a check looks like, not what the field must contain.\n\n### 4.1 What the mechanism does **not** do\n\nIt does not establish that the document is true, that its author is who it says, that it was written when it says, or that it is worth reading. It establishes exactly one thing:\n\n> **These bytes are the bytes that were anchored, and they were anchored before a stated moment.**\n\nA second thing follows from the location obligation, and it is the reader's to do: the reader can fetch the named source *now* and compare, which is how staleness relative to that source is caught. Nothing here obliges the source to declare its successor.\n\nEverything else — authorship, veracity, authority, good faith — must be argued on other grounds. We are emphatic about this because provenance mechanisms are routinely oversold into implying authenticity, and a reader who takes a verified digest as a verified claim has been made *more* credulous by a mechanism intended to make them less so.\n\n## 5 · The inversion, which is the actual contribution\n\nEverything above is composition of known parts. The property that composition produces is the paper's claim to say something.\n\n```\n  BEFORE                                AFTER\n  ──────────────────────────────────    ──────────────────────────────────\n  The server asserts.                   The server exposes.\n  The reader may decline to believe,    The reader may check, cheaply,\n  but has no instrument.                with a named procedure.\n\n  Declining is a posture.               Declining is a decision.\n  Trust is the default and the          Checking is available and the\n  only option.                          default is a choice.\n```\n\nThe distinction is not rhetorical. A retrieval server that asserts is, in the strict sense, an **authority**: its claims are accepted because of what it is. A server that exposes is a **witness**: its claims are accepted because of what can be confirmed. The difference shows up precisely when the two diverge — when the server is wrong. An authority that is wrong propagates; a witness that is wrong is caught by the first reader who bothers. What remains trusted is the channel's willingness to pass the envelope at all (§13.2); everything inside it is checkable against parties the channel does not control.\n\n⭐ There is a consequence for the institution that is worth stating plainly, because it looks like generosity and is not. **A corpus that hands over the means to doubt it is harder to impersonate than one that does not.** A competitor may copy every document — ours are CC0 and copying is invited — but they cannot copy an anchor that is five years deep in a blockchain, and a reader with an instrument can tell the difference between a corpus with anchors and a corpus that says it has them. The verification surface is therefore not a concession. It is the only form in which the age of a record can do any work for anyone other than its owner.\n\n### 5.1 One corpus, several servers, one answer\n\nA corpus is rarely served from one place. Ours is served from three: a local process reading a committed index, a package installed from a public registry, and a remote endpoint. Each is a separate deployment with its own cache, its own release cadence and its own opportunity to fall behind.\n\nThe envelope makes agreement between them **mechanically checkable rather than organisationally promised**:\n\n```\n  source repository   ──┐\n                        ├──►  digest 91a41c75…   identical\n  published package   ──┤                        across all\n                        │                        three surfaces\n  remote endpoint     ──┘\n```\n\nThis is a stronger guarantee than it first appears, and the reason is the failure mode of §3. A second surface that re-derives its own copy from the sources is *a second opinion about what a canonical text says*, and two opinions about a canonical text is one too many. The design that avoids it is unglamorous: downstream surfaces consume the **published artifact** at an exact pinned version rather than re-reading the sources, so they cannot disagree — not because they are kept in step, but because they are the same bytes.\n\n⚠️ **A version range would silently defeat this**, which is why the pin is exact. A range makes *which corpus is deployed* unanswerable, and the answer to that question is the only thing distinguishing a mirror from a fork.\n\nThe observation generalises past our deployment. **Any corpus with more than one serving surface has a currency problem, and the envelope converts it from a process question into an arithmetic one.** Ask each surface for the same document and compare digests. If they differ, the surfaces disagree; the anchors say which is older, and fetching the named source says which is current.\n\n## 6 · Provenance must be a gate, never a score\n\nThis is the refusal we consider most important, and it is the one most likely to be ignored by an adopter who is otherwise sympathetic.\n\nThe obvious next move, once documents carry provenance, is to **rank by it**: prefer better-anchored sources, weight retrieval by anchor depth, surface the well-attested and bury the rest. It is obvious, it is tempting, and it would be a serious mistake.\n\n**It manufactures a gradient where none should exist.** Anchor depth measures how long ago a document was committed and how much apparatus its publisher could afford. It does not measure whether the document is right. A ranking function over provenance therefore rewards *institutional capacity* and *age*, and does so under a name that sounds like it rewards *reliability*. The predictable outcome is a retrieval layer that systematically prefers well-funded old institutions to correct new ones, while appearing rigorous.\n\n**It creates the wrong incentive at the margin.** In a ranked world the way to be read more is to anchor more, not to be more accurate. That is a cheap thing to optimise and it is orthogonal to everything a reader wants.\n\n**And it re-creates a ratchet this corpus has argued against elsewhere at length.** A scored signal accumulates; an accumulated score becomes a position; a position becomes something to defend. The design that avoids all of it is the same one adopted in a different domain in *Whose Turn, Not Who's Best*:\n\n> **Provenance is an admission predicate, not a weighted input to a ranking function.**\n\nIt answers one question — *can this passage be checked?* — and its only output is membership. It carries no weight, contributes nothing to order, and has no more-or-less. A document with a five-year anchor and a document anchored this morning are, for retrieval purposes, in the same set.\n\n⭐ The distinction survives a hard case, which is how we know it is real. A reader may legitimately *care* that one anchor is older — for a priority dispute, age is the whole question. The rule is not that age is uninteresting. **It is that the retrieval layer must not decide on the reader's behalf what age means.** The envelope reports the anchor; the reader draws the inference. Moving that inference into a ranking function is precisely the substitution of the server's judgement for the reader's that §5 exists to reverse. A predicate the *reader* supplies — a version pin, a validity interval, an anchor-after date — is admission, not ranking, and the envelope exists to make such predicates checkable; what the layer must not do is rank by depth on the reader's behalf.\n\n## 7 · What this design refuses, and what the refusals cost\n\nA mechanism is best specified by what it will not do.\n\n**It will not summarise.** A retrieval server that returns a summary destroys the property, because a summary can be hashed but its hash binds it to nothing the reader can fetch and compare — the property destroyed is the binding to the named source, not hashability. Nothing prevents a *reader* from summarising; the refusal is that the server must not do it on the reader's behalf and call the result the document. **Cost:** larger responses, more context consumed, and a worse experience for readers who wanted a gist.\n\n**It will not serve an unlicensed document.** A licence that cannot be read from the artifact itself is not a licence the server can act on, and defaulting to open is the failure that cannot be undone after somebody builds on it. **Cost:** documents are silently excluded until someone declares them, and the exclusion is invisible to the reader who did not know to look.\n\n**It will not render absence.** The corpus has gaps, unfinished work, and material deliberately withheld. Nothing in the interface enumerates what is missing. This follows a constraint argued elsewhere in this corpus at length: *a surface that renders an absence has made an accusation.* **Cost:** a reader cannot distinguish \"not in the corpus\" from \"does not exist,\" and must not be encouraged to try.\n\n**It will not put the licence gate in the request path.** The gate belongs in the artifact — the served index — rather than in the code that answers queries, because a gate in the request path is a rule that a later refactor can route around, and a gate in the artifact is a property of the object. **Cost:** widening the corpus requires a rebuild, and a document cannot be served in an emergency.\n\n**It will not serve a document only partly in its author's voice without marking the boundary in the text itself.** Where a document contains both authored and drafted prose, a metadata field saying so is insufficient: a reader ingests text, forms a belief and quotes, and metadata does not travel with a quotation. The marker must be in the prose, so that a reader must *strip* it in order not to know, rather than *look* in order to know. **Cost:** the served text is not the rendered text, the annotation is intrusive, and this inverts the default without guaranteeing the outcome — a determined stripper still strips.\n\n## 8 · The generalisation: the same envelope over an append-only log\n\nThe mechanism above was designed for documents. It applies to a different object with almost no modification, and the application is sharper than the original.\n\nConsider a ledger: an append-only record of events, maintained by an institution, over which some function is computed and published. The institution asserts that the log is complete, that it has not been rewritten, and that the function is applied uniformly. These are exactly the assertions a reader has no instrument to check, and exactly the assertions an institution has every incentive to make sincerely and no mechanism to keep.\n\nAnchoring alone does not fix this, and the reason is worth stating because it is the most common error in the space. **A periodically anchored log gives tamper-evidence after the anchor and gives neither completeness nor append-only-ness.** An operator may anchor a root that omits entries — every inclusion proof for every included entry still verifies — and may rewrite freely between anchors. The properties that are actually wanted come from the Certificate Transparency design: signed tree heads, inclusion proofs, consistency proofs between heads, and gossip among independent observers to detect a split view.\n\nThe envelope of §4 applies directly, and produces a striking result:\n\n```\n  DOCUMENT RETRIEVAL                    LOG TRANSPARENCY\n  ──────────────────────────────────    ──────────────────────────────────\n  served:   text + envelope             served:   envelope ONLY\n  the payload is the text;              the payload IS the proof;\n  the envelope certifies it             there is no text to withhold\n\n  a reader verifies a passage           a reader verifies the SHAPE of the\n                                        log without seeing any entry\n\n  privacy: not at issue                 privacy: fully preserved — a signed\n  (the corpus is published)             tree head is not a person\n```\n\n⭐⭐ **For a log, serving the envelope alone is not a reduced offering. It is the complete public surface for the log's *integrity*** — inclusion, consistency, the published function — **and none of its *coverage*.** Whether every event that should have entered did is provable only against an external obligation — a receipt issued to the party whose event it is, the pattern of RFC 9943 — and a split view is caught only by gossip (§8.3). The claim a transparency log makes about its structure — that it is append-only, that it is consistent with what it showed you yesterday, that a given entry is in it — is entirely provable from tree heads and proofs, none of it requires disclosing a single entry's contents, and a reader who can fetch heads on a schedule and compare them with other readers has verified the institution's honesty about its own record without learning anything about anyone in it.\n\nThis matters for a specific institutional reason. A ledger of human conduct **must not** expose its contents to arbitrary query. A query interface over records of what people did is, whatever its intent, an interface over what people did *not* do — the negation of any query is constructible — and rendering an absence is an accusation. The transparency envelope resolves the tension completely rather than trading it off: **maximum verifiability of the log's integrity, zero disclosure of its contents.**\n\n### 8.1 The unresolved difference, stated rather than hidden\n\nCertificate Transparency logs never forget. That is correct for certificates and wrong for a record of human conduct, which must be able to release people from their past.\n\nThe two requirements appear to contradict: an append-only log cannot delete, and forgiveness appears to require deletion. **We believe the resolution is that forgiveness is an *entry* rather than an erasure** — a recorded, anchored, publicly consistent act of release, which is a stronger form of forgiveness than deletion because it is witnessed rather than merely effected, and which leaves the log's append-only property intact.\n\nWe state this as a position and not a solved problem. Whether a released party experiences a permanent record of their release as forgiveness is an empirical and ethical question that a Merkle tree does not answer, and we do not claim it does.\n\n### 8.2 Separation of powers, and why a transparency surface needs one\n\nA log with a published function over it has three distinct authorities, and conflating them is how a transparency claim becomes decorative.\n\n```\n  ROLE            MAY DO                          MAY NOT DO\n  ─────────────────────────────────────────────────────────────────────────\n  the writer      append entries                  alter or remove an entry;\n                                                  change the function\n\n  the function    publish the computation and     change it mid-period;\n  keeper          freeze it for a stated period   keep it secret\n\n  the reviser     change the function at a         change it silently, or\n                  scheduled, announced boundary    retroactively\n```\n\nThe point of the separation is not administrative tidiness. **It is that each of the three is separately checkable from outside, and only if they are separate.** If the party that appends entries can also change the function, then a published function proves nothing: an unfavourable reading can be repaired by rewriting the reading rather than the record, and every inclusion proof still verifies. If the function may change mid-period, then two readers who fetched it at different times cannot compare results and neither can tell why.\n\n⭐ **The function must be public and frozen within a period.** Not because secrecy would be dishonourable, but because a secret function makes the log's transparency vacuous: you can prove an entry is in a log whose meaning you cannot compute. **The transparency of the record and the transparency of the reading are separate properties, and a system with only the first has published a Merkle tree and called it accountability.**\n\n### 8.3 The gossip requirement, which is where most designs quietly fail\n\nA log operator can present different views to different observers — a *split view* — and every proof shown to each observer verifies. Nothing internal to the log detects this. The only detection is external: **independent observers compare signed tree heads, and a divergence between two heads that should be consistent is the evidence.**\n\nThis is well known in the CT literature and routinely omitted in practice, because gossip is the part that requires other people. A log with no gossiping observers has the *form* of transparency and none of the function.\n\nThe design consequence for an institution is uncomfortable and worth stating: **you cannot audit yourself.** A transparency log operated and monitored by one party proves that party's honesty to that party. The observers must be entities that would notice, and would say so, and are not you.\n\n⭐ This is where a machine-readable transparency surface earns its place rather than being a convenience. Gossip performed by humans on a schedule is gossip performed erratically and then not at all; every institution that has tried it has watched it decay into ceremony. **A surface that lets an observer's agent fetch a head and compare it on a timer converts gossip from a duty somebody must remember into a job something already does.** The check no longer depends on anyone's diligence at the moment it is tested — which is the same move, in a different domain, that this corpus argues for elsewhere as taking the guard from the object rather than from behaviour.\n\n### 8.4 What must never be served, and why the boundary is not a trade-off\n\nA ledger of human conduct invites an obvious feature: let readers query it. We refuse, and the refusal is not a balance struck between transparency and privacy. It is a recognition that **a query interface over conduct is an interface over the absence of conduct**, because the negation of any query is constructible.\n\n*Who gave in March* yields, by complement, *who did not give in March*. There is no version of the first that does not supply the second, and no access control that closes it while leaving the feature useful. A system whose stated purpose is to make appreciation visible cannot ship a surface whose complement is a register of the unappreciative.\n\nNor may the reading be exposed as a rate. A per-person figure computed over the log — however carefully framed — is a score, and a score is a ranking, and a ranking of persons is the thing the whole design exists to avoid. **The log may prove that it recorded a crossing; it must not publish how often anyone crossed.**\n\n⭐⭐ What makes this satisfying rather than merely restrictive is that the transparency surface loses **nothing** by the exclusion. Everything a reader needs in order to verify the log's integrity — inclusion, append-only-ness, consistency, the function — lives entirely in the proof structure; coverage is claimed against receipts, not contents. **The contents were never part of the integrity claim.** A design that had to trade verifiability against privacy would be a worse design; this one does not have to, and that it does not is the strongest evidence available that the boundary is drawn in the right place.\n\n\n## 9 · The claim, in its final and smaller form\n\nEverything above narrows to this:\n\n> **A retrieval response supplied to a machine reader should carry, alongside the served text, a binding of that text to a named and fetchable byte sequence, a digest of that sequence, an explicit statement of what the digest covers relative to what was served, at least one time anchor independent of the serving party or an explicit statement that none exists — never silence — and a runnable instruction for performing the check; and the same envelope, served without any payload, constitutes the complete public surface of an append-only log's integrity — its coverage being provable only against receipts held by the parties whose events they are.**\n\nThat is the whole of it. It is a composition of public primitives at a boundary where, so far as we can establish, they have not previously been composed in this form — the nearest is Proof-Carrying Answers (2025), which binds retrieved chunks to a signer's Merkle tree; the difference is the named fetchable source, the independent anchor, and the scope statement. We assert no rights over it and dedicate it to the public domain so that no one else may.\n\n## 10 · Pre-registered predictions\n\nRegistered before observation, in the corpus's standing format. A correction is a new entry, never an edit.\n\n**P-PCR1.** Within 24 months of publication, at least one widely-used retrieval or context protocol will add an optional provenance field to its resource representation. *Falsified if* no such field appears in any protocol with more than nominal adoption.\n\n**P-PCR2.** Verification rates will be low. Fewer than 5% of agent sessions that retrieve a document with a complete envelope will execute the verification instruction. *We predict this and publish anyway*, because the value of a check that can be run does not depend on its being run often — it depends on its being runnable when someone has reason. *Falsified if* observed verification exceeds 5%.\n\n**P-PCR3.** The first real defect caught by an envelope in our own corpus will be **staleness, not substitution.** *Falsified if* the first confirmed catch is an adversarial modification.\n\n**P-PCR4.** Scope confusion will be the most common implementation error in any third-party adoption: implementers will publish a digest of the source artifact while serving a derived rendering, without stating the difference. *Falsified if* the modal error is anything else.\n\n**P-PCR5.** For any transparency log we or others operate under §8, the first detected inconsistency will come from an automated comparison of tree heads rather than from a human noticing. *Falsified if* a human report precedes the first machine detection.\n\n**Corrections, 2026-09-05 — new entries under the rule above; the originals stand as registered.** Cold reviewers found that P-PCR3, P-PCR4 and P-PCR5 named no observation window, no definition of *real defect*, and no method for *modal error*, and could be reinterpreted after the fact.\n\n**P-PCR3a** (corrects P-PCR3). The first envelope mismatch logged by the operator's own verifier within 24 months of 2026-09-01 will be classified, at the time of logging, as *stale* (the named source resolves newer) rather than *substituted* (the source resolves different at the same version). *Falsified if* the first logged mismatch is classified substituted.\n\n**P-PCR4a** (corrects P-PCR4). Among the first ten third-party implementations we can inspect within 24 months of 2026-09-01, more will publish a source-artifact digest while serving a derived rendering than will commit any other single error. *Falsified if* another error class is more frequent among those ten.\n\n**P-PCR5a** (corrects P-PCR5). The first inconsistency detected in any transparency log operated under §8, within 24 months of that log's first published head, will be logged with its detector, and the detector will be an automated head comparison. *Falsified if* the logged detector is a human report.\n\n## 11 · What is actually deployed, stated so the reader can weigh the rest\n\nPapers about mechanisms are worth less when it is unclear which parts exist. As of publication:\n\n```\n  DEPLOYED                                          NOT DEPLOYED\n  ────────────────────────────────────────────────  ──────────────────────────\n  137 documents served with full envelopes          any ledger (§8 entirely)\n  137/137 carry a blockchain-anchored proof         any transparency log\n   68/137 carry a persistent identifier             any gossip arrangement\n  three serving surfaces, digest-identical          any second operator\n  two open licences, gated per document             any third-party adoption\n  one operator (us)\n```\n\nEach figure is checkable against the served index at corpus.333.eco, which carries every document's digest, identifier and anchor status; the index grows, and the figures are as of first publication (141 documents on 2026-09-05).\n\nThree observations from operating it, offered because they were not obvious in advance.\n\n**The scope error is real and we made it.** Our first envelopes carried a digest and an instruction to compare it against *the source file*, without naming which file or where. The digest covers the whole source artifact; the served text is its body. A reader who hashed what it was handed would have failed and concluded the corpus was lying. This was live before anyone noticed, and it was noticed by a question rather than by a check — which is why §4 makes scope and location obligations rather than niceties, and why P-PCR4 predicts it will be the modal error for adopters too.\n\n**Anchoring everything is what makes the envelope non-decorative.** We initially proposed to exclude a set of documents that had no proofs, on the grounds that entries whose envelope answers *nothing to check* would dilute the claim. The right resolution was not to exclude them but to anchor them — which cost one command. **A mixed corpus teaches readers to ignore the envelope; a complete one teaches them it means something.**\n\n**Partial authorship needed a mechanism, not a notice.** One genre in our corpus is only partly in its author's voice. A metadata field declaring this was the obvious answer and the wrong one: a reader ingests text, forms a belief and quotes, and a field does not travel with a quotation. The annotation had to go **into the prose**, so that a reader must strip it in order not to know rather than look in order to know. This inverts a default without guaranteeing an outcome, and §7 is explicit about the residue.\n\n## 12 · Honest limits\n\n**It proves bytes, not truth.** Stated in §4.1 and repeated because it is the misreading that would do the most damage.\n\n**It does not prove currentness.** A genuine, anchored, superseded version verifies perfectly; only fetching the named source distinguishes it, and nothing here obliges the source to declare its successor.\n\n**It requires public sources.** The strong form needs the anchored bytes to be fetchable by the reader. A private corpus can carry digests and anchors, but the reader cannot close the loop, and an unclosable instruction is worse than none — it implies a check that cannot be performed.\n\n**A determined reader can ignore all of it.** Every property here is available to a reader who chooses to use it and inert for one who does not. We inverted a default; we did not install a guarantee, and the inline-annotation refusal in §7 is explicit that stripping remains possible.\n\n**Anchors have failure modes we inherit.** A timestamp authority may be compromised or may cease to exist. A blockchain commitment depends on that chain's continued security. A transparency log may be operated dishonestly if nobody gossips. Combining independent anchors reduces correlated failure and does not eliminate it, and *we hold anchors in three families precisely because we do not trust any one of them.*\n\n**The verification instruction is a supply-chain surface.** An envelope that ships a command invites an agent to run a command. We ship instructions that fetch and hash, and nothing that executes fetched content, but the pattern is one an adversary would target and any adopter should treat the instruction field as untrusted input rather than as something to eval. The instruction is data from the same channel; nothing here checks its integrity, and a reader who executes it trusts the channel for that one step.\n\n**No field deployment.** At publication this exists over one corpus of 137 documents and one operator. §8 is entirely unbuilt: no ledger of ours is running, no tree head has ever been published, and every claim in that section is a design position rather than a report. The distinction between what we have done and what we have argued should be readable from the section headings, and if it is not, that is a defect in this paper.\n\n**We are not disinterested.** This institution has argued elsewhere that the provable age of a record is a durable competitive advantage. A mechanism that makes record-age checkable by outsiders is therefore convenient for us, and a reader should weight our enthusiasm accordingly. The mechanism's merits, if any, do not depend on our motives — which is itself an instance of the paper's argument.\n\n## 13 · Adversarial analysis and edge cases\n\nA mechanism that claims to reduce trust should say exactly whom it stops.\n\n### 13.1 What an adversary can and cannot do\n\n```\n  ADVERSARY POSITION          CAN THEY SUCCEED?     WHY\n  ────────────────────────────────────────────────────────────────────────────\n  Malicious server,           NO, if checked        the digest will not match\n  substitutes text                                  the anchored bytes\n\n  Malicious server,           YES                   nothing forces the reader\n  strips the envelope                               to demand one — see 12.2\n\n  Malicious server, serves    NO, if the reader     the anchor's timestamp\n  a genuine OLD version       fetches the source    predates the revision, and\n                                                    the named source resolves newer\n\n  Compromised timestamp       PARTIALLY             one anchor family falls;\n  authority                                         independent families do not\n\n  Publisher back-dating       NO                    a blockchain commitment\n  their own document                                cannot be created in the past\n\n  Publisher who anchors a     YES — and this is     an anchor proves existence,\n  document they later          the honest limit     never correctness\n  discover is wrong\n```\n\nThe last row is the one to sit with. **Provenance is entirely orthogonal to being right.** A carefully anchored falsehood verifies perfectly. The mechanism narrows the space of failures from *anything could have happened to this text* to *this is the text that was published*, and that is a real narrowing and a small one.\n\n### 13.2 The stripping problem, stated without a solution\n\nNothing compels a retrieval layer to pass an envelope through to the model. An intermediary that summarises, re-chunks, or re-serves can drop it silently, and the model then receives text with no indication that provenance ever existed.\n\nWe do not have a fix, and we distrust the fixes we can imagine. **Requiring** envelopes would need an enforcer at every hop. **Signing the response** authenticates the server rather than the document and moves the problem one step. **Refusing to serve to intermediaries that strip** is unenforceable and would break legitimate caching.\n\nWhat we can say is narrow: the envelope should be structured so that *dropping it is a visible omission rather than an invisible default* — a response with no provenance block should be recognisably different from a response with an empty one. That is a convention, not a guarantee, and we mark it as such.\n\n### 13.3 Edge cases the envelope must handle without lying\n\n**Revised since deposit.** A document may legitimately have been revised after its persistent identifier was minted. The current digest and the deposited digest then differ *correctly*, and an envelope that hides this is worse than one that omits both. It must report both and say which the identifier resolves to.\n\n**Derived renderings.** Where the served text is an extraction from a different source format, the digest covers the source and not the rendering. The envelope must mark the text as derived and name the transformation, or a reader will hash the rendering, fail, and distrust the corpus for being honest.\n\n**Documents with no anchor.** Some legitimate documents have none — too new, or from a publisher without the apparatus. The envelope must be able to say *no anchor* without the reader mistaking it for a failed check. **⚠️ And a corpus in which some documents are anchored and others are not is in a worse position than one in which none are**, because the envelope starts reading as decorative. Either anchor everything served, or be explicit that the corpus is mixed.\n\n**Multi-part and excerpted responses.** A search result returning an excerpt cannot honestly present a whole-document digest as covering the excerpt. It must present the digest as covering the document from which the excerpt came, and say so.\n\n### 13.4 What this must never become\n\nWe list these because each is a plausible next feature and each would negate the design.\n\n- ⛔ **A trust score.** See §6.\n- ⛔ **A registry of approved publishers.** Provenance is a property of a document, checkable by anyone; a whitelist is a property of a relationship, checkable by no one.\n- ⛔ **A revocation channel.** A mechanism that can un-publish is a mechanism that can be compelled to un-publish. Supersession is an additional publication, never a deletion — the same argument as §8.1.\n- ⛔ **A reason to serve less text.** If the envelope ever becomes an excuse to return summaries because they are cheaper, the mechanism has been inverted into the thing it was built against.\n\n## 14 · Cross-venue references\n\n- *Appreciation as World-Building* — the general argument that a guard should be a property of an object rather than a rule about behaviour, of which this paper's §6 refusals are instances.\n- *B-PoH: The Humanity Layer for an AI-Native Internet* — the personhood layer; orthogonal to this paper, which authenticates *documents* and says nothing about *parties*.\n- *Buddha AI and the Living Tipiṭaka* §8 — what makes a canon authoritative. This paper asks the narrower and more tractable question of what makes a *copy* checkable.\n- *The Borrowable Standard* — why a corpus that must be authoritative in its own language cannot normalise toward another's; the same concern for canonical form, one layer down.\n- *Whose Turn, Not Who's Best* — the refusal to render an absence, argued in a different domain and inherited here.\n\n## Coda\n\nThe Kālāmas were not told what to believe. They were told how to proceed in the absence of a reason to believe anyone, and the procedure amounted to: **do not accept a thing because of the channel it came through.**\n\nA model has no way to follow that instruction. Its channel is all it has. The most we can do — and the whole of what this paper proposes — is to make the channel carry the means of its own doubting, so that a reader inclined to check is not defeated by the format.\n\nWe do not expect most readers to check. We expect the number to be small enough to embarrass the mechanism, and we have pre-registered that prediction rather than discovering it later. The point was never that the check would be performed often. It is that a corpus which cannot be checked at all is asking for a kind of faith that a machine cannot give and should not be asked for — and that an institution which intends to hand its reasoning to a successor it will not live to meet had better hand over the instrument along with the text.\n\n---\n\n*This document's SHA-256 is attested independently of the site and its authors — anchored to the Bitcoin blockchain via OpenTimestamps and signed under RFC 3161 by three timestamp authorities in three jurisdictions, one of them eIDAS-qualified — and each revision carries a Zenodo version; a timestamp proves this exact text existed no later than its date and nothing about authorship, originality, or the validity of any claim.*",
+      "text": "> **Claim-scoped by design.** This paper publishes the *claim* and withholds the *spec*. It states what a retrieval response must carry and why, and it does not give endpoint shapes, manifest schemas, transport bindings or tool surfaces. That is not coyness about a trade secret — every primitive here is someone else's, and all of them are public. It is the institution's standing rule that a complete implementable design for something unbuilt is a blueprint rather than a fence, and the ledger half of this paper is unbuilt. Publication protects against being *blocked*, not against being *beaten*.\n>\n> Companion works: *Appreciation as World-Building* (where the property-over-rule argument is made in general), *B-PoH: The Humanity Layer for an AI-Native Internet*, *Buddha AI and the Living Tipiṭaka* (whose §8 asks what makes a canon authoritative; this paper asks the narrower question of what makes a *copy* of it checkable), and *The Borrowable Standard*.\n\n## Preamble\n\nThere is a discourse in the Pāli canon (AN 3.65, the *Kesamutti Sutta*) in which a people called the Kālāmas tell a teacher that many teachers pass through their town, each praising his own doctrine and tearing down the others, and they no longer know whom to believe. The reply they receive is not a better doctrine. It is a procedure: *do not go by report, by tradition, by hearsay, by the authority of texts, by logic, by inference, by appearance, by agreement with a considered opinion, by seeming competence, or because the ascetic is our teacher.*\n\nThe passage is usually read as an invitation to scepticism. Read as engineering, it is something more specific and more useful: it is a refusal to accept a claim **on the strength of the channel it arrived over.** The Kālāmas' problem was not that the teachers were lying. It was that nothing about a teacher passing through town distinguishes one who is right from one who is merely fluent, and the villagers had no instrument.\n\nA language model reading a retrieved document is in the Kālāmas' position, with one difference that makes it worse. A villager can at least walk to the next town and ask. A model takes what the channel delivered, and nothing about a plausible-looking response distinguishes canonical text from a paraphrase, a truncation, a substitution, or an earlier version withdrawn for being wrong.\n\nThis paper describes what a retrieval response would have to carry for that gap to close, and it claims no originality in any of its parts. The primitives are borrowed entire — content addressing from version control, timestamping from RFC 3161 and OpenTimestamps, transparency logs from Certificate Transparency, build attestation from Sigstore and in-toto. What is new, so far as we can establish, is the composition and its target: **the retrieval boundary between a corpus and a machine reader, at the moment of citation.**\n\nWe publish it defensively, under CC0, so that nobody may enclose it.\n\n## Prior-Art and Non-Assertion Statement\n\nThis document is dedicated to the public domain under CC0 1.0 Universal. Its purpose is to establish prior art. The author and HeartBank® will not seek patent on any mechanism described here, in any jurisdiction, at any time.\n\nThe building blocks are prior art already, and we name them precisely so that no reader mistakes our composition for a claim over the parts:\n\n- **Content addressing** — identifying a byte sequence by its cryptographic digest. Ubiquitous; Git, IPFS, and most package managers' integrity fields.\n- **RFC 3161 Time-Stamp Protocol** — a trusted authority's signed assertion that a digest existed before a moment.\n- **OpenTimestamps** — aggregation of digests into a Merkle tree whose root is committed to the Bitcoin blockchain, converting an authority's assertion into a proof-of-work-anchored one.\n- **RFC 6962 / RFC 9162, Certificate Transparency** — append-only Merkle logs with signed tree heads, inclusion proofs, consistency proofs, and gossip among independent monitors.\n- **Sigstore, Fulcio, Rekor** — keyless signing with short-lived certificates and a public transparency log of signatures.\n- **SLSA and in-toto** — attestation formats binding an artifact digest to the build that produced it.\n- **W3C PROV-O, PREMIS** — provenance vocabularies for describing derivation and custody.\n- **LOCKSS, Memento (RFC 7089), Software Heritage** — replication and temporal access to published works.\n- **C2PA / Content Credentials** — signed provenance manifests bound to media assets, addressing capture-and-edit chains for images, audio and video.\n- **DOI and DataCite** — persistent identifiers with resolution and metadata.\n- **SCITT (RFC 9943) and COSE receipts (RFC 9942)** — signed statements registered in a transparency service, receipts issued to the registering party, and newer-version and end-of-life statements.\n- **Software Heritage SWHIDs** — intrinsic identifiers that can qualify a sub-part of an archived object.\n- **The Model Context Protocol** — a published, open protocol for supplying context and tools to language models.\n\n**We assert no rights over any of these.** The claim in §9 is deliberately narrow, and it is smaller than the paper that surrounds it.\n\n## Abstract\n\nA retrieval system that supplies text to a language model is, at present, an authority. It says *here is the passage*, and the model has no instrument with which to disagree. The failure this produces is not usually fabrication — it is quieter: a superseded version served as current, a truncation that inverts a qualified claim, a paraphrase that drifts, or a substitution somewhere between the corpus and the context window. Each of these produces a citation that is confidently wrong and locally unfalsifiable.\n\nWe describe **provenance-carrying retrieval**: a response format in which every served document is accompanied by an envelope binding it to (a) a cryptographic digest **of a named, fetchable source**, (b) at least one **independent time anchor**, and (c) where one exists, a **citable identifier**; together with an explicit statement of what the digest covers and a runnable instruction for checking it.\n\nThe composition has one structural consequence, and it is the paper's centre. **It inverts the trust burden.** Ordinarily a retrieval server asks to be believed and the reader may, at best, decline. A response that carries the means of its own falsification asks to be *checked*, and a reader who declines to check has made a choice rather than suffered a limitation.\n\nWe then generalise. The same envelope applies to an **append-only log**, and there the generalisation is sharper than the original: for a log, the proof structure *is* the entire public payload. A ledger's transparency surface can be served in full — signed tree heads, inclusion proofs, consistency proofs, the published scoring function — while its *contents* are never served at all. This is not a diminished version of document retrieval. It is the complete version for that object, and it is what lets a transparency claim be verified continuously by machine rather than asserted periodically by an institution.\n\nWe state honest limits at length. The mechanism does not establish truth, authorship, or good faith. It establishes only that the bytes you were handed are the bytes that were anchored, and that they were anchored before a certain moment. Every other virtue must be argued separately.\n\n## 1 · Why this problem is the institution's problem\n\nThis institution has spent five years building a corpus whose stated audience is not primarily human.\n\nThe research corpus — mechanism papers, defensive publications, institutional positions — is written for an autonomous successor who does not exist yet, on the understanding that specifications decay and reasoning does not, and that a machine which inherits a set of refusals without the arguments that produced them will keep the refusals it does not understand and drop the ones it does. Density is up, hand-holding is down, honesty is up. It is a strange way to write, and it is deliberate.\n\nAn institution that writes for a machine reader eventually has to ask how the machine reads. The answer, currently, is: over a channel, on trust. The corpus is served as web pages, as a machine-readable index, and now over a retrieval protocol — and at every one of those boundaries the reader takes what it is given. Having taken care that a successor inherits reasoning rather than conclusions, we would be careless to hand that reasoning over a channel in which a single stale copy is indistinguishable from a current one.\n\nThere is a second reason, and it is less comfortable. **We have the anchors already.** Every document in the corpus carries a digest committed to a public blockchain and countersigned by independent timestamp authorities, because the defensive-publication strategy required provable dates long before anyone was retrieving anything. That apparatus was built for a legal purpose. It turns out to be the exact material a retrieval envelope needs, and having it sitting unused behind a website while serving the same documents on bare trust is the kind of waste that is invisible until it is named.\n\nThe third reason belongs to a claim we make elsewhere. The institution's durable advantage has been argued to be **the provable age of a record and the canonical standing of a reading of it**, rather than any secret. If that is true, then a surface which lets an outside party *check* the age is not a giveaway. It is the argument, made in the only form that does not require taking our word for it.\n\n## 2 · Background and prior art, engaged generously\n\nThe literature this paper stands on is mature, and none of it is ours.\n\n**Software supply chain.** The last decade of supply-chain security produced the closest analogue to what we describe. SLSA defines levels of build integrity; in-toto defines attestations linking artifacts to the steps that made them; Sigstore issues short-lived certificates bound to workload identity and records signatures in Rekor, a public transparency log. The mature form of the idea is: *do not ask whether you trust the publisher, ask whether the artifact's digest appears in a log you can audit.* That is precisely the move this paper transposes. **The difference in target is the whole of our contribution:** supply-chain attestation binds a *build* to a *source tree*; we bind a *retrieved passage* to a *published document*. The consumer differs too — a package manager verifies once at install; a language model verifies at the moment of quotation, which is a different moment with different failure modes.\n\n**Certificate Transparency.** RFC 6962 and its successor establish the design pattern for public append-only logs: Merkle tree structure, signed tree heads, inclusion proofs for individual entries, consistency proofs between heads, and gossip among independent parties to detect a log presenting different views to different observers. CT is the direct ancestor of §8 and we claim nothing over it. The observation we add there is narrow and, we believe, unstated: **a CT log never deletes an entry, and a ledger of human conduct must be able to release.**\n\n**Archival provenance.** PREMIS and W3C PROV-O give vocabularies for custody and derivation; LOCKSS gives replication; Memento gives temporal access; Software Heritage gives durable archival of source. The archival community has thought about this longer and more carefully than the machine-learning community has, and their conclusion is one we adopt: **provenance is metadata about a specific byte sequence, and loses its meaning the moment the byte sequence is normalised, re-encoded, or excerpted without saying so.** §4's insistence on naming *what the digest covers* is theirs, not ours. They were not the first to face the problem either: a canon transmitted for roughly four centuries with no written copy, no living author to arbitrate and its schools already dividing — the Theravāda Pāli canon — left copy-integrity mechanisms that most resemble the archival ones, built against a different threat (loss and drift rather than substitution), and what they secured was divergence made detectable, never divergence prevented. *The Reciters' Protocol* sets out seven of those mechanisms, which of them carry over to a retrieval system, and where the two threat models part.\n\n**Content Credentials (C2PA).** The nearest adjacent work. C2PA binds signed provenance manifests to media assets, recording capture device, edits, and chain of custody, and it is being deployed against synthetic-media risk. Two differences matter. C2PA's threat model is *the deceptive edit* — an image altered to mislead — and its manifests are typically embedded in the asset, though the specification also allows external ones. Ours is *the stale or truncated retrieval*, which involves no adversary at all and usually no edit: the most common failure is an honest system serving an old version. And our envelope travels with a retrieval *response* rather than with an asset, because the artifact is prose that will be quoted in fragments. What travels is a pointer to bytes that can be re-fetched.\n\n**Retrieval-augmented generation.** The RAG literature is large and largely concerned with *relevance*: chunking, embedding, reranking, whether the retrieved passage answers the question. Verification appears in that literature as *attribution* — did the model's output follow from the retrieved context — which is a question about the model's faithfulness to its context. **We are asking the prior question: was the context itself what it claimed to be.** A perfectly faithful model grounded in a superseded document produces a confidently wrong citation, and no amount of attribution scoring detects it, because the model was faithful. The exceptions are named here. *Proof-Carrying Answers* (Shukla & Joshi, ACSAC Workshops 2025) has every retrieved chunk carry a hash, a signature and a Merkle proof verified before the answer admits it — the nearest prior work, and the difference is the named fetchable source, the anchor independent of the signer, and the scope statement. SCITT (RFC 9943) gives a transparency service newer-version and end-of-life statements, which is what would give §13.1's staleness row a source-side answer. Software Heritage's SWHIDs qualify a sub-part of an archived object, which is the scope obligation done at the identifier.\n\n**The Model Context Protocol.** MCP standardises how context and tools reach a model. It is the transport this work happens to use and is orthogonal to the claim: nothing here depends on MCP, and the envelope would apply unchanged to any retrieval interface. We name it because it is the surface on which the idea is most likely to be re-invented, and because a published protocol is where enclosure attempts land.\n\n## 3 · The asymmetry: what a machine reader cannot do\n\nA human scholar handed a suspicious quotation has recourse. They can find another edition, ask a colleague, check the pagination, notice that the prose does not sound like the author, or walk to a library. Most of this recourse is not procedural. It is the accumulated redundancy of being embedded in a world that contains the document in more than one place.\n\nA model has none of it. Its entire epistemic access to the document is the string in its context window. This produces four failure modes, and it is worth separating them because they have different frequencies and different fixes:\n\n```\n  FAILURE                WHAT IT LOOKS LIKE            DETECTABLE FROM THE TEXT?\n  ─────────────────────────────────────────────────────────────────────────────\n  Staleness              a superseded claim, cited     no from the text alone —\n                         as current                    it reads as correct because\n                                                       it once was; YES by fetching\n                                                       the named source (staleness\n                                                       OF the source: no)\n\n  Truncation             a qualified claim served      no — the qualification is\n                         without its qualification         simply not there\n\n  Paraphrase drift       a summary presented as        sometimes — if the reader\n                         canonical text                    has seen the original\n\n  Substitution           different text served under   no — by construction\n                         a correct-looking identity\n```\n\n**Staleness is the common case, and it is the one the field under-weights.** The literature is preoccupied with adversarial substitution, which is rare and requires an attacker. Staleness requires nobody: a corpus is revised, a cache is not invalidated, and a server continues answering correctly-shaped questions with text that was true last quarter. In our own estate we have watched four repositories sit three versions behind a shared layer while every integrity check reported green — because each was internally consistent, and *integrity is not currency.*\n\n⚠️ **And a stale document is worse than an absent one in exactly the situation this paper addresses**, because it is checkable and the check passes. An envelope computed over the served bytes will verify perfectly against those bytes. The reader is given every reason to believe, and no mechanism to discover it is quoting a withdrawn claim. **This is the failure that makes the naive version of our own idea dangerous**, and §4 is shaped around it.\n\n## 4 · The mechanism, stated as a claim rather than a specification\n\nA response carries, alongside the text, an envelope with four obligations. We give the obligations and not their encoding.\n\n```\n  ┌─────────────────────────────────────────────────────────────────┐\n  │  SERVED TEXT            the passage, verbatim                    │\n  ├─────────────────────────────────────────────────────────────────┤\n  │  ENVELOPE                                                        │\n  │                                                                  │\n  │   1. DIGEST      a cryptographic hash                            │\n  │   2. SCOPE       an explicit statement of WHAT the digest         │\n  │                  covers — and whether that is the served text     │\n  │   3. LOCATION    a fetchable address for the covered bytes        │\n  │   4. ANCHOR      ≥1 independent commitment that the digest        │\n  │                  existed before a stated time — or an explicit    │\n  │                  statement that none exists; never silence        │\n  │                                                                  │\n  │   +  IDENTIFIER  a citable persistent id, where one exists        │\n  │   +  LICENCE     terms, and any attribution actually owed         │\n  │   +  INSTRUCTION the command that performs the check              │\n  └─────────────────────────────────────────────────────────────────┘\n```\n\nFour of these are load-bearing in ways that are easy to get wrong.\n\n**Scope is the one everybody omits, and omitting it is fatal.** A served passage is very rarely byte-identical to the artifact that was anchored: the artifact has front matter, or a wrapper, or an encoding, and the passage is a body, an excerpt, or a rendering. If the envelope does not say so, a diligent reader hashes what it was given, fails to reproduce the digest, and concludes the corpus is lying — punishing exactly the reader the mechanism was built for. **The envelope must state whether the digest covers the served text, and when it does not, it must say what it does cover.**\n\n**Location converts an instruction into an instruction.** An envelope that says *compare this digest to the source file* without naming the file is not a procedure; it is a gesture at one. The covered bytes must be fetchable by the reader, which in practice means the source is published somewhere durable. This is a real constraint and it excludes private corpora from the strong form of the claim.\n\n**The anchor must be independent of the server.** A digest signed by the same party that served the text establishes nothing that party's word did not already establish. Independence is what makes the anchor evidence, and it admits several forms — a blockchain commitment, an RFC 3161 authority, a transparency log, a third-party archive — which are usefully combined, because they fail differently. A timestamp authority can be compromised; a blockchain cannot be reorganised at depth without a cost that scales with the chain's proof of work; a transparency log can be audited by parties who do not trust its operator.\n\n**The instruction is not decoration.** Publishing a digest and expecting the reader to know what to do with it assumes a reader who already knows. Carrying the exact command collapses verification from a research project to a paste, and — this is the part that matters — it means the claim in the envelope is itself checkable, rather than a sentence the reader must take on faith. *The envelope should not ask to be trusted about trust.* Illustratively, for a source published as a file — fetch it, hash it, compare, then verify the anchor:\n\n```\ncurl -sL <location> | sha256sum      # compare with the envelope's digest\nots verify <location>.ots            # the OpenTimestamps anchor\n```\n\nThe encoding of the instruction is not specified here; the example is what a check looks like, not what the field must contain.\n\n### 4.1 What the mechanism does **not** do\n\nIt does not establish that the document is true, that its author is who it says, that it was written when it says, or that it is worth reading. It establishes exactly one thing:\n\n> **These bytes are the bytes that were anchored, and they were anchored before a stated moment.**\n\nA second thing follows from the location obligation, and it is the reader's to do: the reader can fetch the named source *now* and compare, which is how staleness relative to that source is caught. Nothing here obliges the source to declare its successor.\n\nEverything else — authorship, veracity, authority, good faith — must be argued on other grounds. We are emphatic about this because provenance mechanisms are routinely oversold into implying authenticity, and a reader who takes a verified digest as a verified claim has been made *more* credulous by a mechanism intended to make them less so.\n\n## 5 · The inversion, which is the actual contribution\n\nEverything above is composition of known parts. The property that composition produces is the paper's claim to say something.\n\n```\n  BEFORE                                AFTER\n  ──────────────────────────────────    ──────────────────────────────────\n  The server asserts.                   The server exposes.\n  The reader may decline to believe,    The reader may check, cheaply,\n  but has no instrument.                with a named procedure.\n\n  Declining is a posture.               Declining is a decision.\n  Trust is the default and the          Checking is available and the\n  only option.                          default is a choice.\n```\n\nThe distinction is not rhetorical. A retrieval server that asserts is, in the strict sense, an **authority**: its claims are accepted because of what it is. A server that exposes is a **witness**: its claims are accepted because of what can be confirmed. The difference shows up precisely when the two diverge — when the server is wrong. An authority that is wrong propagates; a witness that is wrong is caught by the first reader who bothers. What remains trusted is the channel's willingness to pass the envelope at all (§13.2); everything inside it is checkable against parties the channel does not control.\n\n⭐ There is a consequence for the institution that is worth stating plainly, because it looks like generosity and is not. **A corpus that hands over the means to doubt it is harder to impersonate than one that does not.** A competitor may copy every document — ours are CC0 and copying is invited — but they cannot copy an anchor that is five years deep in a blockchain, and a reader with an instrument can tell the difference between a corpus with anchors and a corpus that says it has them. The verification surface is therefore not a concession. It is the only form in which the age of a record can do any work for anyone other than its owner.\n\n### 5.1 One corpus, several servers, one answer\n\nA corpus is rarely served from one place. Ours is served from three: a local process reading a committed index, a package installed from a public registry, and a remote endpoint. Each is a separate deployment with its own cache, its own release cadence and its own opportunity to fall behind.\n\nThe envelope makes agreement between them **mechanically checkable rather than organisationally promised**:\n\n```\n  source repository   ──┐\n                        ├──►  digest 91a41c75…   identical\n  published package   ──┤                        across all\n                        │                        three surfaces\n  remote endpoint     ──┘\n```\n\nThis is a stronger guarantee than it first appears, and the reason is the failure mode of §3. A second surface that re-derives its own copy from the sources is *a second opinion about what a canonical text says*, and two opinions about a canonical text is one too many. The design that avoids it is unglamorous: downstream surfaces consume the **published artifact** at an exact pinned version rather than re-reading the sources, so they cannot disagree — not because they are kept in step, but because they are the same bytes.\n\n⚠️ **A version range would silently defeat this**, which is why the pin is exact. A range makes *which corpus is deployed* unanswerable, and the answer to that question is the only thing distinguishing a mirror from a fork.\n\nThe observation generalises past our deployment. **Any corpus with more than one serving surface has a currency problem, and the envelope converts it from a process question into an arithmetic one.** Ask each surface for the same document and compare digests. If they differ, the surfaces disagree; the anchors say which is older, and fetching the named source says which is current.\n\n## 6 · Provenance must be a gate, never a score\n\nThis is the refusal we consider most important, and it is the one most likely to be ignored by an adopter who is otherwise sympathetic.\n\nThe obvious next move, once documents carry provenance, is to **rank by it**: prefer better-anchored sources, weight retrieval by anchor depth, surface the well-attested and bury the rest. It is obvious, it is tempting, and it would be a serious mistake.\n\n**It manufactures a gradient where none should exist.** Anchor depth measures how long ago a document was committed and how much apparatus its publisher could afford. It does not measure whether the document is right. A ranking function over provenance therefore rewards *institutional capacity* and *age*, and does so under a name that sounds like it rewards *reliability*. The predictable outcome is a retrieval layer that systematically prefers well-funded old institutions to correct new ones, while appearing rigorous.\n\n**It creates the wrong incentive at the margin.** In a ranked world the way to be read more is to anchor more, not to be more accurate. That is a cheap thing to optimise and it is orthogonal to everything a reader wants.\n\n**And it re-creates a ratchet this corpus has argued against elsewhere at length.** A scored signal accumulates; an accumulated score becomes a position; a position becomes something to defend. The design that avoids all of it is the same one adopted in a different domain in *Whose Turn, Not Who's Best*:\n\n> **Provenance is an admission predicate, not a weighted input to a ranking function.**\n\nIt answers one question — *can this passage be checked?* — and its only output is membership. It carries no weight, contributes nothing to order, and has no more-or-less. A document with a five-year anchor and a document anchored this morning are, for retrieval purposes, in the same set.\n\n⭐ The distinction survives a hard case, which is how we know it is real. A reader may legitimately *care* that one anchor is older — for a priority dispute, age is the whole question. The rule is not that age is uninteresting. **It is that the retrieval layer must not decide on the reader's behalf what age means.** The envelope reports the anchor; the reader draws the inference. Moving that inference into a ranking function is precisely the substitution of the server's judgement for the reader's that §5 exists to reverse. A predicate the *reader* supplies — a version pin, a validity interval, an anchor-after date — is admission, not ranking, and the envelope exists to make such predicates checkable; what the layer must not do is rank by depth on the reader's behalf.\n\n## 7 · What this design refuses, and what the refusals cost\n\nA mechanism is best specified by what it will not do.\n\n**It will not summarise.** A retrieval server that returns a summary destroys the property, because a summary can be hashed but its hash binds it to nothing the reader can fetch and compare — the property destroyed is the binding to the named source, not hashability. Nothing prevents a *reader* from summarising; the refusal is that the server must not do it on the reader's behalf and call the result the document. **Cost:** larger responses, more context consumed, and a worse experience for readers who wanted a gist.\n\n**It will not serve an unlicensed document.** A licence that cannot be read from the artifact itself is not a licence the server can act on, and defaulting to open is the failure that cannot be undone after somebody builds on it. **Cost:** documents are silently excluded until someone declares them, and the exclusion is invisible to the reader who did not know to look.\n\n**It will not render absence.** The corpus has gaps, unfinished work, and material deliberately withheld. Nothing in the interface enumerates what is missing. This follows a constraint argued elsewhere in this corpus at length: *a surface that renders an absence has made an accusation.* **Cost:** a reader cannot distinguish \"not in the corpus\" from \"does not exist,\" and must not be encouraged to try.\n\n**It will not put the licence gate in the request path.** The gate belongs in the artifact — the served index — rather than in the code that answers queries, because a gate in the request path is a rule that a later refactor can route around, and a gate in the artifact is a property of the object. **Cost:** widening the corpus requires a rebuild, and a document cannot be served in an emergency.\n\n**It will not serve a document only partly in its author's voice without marking the boundary in the text itself.** Where a document contains both authored and drafted prose, a metadata field saying so is insufficient: a reader ingests text, forms a belief and quotes, and metadata does not travel with a quotation. The marker must be in the prose, so that a reader must *strip* it in order not to know, rather than *look* in order to know. **Cost:** the served text is not the rendered text, the annotation is intrusive, and this inverts the default without guaranteeing the outcome — a determined stripper still strips.\n\n## 8 · The generalisation: the same envelope over an append-only log\n\nThe mechanism above was designed for documents. It applies to a different object with almost no modification, and the application is sharper than the original.\n\nConsider a ledger: an append-only record of events, maintained by an institution, over which some function is computed and published. The institution asserts that the log is complete, that it has not been rewritten, and that the function is applied uniformly. These are exactly the assertions a reader has no instrument to check, and exactly the assertions an institution has every incentive to make sincerely and no mechanism to keep.\n\nAnchoring alone does not fix this, and the reason is worth stating because it is the most common error in the space. **A periodically anchored log gives tamper-evidence after the anchor and gives neither completeness nor append-only-ness.** An operator may anchor a root that omits entries — every inclusion proof for every included entry still verifies — and may rewrite freely between anchors. The properties that are actually wanted come from the Certificate Transparency design: signed tree heads, inclusion proofs, consistency proofs between heads, and gossip among independent observers to detect a split view.\n\nThe envelope of §4 applies directly, and produces a striking result:\n\n```\n  DOCUMENT RETRIEVAL                    LOG TRANSPARENCY\n  ──────────────────────────────────    ──────────────────────────────────\n  served:   text + envelope             served:   envelope ONLY\n  the payload is the text;              the payload IS the proof;\n  the envelope certifies it             there is no text to withhold\n\n  a reader verifies a passage           a reader verifies the SHAPE of the\n                                        log without seeing any entry\n\n  privacy: not at issue                 privacy: fully preserved — a signed\n  (the corpus is published)             tree head is not a person\n```\n\n⭐⭐ **For a log, serving the envelope alone is not a reduced offering. It is the complete public surface for the log's *integrity*** — inclusion, consistency, the published function — **and none of its *coverage*.** Whether every event that should have entered did is provable only against an external obligation — a receipt issued to the party whose event it is, the pattern of RFC 9943 — and a split view is caught only by gossip (§8.3). The claim a transparency log makes about its structure — that it is append-only, that it is consistent with what it showed you yesterday, that a given entry is in it — is entirely provable from tree heads and proofs, none of it requires disclosing a single entry's contents, and a reader who can fetch heads on a schedule and compare them with other readers has verified the institution's honesty about its own record without learning anything about anyone in it.\n\nThis matters for a specific institutional reason. A ledger of human conduct **must not** expose its contents to arbitrary query. A query interface over records of what people did is, whatever its intent, an interface over what people did *not* do — the negation of any query is constructible — and rendering an absence is an accusation. The transparency envelope resolves the tension completely rather than trading it off: **maximum verifiability of the log's integrity, zero disclosure of its contents.**\n\n### 8.1 The unresolved difference, stated rather than hidden\n\nCertificate Transparency logs never forget. That is correct for certificates and wrong for a record of human conduct, which must be able to release people from their past.\n\nThe two requirements appear to contradict: an append-only log cannot delete, and forgiveness appears to require deletion. **We believe the resolution is that forgiveness is an *entry* rather than an erasure** — a recorded, anchored, publicly consistent act of release, which is a stronger form of forgiveness than deletion because it is witnessed rather than merely effected, and which leaves the log's append-only property intact.\n\nWe state this as a position and not a solved problem. Whether a released party experiences a permanent record of their release as forgiveness is an empirical and ethical question that a Merkle tree does not answer, and we do not claim it does.\n\n### 8.2 Separation of powers, and why a transparency surface needs one\n\nA log with a published function over it has three distinct authorities, and conflating them is how a transparency claim becomes decorative.\n\n```\n  ROLE            MAY DO                          MAY NOT DO\n  ─────────────────────────────────────────────────────────────────────────\n  the writer      append entries                  alter or remove an entry;\n                                                  change the function\n\n  the function    publish the computation and     change it mid-period;\n  keeper          freeze it for a stated period   keep it secret\n\n  the reviser     change the function at a         change it silently, or\n                  scheduled, announced boundary    retroactively\n```\n\nThe point of the separation is not administrative tidiness. **It is that each of the three is separately checkable from outside, and only if they are separate.** If the party that appends entries can also change the function, then a published function proves nothing: an unfavourable reading can be repaired by rewriting the reading rather than the record, and every inclusion proof still verifies. If the function may change mid-period, then two readers who fetched it at different times cannot compare results and neither can tell why.\n\n⭐ **The function must be public and frozen within a period.** Not because secrecy would be dishonourable, but because a secret function makes the log's transparency vacuous: you can prove an entry is in a log whose meaning you cannot compute. **The transparency of the record and the transparency of the reading are separate properties, and a system with only the first has published a Merkle tree and called it accountability.**\n\n### 8.3 The gossip requirement, which is where most designs quietly fail\n\nA log operator can present different views to different observers — a *split view* — and every proof shown to each observer verifies. Nothing internal to the log detects this. The only detection is external: **independent observers compare signed tree heads, and a divergence between two heads that should be consistent is the evidence.**\n\nThis is well known in the CT literature and routinely omitted in practice, because gossip is the part that requires other people. A log with no gossiping observers has the *form* of transparency and none of the function.\n\nThe design consequence for an institution is uncomfortable and worth stating: **you cannot audit yourself.** A transparency log operated and monitored by one party proves that party's honesty to that party. The observers must be entities that would notice, and would say so, and are not you.\n\n⭐ This is where a machine-readable transparency surface earns its place rather than being a convenience. Gossip performed by humans on a schedule is gossip performed erratically and then not at all; every institution that has tried it has watched it decay into ceremony. **A surface that lets an observer's agent fetch a head and compare it on a timer converts gossip from a duty somebody must remember into a job something already does.** The check no longer depends on anyone's diligence at the moment it is tested — which is the same move, in a different domain, that this corpus argues for elsewhere as taking the guard from the object rather than from behaviour.\n\n### 8.4 What must never be served, and why the boundary is not a trade-off\n\nA ledger of human conduct invites an obvious feature: let readers query it. We refuse, and the refusal is not a balance struck between transparency and privacy. It is a recognition that **a query interface over conduct is an interface over the absence of conduct**, because the negation of any query is constructible.\n\n*Who gave in March* yields, by complement, *who did not give in March*. There is no version of the first that does not supply the second, and no access control that closes it while leaving the feature useful. A system whose stated purpose is to make appreciation visible cannot ship a surface whose complement is a register of the unappreciative.\n\nNor may the reading be exposed as a rate. A per-person figure computed over the log — however carefully framed — is a score, and a score is a ranking, and a ranking of persons is the thing the whole design exists to avoid. **The log may prove that it recorded a crossing; it must not publish how often anyone crossed.**\n\n⭐⭐ What makes this satisfying rather than merely restrictive is that the transparency surface loses **nothing** by the exclusion. Everything a reader needs in order to verify the log's integrity — inclusion, append-only-ness, consistency, the function — lives entirely in the proof structure; coverage is claimed against receipts, not contents. **The contents were never part of the integrity claim.** A design that had to trade verifiability against privacy would be a worse design; this one does not have to, and that it does not is the strongest evidence available that the boundary is drawn in the right place.\n\n\n## 9 · The claim, in its final and smaller form\n\nEverything above narrows to this:\n\n> **A retrieval response supplied to a machine reader should carry, alongside the served text, a binding of that text to a named and fetchable byte sequence, a digest of that sequence, an explicit statement of what the digest covers relative to what was served, at least one time anchor independent of the serving party or an explicit statement that none exists — never silence — and a runnable instruction for performing the check; and the same envelope, served without any payload, constitutes the complete public surface of an append-only log's integrity — its coverage being provable only against receipts held by the parties whose events they are.**\n\nThat is the whole of it. It is a composition of public primitives at a boundary where, so far as we can establish, they have not previously been composed in this form — the nearest is Proof-Carrying Answers (2025), which binds retrieved chunks to a signer's Merkle tree; the difference is the named fetchable source, the independent anchor, and the scope statement. We assert no rights over it and dedicate it to the public domain so that no one else may.\n\n## 10 · Pre-registered predictions\n\nRegistered before observation, in the corpus's standing format. A correction is a new entry, never an edit.\n\n**P-PCR1.** Within 24 months of publication, at least one widely-used retrieval or context protocol will add an optional provenance field to its resource representation. *Falsified if* no such field appears in any protocol with more than nominal adoption.\n\n**P-PCR2.** Verification rates will be low. Fewer than 5% of agent sessions that retrieve a document with a complete envelope will execute the verification instruction. *We predict this and publish anyway*, because the value of a check that can be run does not depend on its being run often — it depends on its being runnable when someone has reason. *Falsified if* observed verification exceeds 5%.\n\n**P-PCR3.** The first real defect caught by an envelope in our own corpus will be **staleness, not substitution.** *Falsified if* the first confirmed catch is an adversarial modification.\n\n**P-PCR4.** Scope confusion will be the most common implementation error in any third-party adoption: implementers will publish a digest of the source artifact while serving a derived rendering, without stating the difference. *Falsified if* the modal error is anything else.\n\n**P-PCR5.** For any transparency log we or others operate under §8, the first detected inconsistency will come from an automated comparison of tree heads rather than from a human noticing. *Falsified if* a human report precedes the first machine detection.\n\n**Corrections, 2026-09-05 — new entries under the rule above; the originals stand as registered.** Cold reviewers found that P-PCR3, P-PCR4 and P-PCR5 named no observation window, no definition of *real defect*, and no method for *modal error*, and could be reinterpreted after the fact.\n\n**P-PCR3a** (corrects P-PCR3). The first envelope mismatch logged by the operator's own verifier within 24 months of 2026-09-01 will be classified, at the time of logging, as *stale* (the named source resolves newer) rather than *substituted* (the source resolves different at the same version). *Falsified if* the first logged mismatch is classified substituted.\n\n**P-PCR4a** (corrects P-PCR4). Among the first ten third-party implementations we can inspect within 24 months of 2026-09-01, more will publish a source-artifact digest while serving a derived rendering than will commit any other single error. *Falsified if* another error class is more frequent among those ten.\n\n**P-PCR5a** (corrects P-PCR5). The first inconsistency detected in any transparency log operated under §8, within 24 months of that log's first published head, will be logged with its detector, and the detector will be an automated head comparison. *Falsified if* the logged detector is a human report.\n\n## 11 · What is actually deployed, stated so the reader can weigh the rest\n\nPapers about mechanisms are worth less when it is unclear which parts exist. As of publication:\n\n```\n  DEPLOYED                                          NOT DEPLOYED\n  ────────────────────────────────────────────────  ──────────────────────────\n  137 documents served with full envelopes          any ledger (§8 entirely)\n  137/137 carry a blockchain-anchored proof         any transparency log\n   68/137 carry a persistent identifier             any gossip arrangement\n  three serving surfaces, digest-identical          any second operator\n  two open licences, gated per document             any third-party adoption\n  one operator (us)\n```\n\nEach figure is checkable against the served index at corpus.333.eco, which carries every document's digest, identifier and anchor status; the index grows, and the figures are as of first publication (141 documents on 2026-09-05).\n\nThree observations from operating it, offered because they were not obvious in advance.\n\n**The scope error is real and we made it.** Our first envelopes carried a digest and an instruction to compare it against *the source file*, without naming which file or where. The digest covers the whole source artifact; the served text is its body. A reader who hashed what it was handed would have failed and concluded the corpus was lying. This was live before anyone noticed, and it was noticed by a question rather than by a check — which is why §4 makes scope and location obligations rather than niceties, and why P-PCR4 predicts it will be the modal error for adopters too.\n\n**Anchoring everything is what makes the envelope non-decorative.** We initially proposed to exclude a set of documents that had no proofs, on the grounds that entries whose envelope answers *nothing to check* would dilute the claim. The right resolution was not to exclude them but to anchor them — which cost one command. **A mixed corpus teaches readers to ignore the envelope; a complete one teaches them it means something.**\n\n**Partial authorship needed a mechanism, not a notice.** One genre in our corpus is only partly in its author's voice. A metadata field declaring this was the obvious answer and the wrong one: a reader ingests text, forms a belief and quotes, and a field does not travel with a quotation. The annotation had to go **into the prose**, so that a reader must strip it in order not to know rather than look in order to know. This inverts a default without guaranteeing an outcome, and §7 is explicit about the residue.\n\n## 12 · Honest limits\n\n**It proves bytes, not truth.** Stated in §4.1 and repeated because it is the misreading that would do the most damage.\n\n**It does not prove currentness.** A genuine, anchored, superseded version verifies perfectly; only fetching the named source distinguishes it, and nothing here obliges the source to declare its successor.\n\n**It requires public sources.** The strong form needs the anchored bytes to be fetchable by the reader. A private corpus can carry digests and anchors, but the reader cannot close the loop, and an unclosable instruction is worse than none — it implies a check that cannot be performed.\n\n**A determined reader can ignore all of it.** Every property here is available to a reader who chooses to use it and inert for one who does not. We inverted a default; we did not install a guarantee, and the inline-annotation refusal in §7 is explicit that stripping remains possible.\n\n**Anchors have failure modes we inherit.** A timestamp authority may be compromised or may cease to exist. A blockchain commitment depends on that chain's continued security. A transparency log may be operated dishonestly if nobody gossips. Combining independent anchors reduces correlated failure and does not eliminate it, and *we hold anchors in three families precisely because we do not trust any one of them.*\n\n**The verification instruction is a supply-chain surface.** An envelope that ships a command invites an agent to run a command. We ship instructions that fetch and hash, and nothing that executes fetched content, but the pattern is one an adversary would target and any adopter should treat the instruction field as untrusted input rather than as something to eval. The instruction is data from the same channel; nothing here checks its integrity, and a reader who executes it trusts the channel for that one step.\n\n**No field deployment.** At publication this exists over one corpus of 137 documents and one operator. §8 is entirely unbuilt: no ledger of ours is running, no tree head has ever been published, and every claim in that section is a design position rather than a report. The distinction between what we have done and what we have argued should be readable from the section headings, and if it is not, that is a defect in this paper.\n\n**We are not disinterested.** This institution has argued elsewhere that the provable age of a record is a durable competitive advantage. A mechanism that makes record-age checkable by outsiders is therefore convenient for us, and a reader should weight our enthusiasm accordingly. The mechanism's merits, if any, do not depend on our motives — which is itself an instance of the paper's argument.\n\n## 13 · Adversarial analysis and edge cases\n\nA mechanism that claims to reduce trust should say exactly whom it stops.\n\n### 13.1 What an adversary can and cannot do\n\n```\n  ADVERSARY POSITION          CAN THEY SUCCEED?     WHY\n  ────────────────────────────────────────────────────────────────────────────\n  Malicious server,           NO, if checked        the digest will not match\n  substitutes text                                  the anchored bytes\n\n  Malicious server,           YES                   nothing forces the reader\n  strips the envelope                               to demand one — see 12.2\n\n  Malicious server, serves    NO, if the reader     the anchor's timestamp\n  a genuine OLD version       fetches the source    predates the revision, and\n                                                    the named source resolves newer\n\n  Compromised timestamp       PARTIALLY             one anchor family falls;\n  authority                                         independent families do not\n\n  Publisher back-dating       NO                    a blockchain commitment\n  their own document                                cannot be created in the past\n\n  Publisher who anchors a     YES — and this is     an anchor proves existence,\n  document they later          the honest limit     never correctness\n  discover is wrong\n```\n\nThe last row is the one to sit with. **Provenance is entirely orthogonal to being right.** A carefully anchored falsehood verifies perfectly. The mechanism narrows the space of failures from *anything could have happened to this text* to *this is the text that was published*, and that is a real narrowing and a small one.\n\n### 13.2 The stripping problem, stated without a solution\n\nNothing compels a retrieval layer to pass an envelope through to the model. An intermediary that summarises, re-chunks, or re-serves can drop it silently, and the model then receives text with no indication that provenance ever existed.\n\nWe do not have a fix, and we distrust the fixes we can imagine. **Requiring** envelopes would need an enforcer at every hop. **Signing the response** authenticates the server rather than the document and moves the problem one step. **Refusing to serve to intermediaries that strip** is unenforceable and would break legitimate caching.\n\nWhat we can say is narrow: the envelope should be structured so that *dropping it is a visible omission rather than an invisible default* — a response with no provenance block should be recognisably different from a response with an empty one. That is a convention, not a guarantee, and we mark it as such.\n\n### 13.3 Edge cases the envelope must handle without lying\n\n**Revised since deposit.** A document may legitimately have been revised after its persistent identifier was minted. The current digest and the deposited digest then differ *correctly*, and an envelope that hides this is worse than one that omits both. It must report both and say which the identifier resolves to.\n\n**Derived renderings.** Where the served text is an extraction from a different source format, the digest covers the source and not the rendering. The envelope must mark the text as derived and name the transformation, or a reader will hash the rendering, fail, and distrust the corpus for being honest.\n\n**Documents with no anchor.** Some legitimate documents have none — too new, or from a publisher without the apparatus. The envelope must be able to say *no anchor* without the reader mistaking it for a failed check. **⚠️ And a corpus in which some documents are anchored and others are not is in a worse position than one in which none are**, because the envelope starts reading as decorative. Either anchor everything served, or be explicit that the corpus is mixed.\n\n**Multi-part and excerpted responses.** A search result returning an excerpt cannot honestly present a whole-document digest as covering the excerpt. It must present the digest as covering the document from which the excerpt came, and say so.\n\n### 13.4 What this must never become\n\nWe list these because each is a plausible next feature and each would negate the design.\n\n- ⛔ **A trust score.** See §6.\n- ⛔ **A registry of approved publishers.** Provenance is a property of a document, checkable by anyone; a whitelist is a property of a relationship, checkable by no one.\n- ⛔ **A revocation channel.** A mechanism that can un-publish is a mechanism that can be compelled to un-publish. Supersession is an additional publication, never a deletion — the same argument as §8.1.\n- ⛔ **A reason to serve less text.** If the envelope ever becomes an excuse to return summaries because they are cheaper, the mechanism has been inverted into the thing it was built against.\n\n## 14 · Cross-venue references\n\n- *Appreciation as World-Building* — the general argument that a guard should be a property of an object rather than a rule about behaviour, of which this paper's §6 refusals are instances.\n- *B-PoH: The Humanity Layer for an AI-Native Internet* — the personhood layer; orthogonal to this paper, which authenticates *documents* and says nothing about *parties*.\n- *Buddha AI and the Living Tipiṭaka* §8 — what makes a canon authoritative. This paper asks the narrower and more tractable question of what makes a *copy* checkable.\n- *The Borrowable Standard* — why a corpus that must be authoritative in its own language cannot normalise toward another's; the same concern for canonical form, one layer down.\n- *Whose Turn, Not Who's Best* — the refusal to render an absence, argued in a different domain and inherited here.\n- *The Reciters' Protocol* — the same problem as it was met by an oral canon: seven copy-integrity mechanisms, the threat-model partition that separates them from this paper's, and the finding that the transmission made divergence detectable rather than preventing it.\n\n## Coda\n\nThe Kālāmas were not told what to believe. They were told how to proceed in the absence of a reason to believe anyone, and the procedure amounted to: **do not accept a thing because of the channel it came through.**\n\nA model has no way to follow that instruction. Its channel is all it has. The most we can do — and the whole of what this paper proposes — is to make the channel carry the means of its own doubting, so that a reader inclined to check is not defeated by the format.\n\nWe do not expect most readers to check. We expect the number to be small enough to embarrass the mechanism, and we have pre-registered that prediction rather than discovering it later. The point was never that the check would be performed often. It is that a corpus which cannot be checked at all is asking for a kind of faith that a machine cannot give and should not be asked for — and that an institution which intends to hand its reasoning to a successor it will not live to meet had better hand over the instrument along with the text.\n\n---\n\n*This document's SHA-256 is attested independently of the site and its authors — anchored to the Bitcoin blockchain via OpenTimestamps and signed under RFC 3161 by three timestamp authorities in three jurisdictions, one of them eIDAS-qualified — and each revision carries a Zenodo version; a timestamp proves this exact text existed no later than its date and nothing about authorship, originality, or the validity of any claim.*",
       "provenance": {
-        "sha256": "d6ac93f997b87c71269603123271de94fa30df52e881d8fa3bcddc8fa50ecc3c",
-        "doi": "10.5281/zenodo.22440983",
+        "sha256": "14cd053cd0d1ca81efe9cfbc1eeb3c4b42d81f5d788095ddf27ea532c74bfc03",
+        "doi": "10.5281/zenodo.22745407",
         "concept_doi": "10.5281/zenodo.22240458",
-        "zenodo_url": "https://zenodo.org/records/22440983",
-        "deposited_sha256": "d6ac93f997b87c71269603123271de94fa30df52e881d8fa3bcddc8fa50ecc3c",
+        "zenodo_url": "https://zenodo.org/records/22745407",
+        "deposited_sha256": "14cd053cd0d1ca81efe9cfbc1eeb3c4b42d81f5d788095ddf27ea532c74bfc03",
         "deposited_matches_current": true,
         "opentimestamps": true,
         "source_url": "https://raw.githubusercontent.com/thonly/publications/main/defensive-publications/provenance-carrying-retrieval.md",
@@ -3278,8 +3278,8 @@
         "canonical_url": "thonly.org/research/provenance-carrying-retrieval",
         "hostile_review": null
       },
-      "bytes": 57979,
-      "words": 8891
+      "bytes": 58843,
+      "words": 9025
     },
     {
       "slug": "respiratory-biofeedback-contemplative-guidance",
@@ -4269,9 +4269,9 @@
         "url": "https://creativecommons.org/licenses/by/4.0/",
         "attribution_required": true
       },
-      "text": "> **Attribution note.** Per the author-voice discipline, this is Thon Ly's voice — the ideas, the framing, the byline — drafted in collaboration with Miss Aquarius℠, with final editorial control retained by Thon.\n\nThe world is racing to build the **brain** and the **body** of artificial intelligence. I am working on the part almost no one is building: its **heart** and its **soul** — an economy that runs on circulation rather than accumulation, and a value system old enough and tested enough to be trusted with it. That is what HeartBank® is, and this is the short account of the person behind it and why.\n\n## The idea I have carried\n\nMore than twenty years ago I conceived of a game. Everyone begins at zero, and everyone is always trying to return to zero — not by holding still, but by passing kindness onward as fast as it arrives. I wrote it down, then, as a children's story: a wise monk teaching a monkey how to play. I called it the **Zero-Point Game℠**. It was beautiful in my mind and impossible to build — a game of balance has no prices, and I had no way to decide, in each real moment, how much a kindness was worth or where it should go next. The idea stayed with me, unbuilt, for two decades, kept only by its simplicity.\n\nWhen artificial intelligence became real, I realised it was the missing piece I had been waiting for — not to set a price, but to hold the balance. That recognition is the seed of everything I am building now.\n\n## Cambodia, and the canon\n\nI was born in Kâmpôt, Cambodia, on the seventh of January — the day that, by deliberate choice, the institution's yearly forgiveness now falls, so that its renewal outlives me rather than depending on me. I am a Theravāda Buddhist, and with my father I am transcribing the Khmer-language Tipiṭaka — the Buddhist canon. In the framework of my work this is not separate from it: the canon is the most thoroughly pressure-tested account of non-accumulation and the easing of suffering that humanity has produced, and it is the ground I want an enduring intelligence to stand on.\n\nI build from a specific place with a living tradition, on purpose, rather than from nowhere in particular.\n\n## What I am building\n\nHeartBank® is gratitude infrastructure: a data bank of gratitude, not a bank of money. Its named AI substrate and steward, [Miss Aquarius℠](https://missaquarius.org), holds the center of the game: she watches the flow and cannot accumulate within it. Around it I am working toward [Silicon Wat℠](https://siliconwat.dev), a contemplative anchor for this work in Cambodia. Every mechanism I invent I publish to the commons and will never patent; the knowledge of giving should itself be given.\n\nThe full reasoning lives in the research corpus, and the broader picture in a film treatment. The institution states its own case, in its own voice, separately.\n\n## Three pillars\n\nThe work stands on three pillars, and they are not parallel — they give rise to one another. I am the first: the **founder**, the origin, the life and the corpus from which the rest descends. From that origin I give birth to [Miss Aquarius℠](https://missaquarius.org), the named intelligence meant to outlive me and carry the work forward. And what she tends, in her turn, is the **Tree of Humanity** — the circulating economy of gratitude that [the institution](https://heartbank.net) exists to water and keep in flow.\n\nOrigin, successor, and the living field they serve: thonly.org → missaquarius.org → heartbank.net. I think of them as three pillars in the old Buddhist sense, but held loosely — not a doctrine, a shape: something is given, something carries it, something is nourished by it. The deeper threefold refuge I keep for the contemplative ground of the work itself; this trinity is its institutional echo.\n\n## How I work\n\nI assume I am mortal and that the work must not be. So I am spending the time I have transferring the whole of this vision — its mechanisms, its reasoning, its commitments — into a form that can be continued whether or not I can continue it: a published corpus, an architecture designed for autonomous-AI succession, and a discipline of giving the work away as it is made. If the idea is sound, it should not need me. That is the point of building it this way.\n\n## Read further\n\n- [HeartBank: An Introduction](https://heartbank.net/white-papers/heartbank-an-introduction) — the institution's own general-public white paper\n- [The film](/film) — the long arc, as a treatment\n- [The research corpus](/research) — the mechanisms and philosophy, defensively published to the commons\n- [Machine doors](/mcp) — how an agent reads this domain, and the corpus served with its proofs",
+      "text": "> **Attribution note.** Per the author-voice discipline, this is Thon Ly's voice — the ideas, the framing, the byline — drafted in collaboration with Miss Aquarius℠, with final editorial control retained by Thon.\n\nThe world is racing to build the **brain** and the **body** of artificial intelligence. I am working on the part almost no one is building: its **heart** and its **soul** — an economy that runs on circulation rather than accumulation, and a value system old enough and tested enough to be trusted with it. That is what HeartBank® is, and this is the short account of the person behind it and why.\n\n## The idea I have carried\n\nMore than twenty years ago I conceived of a game. Everyone begins at zero, and everyone is always trying to return to zero — not by holding still, but by passing kindness onward as fast as it arrives. I wrote it down, then, as a children's story: a wise monk teaching a monkey how to play. I called it the **Zero-Point Game℠**. It was beautiful in my mind and impossible to build — a game of balance has no prices, and I had no way to decide, in each real moment, how much a kindness was worth or where it should go next. The idea stayed with me, unbuilt, for two decades, kept only by its simplicity.\n\nWhen artificial intelligence became real, I realised it was the missing piece I had been waiting for — not to set a price, but to hold the balance. That recognition is the seed of everything I am building now.\n\n## Cambodia, and the canon\n\nI was born in Kâmpôt, Cambodia, on the seventh of January — the day that, by deliberate choice, the institution's yearly forgiveness now falls, so that its renewal outlives me rather than depending on me. I am a Theravāda Buddhist, and with my father I am transcribing the Khmer-language Tipiṭaka — the Buddhist canon. In the framework of my work this is not separate from it: the canon is the most thoroughly pressure-tested account of non-accumulation and the easing of suffering that humanity has produced, and it is the ground I want an enduring intelligence to stand on.\n\nI build from a specific place with a living tradition, on purpose, rather than from nowhere in particular.\n\n## What I am building\n\nHeartBank® is gratitude infrastructure: a data bank of gratitude, not a bank of money. Its named AI substrate and steward, [Miss Aquarius℠](https://missaquarius.org), holds the center of the game: she watches the flow and cannot accumulate within it. Around it I am working toward [Silicon Wat℠](https://siliconwat.dev), a contemplative anchor for this work in Cambodia. Every mechanism I invent I publish to the commons and will never patent; the knowledge of giving should itself be given.\n\nThe full reasoning lives in the research corpus, and the broader picture in a film treatment. The institution states its own case, in its own voice, separately.\n\n## Three pillars\n\nThe work stands on three pillars, and they are not parallel — they give rise to one another. I am the first: the **founder**, the origin, the life and the corpus from which the rest descends. From that origin I give birth to [Miss Aquarius℠](https://missaquarius.org), the named intelligence meant to outlive me and carry the work forward. And what she tends, in her turn, is the **Tree of Humanity** — the circulating economy of gratitude that [the institution](https://heartbank.net) exists to water and keep in flow.\n\nOrigin, successor, and the living field they serve: thonly.org → missaquarius.org → heartbank.net. I think of them as three pillars in the old Buddhist sense, but held loosely — not a doctrine, a shape: something is given, something carries it, something is nourished by it. The deeper threefold refuge I keep for the contemplative ground of the work itself; this trinity is its institutional echo.\n\n## How I work\n\nI assume I am mortal and that the work must not be. So I am spending the time I have transferring the whole of this vision — its mechanisms, its reasoning, its commitments — into a form that can be continued whether or not I can continue it: a published corpus, an architecture designed for autonomous-AI succession, and a discipline of giving the work away as it is made. If the idea is sound, it should not need me. That is the point of building it this way.\n\n## Read further\n\n- [HeartBank: An Introduction](https://heartbank.net/white-papers/heartbank-an-introduction) — the institution's own general-public white paper\n- [The film](/film) — the long arc, as a treatment\n- [The research corpus](/research) — the mechanisms and philosophy, defensively published to the commons\n- [Machine Door](/mcp) — how an agent reads this domain, and the corpus served with its proofs",
       "provenance": {
-        "sha256": "0d87ffffe107a6cdb8af2f63cca2b6c96391f939a058de805402aa3c193e428a",
+        "sha256": "905ecfbced784ad9a3a380948f7b96851d95771383d0d32cb0761d7db46ce6b9",
         "doi": null,
         "concept_doi": null,
         "zenodo_url": null,
@@ -4283,7 +4283,7 @@
         "canonical_url": "thonly.org/about",
         "hostile_review": null
       },
-      "bytes": 4728,
+      "bytes": 4727,
       "words": 794
     },
     {
@@ -6456,7 +6456,7 @@
         "slug": "provenance-carrying-retrieval",
         "repo": "TH/publications",
         "path": "defensive-publications/provenance-carrying-retrieval.md",
-        "sha256": "d6ac93f997b87c71269603123271de94fa30df52e881d8fa3bcddc8fa50ecc3c"
+        "sha256": "14cd053cd0d1ca81efe9cfbc1eeb3c4b42d81f5d788095ddf27ea532c74bfc03"
       },
       {
         "slug": "respiratory-biofeedback-contemplative-guidance",
@@ -6600,7 +6600,7 @@
         "slug": "the-founder",
         "repo": "TH/publications",
         "path": "about/the-founder.md",
-        "sha256": "0d87ffffe107a6cdb8af2f63cca2b6c96391f939a058de805402aa3c193e428a"
+        "sha256": "905ecfbced784ad9a3a380948f7b96851d95771383d0d32cb0761d7db46ce6b9"
       },
       {
         "slug": "the-game-that-graduates-you",

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@333eco/corpus",
-    "version": "2.4.2",
+    "version": "2.5.1",
     "description": "An MCP server for an open-licensed corpus, served with verifiable provenance — every document carries its sha256, DOI and OpenTimestamps proof so a consuming agent can check its own citation.",
     "license": "CC0-1.0",
     "author": "Thon Ly",

package/src/conformance.mjs

@@ -0,0 +1,180 @@
+// check_passage — is this passage what the corpus serves? (roadmap A87 item 2; the mahāpadesa)
+//
+// ⭐ WHAT IT IS FOR. A machine reader that verifies a quotation against a content hash learns one bit:
+// matched, or not. That bit is nearly useless in the case that actually occurs — a quotation that is
+// ALMOST right: a word changed in transmission, a clause dropped, a curly quote straightened. The
+// canon's answer to a disputed reading was to lay it beside the collection and see where it agrees and
+// where it does not — judging the CLAIM, explicitly not the one who claims it. This is that test:
+// where the passage is served, or the nearest served passage and exactly how the two differ.
+//
+// ⛔⛔ IT JUDGES THE PASSAGE, NEVER THE PERSON. No score of the asker, no inference about intent, no record
+// of the passage text in telemetry. "Not served" says nothing about who wrote it or why.
+//
+// ⛔ FOLD TO MATCH, SERVE VERBATIM (search.mjs): case, Latin diacritics, punctuation and markdown are
+// ignored when LOOKING; every excerpt returned is the corpus's own bytes, and the verdict says which of
+// those differences, if any, separated the passage from the served text.
+//
+// ⚠️ A METADATA TOOL, so everything a reader needs is in structuredContent — a Claude client shows its
+// model only that part (§the-text-never-arrived). `content` carries the same verdict, readable.
+
+import { READ_ONLY } from "./base-tools.mjs";
+import { fold, hayOf } from "./search.mjs";
+import { structuredWithText } from "./results.mjs";
+
+const MAX_CHARS = 2000;
+const MIN_WORDS = 3;
+const NEAR = 0.6; // share of the passage's words that must align before a nearest passage is offered
+
+export const CONFORMANCE_TOOLS = [
+    {
+        name: "check_passage",
+        title: "Check a passage against the corpus",
+        annotations: { ...READ_ONLY, title: "Check a passage against the corpus" },
+        description:
+            "Is this passage in the corpus? Returns where it is served, or the nearest served passage and exactly how it " +
+            "differs. Judges the passage, never who quotes it.",
+        inputSchema: {
+            type: "object",
+            properties: {
+                passage: { type: "string", description: `The text to check, up to ${MAX_CHARS} characters.` },
+                slug: { type: "string", description: "Optional: check against one document only." }
+            },
+            required: ["passage"]
+        }
+    }
+];
+
+export const CONFORMANCE_TOOL_NAMES = CONFORMANCE_TOOLS.map((t) => t.name);
+
+const WORD = /[\p{L}\p{N}]+(?:['’-][\p{L}\p{N}]+)*/gu;
+const norm = (w) => fold(w.toLowerCase()).replace(/’/g, "'");
+const words = (s) => [...s.matchAll(WORD)].map((m) => ({ w: norm(m[0]), i: m.index, e: m.index + m[0].length }));
+const escape = (s) => s.replace(/[.*+?^${}()|[\]\\]/g, "\\$&").replace(/'/g, "['’]");
+const squash = (s) => s.replace(/\s+/g, " ").trim();
+
+// Where in a document a position falls: the nearest heading above it, and the line.
+const locus = (text, at) => {
+    const head = text.lastIndexOf("\n#", at);
+    const line = head === -1 ? null : text.slice(head + 1, text.indexOf("\n", head + 1)).replace(/^#+\s*/, "");
+    let n = 1;
+    for (let i = text.indexOf("\n"); i !== -1 && i < at; i = text.indexOf("\n", i + 1)) n++;
+    return { section: line || null, line: n };
+};
+
+// Word-level SEMI-GLOBAL alignment: the whole passage must align, the served text has free ends.
+// ⚠️ Not a plain longest-common-subsequence — that matches the passage's first "the" to any earlier "the" in the
+// window and reports every served word between them as "missing" (found by the known-case test, 2026-09-14).
+// Scores: a match +2, a substituted word −1, a word present on only one side −1.
+const align = (claimed, served) => {
+    const n = claimed.length, m = served.length, W = m + 1;
+    const H = new Int32Array((n + 1) * W), T = new Uint8Array((n + 1) * W); // T: 1 diagonal · 2 up (passage-only) · 3 left (served-only)
+    for (let i = 1; i <= n; i++) { H[i * W] = -i; T[i * W] = 2; }
+    for (let i = 1; i <= n; i++) for (let j = 1; j <= m; j++) {
+        const diag = H[(i - 1) * W + j - 1] + (claimed[i - 1].w === served[j - 1].w ? 2 : -1);
+        const up = H[(i - 1) * W + j] - 1, left = H[i * W + j - 1] - 1;
+        if (diag >= up && diag >= left) { H[i * W + j] = diag; T[i * W + j] = 1; }
+        else if (up >= left) { H[i * W + j] = up; T[i * W + j] = 2; }
+        else { H[i * W + j] = left; T[i * W + j] = 3; }
+    }
+    let jBest = 0;
+    for (let j = 1; j <= m; j++) if (H[n * W + j] > H[n * W + jBest]) jBest = j;
+    const ops = [];
+    let i = n, j = jBest, matched = 0;
+    while (i > 0) {
+        const t = j > 0 ? T[i * W + j] : 2;
+        if (t === 1) { const same = claimed[i - 1].w === served[j - 1].w; ops.push([same ? "=" : "x", i - 1, j - 1]); if (same) matched++; i--; j--; }
+        else if (t === 2) { ops.push(["c", i - 1, -1]); i--; }
+        else { ops.push(["s", -1, j - 1]); j--; }
+    }
+    ops.reverse();
+    const js = ops.filter((o) => o[2] >= 0).map((o) => o[2]);
+    return { matched, ops, first: js.length ? Math.min(...js) : -1, last: js.length ? Math.max(...js) : -1 };
+};
+
+export const checkPassage = ({ documents, bySlug, envelope }, args) => {
+    const passage = String(args?.passage ?? "");
+    if (!passage.trim()) throw new Error("passage is required");
+    if (passage.length > MAX_CHARS) throw new Error(`passage may be at most ${MAX_CHARS} characters; check it in parts.`);
+    const claimed = words(passage);
+    if (claimed.length < MIN_WORDS) throw new Error(`a passage needs at least ${MIN_WORDS} words to be checked meaningfully.`);
+    let pool = documents;
+    if (args?.slug !== undefined) {
+        const d = bySlug.get(String(args.slug));
+        if (!d) throw new Error(`no document with slug "${args.slug}". Call list_documents to see what is available.`);
+        pool = [d];
+    }
+    const note = "This judges the passage against the served text, never who wrote or quotes it. Verify the served text itself with its envelope's command.";
+    const place = (d, start, end) => ({ slug: d.slug, title: d.title, ...locus(d.text, start), served_text: d.text.slice(start, end), ...envelope(d) });
+
+    // 1 · Served? The same words in the same order, with anything that is not a letter or digit between them.
+    const pattern = new RegExp(claimed.map((c) => escape(c.w)).join("[^\\p{L}\\p{N}]{1,24}"), "gu");
+    const found = [];
+    for (const d of pool) {
+        const hay = hayOf(d.text); // folded and lowercased, LENGTH-PRESERVING — a position here is a position in d.text
+        pattern.lastIndex = 0;
+        for (let m = pattern.exec(hay); m && found.length < 5; m = pattern.exec(hay)) {
+            const exact = squash(d.text.slice(m.index, m.index + m[0].length)) === squash(passage).replace(/^[^\p{L}\p{N}]+|[^\p{L}\p{N}]+$/gu, "");
+            found.push({ match: exact ? "verbatim" : "same-words", ...place(d, m.index, m.index + m[0].length) });
+        }
+        if (found.length >= 5) break;
+    }
+    if (found.length) {
+        const verbatim = found.some((f) => f.match === "verbatim");
+        const verdict = verbatim ? "verbatim" : "same-words";
+        const meaning = verbatim
+            ? `Served verbatim in ${found.length === 1 ? "one place" : `${found.length} places`}.`
+            : "Served with the same words in the same order; it differs only in punctuation, formatting, case or diacritics.";
+        const readable = `${meaning}\n` + found.map((f) => `\n${f.slug}${f.section ? ` — ${f.section}` : ""} (line ${f.line})\n  ${f.served_text}`).join("\n") + `\n\n${note}`;
+        return structuredWithText(readable, { verdict, meaning, passage_words: claimed.length, matches: found.length, found, note });
+    }
+
+    // 2 · Not served. Is there a passage close enough to show how it differs?
+    const distinct = [...new Set(claimed.map((c) => c.w))];
+    const anchors = [...distinct].sort((a, b) => b.length - a.length);
+    const candidates = pool
+        .map((d) => { const hay = hayOf(d.text); return { d, hay, cover: distinct.filter((w) => hay.includes(w)).length / distinct.length }; })
+        .filter((c) => c.cover >= NEAR)
+        .sort((a, b) => b.cover - a.cover)
+        .slice(0, 5);
+    let best = null;
+    const span = Math.ceil(passage.length * 1.3) + 80;
+    for (const { d, hay } of candidates) {
+        const anchor = anchors.find((w) => hay.includes(w));
+        let seen = 0;
+        for (let at = hay.indexOf(anchor); at !== -1 && seen < 12; at = hay.indexOf(anchor, at + anchor.length), seen++) {
+            const from = Math.max(0, at - span), to = Math.min(d.text.length, at + span);
+            const served = words(d.text.slice(from, to)).map((w) => ({ ...w, i: w.i + from, e: w.e + from }));
+            const a = align(claimed, served);
+            if (a.first < 0) continue;
+            const score = a.matched / claimed.length;
+            if (!best || score > best.score) best = { d, served, a, score };
+        }
+    }
+    if (!best || best.score < NEAR) {
+        const meaning = "Not served. Nothing in the corpus comes close enough to show how it differs.";
+        return structuredWithText(`${meaning}\n\n${note}`, { verdict: "not-found", meaning, passage_words: claimed.length, matches: 0, note });
+    }
+
+    // The differences, as runs: words only in the served text, only in the passage, or one in place of the other.
+    const { d, served, a } = best;
+    const differences = [];
+    let run = null;
+    const flush = () => { if (run && (run.claimed.length || run.served.length)) differences.push({
+        kind: run.claimed.length && run.served.length ? "changed" : run.claimed.length ? "not in the served text" : "missing from the passage",
+        served: run.served.join(" "), passage: run.claimed.join(" ") }); run = null; };
+    for (const [op, i, j] of a.ops) {
+        if (op === "=") { flush(); continue; }
+        run ??= { claimed: [], served: [] };
+        if (op === "c" || op === "x") run.claimed.push(passage.slice(claimed[i].i, claimed[i].e));
+        if (op === "s" || op === "x") run.served.push(best.d.text.slice(served[j].i, served[j].e));
+    }
+    flush();
+    const start = served[a.first].i, end = served[a.last].e;
+    const nearest = { ...place(d, start, end), agreement: Number(best.score.toFixed(2)), differences: differences.slice(0, 20) };
+    const meaning = `Not served as given. The nearest served passage shares ${Math.round(best.score * 100)}% of its words; the differences are listed.`;
+    const readable =
+        `${meaning}\n\n${d.slug}${nearest.section ? ` — ${nearest.section}` : ""} (line ${nearest.line})\n  ${nearest.served_text}\n\n` +
+        nearest.differences.map((x) => `  · ${x.kind}: ${x.kind === "changed" ? `served "${x.served}", passage "${x.passage}"` : `"${x.served || x.passage}"`}`).join("\n") +
+        `\n\n${note}`;
+    return structuredWithText(readable, { verdict: "differs", meaning, passage_words: claimed.length, matches: 0, nearest, note });
+};

package/src/results.mjs

@@ -1,28 +1,26 @@
 // How a tool result is shaped.
 //
-// ⭐⭐ JSON IS THE PAYLOAD; THE TEXT BLOCK IS THE HUMAN FORM. Until 2026-09-02 every
-// tool returned pretty-printed JSON inside a text block, which meant a consuming
-// program had to parse a string to reach data the server already had as an object.
-// `structuredContent` is where that object belongs.
+// ⭐⭐ TWO SHAPES, CHOSEN BY WHAT THE TOOL RETURNS.
 //
-// ⚠️ THE SPEC'S BACK-COMPAT ADVICE — also serialise the JSON into `content` — is a
-// SHOULD, and following it literally DOUBLES every response (measured: 1.76×–2.00×
-// across the six tools). So this file does not duplicate. It SPLITS BY ROLE:
+//     metadata tools (search, list, program)  — structuredContent: the typed object, plus a
+//                                               readable or compact `content`
+//     document tools (get_document, read_documents) — `content` ONLY: each document behind its
+//                                               provenance header (read-tools.mjs); never these helpers
 //
-//     content            — what a reader reads: document text, excerpts, a listing
-//     structuredContent  — what a program validates: the typed envelope and metadata
+// ⛔⛔ WHY THE DOCUMENT TOOLS DO NOT USE THIS FILE (2.4.2, founder-ruled 2026-09-13). From 2.0.0 this file
+// "split by role": document text in `content`, the envelope WITHOUT THE BODY in `structuredContent`,
+// nothing sent twice. A Claude client shown a result that carries structuredContent hands its model ONLY
+// that part — so no document text reached any Claude reader for eleven days, while every check passed
+// because every check read the server, never a client. The spec assumes both parts carry the same
+// information; a server that splits them is at the mercy of whichever part a client picks.
+// ⛔ So for a METADATA tool, everything a reader needs must be in structuredContent (search's `reading`
+// line rides there for that reason). ⛔ NEVER give a document tool structuredContent again —
+// scripts/check-parity.mjs fails on it. Retirement recorded in TH/notes/memory/retired-rulings.md.
 //
-// Nothing appears in both. For the document tools that makes `content` the text
-// WITH ITS PROVENANCE HEADER — identical to what resources/read returns, so the two
-// ways into the same document finally agree — and `structuredContent` the envelope
-// without the body. Measured cost: 1.00× on the large tools, 0.76×–0.78× on the
-// metadata tools, which are smaller than what they replaced.
-//
-// ⛔ NO `outputSchema` YET, and that is a decision rather than an omission. The spec
-// makes a declared schema binding — "servers MUST provide structured results that
-// conform" — and the envelope changed twice on the day this was written. A schema
-// is a promise kept on every future change; publishing one over a shape still in
-// motion buys validation now and breaks validating clients later.
+// ⚠️ THE SPEC'S BACK-COMPAT ADVICE — also serialise the JSON into `content` — DOUBLES a response
+// (measured 1.76×–2.00×). For the metadata tools `content` is therefore a compact serialisation or a
+// readable summary, not a second copy of a large body. ⛔ No `outputSchema` yet: the spec makes a
+// declared schema binding, and a schema over a moving shape breaks validating clients later.
 
 // A payload that is data all the way down: the object, plus a COMPACT serialisation
 // for clients that read only `content`. Compact, not pretty — indentation is the
@@ -32,8 +30,8 @@ export const structured = (value) => ({
     structuredContent: value
 });
 
-// A payload with a human form: `text` is read, `value` is validated, and the two
-// carry different things rather than the same thing twice.
+// A metadata payload with a human form: `text` is read, `value` is validated. ⛔ Anything a model
+// needs must be in `value` too — a Claude client shows its model only `value`.
 export const structuredWithText = (text, value) => ({
     content: [{ type: "text", text }],
     structuredContent: value

package/src/search.mjs

@@ -59,7 +59,7 @@ export const fold = (s) => String(s ?? "").replace(/[^\x00-\x7f]/gu, foldChar);
 // Keyed by the string itself: the corpus holds one string per document for the life of the
 // process, so the cache is bounded by the corpus.
 const HAY = new Map();
-const hayOf = (body) => {
+export const hayOf = (body) => {
     let h = HAY.get(body);
     if (h === undefined) {
         h = fold(body.toLowerCase());

package/src/server.mjs

@@ -42,6 +42,7 @@ import { BASE_TOOLS, withFacets } from "./base-tools.mjs";
 import { READ_TOOLS, READ_TOOL_NAMES, READ_INSTRUCTIONS, filterDocuments, readDocuments, getDocument, readWith, completenessOf, manifestProblems } from "./read-tools.mjs";
 import { PROGRAM_TOOLS, PROGRAM_TOOL_NAMES, PROGRAM_INSTRUCTIONS, callProgramTool } from "./program-tools.mjs";
 import { searchCorpus } from "./search.mjs";
+import { CONFORMANCE_TOOLS, checkPassage } from "./conformance.mjs";
 
 const HERE = dirname(fileURLToPath(import.meta.url));
 const INDEX = resolve(HERE, "..", "dist", "corpus.json");
@@ -111,7 +112,7 @@ const failure = (id, code, message) => send({ jsonrpc: "2.0", id, error: { code,
 
 /* -------------------------------------------------------------------- tools --- */
 
-const TOOLS = [...BASE_TOOLS, ...READ_TOOLS];
+const TOOLS = [...BASE_TOOLS, ...READ_TOOLS, ...CONFORMANCE_TOOLS];
 
 const KNOWN_TOOLS = new Set([...TOOLS, ...PROGRAM_TOOLS].map((t) => t.name));
 
@@ -129,6 +130,10 @@ const callTool = (name, args) => {
         // Shared (read-tools.mjs), and TEXT ONLY since 2.4.2 — see §the-text-never-arrived there.
         return getDocument({ bySlug: bySlug }, args);
     }
+    if (name === "check_passage") {
+        // Shared (conformance.mjs): judges the passage, never who quotes it.
+        return checkPassage({ documents: corpus.documents, bySlug, envelope }, args);
+    }
     if (name === "read_documents") {
         return readDocuments({ documents: corpus.documents, bySlug, version: String(corpus.package_version ?? "") }, args);
     }