Not simply which sequencing file was analysed. Which model was used, which version, how it was trained, which preprocessing steps were applied, which reference genome was used, which parameters and filters were selected, which software environment executed the analysis — and can the resulting call be traced all the way back to the biological sample from which the sequence originated?
These questions are becoming increasingly important as machine learning moves deeper into genomic analysis. A recent example is ClairS, a deep-learning method developed by researchers at the University of Hong Kong for identifying somatic small variants from long-read tumour–normal sequencing data. Published in Nature Methods in July 2026, ClairS demonstrates both how powerful AI-assisted genomic analysis is becoming and why the provenance requirements surrounding computational biology are becoming more complex. The challenge is no longer simply preserving genomic data. We increasingly need to preserve the computational history that turned those data into evidence.
Sequencing a genome does not produce a list of biologically meaningful variants. It produces data that must be processed. A simplified genomic workflow might look like: biological sample → DNA extraction → sequencing → raw reads → basecalling → quality control → alignment → variant calling → filtering → annotation → interpretation.
Every stage can influence the result. Change the reference genome and coordinates may change. Change a software version and behaviour may change. Change filtering thresholds and the variants retained may change. Change the underlying model and the call itself may change. This has always made computational provenance important in genomics. Machine learning adds another layer.
Somatic variants are genetic changes acquired by cells during an individual’s lifetime rather than inherited through the germline. Identifying them is particularly important in cancer genomics, where tumour cells accumulate mutations that can help researchers understand tumour development and, in some contexts, inform clinical analysis.
Much of the established computational infrastructure for detecting these variants was developed around short-read sequencing. Long-read technologies from platforms including Oxford Nanopore Technologies and Pacific Biosciences provide different information. Long reads can span genomic regions that are difficult to resolve with short reads and provide considerably greater haplotype information, but their different error characteristics mean that analytical approaches designed around short reads cannot simply be assumed to work equally well.
ClairS was designed specifically to address somatic small-variant calling using long-read tumour–normal pairs, and its developers faced an interesting machine-learning problem. Training a deep-learning system requires suitable labelled examples. For germline variant calling, large reference datasets containing known variants are available; equivalent truth datasets for somatic variants are much more limited. The researchers therefore developed a method for creating synthetic training examples from real long-read genomic data. Germline variants from one reference individual can effectively be treated as simulated somatic variants when that individual’s sequence data are compared against those from another individual, allowing training data to be constructed across different sequencing coverages, tumour purities, variant allele fractions and levels of normal-sample contamination.
The result is not merely another variant caller. It illustrates how the definition of a genomic result can increasingly depend upon a chain involving both biological observations and a trained computational model.
Consider a conventional description of genomic provenance: sample → sequencer → raw sequence → analysis pipeline → variant. That description is already incomplete. Once machine learning is involved, a more realistic representation becomes: sample → sequencing platform and chemistry → raw sequence → basecaller and version → reference genome → preprocessing → model architecture → trained model → model version → parameters → post-processing → variant call.
And behind the trained model sits another chain: training datasets → truth labels → data preparation → training method → training parameters → software environment → trained model. The analytical result therefore has two histories — the provenance of the biological data being analysed, and the provenance of the computational model analysing them. Both can matter.
The ClairS project itself provides a useful illustration of why versioning matters. The software has continued to evolve: different releases have introduced fixes, documentation changes and support for different models and sequencing conditions. The project’s public repository, for example, records changes between releases and provides different pretrained models for particular sequencing technologies and chemistries. That is normal and desirable software development, but it creates an important scientific consequence.
Saying “variants were called using ClairS” may eventually be insufficient. A reproducible record may need to say which ClairS release was used, which pretrained model was selected, which sequencing chemistry generated the input, which parameters were supplied and which post-processing steps were applied. The same principle applies far beyond ClairS: software versions are not merely an IT administration detail when software contributes to scientific evidence. They are experimental metadata.
Deep learning introduces another question that traditional bioinformatics workflows did not always need to consider: where did the model learn what it knows? In ClairS, the answer is unusually well documented — the researchers describe how synthetic somatic variants were generated from Genome in a Bottle reference samples and how additional real cancer-cell-line data were subsequently used to augment training.
That matters because model behaviour is partly a product of training data. If a model performs differently under particular sequencing conditions, tumour purities, sample types or populations, understanding the training material may become important when interpreting that behaviour. This does not mean every individual model output can be explained simply by identifying a training record — machine-learning systems are not databases retrieving previous answers. But the provenance of the model remains relevant to establishing the conditions under which its outputs should be trusted.
ClairS reported strong performance in its benchmarking experiments. Using Oxford Nanopore Q20+ HCC1395 tumour and HCC1395BL normal data at 50× and 25× coverage respectively, the researchers reported F1 scores of 89.83% for single-nucleotide variants and 73.38% for indels. After augmenting training with real cancer-cell-line data, these increased to 96.19% and 79.67% respectively under the reported benchmark.
Those numbers are impressive, but they are not universal properties of the software. They belong to an experimental context. Coverage matters. Tumour purity matters. Normal contamination matters. Sequencing platform matters. Sequencing chemistry matters. Variant allele fraction matters. Benchmark truth sets matter. The authors themselves evaluate performance across these different conditions, illustrating an important principle for AI-generated biological evidence: a performance number without its provenance can easily become misleading. The number needs to remain connected to the conditions under which it was produced.
ClairS is open source, which is an important contribution to transparency. But open code alone does not guarantee that an analysis can be reproduced. Reproducibility in machine-learning-based life science requires considerably more. Researchers writing in Nature Methods have proposed reproducibility standards for machine learning in the life sciences that encompass data, models, code, software dependencies, computational environments and automated workflows.[3]
The FAIR Guiding Principles make a related point. FAIR is commonly summarised as making data Findable, Accessible, Interoperable and Reusable, but the original FAIR paper explicitly extends the concept beyond conventional datasets to include the algorithms, tools and workflows that produce scientific results. For reusable data, the principles also specifically call for detailed provenance.[2] That becomes particularly important when the analytical workflow contains an AI model. Preserving a FASTQ file is not enough to reproduce a variant call. Preserving a VCF file is not enough to explain how that variant was called. And preserving a source-code repository is not necessarily enough to reconstruct the exact computational environment in which an analysis ran.
A reproducible AI-assisted genomic analysis may need to preserve relationships between several classes of information: the biological specimen (sample identifier, source, collection information and relevant biological metadata); the sequencing process (instrument, platform, chemistry, run information and associated quality information); the raw data (original sequence data and persistent identifiers or checksums capable of demonstrating file identity); reference resources (reference genome, annotation databases and other external datasets, including their exact versions); the analytical software (tool name, software release, dependencies and container or computational environment where appropriate); the AI model (model identifier, model version, architecture and the particular weights used for inference); training provenance (the datasets and processes through which the model was trained, where available); parameters (configuration, thresholds and other settings capable of affecting the result); workflow (the order and relationship between analytical steps); and outputs (intermediate and final results linked to the inputs and processes from which they were derived).
This is considerably more information than simply storing the final genomic result. But without it, reproducibility can gradually decay.
Modern bioinformatics increasingly uses containers and workflow systems precisely because computational environments can be difficult to reproduce. A pipeline may depend upon a particular operating system library, Python package, GPU framework or compiler version, and several years later, recreating that environment manually may be extremely difficult.
Containerisation can preserve much of that environment. Workflow definitions can preserve the sequence in which tools were executed. Version-controlled code can preserve the implementation. Checksums can verify the identity of files. Persistent identifiers can connect datasets and research objects.[4] None solves provenance alone. Together, however, they allow us to move towards a computational chain of custody.
There is sometimes a temptation to treat the complexity of machine learning as a reason why complete provenance is unrealistic. The opposite conclusion may be more useful: as the analytical system becomes more complex, documenting everything surrounding the model becomes more important.
We may not always be able to explain every internal feature contributing to a neural network’s output. But we can establish which model produced the output, which version of that model was used, which data were supplied to it, which preprocessing occurred, which parameters were applied, which software environment executed it, when the analysis occurred, and which downstream transformations converted the output into a reported result. That does not make the model intrinsically interpretable. It makes the process auditable. Those are different objectives. Both matter — which is the same principle that shapes how we think about <a href="”>provenance infrastructure more broadly at The BioChain: a system does not need to explain every internal step to be capable of showing, reliably, what happened and in what order.
The issue becomes still more important when AI-derived biological information moves beyond exploratory research. The US Food and Drug Administration has already proposed a risk-based credibility framework for AI models used to generate information supporting regulatory decisions about drug and biological products.[5] The FDA’s approach centres on the model’s context of use: what question the model is being used to address and how its output contributes to a particular decision.
That distinction is important. An AI model is not simply “accurate” or “inaccurate” in the abstract. Its credibility depends partly upon what we are asking it to do. As AI becomes embedded in genomic medicine, pathogen surveillance, drug development and other biological systems, maintaining the connection between model, context, data and result will become increasingly important.
For much of genomics, we have understandably concentrated on preserving biological data: the sample, the sequence, the variants, the metadata describing the organism. That remains essential. But genomic evidence increasingly has another dimension — it is computationally produced. A variant may exist biologically, but our evidence that it exists may depend upon millions of calculations performed by software and, increasingly, machine-learning models.
That means the provenance chain cannot stop at the sequencer. It has to continue through the computational infrastructure: biological specimen → sequence → data transformation → model → analysis → result → interpretation. Every arrow matters.
ClairS is an impressive example of how deep learning and long-read sequencing can be combined to tackle a difficult genomic problem, and its importance extends beyond cancer variant calling. It provides a useful glimpse of where computational biology is heading. Models will become more capable. Sequencing technologies will change. Analytical pipelines will become increasingly automated. AI systems will operate across larger and more complex biological datasets. The resulting science may become extraordinarily powerful. But scientific evidence has to survive longer than the software release that produced it.
Five years from now, we should be able to return to an AI-generated genomic result and establish what happened. Ten years from now, we should still know which model produced it. And if a model, reference dataset or analytical assumption is later discovered to have a problem, we should be able to identify which results depended upon it. Without that information, we have outputs. With it, we have a reproducible scientific record. That distinction is becoming one of the fundamental data-infrastructure challenges of AI-enabled biology. The same challenge, from the cost side of genomic infrastructure rather than the AI side, is explored in our piece on what happens when sequencing becomes cheap enough to deploy everywhere.
ClairS is a deep-learning method developed at the University of Hong Kong for calling somatic small variants from long-read tumour-normal sequencing data, published in Nature Methods in July 2026.
Long reads can span genomic regions short reads struggle to resolve and provide much greater haplotype information, but they have different error characteristics — so analytical methods built around short-read data can’t simply be assumed to work equally well.
Because the result now depends on two histories rather than one: the biological sample and sequencing process, and separately, the model that analysed it — its architecture, version, training data, and the parameters used at inference.
No. Published reproducibility standards for machine learning in the life sciences call for preserving data, models, code, software dependencies and computational environments together — open code alone doesn’t guarantee an analysis can be rerun and produce the same result.
Not on its own. ClairS’s own reported F1 scores varied by coverage, tumour purity, contamination level, sequencing platform and chemistry — a performance number is only informative when it stays attached to the exact conditions that produced it.
Its 2025 draft guidance uses a risk-based, context-of-use framework — a model isn’t simply rated “accurate” in the abstract, its credibility is assessed against the specific question it’s being used to answer and how that output feeds into a decision.
No — interpretability and auditability are different goals. We may not be able to explain every internal feature of a neural network, but we can still record and preserve which model, version, data, parameters and environment produced a given output, which is what makes the process auditable.
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.