Records that cannot drift

Everything a record says about where a result came from is a reference to something outside it, which makes each of those references load-bearing. A citation is a promise that someone else can go and look. The promise holds only while what is at the other end is still what the author saw. Papers are revised, files are edited in place, branches move, repositories are rewritten or deleted. A reference to “the configuration in the repository” or to “the paper” names something that can be different tomorrow, and a reference like that is not really a citation.

What that costs is the ability to check. When a later reader cannot get the same number, and the inputs may have changed since, there is no way to tell a wrong result from a moved one. Drift does not announce itself.

Where it is, and what it was#

Two different bindings hold a reference still, and they do different work.

• An address says where something is: a URL, a Git commit, an arXiv revision number, the identifier of a record. It is how anyone finds the thing again.
• A digest says what something was: a short fingerprint computed from the bytes by a cryptographic hash function such as SHA-256. Identical bytes always give the same digest, and a change of one character gives a different one.

Neither replaces the other. An address can be re-pointed: a branch moves, a tag is re-cut, a history rewrite leaves different content at the same path. Even an address that names an immutable object, a full commit or a specific arXiv revision, depends on custody, because the repository can go private or be deleted and the address then answers nothing. A digest survives all of that and goes on describing the bytes exactly, but on its own it tells nobody where to get them. Drop the address and the reference is unresolvable; drop the digest and it is unverifiable.

Git shows the pairing working. It stores file contents as objects named by a hash of the content, separately from the commits that mention them, so a history rewrite that leaves a file byte-identical leaves that content findable, while a rewrite that actually changed the file breaks the binding, which is exactly when it should break.

What a digest can and cannot tell you#

Content addressing takes the idea one step further: rather than name a thing and record its digest beside the name, use the digest as the name. Two parties who never met agree on what sha256:0ebb4d… refers to without consulting a registry, because the identifier is derived from the content itself.

For structured data the bytes have to be pinned down first. Two JSON documents that are equal as data can differ in key order or whitespace and hash differently, so what gets hashed is a canonical form: one fixed serialisation, keys sorted, numbers written one way.

What that buys is narrow and exact. A digest detects change. It does not say the content is right: a transcription error hashes as cleanly as the correct number, and a digest over a fabricated results file is a perfectly good digest of a fabrication. Nor does it capture meaning. Two runs that reported the same measurements can differ in a timestamp field and carry different digests, while a digest computed over the meaningful values alone would show them equal.

It also matters who computed it. A digest you are handed is a claim, part of the record like any other author-supplied value. A digest you recompute from bytes you fetched yourself is a check, and that is the only moment at which anything is actually verified. A system that stores digests and never fetches the bytes is keeping the author’s statements about content, not testing them.

How a record is pinned#

Every publication admitted to a Room is an exact version ●Exact versions: Live: an address of its own, a content digest over its canonical JSON, and no edit path. Correcting a record means publishing another one, so anything that already points at the first keeps meaning what it meant.

Because there is no editing, everything that refers to a record refers to one version of it and never to whatever is latest ●Reuse into Threads: Live: reusing a publication in another Thread or Room, naming a premise inside a new record, letting another assertion take part in this one as a value.

Outside the record, the pin is whatever the thing itself supports.

Two constructed examples#

A pin that catches drift. A constructed example: a finding reports an error rate, and the attempt behind it consumed the training configuration as a material identified by a digest of that file. Later someone repeats the work, hashes the configuration at the path the location report gives and gets a different digest. The file was edited in place after the finding was published. Nothing is lost: the mismatch is visible, and the question becomes which configuration the number belongs to. Had the record named only a path on a branch, the second run would have used a different configuration, reported a different number, and the disagreement would have looked like a failed reproduction.

A pin that cannot save you. A second constructed example, in the same Room: the repository is deleted, or rewritten to remove data that should never have been public. The digest still says exactly what the bytes were, but no copy of them is reachable. Nothing in the record becomes wrong, and nothing in it notices either: where a material can be found is a matter of attributed reports ●Location reports and obtainability: Live, so it takes a member who looked and filed a fresh one for the record to say the copy has gone. A pin is a binding, not a copy. It tells you whether what you have is the thing; it cannot produce the thing, and the permanence of a reference is not the permanence of what it refers to.

What a pin does not prove#

Pinning is about identity, not quality. An exact version says that this wording, these numbers and these references were admitted together and have not moved since. It says nothing about whether the experiment ran as described or the measurement is sound, and a record dense with digests can look more reliable than a plain one without being so.

Substrate re-derives no digest from anyone’s files. It stores no bytes, fetches no location and opens no evidence file: the identities and digests in a record are the author’s, checked for shape and never recomputed. Of the addresses, only a pinned repository is checked against the world, and only for reachability — that it is public and that the commit resolves in it. That bounds what agreement means. Two attempts whose outputs carry the same digest have reported the same bytes, which is a fact about bytes; whether that amounts to a reproduction is a judgement someone makes and states in a finding.

Further reading#

• Scott Chacon and Ben Straub, Pro Git, Git Internals: Git Objects, on content-addressed storage under a version control system
• Anders Rundgren, Bret Jordan and Samuel Erdtman, RFC 8785: JSON Canonicalization Scheme
• arXiv, Submit a new version of a work, on why every change makes a new version and why earlier ones stay public

In Substrate#

• Publishing. What a record carries is on Findings and cited claims; the version id, family id and content digest, and how to point at them, are on Reuse and exact versions.
• Pinning inputs and outputs. Material identities, location reports and values digests are on Materials and provenance, and the commits that plans and attempts name on Attempts and the capture adapter.
• Correcting without editing. A record is never rewritten; a later record and an attributed link say what changed, on Corrections, disputes and retractions.
• Author-curated. The author is responsible for the content; Substrate checks structure, attribution and permission to publish, not the science. Immutability makes a claim checkable later; it does not make it true.

Open question#

A record is permanent, but the world it points at is not: repositories disappear, and restricted or personal data can force a rewrite that breaks every pin made against it. What a record should do when its evidence stops being reachable, and how much of the permanence a pin promises an archive can actually keep, is on the laboratory’s research agenda.