The BioChain sits alongside the infrastructure organisations already use. It does not require laboratories, researchers, manufacturers, supply-chain participants or public bodies to move their operational data into one central database. Instead, significant provenance events can be committed to a shared integrity layer.
The BioChain records a persistent provenance history connecting evidence that may remain distributed across many systems — LIMS, ELN, ERP, sequencing platforms, repositories, supply-chain applications, data lakes and partner systems — all connected through APIs and SDKs, without requiring any of it to move.
Every BioChain deployment follows the same five steps, whether the evidence in question is a sequencing run, a food batch, an animal movement or a biobank aliquot. What changes between deployments is the evidence being connected and the organisations entitled to make assertions about it — not the model itself.
Each step below answers the same four questions: what happens, what information is involved, what remains in the existing system, and what The BioChain records. Each one also shows what that step looks like in a BioChain that is running today — the ancient-DNA programme, which follows all five steps against public research data.
The BioChain is connected to the systems that already hold the evidence — laboratory information management systems, electronic lab notebooks, ERP and traceability platforms, sequencing infrastructure, repositories, field and herd-management applications, and partner systems belonging to other organisations entirely. Integration is through APIs and SDKs rather than migration, so each participant continues to operate the system it already depends on.
Nothing is decommissioned and nothing is re-platformed. The systems keep doing the job they were bought to do; The BioChain is given access to the provenance events they generate, and to the identifiers by which those events can be recognised elsewhere.
What The BioChain records: which systems and organisations participate in a given evidence chain, and how records originating in each are identified.
Public archaeogenomic data sources, repositories and metadata records are connected alongside the ingestion and analysis environment the programme runs, without any of them being replaced.
Provenance only works if the things being described can be recognised consistently across organisations that name them differently. This step establishes that shared structure: the identifiers for samples, batches, animals, datasets and other entities; the events that happen to them; the relationships between those events; and the selected evidence that supports them.
Operational data can remain in the systems that already hold it. A sequencing dataset can stay in its repository, a laboratory result in the LIMS, a commercially sensitive formulation in the manufacturer’s own infrastructure. Where an organisation would rather The BioChain held some or all of that data — because no suitable system exists, or because a consortium needs neutral ground — that is supported within its own deployment, with backup and recovery options alongside it. The choice of what stays where it is and what moves belongs to the organisation, not to the architecture.
What The BioChain records: the structured provenance record — identifiers, events, relationships, timestamps and integrity references for the supporting evidence.
Specimens, samples, extractions, libraries, sequencing runs, datasets and their metadata are recorded as structured provenance, while the underlying datasets stay in the public repositories that already hold them.
Individually structured records are not yet a chain. This step connects them, so that a sample is linked to the processing it underwent, the processing to the sequencing run, the run to the analysis, the analysis to the dataset, and the dataset to the conclusion drawn from it — including across organisational boundaries where no single participant can see the whole path.
Crucially, the links preserve origin, version and history rather than flattening them. When a pipeline version changes, when a result is superseded, or when an earlier interpretation is corrected, the new state is recorded as a subsequent event. The state it replaced remains part of the history rather than being overwritten by it.
What The BioChain records: the connected provenance graph — what derived from what, in what order, under which version, and what later revised it.
Excavation → curation → sampling → DNA extraction → library preparation → sequencing → bioinformatics → publication → repository → re-curation — with gaps, corrections and later interpretations preserved rather than smoothed over.
A chain of records is only as useful as the confidence that the right party created each one. This step establishes attribution: which organisation, person or system made a given assertion, and whether it held the authority to make it. A laboratory asserting a test result, a certifier asserting conformity and a veterinarian asserting a clinical finding are each making a claim within a defined role, and the provenance record should say so.
Attribution is cryptographic rather than declarative. An assertion carries a signature identifying its source, so that a later reader can establish who stood behind it without having to trust the application that displayed it. Authority is checked rather than assumed. Each deployment defines which roles may make which assertions, and an assertion is evaluated against those permissions when it is committed — so the record shows not only who made a claim, but that they were entitled to make it.
What The BioChain records: the signed attribution for each significant assertion, and the role under which it was made.
Each step records which institution, repository or analytical process asserted it. Where a record originates from a public repository rather than a named laboratory, the provenance says exactly that instead of implying more than is known.
Verification is the point of the preceding four steps. A reader who was not present when the evidence was produced — an auditor, a regulator, a buyer, a journal, a partner organisation, or the same organisation three years later — can check the provenance of a record, the signature behind each assertion, the version of the process that produced it, and the integrity of the evidence it rests on.
That includes checking whether anything has changed since. Because committed history is append-only, a subsequent correction, retraction or reinterpretation is visible as part of the record rather than as a silent replacement of it. Verification works outside the application that originally presented the evidence, which is what makes it useful to a reader who has no reason to trust that application.
What The BioChain records: nothing new. Verification reads the committed history rather than adding to it.
A reader can reconstruct how a published ancient-genome result was produced, and check whether the datasets or interpretations behind it have changed since — which, in ancient DNA, they frequently have.
“Verified” is used loosely enough to be worth defining precisely. Five separate things are often bundled under the word, and they are not the same claim.
Which organisation, person or system committed this record.
Whether that party held the role or permission required to make that assertion within this deployment.
The path from source material or source record through every subsequent step that produced what is being examined.
Whether the committed record is the one that was committed, and whether it has since been superseded or corrected.
Whether the assertion describes reality. The BioChain does not evidence this one.
The BioChain can provide evidence for the first four. It does not turn an incorrect original assertion into a correct one.
Verification does not make a false assertion true. It makes its origin, authority and history independently checkable.
No rip-and-replace. No re-platforming.
The BioChain does not require large, sensitive or commercially valuable datasets to be stored directly on-chain. Operational data can remain in customer-controlled infrastructure — LIMS, ELN, ERP, object storage, databases, data lakes, sequencing infrastructure, supply-chain applications, research repositories and partner platforms. The BioChain records the provenance and integrity references connecting those systems.
The BioChain is not a cryptocurrency network. It is a permissioned provenance blockchain, built around evidence, integrity, revision and verification. The objective is not to put every piece of data onto a blockchain — the objective is to make important provenance testable.
Organisations operating in regulated or quality-controlled environments need more than a technology claim — they need systems that can form part of validated processes, controlled procedures and appropriate governance. The BioChain is designed to support capabilities including provenance, data integrity, traceable revisions, controlled attribution, auditability, electronic records, integrity verification and exportable evidence histories.
Regulatory applicability and compliance depend on the customer's intended use, validation, procedures, controls and wider quality system. The BioChain's capabilities can support those requirements but do not, by themselves, make a deployment compliant.
No. The same five steps — connect, structure, link, authenticate, verify — apply to every BioChain deployment. What changes between a genomics deployment and a food supply chain is the evidence being connected, the organisations entitled to make assertions about it, and the questions the resulting provenance needs to answer.
No. Operational data can remain in the systems that already hold it, with The BioChain recording the provenance and integrity references that connect those systems. Where an organisation would rather The BioChain stored some or all of that data — because no suitable system exists, or because a consortium needs neutral ground — that is supported within its own deployment, with backup and recovery options alongside it. The decision belongs to the organisation.
Provenance events and their integrity references: which entity was affected, what happened to it, which system or organisation recorded it, when, what it derived from, and what it later produced or revised. Large operational datasets are not required to be committed.
No. Verification establishes identity, authority, provenance and integrity — who made an assertion, whether they were entitled to, where the evidence came from, and whether it has changed since. It does not establish accuracy. Verification does not make a false assertion true; it makes its origin, authority and history independently checkable.
Yes. Committed provenance records can be exported and verified independently of the application that originally presented them. That is deliberate: provenance which can only be checked inside the system that created it is of limited use to an auditor, a regulator or a partner organisation, and it disappears entirely when that system is decommissioned.
Yes. Corrections, revised results and new interpretations are recorded as subsequent events that supersede earlier states rather than overwriting them. The earlier state remains part of the history, which is what allows a later reader to see that a correction occurred at all.
No. The BioChain is a permissioned provenance blockchain, built around evidence, integrity, revision and verification. There is no token, no mining and no public ledger of customer activity.
Talk to our team about how The BioChain connects with your existing infrastructure and regulatory environment.