Questions we are asked about The BioChain.

The BioChain is a shared provenance and integrity layer for evidence that moves between systems and organisations. It connects laboratories, research systems, supply chains, field operations, sequencing platforms and existing databases without replacing them, and records the provenance relationships between the records those systems already hold.

Most organisations already have good systems of record, and each of those systems can maintain an excellent audit trail of what happens inside it. The problem appears when evidence moves between them — when a sample leaves one organisation and enters another, or a laboratory result becomes an input to a different system. At that point no single application’s audit trail describes the complete history. The BioChain exists to connect that history across the boundaries where it currently breaks.

Connect, structure, link, authenticate and verify. Connect brings in the systems that already hold the evidence. Structure records the identifiers, events, relationships and selected evidence the chain depends on. Link joins those records across systems while preserving origin, version and history. Authenticate establishes which organisation, person or system made an assertion and whether it was authorised to do so. Verify allows the provenance, signature, version and integrity of the evidence to be checked, including whether it has changed since.

An audit trail records what happened inside one application. The BioChain records what happened between applications and between organisations. If data and its entire history remain within a single trusted system, a well-designed database, audit trail and backup strategy may be all that is needed. The BioChain is designed for the point where provenance crosses applications, organisations, laboratories, jurisdictions or independent evidence sources.

The BioChain is a permissioned provenance blockchain, built around evidence, integrity, revision and verification rather than around transactions. The objective is not to put every piece of data onto a blockchain; it is to make important provenance testable.

No. The BioChain is not a cryptocurrency network. There is no token, no mining and no public ledger of customer activity.

The BioChain can provide evidence for four things: identity, meaning which organisation, person or system made an assertion; authority, meaning whether that party was entitled to make it; provenance, meaning where the evidence originated and what happened to it; and integrity, meaning whether it has changed. It does not provide evidence for a fifth thing, accuracy — whether the original claim was correct in the first place.

No. Verification does not make a false assertion true. It makes its origin, authority and history independently checkable. If a laboratory reports an incorrect result, The BioChain can show which laboratory reported it, under what authority, from which sample, and whether the record has changed since — but it cannot make the result correct.

Identity answers which organisation, person or system committed a record. Authority answers whether that party held the role or permission required to make that particular assertion within that deployment. A signature can establish identity while still leaving open whether the signer was entitled to make the claim, which is why The BioChain treats the two as separate questions and checks both.

Integrity means that a committed record is the record that was committed, and that any subsequent supersession or correction is visible rather than silent. Because committed history is append-only, a later correction appears as an additional event rather than as a replacement of the earlier state.

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.

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, and when.

No. The BioChain does not require organisations to replace their existing systems. It sits alongside them and records the relationships between the records they hold, through APIs and SDKs rather than migration. Each system remains the system of record for its own data.

No. Requiring every participant to adopt one platform is the problem The BioChain is designed to avoid. Each organisation can continue operating the systems it already depends on, with The BioChain connecting the provenance between them.

No. The BioChain does not require large, sensitive or commercially valuable datasets to be stored on-chain. What is committed is the provenance record and the integrity references connecting the systems that hold the underlying data.

No. The BioChain does not require every participant to see every record. What each participant is permitted to see remains governed by the deployment’s own access controls and by whatever agreements already exist between the organisations involved.

The chain has a gap at that point, which is itself useful information: it shows exactly where traceability currently depends on trust rather than on evidence. Value builds incrementally as more of the chain is covered, so participation does not have to begin with every organisation at once.

By default, operational data remains in the systems that already hold it — the LIMS, ELN, ERP, object storage, data lake, sequencing infrastructure, repository or partner platform where it sits today. The BioChain records the provenance and integrity references that connect those systems rather than taking custody of their contents.

Yes. Where an organisation would rather The BioChain held some or all of its data — because no suitable system exists for it, or because a consortium needs neutral ground that no single member owns — 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.

Yes. Where data is held within a BioChain deployment rather than left in the organisation’s own systems, backup and recovery options are available alongside it. Backup is not what The BioChain is for — its purpose is provenance and integrity — but organisations that choose hosted storage are not asked to arrange resilience for that data separately.

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.

Sensitive and commercially valuable data can remain in the organisation’s own systems rather than being shared, and what each participant can see within a deployment is governed by that deployment’s access controls. A supply chain can establish that a batch was tested without every participant seeing the contents of the test.

Through APIs and SDKs. Existing laboratory systems, repositories, operational applications, pipelines and data platforms are connected so that the provenance events they already generate can be committed to the shared integrity layer. There is no rip-and-replace and no re-platforming.

Differing versions are exactly the kind of detail the provenance record is designed to capture — which version produced which result — so the difference becomes visible and traceable rather than a silent gap in the history.

The provenance record survives independently of whether the original systems are still running, still licensed, or still remembered by the people who used them. That is a large part of why the record is kept outside those systems in the first place.

Private BioChain is a dedicated environment for a single organisation, programme or consortium. The participants’ existing operational systems remain in place, and The BioChain becomes the shared provenance and integrity layer between them.

Yes. A consortium deployment lets participating organisations follow evidence across the consortium while each continues to maintain its own operational systems and its own governance. No member has to migrate onto another member’s platform.

There is no published price list, because no two BioChain deployments are the same. What a deployment involves depends on how many organisations are being connected, which systems they already run, how much evidence moves between them, whether data stays in existing systems or is hosted, and what the resulting provenance has to prove. Publishing a single figure would be wrong for almost everyone who read it, so the scope and the commercial model are worked out per deployment instead.

Because a BioChain deployment is scoped around an evidence chain rather than sold as a fixed unit. A single laboratory connecting two systems and a consortium connecting twenty organisations across several jurisdictions are different pieces of work, and one list price would misrepresent both. More than one commercial model is available, so the arrangement can follow how an organisation or consortium actually wants to fund the work rather than forcing it into a single shape.

Yes. The Ancient BioChain is a full working BioChain, following all five steps against publicly available research data, and it is built rather than planned. It exists precisely because deployments inside customer organisations sit under those organisations’ own confidentiality obligations, so the ancient-DNA work is where the same architecture can be examined rather than only described. Access to the chain itself is arranged through a demo.

Because ancient DNA is an unusually demanding provenance problem. A single ancient individual can accumulate a research history spanning decades, institutions and technologies, moving through excavation, curation, sampling, extraction, library preparation, sequencing, bioinformatics, publication, deposit and later re-curation. Results are also reinterpreted and corrected over time, so the chain has to preserve revision rather than assume a record is final. A provenance layer that holds up there is being tested against a harder case than most commercial supply chains present.

The Ancient BioChain is a full working BioChain applied to publicly available research data, beginning with ancient DNA — a sample history that can span decades, institutions and technologies. It runs all five steps, and it exists so that the architecture can be examined against real evidence rather than only described. It is reachable at theancientbiochain.com, with access to the chain itself arranged through a demo.

No technology makes a deployment compliant on its own. The BioChain is designed to support capabilities that regulated and quality-controlled environments depend on, including provenance, data integrity, traceable revisions, controlled attribution, auditability, electronic records, integrity verification and exportable evidence histories. Regulatory applicability depends on the customer’s intended use, validation, procedures, controls and wider quality system.

The roles and permissions defined for each deployment determine who can assert what, and assertions are evaluated against those permissions when they are committed. 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 shows both who made the claim and that they held the authority to make it.

No. The BioChain does not investigate outbreaks and does not determine causality. Interpretation and causal reasoning remain with the epidemiologists, laboratories and public-health teams involved. What The BioChain preserves is the provenance of the evidence used in the investigation.

No, and The BioChain does not assume otherwise. Cryptographic integrity establishes that a record has not changed since it was committed. It says nothing about whether the record was accurate when it was made. Those are separate claims, and conflating them is one of the most common errors in how provenance technology is described.