Trust over time

Suppose you need to convince a sceptical colleague — or your own future self — that a result has not changed. You might ask a notary to witness the document, so an independent party holds proof of what it said on a particular day. You might publish your lab notebook alongside it, so anyone can see your working. And you might sign your conclusions on a separate page, which you later amend with a dated corrigendum instead of quietly rewriting. MTRL builds the same three moves into every archive. They are called receipts, disclosure, and scientific assertions.

The limit of verification

Verification already proves a great deal. When you verify an archive, MTRL re-reads the saved file and checks every payload, record, and revision against the manifest inside it. That proves internal consistency: the archive is exactly what its own manifest says it is.

But the manifest lives inside the same file it vouches for. If someone replaced the whole archive — data, manifest, and all — verification of the replacement would still pass. Nothing inside the file can rule that out. Each mechanism on this page extends trust past that boundary in a different way.

Receipts: an outside anchor in time

A receipt is a small piece of text you keep somewhere separate from the archive. Once a revision (one committed change to the archive) is saved and fully verified, export_receipt produces one. MTRL refuses to export a receipt for a dirty, unsaved, or corrupted copy, so a receipt can never describe work in progress.

The receipt binds three things: the archive identity, the exact revision identity, and the revision root — a digest over the complete state of that revision. It holds no path and no signature. It is plain JSON text, small enough to paste into a notebook, an email, or a register of record.

Later, verification checks the archive against the receipt you kept, not only against itself. If the archive’s revision root matches the receipt, the archive is the one you recorded. If someone swapped in a different archive, the roots disagree and the check fails. The receipt is the notary’s stamp: the archive no longer has to be its own only witness.

A receipt normally covers one exact revision. A second kind, the source baseline, also covers the retained source files and their interpretation metadata for that revision, so the raw evidence behind the numbers is anchored too.

Disclosure: showing your working

An author can attach two kinds of disclosure to an archive. An environment record is the author’s named claim about the computing environment that produced the evidence: a label, a lockfile digest, and optional text. One archive holds at most one. A source bundle is passive source text bound to one exact custom output record, with an entry point name and an honest list of what the capture leaves out, such as helper functions or external dependencies.

Both are stored text and nothing more. MTRL never imports, compiles, or executes them, and every rendering is framed as the author’s claim, not a verified fact. That is transparency without turning an archive into a programme. Because the text is stored verbatim, the author must keep secrets out of it. And because attachments join the integrity inventory, they are as tamper-evident as the data itself.

A bundle stays with the record it was bound to. If you correct that record later, the bundle remains on the historical version and never retargets, so the disclosed source always names the exact data it claims to have produced.

Assertions: recording what it means

Data says what was measured. It does not say what you concluded. A scientific assertion records one typed claim — “this film is PET” — about the sample, one run such as ftir-replicate-01, or one exact record. Each claim carries a namespaced property such as polymer.identity, a value, and evidence links that point at the records or source files the claim rests on. A link can even name an exact record in another archive, and it stays inert: MTRL never opens the other file.

Claims live apart from the data they cite. A claim keeps one identity through its whole life, but every change is a new immutable version. If fresh evidence changes your mind, you supersede the claim. If it was wrong, you retract it with a reason. Nothing is deleted — the corrigendum is dated and filed next to the original. You can ask what was believed at any past revision, and correcting the underlying spectrum never silently rewrites the conclusion that was drawn from it. Like a correction to a record (see Two kinds of identity), amending a claim adds history rather than erasing it.

The thread that joins them

An archive proves internal consistency. A receipt anchors it to an outside point in time. Disclosure shows your working. Assertions record what it all means. Each mechanism is inert and evidence-preserving: a digest you hold elsewhere, stored text, typed claims. None of them executes anything, and none of them asks the archive to vouch for itself alone.

Where next

• Anchor verification with receipts — export a receipt and verify an archive against it later.
• Record scientific assertions — attach typed claims to a sample, run, or record.