Immutable QC
Document
IQC-RM-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.

Regulatory map

1Scope

Built toward the audit-trail expectations of 21 CFR Part 11, EU Annex 11 and ISO/IEC 17025:2017. Not validated. No electronic signatures yet. Not a substitute for your computerized-system validation or SOPs.

For each expectation: what it asks, in plain words; how Immutable QC approaches it; what exists today; and what it does not cover. A clause number is given only where it is confirmed; elsewhere the standard is named and the expectation paraphrased. This is a reading aid, not a claim that anything here meets an expectation. Check each one against your own copy of the text and the edition you work to.

LegendToday means the open alpha: these pages, the alpha console (a demo in your browser) or the alpha app (not public), as stated. Not covered lists what Immutable QC does not do; items tagged Upcoming are listed in the Roadmap, and the rest are not. All demo data is synthetic.

221 CFR Part 11

2.1Validation; discerning altered records §11.10(a)

Expectation
Systems are validated for accuracy, reliability, consistent intended performance and the ability to discern invalid or altered records.
Approach
Each record carries a SHA-256 fingerprint of its sealed fields, a link to the record before it and a signature, so an altered record fails its own checks and breaks the link into the next record.
Today
The checks run on these pages and in the console demo, on synthetic data. The alpha app fingerprints, links and signs each imported peak area.
Not covered
Validation of any kind; Immutable QC is not validated. Server-side verification in the app Upcoming

2.2Protection of records for retrieval

Expectation
Records are protected so they can be retrieved accurately and readily throughout the retention period.
Approach
Fingerprints show whether a retrieved record still reads as it was sealed. They do not keep the record.
Today
Nothing beyond the check itself. The console keeps its synthetic lab in your browser only.
Not covered
Storage, backup, retention and archiving.

2.3Limiting system access

Expectation
System access is limited to authorized individuals.
Approach
Not addressed. Per-analyst signatures would tie each record to the key that signed it, which is not access control.
Today
None. There are no logins, and the alpha app’s interfaces are open.
Not covered
Authentication, roles and access control.

2.4Audit trails §11.10(e)

Expectation
Secure, computer-generated, time-stamped audit trails independently record the date and time of operator entries and actions that create, modify or delete records. Changes do not obscure what was recorded before.
Approach
A correction is a new record with a reason; the original stays readable and keeps passing. A record changed after sealing fails its checks. A removed record, or a history rewritten to hide a change, shows only against a fingerprint anchored beforehand (anchoring is upcoming; simulated on these pages).
Today
Corrections with a reason on these pages and in the console demo. The reason and the correction time sit beside the seal, not inside it.
Not covered
Operator identity. A trusted time source: in the alpha app the capture time is an injection time typed at import, or the server’s clock if none is given, the same for every peak in a file. Corrections in the alpha app.

2.5Controls for open systems

Expectation
Additional measures, such as document encryption and appropriate digital signature standards, ensure record authenticity, integrity and, where needed, confidentiality.
Approach
ECDSA P-256 signatures (FIPS 186-5) over each record’s fingerprint. When anchoring becomes available, only a fingerprint will go on a public network, never the values; values would leave the lab only encrypted, and only if the lab chooses the encrypted archive (upcoming).
Today
Demo keys only: a build-time key on these pages, a key made in your browser in the console, one server key in the alpha app.
Not covered
Managed keys and encryption. Per-analyst signatures Upcoming Privacy on public networks, with salted commitments in place of plain fingerprints Upcoming

2.6Signature manifestations and linking §11.50, §11.70

Expectation
A signed record shows the signer’s printed name, the date and time, and the meaning of the signature, such as review or approval. Signatures are linked to their records so they cannot be excised, copied or transferred.
Approach
An ECDSA signature over a record’s fingerprint covers exactly those sealed fields and fails on any other.
Today
Demo signatures that cover the fingerprint. 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.
Not covered
Signer name, signing time and meaning. Reviewer sign-off Upcoming

2.7Electronic signatures

Expectation
Electronic signatures are unique to one person, the person’s identity is verified, and identification codes and passwords are controlled.
Approach
Per-analyst signatures and reviewer sign-off are upcoming; an electronic signature needs more than a key.
Today
None.
Not covered
Electronic signatures of any kind.

3EU GMP Annex 11 (2011)

A revised Annex 11 has been in consultation; check the numbering against the edition you work to.

3.1Validation

Expectation
Computerized systems are validated across their life cycle, with documented evidence.
Approach
The method is public, and every value on these pages is recomputed in your browser and at build.
Today
Build-time checks of the demo data and the page’s own functions.
Not covered
Validation of any kind; Immutable QC is not validated.

3.2Data storage

Expectation
Data are secured against damage, and checked for accessibility, readability and accuracy throughout the retention period.
Approach
Fingerprints let stored data be checked against what was sealed.
Today
The check, on demo data.
Not covered
Storage, backup and restore.

3.3Audit trails §9

Expectation
Based on risk, the system records GMP-relevant changes and deletions; for a change or deletion the reason is documented. Audit trails are available, intelligible and regularly reviewed.
Approach
Corrections are appended with a required reason; the original stays. A deleted record, or a history rewritten to hide a change, shows only against a fingerprint anchored beforehand (anchoring is upcoming; simulated on these pages).
Today
On these pages and in the console demo, with the reason and the correction time beside the seal, not inside it.
Not covered
Who made the change; review of the audit trail; corrections in the alpha app. Reviewer sign-off Upcoming

3.4Security

Expectation
Physical or logical controls restrict access to authorized persons, and the system records the identity of operators entering, changing, confirming or deleting data, with the date and time.
Approach
Not addressed. Per-analyst signatures would record which key signed each record, which is not access control.
Today
None.
Not covered
Access control and operator identity.

3.5Electronic signature §14

Expectation
Electronic signatures have the same impact as handwritten ones within the company, are permanently linked to their record, and include the time and date they were applied.
Approach
An ECDSA signature over the fingerprint is bound to the record’s sealed fields.
Today
Demo signatures only; no person signs anything.
Not covered
Electronic signatures.

3.6Archiving

Expectation
Archived data are checked for accessibility, readability and integrity, including after changes to the system.
Approach
A fingerprint and a link can be recomputed years later with standard tools, without the original software.
Today
The recompute recipe on Check a record.
Not covered
An archive, and a documented export format.

4ISO/IEC 17025:2017

4.1Technical records

Expectation
Technical records include the date and the identity of the personnel responsible for each activity and for checking data and results. Original observations, data and calculations are recorded when they are made.
Approach
The capture time is one of the sealed fields.
Today
In the alpha app the capture time sealed with each peak area is an injection time typed at import, or the server’s clock if none is given, the same for every peak in a file. It is not read from the export or from the instrument.
Not covered
Personnel identity; sealing at capture Upcoming; reading the injection time from the export; a trusted clock.

4.2Amendments to technical records

Expectation
Amendments can be tracked to previous versions or original observations. The original and amended data are both kept, with the date of the change, what was changed and who made it.
Approach
A correction is appended as a new record that names the record it corrects; the original is kept as sealed.
Today
On these pages and in the console demo. The correction carries the result’s capture time, not the time it was made, which sits beside the seal.
Not covered
Who made the change. The reason and the correction time are not sealed; sealing them is part of sample and method metadata in the seal Upcoming

4.3Validation of the information system

Expectation
The laboratory information management system is validated for functionality before it is introduced, and after changes.
Approach
None; Immutable QC would sit beside a validated system, not replace it.
Today
None.
Not covered
Validation.

4.4Protection and integrity of data

Expectation
The system is protected from unauthorized access, safeguarded against tampering and loss, and maintained so that the integrity of data and information is ensured.
Approach
Tamper-evidence. A change after sealing shows in the record’s checks and, once anchoring becomes available, against an anchored fingerprint.
Today
Tamper-evident record history on demo data.
Not covered
Access control; protection against loss. Tamper-evidence does not prevent changes.

5ALCOA+

The data-integrity principles as described in, for example, the MHRA GXP data integrity guidance (2018) and PIC/S PI 041-1. A fingerprint shows that a record has not changed since it was sealed; it cannot show that the result was right when it was captured.

5.1Attributable

Approach
A signature ties the record to the key that signed it.
Today
In the alpha app one server key signs each imported row, which identifies the system, not a person. These pages and the console use demo keys.
Not covered
User accounts. Per-analyst signatures Upcoming

5.2Legible

Approach
Records are plain fields; every fingerprint can be recomputed with standard tools.
Today
The payload and the recompute recipe are printed for every record.
Not covered
A documented export format for reading records years later.

5.3Contemporaneous

Approach
The capture time is sealed; a correction carries the time it was made, beside the seal.
Today
In the alpha app the capture time is an injection time typed at import, or the server’s clock at import. It is not read from the CSV export.
Not covered
Sealing at capture Upcoming; a trusted clock.

5.4Original

Approach
Values parsed from the export are sealed on import.
Today
In the alpha app, the peak area per peak.
Not covered
The CSV file itself is not stored or fingerprinted.

5.5Accurate

Approach
A fingerprint shows whether a value changed after it was sealed.
Today
That check, on demo data.
Not covered
Whether the value was right at capture; that stays with your method, system suitability and review.

5.6Complete

Approach
Records are linked in order, so a removed or inserted record breaks a link. If every later link is rewritten, which needs no key, only a fingerprint anchored beforehand shows it (anchoring is upcoming; simulated on these pages).
Today
On these pages and in the console demo.
Not covered
Only the peak area of each result is sealed, with instrument, unit and capture time. Sample and method metadata in the seal Upcoming

5.7Consistent

Approach
Corrections are appended in time order with a reason; the original stays.
Today
On these pages and in the console demo.
Not covered
Corrections in the alpha app.

5.8Enduring

Approach
Anchoring batch fingerprints outside the lab, an upcoming feature.
Today
A simulated anchor on these pages and in the console; nothing is written to a network.
Not covered
Keeping the records: for GMP retention the lab’s validated archive stays the record, and a Filecoin copy would be one more encrypted copy, whose storage providers would need the supplier controls EU Annex 11 expects. Anchoring on a public test network Upcoming Encrypted archive on Filecoin Upcoming

5.9Available

Approach
Anyone holding the records can recompute and compare the fingerprints.
Today
The recipe and the browser check.
Not covered
A shared registry anyone could check Upcoming

6GMP records

6.1Computer systems (21 CFR Part 211)

Expectation
Controls ensure that changes to records are made only by authorized personnel; input and output are checked for accuracy; a backup of the data is kept.
Approach
A change after sealing becomes evident. It is not prevented.
Today
The check, on demo data.
Not covered
Authorization, input checks and backup.

6.2Laboratory records (21 CFR Part 211)

Expectation
Laboratory records include complete data from all tests.
Approach
Every injection becomes a linked record. A removed one breaks a link; if every later link is rewritten, only an anchored fingerprint shows it (anchoring is upcoming).
Today
The demo sequence of 5 system-suitability and 3 sample injections, checked against a simulated anchor. The alpha app links each imported peak area.
Not covered
Sealing the complete data: the source file, sample, method and integration events. Server-side verification in the app Upcoming

6.3Alterations to entries (EU GMP)

Expectation
An alteration is signed and dated, leaves the original readable and, where appropriate, records the reason.
Approach
A correction is a new record with a reason and a time; the original stays readable.
Today
On these pages and in the console demo.
Not covered
A signature by the person making the alteration.

7Environmental labs (TNI)

The TNI Standard (2016) for environmental laboratories. The expectations are given in plain words, without section numbers; find each one in the edition your accreditation body uses.

7.1Control of records

Expectation
Records are legible, identifiable and retrievable, and changes to them can be traced to the original, with the date and the person.
Approach
Corrections appended with a reason; the original stays and keeps passing.
Today
On these pages and in the console demo.
Not covered
The person; retention.

7.2Handling of samples

Expectation
Sample receipt, chain of custody and holding times are documented.
Approach
None.
Today
Outside the alpha: no sample records are sealed.
Not covered
Chain of custody and holding times.

7.3Quality control for chemical testing

Expectation
Quality-control samples, such as method blanks and laboratory control samples, are run and recorded with each batch.
Approach
QC results could be sealed like any other result.
Today
The alpha seals peak areas only; QC sample types are not modeled.
Not covered
QC sample types and batch links.