Roadmap

• These pagesOne synthetic HPLC sequence, sealed with the alpha’s five-field payload and link rule from 64 zeros, signed with a demo key at build, with a simulated anchor. Your browser recomputes every check.
• Alpha console · demoA synthetic lab that runs only in your browser: records sealed and linked, signed with a demo key made in your browser, corrections appended with a reason, and every check recomputed after each change. Its anchor is simulated, with no network call.
• Alpha app · not publicImports HPLC CSV files, then fingerprints, links and signs each peak area with one server key, using the same payload construction and link rule.

DemoOpen the alpha console

The automated-lab items first, then the rest; no dates. Each item is labeled Upcoming until it works.

In an automated lab, software already sits between the instrument and the record: the scheduler or orchestrator, the device drivers and the data pipeline. Sealing each result there, when it is produced, is the plan: the orchestrator or driver would fingerprint, link and sign a result before anything downstream could change it, so the window for an unnoticed change would close at capture rather than at import. SiLA 2 and OPC UA LADS are the two device standards an adapter would speak; the first adapter would seal the results of one SiLA 2 device, through the orchestrator, into a record history that would also carry the sample, the well or position and the method inside the seal (2.13). What happens before capture (a swapped sample, a miscalibrated instrument, compromised robot software) would still not be covered.

A fingerprint shows that a record has not changed since it was sealed, not that it was ever measured. So only a record sealed at capture, by the instrument’s or orchestrator’s key, would count as measured. Anything an agent, a script or an analysis produces would be a derived record, under a different signer, and would have to cite the fingerprints of the sealed records it came from. A number an agent gives either traces back to a measurement or it does not; one that does not would be flagged before use. That would expose an invented or hallucinated value with no measurement under it, which hashing alone cannot catch. A derived number that cites real measurements but was computed or copied wrongly would still pass, so a checker would re-run the analysis from its cited inputs where it is deterministic. All of this would hold only if agents and scripts cannot use the capture key: it would live in the driver or adapter alone, sign only what the device returns, and seal the device’s identity with each result.

Because a derived record would cite its inputs, records would form a lineage graph: measurement to analysis to model to decision. When a measurement is found wrong and corrected, its reach would be computable in one step: every analysis, model and decision recorded as a derived record that cites it, and which agents must re-check. It would be a data recall, like the impact assessment of an out-of-specification investigation, but automatic, and it would reach only work recorded that way: an analysis done in a notebook or a spreadsheet outside the sealing library would stay invisible to it. Until then, a correction appended with a reason (How a record is sealed, section 6) marks the wrong value, and finding what used it is still a search.

Verified experiment data that AI agents would check before they use it in research and work: the four checks shown on Check a record and, with measured and derived records (2.2), whether a number traces back to a measurement at all.

Check a record shows one record the way an agent would receive it, as JSON. It is a preview, not an API. It would need a documented record schema, keys published outside the lab and a shared registry first.

IQC-CK-01 §2The agent-readable record

Today a batch fingerprint is the link of its newest record: one value for the whole run, which shows that the run is intact but nothing about one record without the rest. A Merkle tree would commit to a whole run in one 32-byte root, and a short path of hashes would show that one record is in the anchored batch without revealing the others’ contents (it would show how many records the batch holds, and this one’s place): an inclusion check, for selective disclosure. Every leaf would be salted, so the salted commitments of 2.6 would be the leaves of this tree. Each anchored root would also commit to the root anchored before it, so the anchors would form one sequence that a dropped batch or a restored backup would break, much as Certificate Transparency checks one growing tree against its earlier heads. The construction would be the tree hash of RFC 6962, kept in RFC 9162, with domain separation between leaves and inner nodes and no duplicated leaf, as Certificate Transparency logs and Sigstore’s Rekor use it.

Anything written to a public network should reveal nothing about results. A plain SHA-256 of a few guessable fields can in principle be matched by trying likely values, so a plain fingerprint is not enough. When anchoring becomes available it will write only a batch fingerprint, never the values; even so, two anchors one record apart would let the record between them be tried the same way.

• FirstSalted (hiding) commitments in place of plain fingerprints; they would be the leaves of a Merkle batch (2.5). The lab keeps a random salt, and what is published reveals nothing without it.
• LaterZero-knowledge proofs, so that a lab can show a property, such as “within specification” or “reviewed before release”, without disclosing the value.

Anchoring will write a batch fingerprint, with a time, to a registry on a public test network, so that a later rewrite of the record history shows against a fingerprint the lab does not control. The registry code (a smart contract) is written; nothing on this site or in the console writes to a network, and every anchor shown here is simulated. As the registry code is written, an entry would also show the address that wrote it, which links a lab’s anchors to one another, and the first and last record numbers of its batch. A test network can be reset, so this is a first step; anchoring on Filecoin itself would follow.

IQC-HS-01 §7Anchoring a batch

Three storage tiers would be offered, chosen per lab. Anchor only, the default: the records would stay in the lab’s own systems, and only batch fingerprints would leave it. An encrypted archive on Filecoin: each batch would be encrypted in the lab before upload, with keys that stay in the lab, so Filecoin would hold only ciphertext and never readable results; content addressing would let anyone who fetches a copy check that it is, byte for byte, the ciphertext the lab archived under that address, once the address is sealed and anchored with its batch; that it holds the sealed records would be checked in the lab, after decryption, against their fingerprints. Or the lab’s own storage, in the same encrypted form. Storage deals on Filecoin have a term and must be renewed, so an archive there would last only while the lab renews its deals, with more than one storage provider, and keeps its keys; the lab’s own copy would stay primary.

Each analyst would sign with their own key, in place of the one server key. Electronic signatures under 21 CFR Part 11 need more than a key: verified identity, the signature’s meaning, and controls over credentials.

Today each signature covers only its own record’s fingerprint, as in the alpha app. So a record removed, moved or copied to a second position, with every later link rewritten, passes every check except an anchor taken earlier, and that needs no key. Signing the record’s link, which depends on its position and on every record before it, would show that change without an anchor to anyone without the signing key; a rewrite by whoever holds it, or records dropped from the end, would still show only against an anchor. It would change the alpha app and these pages together.

Second-person review recorded as a signed record that names the records it covers, signed with the reviewer’s own key.

The alpha app recomputing every fingerprint, link and signature on the server, as these pages and the console do in your browser.

Sample, method, injection and retention time sealed inside each record, not shown beside it; and a correction’s reason and reference sealed with it.

One public registry of batch fingerprints, which anyone would be able to check; no lab would have to run its own.

Long term. SHA-256 and Merkle trees would hold up against a quantum computer; the ECDSA P-256 signatures are the part one would break. First would come algorithm agility, an algorithm id on every signature, so that a record says what signed it. Then hybrid signatures would follow, ECDSA plus ML-DSA (NIST FIPS 204), or SLH-DSA (FIPS 205, hash-based, a natural fit for a construction built on hashes), and old records would be re-anchored under the stronger algorithm, with what is anchored covering each record’s signature as well as its fingerprint, as long-term archive standards do (RFC 4998). An encrypted archive would use AES-256-GCM for the data, under keys that stay in the lab: stored ciphertext is a harvest-now, decrypt-later target, and AES-256 would hold up against it. Wherever a data key had to be sent to someone else’s public key, such as a client’s or a second site’s, ML-KEM (FIPS 203) would wrap it, alongside a classical key exchange and never RSA or elliptic-curve key exchange alone.

Nothing is in production use. There are no customers, no electronic signatures, no validation, no capture at the instrument or orchestrator, no archive on Filecoin and no post-quantum signatures, and nothing on this site writes to a public network.