How a record is sealed

How the alpha turns one result into a sealed record, step by step, with record 6 of the synthetic sequence SEQ-0914-02 as the example. Every value on this page was computed and checked when the page was built; Check a record recomputes them in your browser.

Five fields, joined with a vertical bar in this order, with no spaces: instrument, measurement type, value, unit and capture time (UTC, ISO 8601). For record 6, a peak area in counts:

instrumentId

HPLC-02

instrument

sensorType

hplc

measurement type

value

1508811

peak area

unit

counts

unit

capturedAt

2026-09-14T08:47:50Z

capture time

The payload is the UTF-8 text below, 48 bytes:

No field may hold the vertical bar or a control character. Otherwise two different records could give the same payload, so a checker fails any record whose fields do.

BasisThe payload the alpha app’s HPLC import seals for each peak area; in the app, the instrument field is its internal instrument number. The alpha records peak area with the unit “counts”.

Injection, sample id and retention time are shown beside each record as context; they are not inside the seal. The alpha app keeps retention time unsealed and does not keep sample or method yet. Sealing sample and method metadata inside the record is upcoming.

r₆ is the SHA-256 of the payload, written as 64 lowercase hex characters:

eb1690bc5922a312d90ee139fdf8e20b92bf2cb0feae8ee0e70bd24fbd2b54d7

Change one character of any field and the fingerprint changes completely. Anyone who has the five fields can recompute it in a UTF-8 terminal:

printf '%s' 'HPLC-02|hplc|1508811|counts|2026-09-14T08:47:50Z' | sha256sum

On macOS, use shasum -a 256. Section 9 explains why a fingerprint is not encryption.

BasisSHA-256, FIPS 180-4, over the UTF-8 bytes as they are, with no Unicode normalization.

Each record also stores a link, h_n. It is the SHA-256 of h_n−1, r_n and n, written one after another as text (lowercase hex, then the decimal position). The first record links to 64 zeros. A record stores the previous link it was built on and its own link; the next record stores that link as its previous one. For record 6:

h₅ · previous link, stored with record 6

c04af03f4b9c69a30d06e27d9906e4e7f2bc176b7ba0a212582ad8c65f6bdfd5

r₆ · fingerprint

eb1690bc5922a312d90ee139fdf8e20b92bf2cb0feae8ee0e70bd24fbd2b54d7

position

6

h₆ · link, carried by record 7

c427b83a4e29adf9380bef67d00302e12ddfd558ae8f5a558547b2b0cf3cba23

printf '%s' 'c04af03f4b9c69a30d06e27d9906e4e7f2bc176b7ba0a212582ad8c65f6bdfd5eb1690bc5922a312d90ee139fdf8e20b92bf2cb0feae8ee0e70bd24fbd2b54d76' | sha256sum

A checker recomputes each record’s link from the previous link that record stores, its recomputed fingerprint and its position. It compares the result with the link the record stores, which is also the link the next record carries. So a changed value fails that record’s fingerprint and signature and breaks only the link into the next record. The later records still pass their own checks.

The change still shows across the whole history. Replayed from 64 zeros over the recomputed fingerprints, the link of the newest record comes out different, so the head no longer matches the anchored fingerprint (section 7).

The links do not show a record that was removed when every later link was rewritten. Each signature covers only its own record’s fingerprint, so that rewrite needs no key. Only a fingerprint anchored beforehand would show it. Signatures that cover each record’s position are an upcoming feature.

Each fingerprint is signed with ECDSA P-256 over its 32 bytes. On these pages, records 1 to 8 were signed when the site was built, by a demo key whose private half was then discarded. Its public key is published on the pages that check it. That shows the method, but it is not independent evidence. In use, the public key would be published outside the lab’s system. Demo signatures. In the alpha, one server key signs imported rows; per-analyst signatures are upcoming.

In the record checker, an edited record’s signature still fails after the history is rewritten, but only because the demo key was discarded. In the alpha, whoever holds the one server key could re-sign an edited record; only a fingerprint anchored outside the lab beforehand would still disagree.

Where your browser can check signatures, every record on these pages is signed, so a record with no signature fails.

A signature made with a system key on a record’s bytes is neither an electronic signature nor a digital signature as 21 CFR Part 11 uses those terms: both identify a person.

BasisECDSA, FIPS 186-5. IEEE P1363 encoding, in its low-S form only. Demo key id 7A15F562…

A record is never edited in place. A correction is a new record, appended after the newest one, with the corrected value, its own fingerprint, link and signature, the reason for the change and the number of the record it corrects. The original stays as sealed and keeps passing its checks. Records 1 to 8 still match the anchored fingerprint (simulated on these pages); the new head is not yet anchored.

On these pages and in the console a correction carries the result’s capture time, not the time it was made. The reason, the reference and the time the correction was made sit beside the seal, not inside it, because the alpha’s payload has five fields. The alpha app has no corrections yet.

A correction made here is signed with a one-time key made in your browser, and its public key travels with the correction. So its signature shows only that the correction has not changed since it was signed, not who may make corrections.

IQC-CK-01Try a correction on a record

Anchoring is an upcoming feature. It will write a batch fingerprint, with a time, somewhere the lab does not control, so that a later rewrite of the history shows. On these pages the batch fingerprint is the link of record 8, the newest record in the batch, replayed from 64 zeros. It is stored on the page as the anchored fingerprint (simulated, no network call).

0a35688a4c3ec82a5e621cede1f173a6d436ade0e20f159dca92c2a3711e3dc1

The first network will be Filecoin Calibration (a public test network). The registry code for that network (a smart contract) is written, but nothing on this site or in the console writes to a network, and no shared registry exists yet. Every anchor here is simulated.

Anchoring will put only a fingerprint on the network, never the values. A registry entry would show that a fingerprint existed by a given time, and the address that wrote it, which links a lab’s anchors to one another; as the registry code is written today, it would also show the first and last record numbers of the batch. It would show no value, and it would not keep the records.

A pass shows

The five sealed fields are unchanged since the record was sealed (fingerprint). The holder of the key signed that fingerprint (signature). The record agrees with the previous link it stores, and the next record with its link (link); only an anchor fixes its place in the history. The replayed history still reaches the anchored fingerprint (anchor; simulated on these pages).

A pass does not show

That the result was right when it was captured: the right sample, a suitable system, correct integration. Who made the record, since signatures are not yet per analyst. Anything about fields outside the seal, such as sample, method or retention time. That no record was removed: a removed record, with every later link rewritten, passes every check but the anchor. That the value was ever measured: a pass shows that a record has not changed since it was sealed, not that an instrument produced it, so a value an agent or a script invented and then sealed would pass too; measured and derived records, which would tell the two apart, are upcoming. With the key and the anchor on the same page, it shows the method, not independent evidence.

A fail shows

Something changed after sealing, and where: which record no longer gives its fingerprint, and which link it breaks. A rewritten history shows as a signature that fails or a head that no longer matches the anchor.

A fail does not show

Who changed it, when, or which value is right. Nor that the change was improper: a correction appended with a reason is the proper route, and it passes.

A fingerprint hides nothing that can be guessed. A plain SHA-256 of a few guessable fields (an instrument id, a measurement type, a peak area in a known range, a capture time to the second) can in principle be matched by trying likely values.

Nothing on this site or in the console writes to a public network. When anchoring becomes available, it will write only a batch fingerprint, never the values. A batch fingerprint of guessable fields can still be tried. So can two anchors one record apart: from the head before and the head after, the one record between them can be found by trying likely values.

Upcoming Salted (hiding) commitments in place of plain fingerprints, so that what is published reveals nothing without the salt the lab keeps; as the leaves of a Merkle batch, they would also let a lab show that one record is in an anchored batch without revealing the others’ contents. Later, zero-knowledge proofs, so that a lab can show a property, such as “within specification” or “reviewed before release”, without disclosing the value.

Storage would follow the same rule as anchoring: nothing readable leaves the lab. An encrypted archive on Filecoin is upcoming; each batch would be encrypted in the lab before upload, with keys that stay in the lab, so the network would hold ciphertext and never results, and content addressing would let anyone who fetches a copy check that it is, byte for byte, the ciphertext the lab archived under that address.

IQC-RD-01 §2.6Privacy on public networks

IQC-RD-01 §2Upcoming, item by item