An audit trail can tell you what happened inside a system. Provenance asks a larger question: where did this evidence come from, what happened to it, and how did it move between people, systems and organisations?
Modern laboratories, research organisations, food businesses and supply chains are not short of records. A LIMS may record who changed a sample status. An ERP may record the movement of a production batch. A sequencing platform may retain details of a run. A Git repository can preserve changes to analytical software.
Each system may have a perfectly good audit trail. The difficulty begins when the evidence chain crosses the boundary of one system.
A physical sample may be collected by one organisation, processed by another, sequenced by a third and analysed elsewhere. A food product may move from producer to processor to distributor while laboratory and genomic evidence about that product is generated in entirely separate systems.
Inside one system the question may be: “Who changed this record?” Across an evidence chain it becomes: “Can we reconstruct where this evidence came from, how it changed, and how the records held by different organisations relate to one another?”
Audit trails are established controls for trustworthy electronic records. In the UK, the MHRA’s GxP Data Integrity Guidance describes expectations for data governance across GxP sectors and states that routine data review should include documented audit-trail review where this is determined by risk assessment.[1]
In the EU, EU GMP Annex 11 on Computerised Systems says that, based on risk assessment, systems should create records of GMP-relevant changes and deletions; reasons for changes or deletions should be documented, and audit trails should be available in an intelligible form and regularly reviewed.[2]
These controls matter. They help establish what happened to records within the scope of a computerised system. But their existence does not automatically create a provenance history across every system that contributes to a later piece of evidence.
The W3C PROV family defines provenance as information about the entities, activities and people involved in producing a piece of data or thing, and was designed to support interoperable exchange of provenance information across heterogeneous environments.[3]
Its core concepts are deliberately simple: entities are the things whose history matters; activities are processes that use, transform or generate them; and agents are people, organisations, software or other actors associated with those activities.[4]
Audit history and provenance overlap, but they are not identical. An audit trail is usually centred on events within a particular system. Provenance can describe how an entity was produced, transformed, derived, attributed and revised across a wider chain of systems and actors.
Consider a collaborative research workflow. One institution collects material. A specialist laboratory performs extraction. A sequencing provider generates raw data. A bioinformatics group processes those data. A consortium later incorporates the resulting dataset into another analysis.
Every participant may maintain an appropriate audit trail. The unresolved question is whether the identifiers and relationships between those systems are preserved well enough to reconstruct the complete history later.
Five good audit trails do not automatically constitute one end-to-end provenance record.
The same issue appears in food safety and One Health. EU food law already treats traceability as a chain-wide requirement: 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, and requires operators to identify suppliers and businesses supplied.[5]
Modern outbreak investigation adds further evidence systems to that chain. EFSA and ECDC’s One Health WGS system uses interconnected platforms for food-safety and human-health genomic data. EFSA states that genomic information is used together with relevant traceability and epidemiological evidence when assessing multi-country foodborne outbreaks.[6]
The UK provides the same kind of cross-domain example. Whole-genome sequencing has been used routinely for Salmonella public-health surveillance, and UK research has demonstrated surveillance approaches that integrate genomic and epidemiological data for outbreak investigation.[7][8]
The challenge is therefore not simply storing a Salmonella sequence, a laboratory result or a product-lot record. It is preserving the relationships between different forms of evidence held by different actors.
A common response to fragmented provenance is to imagine one central database containing everything. That is often neither necessary nor desirable.
A laboratory result can remain in the LIMS. A commercial product record can remain in an ERP or traceability platform. Sequence data can remain in an appropriate repository. Research data can remain in object storage. Sensitive information can remain within the systems authorised to hold it.
What needs to survive across those boundaries are the identifiers, relationships, source references and integrity evidence required to reconstruct the chain.
Evidence changes for legitimate reasons. A laboratory may issue a corrected result. A research dataset may be re-curated. An analytical pipeline may be rerun. A pathogen may be reclassified as new reference material becomes available.
Good provenance should not prevent revision. It should make the relationship between the old and new states visible.
W3C PROV explicitly models generation and derivation, and its primer describes revision as an activity that produces a new version rather than requiring the earlier entity to disappear.[4]
Revision is not tampering. A legitimate correction should create a new state linked to the record it revises. Silent alteration removes that distinction.
Cross-organisational provenance introduces a further question: who must be trusted?
If Organisation A exports an audit trail, the recipient is still relying on Organisation A’s system and governance to establish that the exported history is the history that existed previously. For many workflows, that is entirely adequate. For higher-value evidence chains, participants may want stronger evidence that a previously committed record has not subsequently been rewritten.
Cryptographic techniques can support that property by associating provenance events with content hashes, signatures and tamper-evident history. They do not establish that an underlying scientific or operational claim is true.
A perfectly signed incorrect laboratory result remains incorrect. Cryptographic verification can establish what was committed, who or what attested to it, and whether the committed record has changed. It cannot prove the scientific claim itself.
Often. If one trusted organisation controls the complete workflow and all of the history needed for the intended purpose is contained within a properly governed system, appropriate audit trails, access controls, retention and backups may solve the problem well.
Additional provenance infrastructure becomes more interesting when evidence crosses multiple systems or organisations; different organisations are responsible for different parts of the history; records are reused long after creation; revisions must remain distinguishable from silent alteration; provenance must survive the lifetime of an application or project; or a recipient needs to verify a committed history without relying solely on one organisation’s database.
The BioChain is being developed as a provenance and integrity layer that sits alongside existing systems.
It is not intended to replace LIMS, ELNs, ERP systems, repositories, sequencing platforms, food-traceability systems or supply-chain applications. Those systems should continue doing the jobs for which they were designed.
The BioChain is concerned with the relationships between their evidence: how records move, change, derive from one another and remain connected across organisational boundaries.
And where a single trusted system already provides everything required, a BioChain may not be necessary. Knowing that boundary is important.
An audit trail generally records activity affecting records within a particular computerised system. Provenance describes the wider history of an entity or piece of evidence, including the entities, activities and agents involved in producing, transforming or delivering it.
Yes. A LIMS can provide substantial provenance for laboratory activities within its scope. The problem becomes harder when the complete evidence chain also includes systems, organisations or stages outside that LIMS.
No. Existing operational platforms should continue managing the processes and data for which they were designed. The BioChain is intended to connect provenance across them.
Different organisations use different identifiers, systems, responsibilities and audit histories. Reconstructing the complete history requires preserving the relationships between records held by independent parties.
No. Large, sensitive or commercially valuable data can remain in existing systems. A provenance layer can record identifiers, relationships, hashes and source references without storing the complete underlying payload.
No. Cryptographic integrity can help establish that a committed record has not changed and identify the attestation associated with it. It cannot prove that an observation, laboratory result or interpretation was scientifically correct.
A correction should normally create a new state linked to the record it revises while preserving the earlier state as part of the provenance history.
EU Regulation (EC) No 178/2002 requires traceability through production, processing and distribution. The BioChain is not a replacement for those systems; its potential role is to connect provenance across traceability, laboratory, genomic and other evidence systems.
When one trusted system contains the complete history needed for the intended purpose and appropriate audit, access-control, retention and backup controls are in place, additional cross-organisational provenance infrastructure may not be necessary.
Evidence chains where provenance crosses systems or organisational boundaries and where preserving and verifying the relationships between those records matters.
If evidence moves between laboratories, systems, partners or organisations, the difficult part is often not the audit trail within each system. It is preserving the provenance between them.
The BioChain is being developed to provide that shared integrity layer without replacing the systems you already use.
Explore how The BioChain works →
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.