Digital One Foundation The Text Layer
Paper 004 · Research

Properties, not promises.

Extraction from a text layer is deterministic and checkable; past it, questions are open. Where converted Markdown should live is the corpus owner's question, and the record is the canonical Markdown and a hash over it: every index above that pair can be dropped and rebuilt from it. Repetition across an estate is the part an archive could compress, and the archive must reproduce the canonical bytes exactly; no compression figure appears here. Egress declared as a field and written onto the conversion is a property, not a promise, because a policy says where pages are allowed to go and a record says where they went.

§1What is open past the text layer

Everything in Paper 001 and Paper 002 describes a floor rather than a finished thing. Extraction from a text layer is deterministic and checkable — a value can be traced to the row it was printed in — while anything said about a picture is generated, and is a claim. Three questions sit past that line and none is answered here: how a description of a figure might reach a model honestly, labelled as derived, kept below certain, carrying a way back to the pixels; where converted text should live once there is a corpus of it; and what an estate's own repetition makes compressible. They are the subject of Paper 003 and of this paper, marked in both as open research rather than as results. None of them exists in the code these notes draw on.

§2Where the Markdown should live

Today the engine returns Markdown and a structure map and stores nothing, a decision rather than an omission: the moment an engine embeds, it needs a model, a store and a network, and the property being protected — that documents stay inside the operator's perimeter and jurisdiction — is gone.

So the question belongs to the corpus owner: a document store, one record per source with sections addressable by heading path; a vector index, chunks mapped to embeddings; or both. They are the same kind of thing — derived indexes over a canonical text — since an index adds no information and dropping it deletes nothing, because it rebuilds.[1] A vector index is derived twice over, the boundaries a pipeline decision and the embedding a model's output.

The record is the canonical Markdown and a hash over it. Every index above that pair is a derived structure that can be dropped and rebuilt from it. The discipline that follows is exact: whatever an index returns must be re-findable in the record, or it has left the chain — and a store that cannot name the bytes its answer came from has quietly become the record itself. A direction, not a decision, taken jointly by those who own the corpus.

§3Repetition is the compressible part

Estates repeat themselves — running headers and footers, boilerplate clauses, recurring tables, template pages. Inside one PDF the engine already strips headers, footers and page numbers, and because that is the one pass that deletes text, dropped lines are warned. Across documents it does not look.

Content-defined chunking sets block boundaries from the bytes rather than from position, so a repeated block gets the same boundaries wherever it sits; content addressing makes a block's identifier the hash of its contents, so duplicates coalesce and corruption shows on read.[2] A repeated clause is then stored once and referenced by hash — cacheable, and more to the point checkable. The chunk sizes and window widths in that work were tuned for source trees over slow links, so no compression figure appears here: none has been measured on a Markdown corpus.

Prompt caching has the same shape and not the same lifetime: a hit requires byte-identical segments, and the default is five minutes, an hour at additional cost.[3] A cache is a cost instrument with a horizon in minutes; an archive is a record. What repetition invites is an archive format for Markdown corpora: dictionary compression across documents, block-level deduplication, an index. The dictionary format RFC 8878 specifies travels out of band, identified by an ID the decoder checks, and that specification leaves its provisioning "being explored".[4]

What must never be traded away

The archive must reproduce the canonical bytes exactly. A reference is a commitment, not a summary; a deduplicated block that is "close enough" is an edit, and an edit breaks every hash above it. Content addressing is parameter-sensitive too: identical text under different hash, chunking or encoding settings gets different addresses,[5] so a format has to pin all three. None of this is built.

§4A record says where pages went, not that the lines are right

Egress declared as a field and written onto the conversion is a property; "documents stay in Europe" is a promise. A policy says where pages are allowed to go, a record says where they went, and the two are indistinguishable while nothing goes wrong.

The fifth property is the record itself, and its limit belongs in the same breath. Paper 004 of The Project Handshake gives the general form: a record shows what was done, not that it was right. A conversion record shows that a page went to a local binary and how confident that binary reported itself to be, not whether the lines it returned are the lines on the page.

// what a conversion record carries today · fields present where each step ran
meta.source_sha256    60b30efa…d814c89   // rfc9110.pdf, 194 pages
structure.converted   {converter, converter_version, risk, endpoint}
structure.ocr         {provider, provider_version, egress, endpoint, pages.*}
                      // page text deliberately absent
blocks[*].confidence  1.0 certain · 0.75 inferred · 0.45 guessed · 0.2 salvaged
blocks[*].enhanced    // false on every block: the tier does not exist

// needed, and not there
a hash of the Markdown that came out
the engine release, which the documented response has no field for
per derived block: page · bounding box · raster sha256
an open schema anyone can implement and check

Those last four lines are the proposal. What does not exist is an agreed shape: an open schema for conversion records — the fields, the hashes, how a derived block points back to its raster — is the kind of open standard the Foundation being established is meant to steward. These notes propose only that it should exist.

§5An honest ledger of what is open

Collected here, because a reader deciding what to demand is entitled to them together, each with what would settle it and who decides:

  1. Whether a generated description can be kept below certain and still be worth having. Settled by a tier shipping with every touched block marked and capped, falsified if the cap is lifted. The engine's owners decide.
  2. Whether chart-to-table and diagram-to-graph can be scored on an estate's own documents. Settled by ground truth that does not exist yet, and a margin over the baseline. The estate owner decides, and pays for the annotation.
  3. Where the canonical Markdown lives, and what is derived from it. Falsified by an index whose results cannot be re-found in the record. The corpus owner decides.
  4. Whether chunking and dictionary compression pay on Markdown corpora. Settled by measurement on a named corpus, of which no figure exists, and falsified if body repetition proves smaller than the furniture already stripped. Whoever runs it decides.
  5. Whether a declared egress can be enforced below the engine. Settled at the operating-system boundary, where a service unit can deny a converter the network; the engine declares and records, and cannot prove. The operator decides.
  6. Whether an open schema can be written so that two implementations agree. Settled by two independent implementations checking each other's records, and held by a body that owns no product — the Foundation being established, if those establishing it so decide.

Nothing above is committed: the decisions are joint, and these notes take none of them.

On the provenance of this material

The engine these notes draw on is crunch.md, a Digital One product. Its core engine and MCP server are Apache-2.0-licensed and run offline; the hosted service is proprietary, and the repository is to be published at a named milestone rather than readable today, so that licence is a statement of intent rather than something a reader can check today. What is published here is method and open questions, not a product argument. Deliberately absent: prices, plans and tiers, and deployment internals.

References

  1. M. Kleppmann, Turning the database inside-out with Apache Samza, 4 March 2015, martin.kleppmann.com/2015/03/04/turning-the-database-inside-out.html, read 11 September 2026.
  2. A. Muthitacharoen, B. Chen, D. Mazières, A Low-bandwidth Network File System, §3.1, pdos.csail.mit.edu/papers/lbfs:sosp01/lbfs.pdf; and S. Quinlan, S. Dorward, Venti: a new approach to archival storage, FAST 2002, usenix.org/legacy/publications/library/proceedings/fast02/quinlan/quinlan.pdf. Both read 11 September 2026.
  3. Anthropic, Prompt caching, Claude Developer Platform documentation, platform.claude.com/docs/en/build-with-claude/prompt-caching, read 11 September 2026.
  4. Y. Collet, M. Kucherawy (ed.), Zstandard Compression and the 'application/zstd' Media Type, RFC 8878, February 2021, Informational, §5 and §6, rfc-editor.org/rfc/rfc8878, read 11 September 2026.
  5. Content Identifiers (CIDs), IPFS documentation, "Content addressing": the identifier depends on the hash function, the chunking and the codec as well as the bytes, docs.ipfs.tech/concepts/content-addressing/, read 11 September 2026.