The Role of Data Provenance in Bioinformatics Audits

By Dr. Zubair Khalid, DVM, MS, PhD · 2026-11-11

Data provenance is the recorded history of where a dataset came from and every process that changed it, while reproducibility is the ability to run that history again and get the same result. An audit demands both, and provenance is the evidence that connects them, because a reviewer who cannot trace how a result was produced cannot verify that the result means what you claim it means. The rule of thumb for choosing an approach is simple. Capture provenance automatically at the point of execution, store it beside the data it describes in a queryable format, and rehearse a full replay of the analysis long before the auditor arrives, because provenance you assemble by hand the week before an inspection is provenance an auditor will not trust.

This guide explains what a bioinformatics audit actually asks of your records, compares the main provenance capture options on the criteria that decide real choices, and walks through worked scenarios for labs of different sizes and missions. The options differ sharply in overhead, granularity, and tamper resistance, and the best data provenance bioinformatics audit setup for a two-person academic lab is rarely the right one for a multi-institution consortium.

What a Bioinformatics Audit Actually Asks For

An audit is a structured request for evidence. Whether the auditor is a regulatory inspector, a clinical accreditation body, a journal reviewer, a funding agency, or an internal quality team, the questions reduce to a short list.

Origin. Where did each input dataset come from? For sequencing data this means sample identity, collection context, sequencing platform, library preparation, and the raw read files with checksums that prove the files have not changed.

Transformation. What software, in what version, with what parameters, on what reference data, produced each intermediate and final file? An auditor wants to walk the chain from raw reads to a variant call, a phylogeny, a differential abundance table, or a machine learning prediction.

Environment. Did the analysis run in a defined computational environment? Container image digests, dependency manifests, and operating system details determine whether the same commands would produce the same output on a different machine.

People and time. Who ran each step, and when? Attribution matters when an auditor investigates an anomaly, retraces a contamination event, or evaluates whether an unapproved protocol change affected published results.

Integrity. Can you show that the records themselves have not been altered after the fact? This is where provenance systems diverge most sharply, because a plain text log is easy to edit and a tamper-evident record is not.

Reviews of large-scale genomics operations identify analysis provenance, data management of massive datasets, and reproducibility as the central obstacles that extend beyond algorithms and tools, and they highlight the opportunity to build pipelines that incorporate data tracking and auditing from the start [1]. The same review notes that these requirements apply across basic research, translational, and clinical settings, which means an audit-ready provenance design is not a clinical-only concern.

The Role of Data Provenance in Bioinformatics Audits in Practice

The role of data provenance in bioinformatics audits is to convert claims into checkable records. Without it, an audit becomes an exercise in reconstructing events from memory, README files, and shell history, and reviewers of whole genome sequencing programs in regulated industrial settings describe exactly this gap. In pathogen source tracking for the food industry, wet laboratory sequencing protocols have benefited from standardization guided by regulatory authorities, while data analysis and results interpretation still lack consensus across institutions, so the burden of demonstrating reliable analysis falls on documented, reproducible computational work [2].

That burden has a practical shape. A food industry WGS program must produce defensible source attribution conclusions within a time frame that allows factories to act on the findings, which means the provenance system has to be complete enough for an audit and fast enough for operations [2]. A provenance approach that requires weeks of manual curation fails the second requirement. A provenance approach that captures nothing verifiable fails the first. Most of the engineering decisions in this article come down to balancing those two failure modes.

Provenance also answers audit questions that pure reproducibility cannot. In machine learning pipelines applied to human data, provenance tracking lets you identify which models consumed a particular user's data so those models can be retrained without it, enforce the strict isolation of training and test data, and detect whether a model behaves differently across demographic groups [3]. An auditor in a privacy or fairness review is not asking whether you can rerun the pipeline. The auditor is asking what the pipeline touched, and only a lineage record answers that.

The Main Data Provenance Bioinformatics Audit Options

There is no single tool called a provenance system. The realistic options fall into seven families, each with distinct strengths. Understanding what each one captures, and what it misses, is the foundation for choosing among data provenance bioinformatics audit options.

Option 1: Workflow-engine-native provenance

Modern workflow managers record provenance as a side effect of running the pipeline. Snakemake, Nextflow, and Common Workflow Language engines log the resolved DAG of jobs, tool versions, parameters, input file identities, and container images for each executed step. Containerized Snakemake pipelines demonstrate this pattern in practice. The FALAPhyl and FAVABEAN pipelines for 16S rRNA microbiome analysis are Snakemake-based, run in containers across local, cluster, and cloud environments, and include integrated provenance tracking in the downstream analysis stage [4].

The QIIME 2 platform goes further by embedding provenance inside its result artifacts. Every artifact carries a record of the actions that produced it, and the Provenance Replay tool generates new executable code from archived results, which closes the loop between a stored record and a runnable analysis [5]. The QIIME 2 developers are explicit about the motivation. Many biologists are not trained to record analysis steps manually, critical information goes missing, and software that automates provenance tracking removes most of the barriers to reproducibility [5].

What it does well. Capture is automatic, the record is structured and machine-readable, and the evidence maps directly to what an auditor asks for, namely exact versions and parameters. Overhead per analysis is low because the workflow engine is already mediating every step.

What it misses. Provenance ends where the workflow ends. Interactive exploration in R or Python notebooks, manual file edits, ad hoc script runs between pipeline stages, and results produced before the workflow was adopted are invisible. Auditors who look at a directory tree of one-off scripts know this gap immediately.

Option 2: Transparent capture in the execution environment

The second option instruments the environment itself so provenance is captured even when code is exploratory and never becomes a formal workflow. The Ursprung system integrates with the execution environment to automatically track static and runtime configuration parameters of data science pipelines, building lineage without asking users to modify their code or adopt specific tools [6]. The design philosophy responds to a documented adoption problem. Most existing provenance systems require users to augment their code, which hinders productivity and results in a lack of adoption, so transparent capture targets the reproducibility crisis at its root [6].

This option matters for audits of research-grade analyses, where the honest record includes the twenty failed attempts and the notebook that preceded the final pipeline. An auditor evaluating scientific integrity often wants to see that record, not just the polished final run.

What it does well. Coverage of informal analysis, low user burden, and a lineage graph that reflects what actually happened rather than what the pipeline definition says should happen.

What it misses. It is platform-dependent, it captures what code ran but rarely the semantic intent behind a decision, and deployment requires integration work with the specific environment your team uses.

Option 3: Fine-grained, element-level provenance

Workflow-level records tell an auditor which script produced a file. Element-level provenance tells them which rows and values in that file came from which rows and values in the input. Systems designed for data preprocessing define a core set of preprocessing operators and provenance patterns for each, and implement application-level capture libraries that run alongside Python, generating provenance records at the level of individual elements within a dataset [7]. The published evaluation measured provenance processing and storage overhead and demonstrated scalability over both machine learning benchmark pipelines and the TCP-DI benchmark dataset [7].

For bioinformatics audits, this granularity answers questions that coarser records cannot. Which samples were filtered by that QC step, and under exactly what threshold? Which cells of the feature table changed when the taxonomy database was updated? Which patient records fed the training set for a model now under fairness review? Fine-grained provenance supports a suite of benchmark queries that map to the debugging questions developers actually ask, as drawn from real developer forums [7].

What it does well. Definitive answers about data quality, per-record lineage, and the effect of each preprocessing step on model properties such as accuracy and fairness [7].

What it misses. It carries the highest storage and engineering cost of any option, and the capture library must be integrated into preprocessing code, which reintroduces some of the adoption friction that transparent systems avoid.

Option 4: Institutional data management platforms and virtual research environments

The fourth option treats provenance as part of bioinformatics data management infrastructure rather than as a pipeline feature. A virtual research environment captures information about the usage of datasets in addition to their preservation over time, supporting reproducibility, verification of the work of others, and confirmation that data were used under appropriate conditions. The same work identifies the hard problem honestly. The dynamic and distributed nature of grid and cloud computing makes provenance capture and processing a major research challenge, and tracking data or workflows separately is insufficient to support the collaborative scientific process.

Efforts to build a provenance metamodel that fits complex bioinformatics pipelines specifically approach the problem reconstructively, working backward from the realities of existing pipelines rather than imposing an idealized model on them. At the lighter end of this spectrum, the Datatrack R package addresses data versioning and provenance in multi-stage experimental workflows, with particular attention to the interactive scripting patterns that dominate real analysis sessions [8].

At the enterprise end, responsible data lake governance architectures embed automated lineage tracking, metadata management, dataset versioning, access control, and human oversight through data stewardship, approvals, governance committees, and audit across raw, curated, and semantic data zones [9]. This layer is where bioinformatics data management and provenance policy meet.

What it does well. Alignment with governance, accountability, and organizational audit processes. Study-level provenance across long project lifetimes. A home for provenance that survives individual project turnover.

What it misses. Requires sustained infrastructure investment. Capture across dynamic, distributed compute remains difficult, as the virtual research environment literature acknowledges directly. It complements rather than replaces per-step workflow capture.

Option 5: Immutable, blockchain-backed provenance stores

When an audit question is whether records were altered after the fact, the answer is a tamper-evident storage layer. Recent architectures apply permissioned blockchain infrastructure to guarantee integrity, immutability, and auditability of provenance in federated, multi-institutional research settings, with persistent identifiers for artifact traceability and a provenance versioning model that preserves the history of updates. A parallel line of work applies the same idea to AI training pipelines, recording dataset lineage, preprocessing steps, annotation events, and model updates as immutable smart contract transactions, with a lightweight off-chain storage mechanism that reduces blockchain overhead while maintaining audit guarantees [10]. In that system's evaluation across three machine learning pipelines, the framework showed a 95 percent reduction in provenance disputes and full traceability across all data contributors, and parallelized validation nodes kept blockchain latency from significantly affecting pipeline throughput [10].

The pattern is not confined to one domain. A git-based decentralized framework for versioning encrypted data embeds hash-based content identifiers in Merkle trees, captures initial datasets as full encrypted commits and later changes as encrypted git patches, and describes the result as FAIR-compliant provenance supporting transparent, auditable, immutable tracking of data changes [11]. The mechanism transfers directly to genomics data storage, where encrypted, version-controlled data with verifiable change history serves the same audit purpose.

What it does well. Non-repudiation and tamper evidence, which no local log file provides. Cross-organization trust without a single trusted custodian.

What it misses. Operational complexity, the design problem of what to anchor on-chain versus off-chain, and the fact that immutability guarantees record integrity, not record completeness. A blockchain-anchored log of an incomplete capture is still incomplete.

Option 6: Adaptive and security-oriented provenance capture

Static provenance policies fail in elastic cloud environments, where ephemeral execution contexts cause incomplete lineage tracking, delayed incident detection, and loss of forensic evidence. Adaptive Provenance Control addresses this by treating provenance capture and verification as adaptive system functions that adjust granularity in response to runtime risk signals rather than as static logging. Under representative big data workloads, the approach achieved up to 29 percent reduction in detection latency, up to 92 percent provenance completeness, and up to 41 percent reduction in storage overhead compared to always-on provenance approaches [12].

A complementary direction monitors the provenance event stream itself for tampering. A transformer-based model trained on the typical characteristics of normal provenance event flow identified anomalies created through spoofing, poisoning, and event insertion attacks, with rapid shifts in the anomaly score at attack onset, while LSTM and rule-based baselines failed to process longer sequences [13]. The evaluation used synthetic events, so the result establishes feasibility rather than production readiness.

What it does well. Scalability in cloud genomics, forensic value under attack, and overhead control tuned to risk.

What it misses. Maturity. These are recent research systems, one validated on synthetic data, and adopting them means accepting earlier-stage tooling than a workflow engine's built-in provenance.

Option 7: Queryable semantic lineage graphs

The final option represents provenance as a knowledge graph built on established standards. A proposed framework integrates provenance standards including the Open Provenance Model and the W3C PROV model with semantic technologies such as RDF, OWL, and SPARQL, enabling lineage reasoning, impact analysis, and prediction of future dependencies and schema evolution rather than purely retrospective tracking [14]. This addresses a real audit pain point. When a reference database or pipeline version changes, an auditor wants to know everything downstream that the change could affect, and graph reasoning answers impact questions that file lists cannot.

Uncertainty is a related strength. Provenance models developed for archaeological dating handle imprecise temporal information with fuzzy logic and derivation rules that refine provenance as interpretations evolve [15]. Bioinformatics audits meet the same problem when sample collection dates, processing timestamps, or database versions are recorded approximately, and a model that carries explicit confidence alongside derived facts is more honest than one that pretends every timestamp is exact.

What it does well. Impact analysis, cross-dataset reasoning, and alignment with open standards that make records portable between systems.

What it misses. Requires modeling investment and ontology maintenance, and semantic prediction of future lineage remains a conceptual framework rather than deployed infrastructure [14].

Side-by-Side Comparison of Provenance Capture Options

Comparison of four provenance options by granularity, what the auditor gets, overhead and the main gap in each.

The table below is the core of the comparison. Read it as a menu of trade-offs, not a ranking, because the right choice depends on the audit you face.

Option	Typical tooling	Granularity	What the auditor gets	Overhead	Main gap
Workflow-native	Snakemake, Nextflow, CWL, QIIME 2 [4][5]	Per execution step	Exact tool versions, parameters, containers, input identities, replayable records	Low, automatic	Invisible outside the workflow, including interactive work
Transparent environment capture	Ursprung-style instrumentation [6]	Pipeline level, automatic	Lineage of exploratory and final code alike, without user effort	Moderate integration effort	Platform-dependent, thin on semantic intent
Fine-grained element-level	Python provenance capture libraries [7]	Row and element level	Per-record lineage, preprocessing effects on quality and fairness	Highest storage and engineering cost	Requires integration into preprocessing code
Platforms and VREs	Virtual research environments, governed data lakes [9]	Study to dataset level	Governance alignment, usage conditions, stewardship and approvals, long-horizon records	High infrastructure investment	Capture across dynamic cloud compute is hard
Immutable distributed stores	Permissioned blockchain, git with Merkle trees [10][11]	Artifact and commit level	Tamper evidence, non-repudiation, persistent identifiers, version history	Operational complexity, anchor-versus-off-chain design	Integrity without completeness, latency management [10]
Adaptive and security-oriented	Control-plane-driven capture, anomaly detection on event streams [13][12]	Dynamic, risk-adjusted	Forensic evidence in ephemeral cloud runs, tamper detection, controlled overhead	Earlier-stage tooling	Validated mainly on benchmark or synthetic workloads [13][12]
Semantic lineage graphs	Knowledge graphs over W3C PROV and OPM [14]	Graph level	Impact analysis, dependency reasoning, standards-based portability	Ontology and modeling investment	Predictive capability remains conceptual [14]

Three comparisons deserve emphasis because they decide most real choices.

Reproducibility evidence. Workflow-native capture and QIIME 2 style embedded provenance are the only options that directly produce a runnable reconstruction, and Provenance Replay demonstrates the strongest version by generating executable code from archived results [5]. Everything else documents what happened without necessarily enabling a rerun.

Tamper resistance. Only the immutable store family provides cryptographic evidence that records are unchanged, which matters when audit findings carry legal weight or when multiple institutions must agree on a shared record. Every file-based option can be strengthened with checksums and signed manifests, but those remain weaker guarantees than a distributed consensus record.

Overhead behavior at scale. Fixed always-on capture conflicts with elastic genomics data storage and compute costs. Adaptive capture resolves the conflict by spending provenance budget where risk is highest, and its published results quantify the trade in both directions, more completeness in relative terms than static logging achieves in practice while cutting storage overhead by a large margin [12].

How to Choose: Criteria That Decide Real Audits

Decision path from audit type to the provenance setup it needs, ending in workflow capture plus a tamper-evident record layer.

Ask five questions in order. The answers usually determine the option, or more often the combination, because mature installations layer two or three families.

First, what kind of audit? A journal or funder reproducibility review is satisfied by workflow-native capture with containers, because the auditor wants to rerun the analysis. A privacy or fairness review needs lineage breadth, meaning the ability to enumerate every model and result that consumed a dataset, which is the capability demonstrated for machine learning pipelines [3]. A regulatory inspection in a clinical or food safety setting needs both replay evidence and integrity evidence, pushing you toward workflow capture plus a tamper-evident record layer [2].

Second, where does the compute run? Fixed clusters behave predictably and tolerate simple always-on capture. Elastic cloud introduces ephemeral execution contexts that destroy forensic evidence unless capture is designed for them, which is the specific problem adaptive provenance control targets [12]. If your genomics data storage and compute are bursty and short-lived, static logging is the wrong default.

Third, how fine must the answer be? If audit questions stop at "which pipeline produced this result," step-level records suffice. If they extend to "which samples and which values were affected by this threshold change," you need element-level provenance and should budget for its storage cost [7].

Fourth, how many organizations share the record? Single-institution audits work with local systems plus signed exports. Federated collaborations need persistent identifiers, versioned provenance, and integrity guarantees that no single party controls, which is the design space of blockchain-backed federated provenance.

Fifth, who maintains it? A system that requires every analyst to change their habits will decay within a year. Transparent capture and workflow-native capture both succeed precisely because they remove the user burden that undermined earlier provenance tools [6]. Buy maintenance effort with infrastructure effort, not with analyst discipline.

Worked Scenarios

Scenario one, a translational genomics core facing its first external audit. The core runs WGS and bulk RNA-seq on a fixed SLURM cluster with roughly a dozen staff analysts. The best fit is workflow-native provenance in containerized Nextflow or Snakemake pipelines, with every result directory storing the resolved config, container digests, and a checksummed manifest, mirrored in an institutional data management system that holds approvals and data usage conditions [1][9]. The core rehearses a replay quarterly by rerunning a small test sample end to end and diffing outputs. Interactive side analyses are handled by requiring analysts to commit notebooks to a repository with pinned environments, accepting an imperfect record rather than paying for element-level capture the core cannot maintain.

Scenario two, food industry pathogen source tracking. The constraints are regulatory scrutiny, a need for actionable results within an operational time frame, and interpretation guidelines that lack inter-institutional consensus [2]. The provenance design must make every attribution result traceable to raw reads, pipeline version, and reference database version quickly enough to support factory decisions. A containerized workflow with embedded provenance, versioned reference databases, and a signed audit export per case satisfies both the speed and defensibility requirements. The interpretation-consensus gap is handled by recording not just the computational result but the interpretation ruleset version applied, so an auditor can distinguish a pipeline change from a judgment change.

Scenario three, a microbiome research lab standardized on QIIME 2. Provenance is already embedded in every artifact, which removes the training burden that undermines manual record keeping [5]. The lab adopts Provenance Replay as its audit rehearsal. When a reviewer or collaborator questions a five-year-old diversity analysis, the lab regenerates executable code from the archived artifacts and reruns it against current infrastructure. The residual gap, analyses performed outside QIIME 2, is covered by a lightweight rule that all such outputs must live in a git repository with a pinned environment file.

Scenario four, a federated consortium of hospitals sharing genomic models. No single institution is trusted to hold the shared record, and privacy review requires knowing exactly which models consumed which patient-derived datasets. The consortium deploys a permissioned blockchain provenance layer with persistent artifact identifiers and versioned provenance, anchoring dataset registration, preprocessing events, and model training events on-chain while keeping bulk data off-chain. Smart contracts encode access and validation rules so only approved datasets enter training, the pattern shown to automate compliance checks in the AI training pipeline framework [10]. The audit trail answers both the integrity question and the data-consumption enumeration question across organizational boundaries.

Scenario five, a cloud-native analytics team with bursty elastic workloads. Always-on capture is costing too much in genomics data storage and slows incident response because logs are incomplete across ephemeral runs. The team adopts an adaptive provenance policy that raises capture granularity when risk signals rise, such as unusual access patterns or anomalous event sequences, and relaxes it during routine runs, accepting the published trade of high provenance completeness with materially reduced storage overhead and faster detection [12]. Anomaly detection over the provenance stream adds a tamper tripwire, with the caveat that the team monitors false positive behavior on real traffic given the synthetic-data validation in the literature.

Common Mix-Ups

Confusing provenance with logging. A log says a job ran. Provenance says which inputs, which code, which parameters, and which outputs. An audit based on logs alone cannot answer the transformation questions that decide findings.

Confusing captured provenance with replayable provenance. A record of tool versions is not the same as executable code. QIIME 2's Provenance Replay exists because archived provenance needed a path back to execution, and the tool's design guidance for developers who want similar functionality is published and specific [5].

Assuming capture equals integrity. Every local record can be edited. If an audit finding depends on records not having been altered, you need checksums, signatures, or an immutable store, because capture completeness and record integrity are independent properties.

Treating provenance as a publication formality. The same lineage record that satisfies a reviewer also powers debugging. Fine-grained provenance answers the concrete questions developers ask when a preprocessing step corrupts data or quietly biases a model [7], and end-to-end architectures now couple provenance with explainable AI metrics such as SHAP values and training data influence functions to trace how data manipulations affect deployed model behavior [16]. Teams that capture provenance only for audits lose the operational payoff.

Equating always-on capture with better audits. Completeness has a cost curve. Adaptive schemes exist because uniform maximum capture is neither affordable nor necessary in elastic environments [12]. The audit-relevant question is whether capture completeness covers the steps that matter, not whether it covers everything at the same resolution.

Overlooking uncertainty in the record itself. Timestamps and collection dates are frequently approximate. A provenance model that carries explicit confidence in uncertain values produces more defensible audit testimony than one that stores approximations as certainties [15].

Common Mistakes and Limitations

Manual provenance assembly. Reconstructing analysis history by hand after the fact is the single most common failure. The evidence is consistent across the literature. Systems that require users to augment their code see poor adoption, which is why transparent capture integrates with the execution environment instead [6], and software that automates provenance tracking is recommended specifically because most analysts are not trained to record steps reliably [5]. If your plan requires analyst discipline to work, plan for it to fail.

Capture that stops at the workflow boundary. Audits routinely surface results produced by scripts outside the sanctioned pipeline. Either instrument the environment transparently or constrain analysis to provenance-capturing platforms. Do not assume the gap is small.

Ignoring the right to be forgotten and data-consumption questions. Retraining obligations and privacy reviews require identifying every model that consumed a given dataset. Workflow logs organized per project rarely support this query across years. Plan a lineage store that answers it.

Underestimating storage growth from fine-grained capture. Element-level records multiply quickly, and the overhead was measurable even in benchmark evaluations [7]. For large genomics data storage volumes, decide granularity per data class, reserving element-level capture for datasets where per-record questions are plausible.

Deploying immature tooling without a fallback. Transformer-based anomaly detection over provenance streams and adaptive control-plane capture are promising but recent, and the anomaly detection result rests on synthetic events [13][12]. Pilot them on non-critical workloads, and keep a conventional provenance record running underneath.

Confusing immutable records with trustworthy content. A blockchain anchor proves that what was written stayed written. It says nothing about whether the capture was complete or the process correct. The 95 percent reduction in provenance disputes reported for one smart contract framework came from a system that also automated validation of which datasets were permitted into training, so process controls and immutable storage worked together [10].

Letting the provenance system rot between audits. Provenance infrastructure decays when the person who built it leaves. Institutional platforms and governance structures with named stewards and committees exist to prevent exactly this, which is the argument for embedding provenance in bioinformatics data management rather than in one engineer's home directory [9].

A final limitation applies to every scenario here. Audit readiness is a property of the whole system, and individual analyses, especially those feeding clinical or regulatory decisions, still require review by a qualified bioinformatician who understands the biological context, because no provenance record substitutes for expert judgment about whether an analysis means what it appears to mean.

Frequently Asked Questions

What does data provenance mean in a bioinformatics audit?

It is the documented history of where each dataset came from and every process that touched it, including software versions, parameters, container identifiers, timestamps, and the people or services that ran each step, stored in a form an auditor can verify. Provenance converts audit claims about how a result was produced into checkable records.

What is the best data provenance setup for a small academic lab?

A containerized workflow with engine-native provenance capture, such as Snakemake or QIIME 2, is the strongest default for a small lab. It records versions and parameters automatically with minimal extra work, produces replayable evidence, and matches what most reproducibility reviews request. Add interactive-code coverage through pinned environments and version-controlled notebooks.

Do you need blockchain to pass a provenance audit?

No. Most audits accept well-organized, checksummed, timestamped records with a clear custody trail. Blockchain-backed provenance becomes valuable when multiple organizations must share tamper-evident records and no single party is trusted as custodian, which is the federated setting those architectures target.

How does provenance relate to reproducibility?

Provenance is the record of what happened, and reproducibility is the ability to make it happen again. Strong provenance enables reproduction, and tools like QIIME 2 Provenance Replay close the loop by generating executable code directly from archived provenance records [5].

How much extra storage does provenance capture require?

It depends on granularity. Step-level records are small relative to the raw genomics data storage they describe, element-level capture can grow substantially because it records per-value lineage [7], and adaptive schemes control overhead by adjusting capture intensity to runtime risk [12].

What should a provenance record contain to satisfy an auditor?

At minimum, input file checksums, exact software and database versions, all parameters, container image identifiers, execution timestamps, the person or service responsible for each step, and the mapping from each input to each output. Store it in a structured, queryable format rather than free text, and test annually that you can replay a representative analysis from the record alone.