Your bioinformatics pipeline runs. Could anyone else run it next month?

The pipeline only one person can run

Your Nextflow pipeline works because one bioinformatician knows its quirks: which reference folder is current, which parameter to pass, which warnings to ignore. When that person is on leave, a failed run waits. When they move on, the team inherits a results folder nobody can fully explain.

Consider Northbank Bio, a fictional example. Its approved analysis runs eight research samples, the job exits successfully and eight summaries appear. One input used the wrong identifier and one file is a leftover from last week. The count is right; the result is not.

A green run is the start of delivery, not the end of it.

Start from your engine and approved analysis. The missing piece may be an input contract, a reconciliation step or a handoff another operator can use, rather than another scheduler or data platform.

Agree the run contract before computing

Write down what one accepted run contains. Use authoritative sample identifiers and keep the source delivery version with a content fingerprint, because the same filename can arrive with different contents.

• Inputs: expected sample identifiers, source versions and required metadata.
• Method: workflow revision, parameters, reference versions and execution environment.
• Execution: run identifier, attempts, start and end times, terminal status.
• Outputs: required artifacts per sample, integrity checks and QC results.
• Acceptance: permitted exclusions, reviewer, decision and reasons.

A checksum detects changed bytes; it cannot tell you a tube was labeled correctly. Resolve identity through the lab’s authoritative records. For external deliveries, the CRO intake guide covers that earlier handoff.

Pin everything that can change the answer

Record the workflow revision, container or environment, reference data and parameters, including derived reference indexes. A moving branch, a reusable image tag or an unversioned reference folder makes any later comparison ambiguous.

Run a small scientist-approved fixture twice in the target environment, with the comparison rule agreed first: exact matches for some outputs, justified tolerances for others. A container or a random seed alone does not guarantee identical output.

Record the rule and its outcome. A repeatable incorrect method is still incorrect, so the scientific owner decides whether the method and comparison suit the research question.

Reconcile outputs before calling a run accepted

For Northbank, compare expected identifiers with produced ones and flag missing, unexpected and duplicate outputs. Keep each run in its own location so leftovers cannot satisfy the count. If a sample is excluded, keep the reason and approval instead of quietly changing the expected total.

Give the receiver a per-sample manifest with the input version, output links and accepted or excluded status. Test it by swapping one identifier while the file count stays the same: the mismatch must stay visible. If the source delivery is corrected after approval, the new run gets its own acceptance decision.

Use Nextflow’s built-in reports for run history, resource use and timelines. Where packaging helps, Workflow Run RO-Crate records execution provenance with the inputs, outputs and code. A supported format beats a homemade one, and computational completion stays a separate state from scientific acceptance.

Prove resume before relying on it

Nextflow’s cache and resume documentation is precise: a task is reused only when its cache entry matches and its outputs are still in the work directory. Clean the work directory and those tasks run again from scratch. A resume flag is not a recovery plan.

Run the opposite case too: delete a required work output in a disposable run and confirm the task re-executes instead of presenting missing data as complete. Check that final results contain no duplicated or partial outputs. Then agree separate retention for source data, final results, run evidence and disposable work files, and test a restore with the operator.

Make the pipeline operable by its next owner

Name who resolves failed runs, approves reference changes and accepts new workflow versions. A changed method or reference is a new comparison, so keep the previous accepted result rather than overwriting it under the same label.

Measure elapsed time, operator effort and cost per accepted run on comparable workloads, including failures, retries, storage and transfer. A lower compute bill is one input, not proof of better science. Diagnostic or patient-related use needs its own intended-use assessment and qualified owners.

An acceptance checklist for one pipeline

Request a call from this article and describe the run that failed last, or the person your pipeline depends on. The first conversation needs no data. See how we work with biotech teams. If users need an app around the pipeline, read the research app guide.