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]
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.
- Egress as a recorded fact on the conversion, with a status for every page. A declared field, checked before a provider authenticates and written onto the result: enforcement of a declaration, not proof of one. Paper 002 §3 gives the rungs.
- Determinism. The same bytes give the same Markdown — asserted in documentation rather than demonstrated by a published corpus, the property tests that would pin it planned rather than run, and table column alignment dropped on emission, denting idempotence.
- Measurement with the counter the claim is about. Stated against native document upload on one vendor's models; on a vendor billing a flat rate per page the sign reverses. Paper 001 carries the figures and the spread.
- Estate economics on CPUs inside the building. CPU-bound and per core, with no GPU in the path.
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:
- Whether a generated description can be kept below
certainand 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. - 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.
- 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.
- 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.
- 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.
- 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.
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
- 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.
- 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.
- Anthropic, Prompt caching, Claude Developer Platform documentation, platform.claude.com/docs/en/build-with-claude/prompt-caching, read 11 September 2026.
- 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.
- 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.