- Document
- IQC-AB-01
- Revision
- Draft 6
- Updated
- 2026-10-07
- Status
- Independent project · Open alpha · Synthetic demo data · No customers yet
- Use
- Informational draft. Not a controlled document; not a regulatory assessment or a validation statement.
About
1Who builds it
Immutable QC is built by José A. Fernández Abreu. For contact, and for more about him and his work, see joseqc.com.
2Independence
Immutable QC is an independent project built on the founder’s own time. It is not affiliated with or endorsed by any employer.
3Status
Independent project · Open alpha · Synthetic demo data · No customers yet
The demo data is synthetic. Nothing on this site is validated for regulated use.
4Why it exists
In an automated lab, results arrive faster than anyone can review them, and models train on them and choose the next experiment. In a regulated lab, work that is not documented is treated as not done. Both already keep records; the aim is a record that someone outside the system can check from the record itself: a reviewer, an auditor, a model, or an AI agent.
5Questions
5.1What kinds of labs is this for?
Automated research labs first: biotechnology, microbiology, chemistry and materials science, where self-driving labs, robotic workcells, cloud labs, AI-first research companies and CROs that hand automated data to clients produce results faster than people can review them, and models train on them. The founder’s own background is materials science, chemistry and microbiology. Regulated QC labs are the expansion path, not the opening; the Regulatory map is written for them.
5.2Do I need to buy or hold anything?
No. There is nothing to buy, hold or connect. These pages and the alpha console run in your browser, with no sign-up.
5.3Is my data put on a blockchain?
No. Nothing on this site or in the alpha console writes to any network, and the values you enter stay in your browser. Anchoring is an upcoming feature. By default it will put only one batch fingerprint, a 64-character code for a whole run of records, on a public test network (a blockchain run for testing). A lab that chooses the encrypted archive, also upcoming, would store its records on Filecoin too, encrypted in the lab first and never readable there. On this site and in the console the anchor is simulated.
5.4Does it replace my orchestrator, ELN, CDS, LIMS or audit trail?
No. Today it sits beside an HPLC CSV export; upcoming, it would sit in or beside the orchestrator and hand each sealed result on unchanged. The alpha app fingerprints, links and signs each imported peak area with one server key; checking them in the app is upcoming. Your orchestrator, CDS audit trail, ELN, LIMS, SOPs and validation stay as they are. In the alpha the fingerprint covers five fields: instrument, measurement type, value, unit and capture time, joined by a vertical bar and hashed with SHA-256; sample, injection and retention time are shown for context only, and sealing sample and method metadata is upcoming.
5.5Can I use it for GMP records today?
No. It is an open alpha on synthetic data: not validated, with no electronic signatures, no user accounts and no capture at the instrument or orchestrator. Use it to judge the approach, and keep regulated records in your validated systems.
5.6What if someone edits the database directly?
The edited record no longer matches its fingerprint, its signature fails, and the link into the next record breaks. Someone who also rewrites every later link and re-signs with the signing key can make the history consistent again. Deleting a record and relinking the ones after it needs no key at all, because each signature covers only its own record’s fingerprint. In the alpha one server key signs, so whoever holds it could do either. Only a fingerprint anchored outside the lab beforehand would still show it, and anchoring is upcoming.
5.7What about sabotage and espionage?
Most bad data is not malicious: a script, a sync conflict, a crash, a restored backup, a migration or a model that filled in a blank. Sabotage is the minority case, and the same checks cover it, within limits.
Detected today, wherever the checks are run (these pages, the console, or the recipe in How a record is sealed; checking in the alpha app is upcoming): a sealed value changed after sealing by anyone without the signing key, whoever it was and why; the fingerprint, the signature and the link into the next record fail. A history rewritten with the key would show only against an anchor taken earlier. A record deleted, moved or copied, with the rest relinked, needs no key today; it would show against an earlier anchor too, and through signatures that cover each record’s position when done by anyone without the key. Both are upcoming.
Not detected: anything before sealing, such as a swapped sample, a miscalibrated instrument or compromised robot software. In the alpha app, records are sealed at import; sealing at capture (upcoming) would narrow that window, not close it.
Espionage is not detected: a seal makes a change show, not a copy. What limits it is that nothing readable leaves the lab. Anchoring would put only a fingerprint on a public network, and once salted (upcoming) it would reveal no value; values would leave only encrypted in the lab, with keys that stay there, and only if the lab chooses the encrypted archive (upcoming). Protecting the records, the keys and the people who hold them stays with the lab; Immutable QC would be one part of that, not a security program.
6Sources and licenses
SHA-256: FIPS 180-4. ECDSA: FIPS 186-5. Fonts: IBM Plex Sans, IBM Plex Mono and Archivo, self-hosted under the SIL Open Font License 1.1; the license texts are linked in the footer. No third-party requests, no analytics and no cookies.
7Revision history
| Revision | Date | Change |
|---|---|---|
| Draft 6 | 2026-10-07 | Repositioned for automated research labs: the Scope names the audience; the Overview gains section 2, “Why: one wrong value snowballs”, with the founder’s line, redraws Where it fits for an automated lab (today beside an HPLC CSV export; sealing at the orchestrator or driver, upcoming), moves the regulatory position to “When your process moves into GMP” and renumbers the later sections; the Roadmap adds sealing at capture, measured and derived records, lineage and recall, Merkle batches with salted leaves and post-quantum signatures and encryption, and rewrites Filecoin integration as an encrypted archive on Filecoin, all Upcoming, with the automated-lab items first; How a record is sealed says a pass does not show that a value was ever measured, what a registry entry would show, and that nothing readable leaves the lab; About adds two questions, on the kinds of labs it is for and on sabotage and espionage, and folds “What does a fingerprint cover?” into the question on the orchestrator, ELN, CDS and LIMS. |
| Draft 5 | 2026-10-07 | The Overview gains section 2, “How a result becomes a sealed record”, which walks record 6 through seven animated steps (captured, fingerprinted, signed, linked, a change, a correction, and what is upcoming) with every value computed at build; the later sections and figures are renumbered. |
| Draft 4 | 2026-10-07 | Adds one upcoming item, signatures that cover each record’s position, so a removed or moved record shows without an anchor; How a record is sealed links to it. Today’s signatures still cover only each record’s own fingerprint, as in the alpha app. |
| Draft 3 | 2026-10-07 | Everything not built yet is labeled Upcoming, under one label, and the Scope states anchoring as upcoming; the status line no longer names a test network; the Roadmap lists nine upcoming items; on the Regulatory map, clause numbers stay only where confirmed and “Not covered” replaces “Not yet”; the alpha app’s capture time, and what a removed record shows, described as they are; a missing signature, or a field holding the separator, now fails its check; corrections need a reason of at least three words and, in the console too, carry the result’s capture time, not the time they were made; the console can simulate a deleted record; the set is marked informational, not a controlled document; GitHub Pages publishes only the built site, through GitHub Actions. |
| Draft 2 | 2026-10-06 | Full document set: every page written in full; Fig. 2 Record history on the Overview; one ring-and-dot mark for the nav, favicon and og card; the auditor’s link rule (a changed value breaks only the link into the next record); the privacy roadmap item; a regulatory map clause by clause; the alpha console reworked as an in-browser demo and linked again. |
| Draft 1 | 2026-10-06 | Prototype of the document set: Overview and Check a record in full; How a record is sealed, Regulatory map, Roadmap and About in outline. Not published. |
The document set stays in draft until the founder publishes a first release. It is informational: not a controlled document, and not a regulatory assessment or a validation statement.