The practices that make a result recomputable are decided before the research
Which inputs and decisions must be recorded so a research result can be recomputed?
Save input versions, code revision, parameters, random seeds, split boundaries and expected outputs when the experiment is designed. Then rerun the calculation independently from those records; a result without its data and decision trail cannot be recomputed reliably.
Wilson and coauthors explicitly do not cover reproducibility directly; attribute recomputability practices to the combined cited sources.
Evidence map
| Aspect | Finding |
|---|---|
| What it is | The working habits that let a result be regenerated from its inputs months later, by someone else. |
| The pitfall it addresses | The costly failure is not a wrong result, it is an unreachable one. |
| How to apply it | Keep everything that produces a number under version control, including the analysis and the parameters, and give every reported figure a commit that generated it. |
What it is
They are the operational counterpart of reproducibility as a gate: version control over code and analysis, a single script that runs the whole pipeline from raw input to reported figure, an explicit record of data provenance and of every transformation applied, fixed random seeds, and dependencies pinned to versions. The literature on scientific computing converges on the same short list, and its central claim is that these are cheap when adopted at the start and expensive to retrofit.
The pitfall it addresses
A promising figure produced by a sequence of interactive steps, some of them manual, cannot be regenerated once the session is gone; the researcher then either repeats the work from memory, which produces a different number, or trusts the original, which cannot be checked. Silent versions of the same failure are worse: a pipeline whose intermediate file was edited by hand, a seed left unset so that a rerun gives a different answer with no explanation, a library upgraded between the run and the review so that the same code produces different output. Each converts a measurement into an anecdote, and none announces itself.
How to apply it
Write the pipeline so that it runs end to end from raw inputs with one command, with no manual step in the middle, and make it stop with an error on a missing input. Set and record seeds for anything stochastic, and check that a rerun reproduces the figure before the figure is reported. Record where each dataset came from, when it was obtained and what was done to it, since data provenance is the part most often lost. Treat the reproduction run as a gate that precedes interpretation, not as a courtesy afterwards.
Source
Wilson et al., "Best Practices for Scientific Computing", PLOS Biology 12(1), 2014, e1001745; Wilson et al., "Good enough practices in scientific computing", PLOS Computational Biology 13(6), 2017, e1005510; Sandve, Nekrutenko, Taylor & Hovig, "Ten Simple Rules for Reproducible Computational Research", PLOS Computational Biology 9(10), 2013, e1003285; Peng, "Reproducible Research in Computational Science", Science 334, 2011, 1226-1227. Primary source