Why quality records need a chain
Quality management stands or falls with one question — has this record changed since it was created? DataVeritas turns that claim into a verifiable fact.
Every quality management system produces evidence: test protocols, calibration certificates, batch releases, deviation reports, CAPA actions. Day to day they live in a QMS, a LIMS, an MES or simply on a file server. As long as nobody asks, that is fine.
In an audit, somebody asks. And the decisive question is rarely "do you have the record?" but: "can you prove it has not changed since it was created?"
The trust problem of central archives
An audit trail in a database is only as trustworthy as the database itself. Whoever holds admin rights can change entries — in the worst case including the audit trail. That is not an accusation against anyone; it is a property of the architecture: integrity is a claim made by the operator, not a fact a third party can check.
Three more frictions every QM team knows:
- Many parties, many copies. Supplier, lab, carrier, customer and certifier each keep their own copies. Reconciliation runs on e-mail and PDF.
- Long retention. Retention periods of ten years and more outlive software generations, vendors and database schemas.
- Late detection. Tampering or silent data corruption often surfaces only when the record is needed — which is too late.
The idea behind DataVeritas
DataVeritas separates two things that are mixed up today: the document and the proof of its integrity.
- The document stays where it is — in the existing system.
- At the source, a cryptographic fingerprint (hash) is created and signed by the responsible party.
- Named authorities — labs, plants, notified bodies, regulators — take turns sealing these entries into blocks (Proof of Authority). Every signature is attributable to a legal identity.
- Block bodies are cut into shards and spread across many independent nodes, much like BitTorrent spreads files.
- An auditor fetches the shards from any nodes, rebuilds the record, hashes it on their own machine and compares it with the signed block header.
The result: nobody has to trust the archive. You trust one signed header — and verify the rest yourself, in milliseconds.
Why Proof of Authority and not mining?
Quality environments do not need anonymous consensus. The participants are known, legally accountable and interested in clean data. Proof of Authority fits exactly: no energy spent on mining, no capital locked as stake, finality in seconds — and a bad block is not just invalid, it is attributable.
ALCOA+ as the yardstick
The data integrity principles — Attributable, Legible, Contemporaneous, Original, Accurate plus Complete, Consistent, Enduring, Available — are well established in regulated industries. DataVeritas addresses them directly:
| Principle | Implementation |
|---|---|
| Attributable | Signature of the submitter and of the sealing authority |
| Contemporaneous | Hash and signature at the moment of measurement |
| Original | Rebuilt shards must match the sealed hash bit for bit |
| Complete | The hash chain exposes every gap |
| Enduring | Per-shard redundancy instead of a single archive |
Important: technology alone does not make a system compliant. Whether and how DataVeritas contributes to requirements such as ISO 9001, EU GMP Annex 11 or 21 CFR Part 11 follows from validation in the concrete use case. But the architecture delivers something central archives structurally cannot: verifiable immutability without a leap of faith.
What's next?
The live simulator lets you play through the storage model: node count, failures, roles, bandwidth and data volume. In the next post we work out why every new node lowers the storage load for everyone else.