10 The Literature IV: Pipelines, Reproducibility, and Standards
An SCE is, at bottom, a pipeline with duties. This chapter reviews the machinery the field has developed for making pipelines reproducible — and the standards conversation that will shape the next five years.
10.1 The pipeline-tool lineage
The idea that a workflow should know its own dependency graph — skipping up-to-date steps and invalidating stale ones — goes back through GNU Make, and its most mature R-native expression is Will Landau’s {targets} (ropensci), the successor to {drake}. Its framing deserves quotation-level attention: when all targets are up to date, “this is evidence that the results match the underlying code and data,” which makes the pipeline itself a trust instrument. {targets} belongs to the exploratory tradition — but the insight transfers exactly to regulated work: a pipeline that can prove its own up-to-dateness has already generated half its audit trail.
The clinical ecosystem wraps the same insight in compliance clothing: {whirl} executes pipeline scripts with structured logging and log validation; {logrx} captures locked package versions and code hashes at execution time; {envsetup} standardizes environment provisioning. None of these is an SCE by itself. Together they sketch one.
10.2 Locking the world
Reproducibility in R has a second meaning beyond graphs: environment reproducibility, pinning the language-plus-packages world. The standard practice — {renv} lockfiles, CRAN snapshot repositories, and container images built from them — is documented across the R Validation Hub’s reproducibility discussion and the PHUSE open-source guidance (as engaged in the companion papers), and is effectively universal in regulated R deployments. The practitioner refinement this book advocates: treat the container image digest itself as an artifact — a self-evidencing reference environment — so that “which world did this run in?” becomes a hash lookup rather than a rebuild ritual.
10.3 The standards conversation
Three standardization threads will shape SCE architecture through the rest of the decade:
- Analysis Results Data. The cards/cardx packages in pharmaverse implement the ARD idea — analysis results as structured, display- agnostic data objects — decoupling computation from presentation. The direction aligns with CDISC’s ARD initiative; convergence would give the trust layer a standard intermediate at which to verify, which is exactly where verification belongs (verify the numbers before they are typeset).
- Dataset-JSON. Transport formats are migrating from XPT toward JSON-based interchange, already supported in the ecosystem’s I/O packages. For pipeline contracts, JSON is the native tongue — the artifact-graph idea and the submission-format idea are converging.
- Pipeline evidence. No serious candidate yet exists for a standard format for pipeline evidence — manifests, comparison records, verification verdicts — which is why this book’s platform (Part IV) versioned its own contracts. The first credible open standard here will be adopted fast, because every builder is currently inventing the same three JSON files.
10.4 What the review implies
Stack the four literature chapters and a shape emerges. The regulatory frame says evidence, proportionate to risk. The validation literature supplies screening, then intended-use evidence, then governed AI. The platform literature supplies parts, catalogs, and honest disclaimers. The pipeline literature supplies graphs, locks, and converging standards. Nothing in any of it supplies the binding: a composed environment whose every execution emits all three evidences — accuracy, reproducibility, traceability — as a side effect. Part III states the principles for that binding. Part IV builds it.
The test. Ask any pipeline the {targets} question at regulated scale: “If nothing has changed since the last run, can you prove the outputs still match the inputs — without re-running?” A pipeline that must re-execute to reassure is remembering; one that answers from its own graph is recording.