Modern organisations are surrounded by systems of record. Laboratories have LIMS and ELNs. Manufacturers have ERP and quality systems. Research groups have repositories, workflow platforms and Git. Food businesses have traceability systems. Public bodies have surveillance and case-management platforms. Each can be well designed, properly governed and capable of producing a reliable audit trail.
Yet important evidence rarely respects the boundary of one application. A physical sample moves from collection to a laboratory. A dataset moves from a sequencing provider to a bioinformatics group. A food batch moves through processors and distributors while laboratory and genomic evidence is generated elsewhere. A supplier’s certificate becomes an input to a manufacturer’s assurance record. A research consortium ends, but its data continue to be reused.
This paper calls the resulting discontinuity the provenance gap: the space between otherwise competent systems where identifiers, responsibilities, transformations, source references and versions must remain connected if an end-to-end evidence history is to survive.
An audit trail is essential but normally system-centred. Provenance is broader. W3C PROV defines provenance around entities, activities and agents involved in producing or influencing a thing, and was designed for interoperable interchange across heterogeneous environments. FAIR requires reusable data and metadata to be associated with detailed provenance. UK MHRA and OECD guidance emphasise data flows and the data lifecycle. GS1 traceability standards explicitly extend visibility beyond the walls of one enterprise. [1–8]
The problem is not that organisations lack databases. It is that no single database necessarily owns the complete evidence chain.
A provenance layer should not centralise every payload. Large, sensitive or commercially valuable data can remain in the systems designed to hold them. What needs to survive are persistent identifiers, significant events, relationships, source references, revisions, responsible actors and integrity evidence.
Cryptography can add evidence that a previously committed provenance record has not been silently rewritten. NIST describes blockchains as shared, tamper-evident and tamper-resistant digital ledgers in which blocks are cryptographically linked. Hashes, digital signatures and tamper-evident ledgers can support integrity and attestation. They cannot establish that a scientific claim is true, that an inspection was competent or that a source actor was honest. Integrity is not truth. [9]
The BioChain is being developed around this boundary. Its intended role is not to replace LIMS, ERP, ELN, repositories, traceability platforms, data lakes or domain standards. It is to connect provenance across them.
The practical conclusion is deliberately narrow: if one trusted system already contains the complete history you need, use it. If the evidence chain crosses independent systems or organisations and must remain verifiable beyond any one of them, you may have a provenance problem.
Keep your systems. Connect their provenance.
Enterprise architecture has spent decades creating specialised systems for specialised jobs. This is generally a strength. A laboratory information management system can manage samples, tests, instruments and workflows. An ELN can document experiments. ERP systems can manage orders, materials and production. Manufacturing systems record production activity. Research repositories preserve datasets. Version-control systems preserve software history.
These systems are often surrounded by mature controls: authentication, authorisation, backups, change control, retention policies, validation, audit trails and business-continuity procedures. In regulated environments these controls are fundamental. MHRA’s GxP Data Integrity Guidance describes data governance as a core element of compliant pharmaceutical lifecycle activity. OECD GLP data-integrity guidance asks facilities to understand the data flows for which they are responsible across the data lifecycle so that risk-based controls can be applied. [3][4]
The first mistake in discussing provenance infrastructure is therefore to declare that existing systems are broken. Usually they are not. A LIMS may be exactly the right system for a laboratory. An ERP may be exactly the right system for a processor. Git is a better tool for software version control than a blockchain. Object storage is a better place for a 200-gigabyte sequencing file than a distributed ledger. A backup system is the right mechanism for recovering lost operational data.
The harder question is what happens when the evidence required to understand a result is no longer contained within one system. Consider a multi-partner research programme. One organisation collects samples. Another stores biospecimens. A contract laboratory performs assays. A sequencing provider generates data. A bioinformatics company processes them. A university group performs a later analysis. A repository preserves the published dataset. Years later another consortium reuses it.
Each participant can have a good audit trail. None necessarily owns the complete history. That distinction — between trustworthy systems and trustworthy cross-system history — is the starting point for verifiable provenance.
The same logic applies outside science. A food manufacturer can have an excellent ERP while its supplier maintains separate production records and a contract laboratory maintains analytical evidence. A livestock exporter can have a traceability platform while veterinary treatments, movements, slaughter and official certification are recorded elsewhere. The evidence required to explain the final product is distributed because responsibility itself is distributed.
The question is therefore not whether we can build a bigger database. It is whether the history can remain coherent when no single application, department or legal entity is naturally responsible for every part of it.
Audit trails are foundations of trustworthy electronic records. In regulated settings they help reconstruct who or what created, changed or deleted a record and when. FDA guidance describes secure, computer-generated, time-stamped audit trails for electronic records. EU GMP Annex 11 requires risk-based audit trails for GMP-relevant changes and deletions and expects those trails to be available in an intelligible form and reviewed. MHRA guidance places audit trails within broader data governance. [3][10][11]
If a laboratory result changes inside a LIMS, the audit trail can help establish the sequence. If an authorised user modifies a manufacturing record, the system can preserve the earlier entry and the change. If a dataset is replaced inside a managed repository, version history can identify what happened.
But the audit trail is normally attached to the system and records within its scope.
Suppose a sample is created in System A and transferred to Organisation B. Organisation B gives it a new identifier. It is processed and a derived sample goes to Organisation C, which generates a dataset and deposits it in Repository D. Each system correctly records its own activity. The cross-system question is whether A-104, B-7781, aliquot C-99 and accession D12345 can still be shown to form one evidence chain.
The missing relationship may live in a transfer manifest, spreadsheet, interface log, shipping record, certificate, email or the memory of a member of staff. Five good audit trails do not automatically constitute one provenance record.
An audit trail answers questions about events in a system. End-to-end provenance asks how evidence came to exist across systems, activities and custodians.
This distinction prevents provenance infrastructure from being sold as a replacement for audit controls. If a customer’s problem is simply that users can edit records without an audit trail, the solution is to fix the application and its controls. A distributed ledger is unnecessary. The provenance problem starts when the history that matters is larger than the boundary of the application whose audit trail is being inspected.
W3C PROV provides a domain-independent vocabulary. Provenance is information about entities, activities and people involved in producing a piece of data or thing, information that can be used when assessing quality, reliability or trustworthiness. PROV was designed for interoperable interchange in heterogeneous environments. [1][2]
An entity can be physical, digital or conceptual. An activity acts upon entities and can generate new entities. An agent is a person, organisation, software system or other actor associated with responsibility. PROV can describe derivation, attribution, generation, usage, revision and time.
A cow can be an entity. A biospecimen can be an entity. A sequencing file can be an entity. A food lot can be an entity. A scientific hypothesis can be an entity. Collection, testing, transformation, sequencing, analysis and revision are activities. Farms, laboratories, companies, researchers and software services can be agents.
The value comes from relationships. A result was generated by an analysis. The analysis used a dataset. The dataset was derived from sequence files. The sequence files were generated from a sample. The sample was derived from a specimen. A later dataset was a revision of an earlier dataset.
FAIR reinforces the same idea. Reusability principle R1.2 requires data and metadata to be associated with detailed provenance, while FAIR also stresses persistent identifiers and qualified references between metadata. [5][6]
Provenance is not a blockchain invention. It is an information-management requirement. The technological question is how to preserve it when responsibility is distributed.
This is also why provenance should not be confused with ownership. The organisation that currently stores a dataset may not have generated it. The organisation that generated a result may not own the source sample. The organisation that publishes a conclusion may depend on evidence produced by several independent actors. Provenance makes those roles explicit instead of forcing them into one ambiguous notion of ‘the record owner’.
Boundaries are where evidence chains become fragile. A technical boundary changes identifiers as a record moves between applications. An organisational boundary transfers custody or responsibility. A semantic boundary means two systems use different terminology. A temporal boundary appears when the original application is retired before the evidence is reused. A jurisdictional boundary may prevent centralisation.
These boundaries create familiar failure modes. Identity fragmentation occurs when the same object acquires unrelated identifiers. Transformation ambiguity occurs when inputs and outputs are recorded locally but the relationship is lost. Attribution gaps occur when the organisation is known but the responsible actor or system is not. Version ambiguity occurs when a current dataset exists but the exact version used by an earlier analysis is unclear. Context loss occurs when a file survives but the metadata required to interpret it does not.
UK Government data-quality guidance recognises the importance of metadata throughout the lifecycle, including information about how data were collected, changes made, contributors, known quality issues and responsibility for maintaining the dataset. It recommends comprehensive metadata throughout the lifecycle and updating it alongside data. [12][13]
The provenance gap is what happens when that context must survive beyond the system that originally maintained it.
Standards help, but standards alone do not create continuity. Adoption, identifiers, mappings and governance remain distributed. A traceability event may be represented in GS1 EPCIS while a laboratory result uses a domain-specific standard and a research output uses DOI metadata. The provenance layer must connect rather than erase those semantics.
The gap is also where disputes become expensive. If two organisations disagree about whether a particular batch, sample or dataset is the one originally transferred, each can produce internally consistent records. The question becomes whether the relationship between those records was established at the time of transfer or reconstructed retrospectively.
Retrospective reconciliation is possible, but it is slower, more dependent on surviving institutional knowledge and more vulnerable to ambiguity. Capturing provenance as significant events occur moves the organisation from forensic reconstruction towards continuous evidence continuity.
Before provenance can be connected, entities must remain identifiable. Within one application this is usually straightforward. A sample has a primary key. A product has a lot number. A research dataset has an accession. The problem begins when the same real-world object acquires several identifiers across its lifecycle.
A biological specimen may have an archaeological catalogue number, a laboratory accession, a sequencing-library identifier, a repository accession and an identifier in a curated dataset. A cow may have an official animal identifier, farm-management record, movement-system identifier, slaughterhouse number, carcass identifier and processing-lot relationship. A food ingredient may be known by supplier lot, internal lot, manufacturing batch and customer-facing product code.
None of these identifiers is necessarily wrong. They exist because each system has its own operational purpose.
Provenance therefore needs identity mapping rather than identifier replacement. The question is not ‘which identifier should everyone use?’ but ‘what evidence establishes that these identifiers refer to the same entity or to entities derived from one another?’
Persistent identifiers are particularly valuable when evidence must survive organisational change. FAIR calls for globally unique and persistent identifiers for data and metadata. GS1 uses identification keys to connect physical and information flows across trading partners. [5][7]
Identity resolution should itself be provenance-aware. If two records are later discovered to represent the same individual or lot, the reconciliation should be recorded as a curation or assertion event with a source, actor and time. Silent merging destroys information about how the evidence was previously understood.
This principle becomes important in scientific curation, master-data management and supply-chain reconciliation. Identity is not always a one-time database operation. It can be a scientific or operational claim that deserves its own history.
Evidence chains are not merely chains of custody. Objects are transformed.
A sample is divided into aliquots. DNA is extracted from tissue. A sequencing library is generated from DNA. Raw reads are processed into aligned data. A food ingredient becomes part of a batch. Several animals become carcasses, cuts and processed lots. A software pipeline turns input data into an analytical result.
Traceability is weak if it records only movement while losing transformation.
GS1’s traceability model explicitly recognises transformation events and the need to connect inputs and outputs. EPCIS visibility data records business-process events involving physical or digital objects and supports interoperable sharing across enterprises. [7][14]
W3C PROV provides the corresponding general concept of derivation: one entity can be derived from another through an activity. [1][2]
This relationship is central to evidence. If a laboratory result is challenged, the important question may be which sample generated it. If a food lot is recalled, the important question may be which input lots contributed to it and which downstream products contain it. If a research conclusion is questioned, the relevant history may extend through several derived datasets and analytical steps.
Transformation also creates branching and merging. One source sample can produce several aliquots and datasets. Several ingredients can become one production lot. One dataset can feed multiple analyses. A provenance graph therefore cannot always be represented as a simple linear timeline.
The architecture must preserve these many-to-many relationships without pretending that the world is a single chain. ‘Evidence chain’ is a useful phrase, but the underlying structure is usually a graph.
Supply chains demonstrate the problem because physical objects cross organisational boundaries by design. GS1’s Global Traceability Standard defines Critical Tracking Events such as receiving, transforming, packing and shipping, and Key Data Elements describing those events. It explicitly states that end-to-end supply-chain traceability extends responsibilities outside the walls of one enterprise. [7]
GS1 asks familiar provenance questions: Who? What? Where? When? Why? EPCIS provides a common data model and interfaces for capturing and sharing visibility-event data within and across enterprises. EPCIS 2.0 can also carry sensor and certification information. [14][15]
EU food law provides another example. Article 18 of Regulation (EC) No 178/2002 requires traceability of food, feed, food-producing animals and relevant substances through all stages of production, processing and distribution. Operators must identify suppliers and businesses supplied. [16]
These requirements do not imply that every participant should use one database. They imply that evidence must remain connected across a chain of independent operators.
A processor can know exactly which input lots entered a batch. A distributor can know exactly which pallets were shipped. A laboratory can know exactly which sample was tested. An importer can know exactly which consignment arrived. End-to-end provenance depends on the relationships between those local truths.
The more complex the network, the more difficult direct pairwise exchange becomes. GS1’s EPCIS implementation guidance explicitly discusses the complexity of ecosystems with many trading partners and the need to separate event content from the choreography of where data reside and how they are exchanged. [17]
That distinction is highly relevant to provenance infrastructure. A shared model of significant events should survive changes in the network topology and technology used to exchange them.
Research provenance is often discussed in terms of reproducibility, but multi-organisation science creates a wider history. A sample may have physical provenance before entering a laboratory. It may then be aliquoted, transformed, sequenced and analysed. Code may be versioned in Git. Data may be deposited in a repository. Metadata may later be curated by a community resource. A later paper may use the curated version rather than the original representation.
Each step can be legitimate. The scientific question is whether the relationships remain inspectable.
FAIR makes provenance part of reusability rather than an optional annotation. W3C PROV explicitly supports derivation, agents, activities and revision. OECD GLP guidance asks organisations to understand data flows across the lifecycle. [1][4][5]
When a research programme ends, the problem becomes harder. Staff leave. Systems are decommissioned. Project websites disappear. Identifiers survive but mappings are lost. A repository may preserve a dataset without preserving every institutional hand-off that produced it.
A durable provenance layer is partly a mechanism for preserving institutional memory in machine-readable form. It does not replace good research practice; it makes the evidence chain less dependent on organisational continuity.
This matters increasingly as datasets are reused for purposes not anticipated when they were created. The future user may not have access to the original project team. Detailed provenance allows that user to distinguish source evidence from later curation and to understand the transformations that produced the object being reused.
The same principle applies to AI-assisted analysis. If a model, pipeline or automated system contributes to a derived result, its identity, version and role become part of the provenance. The fact that an activity was automated does not remove the need to understand how the output was produced.
One Health is almost a textbook provenance problem because the evidence crosses human, animal, food and environmental domains.
A foodborne outbreak may involve farm records, feed or flock information, product lots, distribution records, diagnostic isolates, whole-genome sequencing, epidemiological interviews and public-health decisions. These records are held by organisations with different purposes, legal responsibilities and access controls.
EFSA and ECDC’s One Health WGS system demonstrates the need to bring different evidence streams together. The agencies’ platforms exchange genomic profiles from human-health and food-safety domains, and EFSA states that the genomic information is assessed alongside relevant traceability and epidemiological evidence in multi-country outbreak investigations. [18]
This is important because genomics does not replace traceability and traceability does not replace epidemiology. Each contributes a different type of evidence.
A provenance architecture should therefore resist the temptation to reduce the chain to one preferred evidence type. The genomic cluster, the product lot, the farm, the clinical case and the epidemiological hypothesis are different entities connected by activities and assertions.
The same logic applies to antimicrobial resistance surveillance, zoonotic disease, environmental sampling and animal-health programmes. A result may only become meaningful when evidence from several sectors can be related without collapsing their governance boundaries.
The opportunity for verifiable provenance is not to create one giant One Health database. It is to make the relationships between authorised evidence sources durable, explicit and inspectable.
The obvious response to fragmented evidence is one enormous database. Sometimes that is appropriate. If one organisation controls the workflow, has authority to hold all relevant data and can impose one system, centralisation may be simplest.
Cross-organisational evidence often resists that model for good reasons. Data may be commercially sensitive. Personal data may be restricted. Research partners may have contractual obligations. Countries may impose residency requirements. Laboratories may operate validated systems that cannot simply be replaced. Suppliers may refuse to expose proprietary records. A consortium may exist only temporarily.
Centralising all payloads can also create a concentration of risk. A single repository becomes a high-value security target and a single governance authority becomes responsible for data it may not be entitled or competent to control.
A provenance layer should distinguish the evidence object from evidence about the object. A sequencing file can remain in object storage. A veterinary treatment record can remain in the veterinary system. A manufacturing record can remain in the quality system. A food lot can remain in ERP. The provenance layer preserves identifiers, hashes, event relationships, responsible actors, timestamps and source references.
This approach is compatible with the principle that metadata can remain useful even when underlying data are restricted or unavailable. FAIR explicitly recognises that metadata may remain accessible even where data are not. [5]
Data minimisation is not merely a privacy principle. It is good architecture. The objective is to preserve enough information to understand and verify the evidence chain without turning the provenance system into an uncontrolled duplicate of every source system.
A useful provenance layer does not need to understand every field in every connected application. It needs a stable common envelope for significant events.
It must identify the entity: animal, sample, dataset, batch, document, analysis, result or other object. It must identify the activity: collection, transfer, transformation, analysis, approval, publication, revision or another domain event. It must identify the actor or source system and organisational context. It needs effective and recorded time. It needs inputs and outputs so derivation is explicit. It needs source references. It needs version and revision relationships. It needs an integrity reference to the associated payload where appropriate.
This structure should remain deliberately close to provenance standards rather than one industry schema. Domain systems remain responsible for detailed semantics. A laboratory may use its own test ontology. A supply chain may use GS1 identifiers and EPCIS. A research repository may use DOI and domain metadata. The provenance layer connects these rather than flattening them into a proprietary replacement vocabulary.
The architecture also needs explicit uncertainty. Unknown actors, unresolved identity mappings and missing hand-offs should be represented as gaps. A clean-looking invented chain is worse than an incomplete honest one.
A significant event should also have a clear reason for being committed. Recording every page view, mouse click or transient state on a blockchain creates cost without necessarily creating evidential value. Provenance infrastructure should focus on events that change custody, identity, derivation, interpretation, responsibility or assurance.
The minimum viable event therefore has to be both technically precise and semantically meaningful. The point is not to generate more logs. The point is to preserve the events that make the history explainable.
One of the most important design distinctions is between legitimate revision and silent alteration.
Science changes. A dataset is re-curated. A pathogen lineage is reclassified. A laboratory issues a corrected result. A food investigation acquires new evidence. A supplier certificate is superseded. A model is rerun with a new pipeline.
A system that promises records can never change is not necessarily trustworthy; it may simply preserve mistakes forever.
Good provenance creates a new state and links it to the state it revises. W3C PROV supports revision relationships precisely because version history matters. [2]
This is also important for reproducibility. If Study A used dataset version 3, version 5 cannot retroactively become the dataset Study A used. The current preferred record and the historical record answer different questions.
A provenance infrastructure should therefore be append-only at the level of committed history while still allowing new events to supersede, correct or reinterpret earlier entities. Immutability applies to what was committed, not to the proposition that knowledge can never change.
This distinction is commercially important in regulated and assurance contexts. A correction should not require destroying the evidence that a previous decision was made using an earlier state. The history should show the original state, the revision, the actor or system responsible, the reason or source where appropriate, and the downstream entities affected.
The result is not a frozen database. It is an inspectable history of change.
Cross-organisational provenance introduces a trust question. If Organisation A exports an audit log, the recipient ultimately relies on Organisation A’s system and governance to establish that the exported history is the history that existed previously. For many purposes this is adequate.
For higher-value evidence chains, participants may want stronger evidence that a previously committed provenance record has not been silently rewritten.
NIST describes blockchains as tamper-evident and tamper-resistant digital ledgers implemented in a distributed fashion. Transactions are grouped into blocks, blocks are cryptographically linked, and alteration of an earlier block changes the cryptographic relationship and can therefore be detected. [9]
Hashes can bind a provenance event to a particular payload. Digital signatures can associate an attestation with a key controlled by an authorised actor or system. Merkle structures can provide efficient proofs that transactions were included in a committed block. Distributed validation can reduce dependence on one operator.
But cryptography has strict limits. A signed false statement remains false. A perfectly hashed laboratory error remains an error. A blockchain cannot determine whether a veterinarian lied, whether an archaeological interpretation is correct, whether a supplier committed fraud or whether a regulator should accept an assurance programme.
Cryptographic verification establishes integrity and attestation. Scientific, legal and operational truth still depends on evidence, governance and competent judgement.
This distinction should be explicit in product design and marketing. ‘Verified’ must not be allowed to mean ‘scientifically true’ when it only means ‘cryptographically consistent with the committed record’. Precision here is part of trustworthiness.
Blockchain is not required for provenance. A conventional append-only database with strong controls may be enough. The question is whether the trust model benefits from a shared tamper-evident ledger.
A blockchain becomes more defensible when multiple independent participants need to contribute to or verify a shared history; when no single participant should be able to rewrite accepted history unilaterally; when records need to survive beyond one application or organisation; and when portable verification matters.
It is less defensible when one trusted organisation owns the complete workflow, when performance requires frequent mutable state with little evidential value, when the data should simply live in a normal database, or when blockchain is being used as a substitute for governance.
NIST’s technology overview is useful precisely because it separates the technical properties of a blockchain from cryptocurrency. A blockchain is a ledger architecture; whether it is appropriate depends on the problem. [9]
The BioChain design therefore uses blockchain as an integrity mechanism for significant provenance events, not as a universal storage layer. Large payloads remain off-chain. Routine UI interactions do not need blocks. The chain should record events whose provenance has durable value.
Permissioning also matters. Many evidence chains involve confidential commercial, scientific or personal information. A public permissionless network is rarely the obvious default. A permissioned provenance blockchain can restrict participation while retaining cryptographic integrity and, where appropriate, distributed validation.
The strongest test is architectural honesty: if replacing the blockchain with a normal database would preserve all required trust properties at lower complexity, use the database. Blockchain earns its place only when the shared verification model adds something material.
Consider a sponsor running a research programme through external partners. A field or clinical site collects a sample. A biobank stores it. A CRO coordinates analysis. A specialist laboratory extracts material. A sequencing provider generates raw data. A bioinformatics team produces a derived dataset. The sponsor incorporates the result into an internal programme.
Every organisation may have mature controls. The sponsor nevertheless needs to understand how the final result relates to the original sample.
A provenance layer can preserve the source sample identifier, transfer to the biobank, derived aliquots, laboratory processing, sequencing run, repository or object-storage reference, pipeline version, analysis output and final result. Each participant remains responsible for its own operational system.
This becomes especially valuable when the programme lasts longer than a vendor contract or when the data are reused. The provenance should not depend on every original application remaining online indefinitely.
The same model can support research consortia in which no single university or company should be treated as the sole authority for everybody else’s actions. Each participant can attest its own part of the history while the shared provenance layer preserves the relationships.
A foodborne outbreak can create an evidence chain across agriculture, processing, retail, diagnostics, genomics and epidemiology.
A suspected Salmonella incident may begin with a farm or food-production record. A processor records a batch. A distributor records movements. A laboratory identifies an isolate. Whole-genome sequencing produces a genomic profile. Epidemiologists connect cases and exposures. A public authority may issue a recall or control action.
EFSA and ECDC already combine WGS information with traceability and epidemiological evidence when assessing multi-country foodborne outbreaks. [18]
A provenance layer does not decide that a food is the source of an outbreak. It preserves how the evidence used to reach that conclusion relates across systems.
This distinction matters when evidence changes. A genomic cluster can be redefined. A product lot can be excluded. A new epidemiological link can alter the working hypothesis. Provenance should preserve those revisions rather than presenting the final investigation as though it had always been known.
Livestock export assurance illustrates the relationship between physical identity and regulatory evidence.
An animal can move through several holdings, receive veterinary care, enter a slaughterhouse, become a carcass, be divided into lots and ultimately form part of an export consignment. Different systems may hold animal identity, movement, treatment, slaughter, processing and certification records.
The evidence chain is valuable because the final consignment inherits claims about the history of its source animals.
A provenance layer can connect animal identity to holdings, veterinary evidence, movements, slaughter transformations, processing lots and certificates without copying every source record into one database.
The same identity chain can support different assurance questions. One programme may care about antimicrobial use. Another may care about geolocation and deforestation. Another may care about disease status or breed provenance. The substantive rules differ, but the underlying need for persistent identity and event history overlaps.
This is why reusable provenance infrastructure can be more valuable than a separate point solution for every assurance regime.
Long-lived datasets demonstrate the temporal boundary.
A dataset may be created by a project that ends after three years but remain scientifically useful for decades. The original team disperses. Software versions change. Repositories migrate. Community resources re-curate metadata. Later analyses may use a representation that did not exist when the original paper was published.
The provenance history needs to distinguish source data, processing, curation and later revision.
FAIR’s insistence on persistent identifiers and detailed provenance is particularly relevant here. [5][6]
A BioChain-style provenance record can preserve the relationships without pretending that the latest curated record is identical to the historical record used by earlier researchers. That supports both reproducibility and scientific revision.
Ancient DNA is an extreme but useful public demonstrator of this pattern because specimens, laboratories, publications, repositories and curated datasets can span decades and institutions.
A cross-organisational provenance architecture should sit beside existing systems rather than above them as a replacement.
At the edge are systems of record: LIMS, ELN, ERP, traceability platforms, repositories, data lakes, sequencing systems, field applications and partner systems. Each remains authoritative for the detailed operational data it owns.
Integration gateways or SDKs translate significant domain events into a common provenance envelope. Domain identifiers and standards are preserved. A GS1 event should remain recognisably GS1. A DOI remains a DOI. A laboratory test retains its domain semantics.
The provenance service validates the event, canonicalises the committed representation, records source references and relationships, and submits the event to the integrity layer.
The integrity layer maintains append-only history, cryptographic hashes, signatures, block relationships and inclusion proofs. Searchable projections can be built in conventional databases for performance. If the projection is lost, it should be reconstructable from the authoritative event history.
Large payloads remain off-chain. The provenance record contains the minimum necessary identity, relationship and integrity information.
Above this sit the user-facing capabilities: provenance timeline, graph, revision history, verification, export and APIs.
This separation matters. The blockchain is not the application database. The application database is not the authoritative integrity history. The source systems are not replaced. Each layer has one job.
Systems of record remain responsible for operational data.
Adapters map significant events into a common provenance envelope.
The provenance model preserves entities, activities, agents and relationships.
The integrity layer commits hashes, signatures and append-only history.
Conventional read models provide search and dashboards.
Portable exports allow provenance to travel beyond the originating application.
No cryptographic design can rescue weak governance.
A provenance network needs rules defining who may create events, which identities are trusted, how organisations join and leave, how keys are issued and revoked, how erroneous attestations are corrected, how disputes are handled and which events require additional approval.
Identity governance is particularly important. A digital signature proves control of a key, not the real-world authority of the person or organisation using it. The network therefore needs a trustworthy relationship between keys, systems, organisations and roles.
Key rotation and revocation must preserve historical verification. If a key is compromised in 2028, a verifier still needs to distinguish events legitimately signed before compromise from events created afterwards.
Governance also determines visibility. Not every participant should necessarily see every event or payload reference. A consortium may need shared provenance with selective disclosure.
The strongest architecture therefore treats cryptography as one component of a broader trust system. Policy, contracts, standards, audits, certification and competent authorities remain necessary.
This is particularly important in regulated settings. A software platform can support controls required by a quality system; it does not independently make the customer’s process compliant. Intended use, validation, procedures, training and governance remain customer and regulatory concerns.
A provenance platform becomes dangerous if it demands that every domain abandon its existing standards.
W3C PROV already provides a general model for provenance. FAIR provides principles for reusable research data. GS1 EPCIS provides event-based visibility across supply chains. Domain-specific standards exist for laboratories, healthcare, research repositories, geospatial data and many other fields.
The correct architecture is compositional.
BioChain can use W3C PROV as an interoperability layer while preserving domain-specific identifiers and vocabularies. A GS1 EPCIS event can be represented as a provenance activity without losing the EPCIS payload. A research dataset can retain DOI and repository metadata. A laboratory result can retain the originating system’s test semantics.
GS1’s EPCIS guidance explicitly aims to let disparate applications create and share visibility events across enterprises. [14][17] That is complementary to a provenance ledger, not competitive with it.
The ledger adds integrity and shared history; standards add meaning and interoperability.
This also protects customers from vendor lock-in. If provenance can be exported using open representations such as JSON-LD, RDF or W3C PROV serialisations, the evidence history is not meaningful only inside one vendor’s interface.
Open provenance is particularly important for long-lived research and regulatory evidence. The data may need to outlive the software that first displayed it.
Cross-organisational provenance can easily become a privacy and confidentiality problem if implemented carelessly.
A provenance event may reveal commercially sensitive relationships, patient or participant information, farm locations, research activity or supplier identities. The fact that a ledger is technically capable of storing information does not mean that information belongs on the ledger.
The design principle should therefore be minimisation. Store the minimum provenance required to establish identity, relationship and integrity. Keep sensitive payloads in the systems authorised to hold them. Use pseudonymous or scoped identifiers where appropriate. Separate public, consortium and restricted metadata.
Hashing is not anonymisation. A hash of predictable or low-entropy personal information may still create privacy risk. Nor does encryption remove governance obligations if the encrypted material is replicated broadly.
Permissioned deployment helps because network membership and access can be controlled, but permissioning is not a substitute for data-protection analysis.
The practical architecture should therefore support selective disclosure. A verifier may need proof that an event exists and that a particular authorised organisation attested it without receiving every underlying field.
This is another reason portable evidence packages should be designed carefully. An export for an auditor may legitimately contain more information than an export intended for a customer or public demonstrator.
Provenance is valuable precisely because context matters. Privacy architecture should respect the same principle.
‘Independently verifiable’ is a strong claim and should have a precise meaning.
At minimum, a recipient should be able to verify a portable provenance package without trusting the user interface that produced it. The verifier should check canonical record hashes, signatures, block continuity and inclusion proofs using published protocol rules.
A stronger model allows the recipient to compare the committed history against checkpoints or copies maintained by independent nodes. That reduces dependence on the operator of the originating application.
Verification should produce granular results. A package can have valid cryptographic integrity while containing unresolved provenance gaps. A signature can be valid while the associated key has since been revoked. A source file can be missing while the ledger event remains intact.
The output should therefore distinguish integrity, identity, completeness and scientific or operational interpretation.
A useful verifier might report: chain integrity valid; signatures valid; two source artefacts unavailable; one provenance gap unresolved; record revised twice; current preferred state identified; no claim made about scientific correctness.
This is more informative than a green ‘verified’ badge.
The design goal should be to make the evidence inspectable by another party, not merely to produce confidence-inducing UI.
A production-minded provenance platform should adopt a small number of hard rules.
First, own the protocol but not the cryptography. The block format, transaction envelope, validation rules and provenance semantics can be product IP. Hash functions, digital signatures and canonicalisation should use established standards and well-reviewed libraries.
Second, separate the ledger from the read model. The authoritative history should be replayable. Search, dashboards and reporting can use conventional databases optimised for those tasks.
Third, make domain semantics modular. The core should understand entities, activities, agents, relationships, attestations and revisions. It should not contain concepts such as cow, DNA, patient or food batch. Those belong in domain modules.
Fourth, design for versioning from the first release. Protocols, schemas and cryptographic algorithms evolve. Historical records must remain verifiable after upgrades.
Fifth, make gaps first-class. Do not invent continuity when source evidence is absent.
Sixth, support idempotent integration. External systems will retry events. Duplicate submissions should not create duplicate history.
Seventh, make exports deterministic and testable. A portable record should be verifiable on a clean machine.
Eighth, test tampering deliberately. Change a byte, remove an event, reorder a block, use a revoked key and alter a source artefact. Verification should fail in predictable ways.
Ninth, preserve corrections as new events. Never provide an administrative back door that silently rewrites committed history.
Tenth, design the developer experience around existing systems. The easiest path should be ‘add provenance to my application’, not ‘rebuild my application inside BioChain’.
The strongest provenance proposition includes a clear boundary.
If one trusted system contains the complete history required for the intended purpose, a conventional database, audit trail, access controls and backups may be sufficient.
If the primary requirement is disaster recovery, use backups.
If the requirement is software version control, use Git.
If the requirement is laboratory workflow management, use a LIMS.
If the requirement is supply-chain event exchange and the trust model is satisfied by existing EPCIS infrastructure, use EPCIS.
If the requirement is a central repository controlled by one organisation and there is no need for independent verification, a normal database may be simpler.
If source data are unreliable, adding a blockchain does not make them reliable.
If participants cannot agree on identifiers, governance or responsibilities, cryptography will not create agreement.
BioChain becomes relevant when the problem is specifically cross-boundary provenance: multiple systems or organisations contribute to a history; the relationships between their records matter; the history must survive organisational or technical change; revisions must remain visible; and verification should not depend solely on one application’s current database.
This discipline protects both customers and the product. A technology that claims to solve every data problem is unlikely to solve any of them particularly well.
A practical assessment can begin without discussing blockchain.
Ask where the evidence begins. Is there a physical object, sample, dataset, product, document or decision whose history matters?
List every system that contributes to the final evidence. If there is only one, the problem may be internal governance rather than cross-system provenance.
List every organisation that creates, transforms, stores, interprets or certifies part of the evidence. Where responsibility changes, ask how identity is preserved.
Identify transformations. What inputs become what outputs? Can those relationships be reconstructed today?
Identify versioned objects. Which datasets, results, certificates or interpretations can change? Can an earlier state still be identified?
Identify hand-offs. Are they machine-readable, or do they depend on spreadsheets, emails and human reconciliation?
Ask what happens if one partner disappears. Can the remaining organisations still establish the evidence chain?
Ask what happens if two parties disagree about a historical state. Which record is authoritative, and why?
Ask whether the recipient needs to trust one organisation’s database to accept the history. Would portable independent verification materially reduce risk?
Ask which payloads cannot or should not be centralised.
Finally, ask what the cost of a broken chain would be: lost research reproducibility, delayed recall, failed market access, regulatory investigation, contractual dispute, inability to reuse data or loss of confidence.
The higher the consequence and the more distributed the evidence, the stronger the case for explicit provenance infrastructure.
Who owns the evidence chain?
In many modern workflows, nobody does — at least not in the sense of one organisation naturally controlling every source record, transformation and interpretation.
That is not necessarily a governance failure. It is often the consequence of specialisation. Laboratories should operate laboratory systems. Suppliers should manage their production. Repositories should preserve datasets. Public-health agencies should govern sensitive case data. Research partners should retain responsibility for their own work.
The missing layer is not another system trying to absorb all of those responsibilities. It is a way to preserve the relationships between them.
Standards already provide important pieces. W3C PROV gives us a general provenance model. FAIR makes provenance part of reusable research data. GS1 EPCIS provides interoperable supply-chain visibility. MHRA, OECD and other regulators emphasise lifecycle understanding and data integrity. The opportunity is to connect those principles with a durable integrity layer when the trust model requires it. [1–8][14]
Blockchain can contribute to that layer when multiple participants need a shared tamper-evident history and no single party should be able to rewrite accepted provenance unilaterally. It should not be used merely because the word ‘blockchain’ sounds stronger than ‘database’.
The BioChain is therefore deliberately positioned after the existing systems, not instead of them.
The LIMS remains the LIMS. The ERP remains the ERP. The repository remains the repository. The traceability platform remains the traceability platform.
BioChain starts where the individual audit trail stops.
Keep your systems. Connect their provenance.
An evidence chain is the connected history of the entities, activities, actors and transformations that lead from source material or information to a later record, result, product or decision.
An audit trail usually records activity within a particular system. Provenance describes how entities were generated, transformed, attributed, used and revised across a wider history, potentially spanning several systems and organisations.
They overlap. Traceability often focuses on the ability to follow objects through a process or supply chain. Provenance can additionally represent derivation, attribution, processing, revision and the origins of digital or conceptual entities. Standards such as GS1 EPCIS and W3C PROV are complementary.
Each audit trail can accurately describe its own system while the mappings between identifiers, transfers and transformations remain outside those systems. The cross-system relationships are the provenance gap.
No. Its intended role is to connect provenance across existing systems. Operational systems remain responsible for their own detailed data and workflows.
No. Large, sensitive or commercially valuable payloads should normally remain in authorised source systems. The provenance layer can commit identifiers, relationships, hashes, attestations and source references.
No. Cryptographic verification can show that a committed record has not changed and can verify signatures or inclusion in a ledger. It cannot prove that the original statement, measurement or scientific interpretation was correct.
When multiple independent participants need a shared tamper-evident history, when no single participant should be able to rewrite accepted provenance unilaterally, and when portable verification matters.
When one trusted organisation controls the complete evidence history and conventional database, audit and backup controls satisfy the trust requirement.
W3C PROV is a family of standards for representing and exchanging provenance information using concepts including entities, activities and agents.
FAIR principle R1.2 says that data and metadata should be associated with detailed provenance to support reuse.
EPCIS is a standard for capturing and sharing visibility-event data across supply chains. BioChain should preserve and integrate such standards rather than replace them, adding shared integrity and provenance where required.
A correction should normally create a new state linked to the record it revises. The earlier state remains part of the historical provenance.
It means a recipient can check the integrity of a portable provenance record using published protocol rules without relying solely on the originating application’s user interface or current database.
A signature proves control of a key. Governance establishes who that key represents, what the signer is authorised to attest, how keys are revoked and how disputes or errors are handled.
Potentially. A provenance layer can preserve references and integrity evidence while underlying payloads remain in appropriate local systems, subject to legal, contractual and technical design.
It is the loss or fragmentation of identity, context, transformation history, attribution or version relationships as evidence crosses system or organisational boundaries.
The BioChain is being developed as trusted infrastructure for verifiable provenance: a permissioned provenance layer intended to connect evidence across existing systems and organisations.
Ask whether the complete evidence history fits inside one trusted system. If it does, BioChain may be unnecessary. If the history crosses independent systems or organisations and must remain verifiable, there may be a provenance problem.
Before selecting technology, an organisation should map the evidence chain as it exists today. The exercise is deliberately broader than a data-flow diagram. A data-flow diagram can show where information moves; an evidence-chain assessment asks what claims depend on that information, which organisation is responsible for each claim, and what would be needed to reconstruct the history later.
Begin with the decision, product, result or research output whose provenance matters. Work backwards to the source. Identify every physical and digital entity that contributes to it. Record the identifiers used by each system. Note where identifiers change and whether the mapping is explicit, inferred or manually maintained.
Then map activities. Collection, receipt, transformation, analysis, approval, transfer, publication and revision should be treated as distinct events when they materially change the evidence history. For each activity, identify inputs, outputs, actor, organisation, system, time and source record.
Next identify the boundaries. Which hand-offs cross applications? Which cross legal entities? Which cross jurisdictions? Which rely on files or spreadsheets rather than managed interfaces? Which depend on an individual member of staff knowing that two identifiers refer to the same object?
The assessment should then examine failure scenarios. If the source application disappeared tomorrow, could the relationship still be reconstructed? If a partner challenged the historical state, what evidence would establish what was transferred? If a record was corrected, could an auditor identify both the original and revised state? If an artefact was substituted, could the change be detected?
Finally, classify the trust requirement. Some relationships require only operational convenience. Others support scientific conclusions, market access, regulatory decisions, product recalls, contractual obligations or safety decisions. Provenance investment should follow consequence and risk rather than the novelty of the technology.
This assessment frequently reveals that only a small subset of events need stronger provenance controls. That is a positive result. A well-designed system commits the important history, not every possible event.
Evidence-chain workshop questions
What is the final evidence object or decision we are trying to explain?
Which source entities contribute to it?
Which systems create or transform those entities?
Which organisations control those systems?
Where do identifiers change?
Where are transformations recorded?
Which hand-offs are currently manual?
Which records are versioned or corrected?
Which source artefacts must remain available?
Which payloads cannot be centralised?
Who needs to verify the history later?
What happens if a participant leaves the consortium or supply chain?
What is the consequence of an unresolved provenance gap?
Which standards are already in use?
Which events are sufficiently important to justify cryptographic commitment?
It does not. A ledger can preserve the integrity of a statement without establishing the truth of the statement. Source quality, calibration, scientific method, inspection, fraud controls and professional judgement remain necessary. The correct claim is that cryptography can make later alteration detectable and can support attribution to an authorised key or system.
A useful provenance ledger is append-only, not intellectually frozen. A correction is represented as a new event that revises or supersedes an earlier state. The earlier state remains visible because it is part of the historical evidence. This is particularly important in science, where revision is expected, and in regulated environments, where the reason for a change may itself be important.
Not necessarily. Audit trails can be excellent while the relationships between systems remain weak. If Organisation A calls a sample 1007 and Organisation B calls it LAB-882, the two audit trails may each be correct without proving that those identifiers refer to the same transferred material. Cross-system identity and transformation relationships need their own evidence.
Usually the opposite. Large payloads are expensive and unnecessary to replicate, and sensitive data may be inappropriate for broad ledger distribution. The provenance layer should commit the minimum information required for integrity and relationship verification while source systems retain detailed payloads.
No. Participants still need to trust identity governance, source controls, inspections and the competence of actors. Distributed validation can reduce the ability of one party to rewrite shared history, but it cannot remove real-world trust from the evidence-creation process.
They solve different parts of the problem. Standards provide interoperable meaning and data structures. A ledger can provide shared integrity and durable commitment. A strong architecture uses standards inside or alongside the provenance layer rather than replacing them.
Not always. Recording every technical event can obscure the evidence that matters. Provenance should capture events that change identity, custody, derivation, interpretation, responsibility or assurance. Detailed operational logs can remain in source systems and be referenced where necessary.
It need not. A permissioned system can allow authorised parties to verify integrity without publishing sensitive payloads. Selective disclosure, hashes, scoped identifiers and portable evidence packages can separate verification from unrestricted access.
That is usually a warning sign. Existing systems already manage detailed operational state. The provenance layer should preserve cross-system relationships and integrity, not become a second ERP, LIMS or repository.
Decentralisation is not an end in itself. The useful property is an appropriate trust model. Some deployments may be single-authority during a demonstrator and later add independent validators or witnesses. Others may remain organisationally private. Architecture should follow the assurance requirement rather than an ideological preference for decentralisation.
Organisations do not move directly from spreadsheets to cryptographically verifiable multi-party provenance. A staged maturity model is more realistic.
Level 1 — Local records. Each system maintains its own operational history, but cross-system mappings are informal or manual.
Level 2 — Documented hand-offs. Transfer manifests, interface mappings and shared identifiers make important boundaries explicit. The organisation can reconstruct most evidence chains with effort.
Level 3 — Interoperable event provenance. Significant events are represented using stable identifiers and machine-readable relationships. Domain standards are used where available. Cross-system history can be queried rather than reconstructed manually.
Level 4 — Integrity-backed provenance. Significant events and source artefacts are cryptographically committed. Revisions are append-only. Portable verification can detect tampering.
Level 5 — Multi-party verifiable provenance. Independent participants attest their own events and share or witness the committed history under an agreed governance model. No single participant can silently replace the accepted cross-organisational history.
Not every organisation needs Level 5. A single laboratory may be well served by Level 2 or 3. A complex consortium, premium export chain or high-value regulated evidence network may justify Level 4 or 5.
The maturity model is useful because it separates provenance improvement from blockchain procurement. Organisations can improve identifiers, metadata, hand-offs and revision practices before adopting any ledger technology. In many cases that preparatory work creates immediate value regardless of the eventual architecture.
This is also the role of BioChain Advisory: understand the evidence chain first, identify where provenance actually breaks, and only then decide which controls and infrastructure are proportionate.
Good provenance is boring in the best possible sense. An investigator should not need privileged knowledge of the original project to understand the evidence chain. Identifiers are stable or their mappings are explicit. Important transformations have named inputs and outputs. The source of an assertion is visible. The organisation or system responsible for an event is distinguishable from the organisation currently storing the record. Dates and versions are unambiguous. Corrections do not erase the state that preceded them.
Good provenance is also proportionate. It does not replicate every source database or expose confidential information merely to demonstrate technical sophistication. It records enough context to explain the evidence and enough integrity information to detect substitution or silent alteration. Detailed payloads remain where they are appropriately governed.
Most importantly, good provenance survives change. Staff can leave, applications can be replaced and collaborations can end without making the evidence unintelligible. A future researcher, auditor, customer or partner can identify the source, follow the transformations, see the revisions and understand where the chain is incomplete.
That is the standard against which a provenance platform should be judged. The goal is not the number of blocks produced, the novelty of the consensus algorithm or the volume of events committed. The goal is whether an important evidence history remains understandable and verifiable when it crosses the boundaries that normally cause context to disappear.
Editorial word count: approximately 10,128 words including contents, Q&A, appendices and references.
The BioChain is developing trusted infrastructure for verifiable provenance across systems, organisations and evidence chains. It is designed to sit alongside existing operational systems rather than replace them.
If your organisation generates, manages, analyses or governs biological evidence and would be interested in participating in a UK or European provenance demonstrator, The BioChain would welcome the conversation.
Get in touch
Regulatory developments, technical notes and platform news — sent occasionally, straight to your inbox.