A handshake, in a protocol, is the part that happens before any real message. Two parties with no prior reason to trust each other establish, in the open, terms that each can verify for itself. It assumes the network is hostile. It is designed to fail loudly rather than quietly.
These are working notes on doing the same thing with records: publishing the constructions, the reasoning behind each choice, and the mistakes found along the way, so that anyone deciding whether to rely on this class of infrastructure can examine the terms first.
Systems that produce evidence have an awkward property: the more important their output, the less their own assurances are worth. A record that matters is a record someone will one day want to dispute, and at that moment every claim made by the party who produced it is exactly the claim under examination. The only statements that survive are the ones a sceptic can check without cooperation.
That is an argument for publishing methodology rather than conclusions. A construction that is described precisely enough to re-implement can be attacked by people who owe us nothing — which is the only review that counts. The notes below are written for that reader: someone deciding whether a construction is sound, not someone deciding whether to buy something.
They are contributed to the Foundation's public record under an open licence. The Foundation is being established under Dutch law as an independent steward of exactly this kind of material — open evidence, open standards, and neutral infrastructure meant to outlive any single company. Papers here describe constructions, not products. Where a construction was developed inside a commercial system, that provenance is stated plainly; where a design decision is a product decision rather than a technical one, it is marked as out of scope rather than dressed up.
Every byte-level claim in these papers is reproducible from the description given. Every defect described is one that was actually found in working code, with the failing input stated. Where a limitation exists, it is named in the paper that would otherwise be read as claiming otherwise — not in a footnote at the end of the series.
Prevention and detection are different security properties with different threat models, and conflating them is the most common error in this field. What a record can prove once you place the database — and yourself — inside the adversary.
Paper 002Hashing a document is the wrong primitive for disclosure: it makes withholding and verifying mutually exclusive. A salted-leaf Merkle construction that survives redaction — and the length-encoding defect that made an earlier version of it silently wrong.
Paper 003The bytes a signature covers should be derived from an enumeration of replay attacks, not chosen for convenience. Each field earns its place — including the one whose absence let a whole history be relabelled as somebody else's.
Paper 004A truncated chain is a valid chain. On the limits of self-checking evidence, the role of an external witness, and why the honest answer to "why not a blockchain" is a transparency log and a countersignature.
Paper 005Governance, liability evidence and agent authority look like one problem and are three. Why they must be separate layers, what they legitimately share, how they compose over a single event — and the custody seam that is still open.
Two categories are absent by design, and it is better to say so than to let a reader hunt for them.
Everything else — the primitives, the byte layouts, the failure modes and the reasoning — is here in full, because a construction you cannot re-implement is a construction you cannot check.
Several papers reference European instruments where they explain why a technical property matters. Those references are contextual and are cited to their published text so a reader can go and read it. They are not legal analysis, they are not advice, and where a legal question is genuinely unsettled the papers say so rather than resolving it in passing.