The same button, a different analysis
A researcher opens a previous analysis and selects “Run again.” The sample names look familiar. The workflow has the same title. This time, however, the output table is different. The researcher now needs to find out whether the difference came from a deliberate change, a new default, or an input that was replaced under the same filename.
Consider a representative research team comparing measurements from an assay. Its analysis product stores results and lets users repeat a workflow. The team wants a colleague to be able to reconstruct a particular run without borrowing the original analyst's laptop or remembering which options were selected. This is an illustrative design case, not a report of a client implementation.
Here, computational reproducibility means repeating an analysis with recorded inputs and conditions, then comparing its outputs against a defined expectation. That scope matters. Repeating the computation does not establish that the experiment was well designed or that another laboratory would reach the same scientific conclusion.
Defaults are part of the experiment
Suppose the original workflow excluded observations below a threshold of 10. The researcher left the threshold field untouched because 10 was the default. Before the rerun, the workflow maintainer changed that default to 20. Both numbers are illustrative. They describe a possible failure, not a recommendation for any assay.
If the saved run records only user overrides, its parameter list is empty. Reopening that list against the current workflow applies the new threshold. The interface appears to repeat the original analysis while requesting a different one.
For this product, the run record should capture the effective value of every parameter that influences the result, including defaults resolved at launch. The comparison view can then show “threshold: 10 → 20” and identify where the change came from. The researcher can choose to preserve the original value or deliberately test the revised one.
A repeated run should receive its own identifier and point back to the source run. Editing the original record would erase the distinction the researcher is trying to inspect. A separate rerun record also gives the team somewhere to explain why the comparison was made.
Save what actually ran
A launch form describes an intention. The execution record needs to describe what happened. In the representative system, that would include the selected input release, a file manifest with content identifiers, workflow code revision, resolved parameters, software environment, and produced outputs. Record exclusions and preprocessing decisions where they affect interpretation.
A filename alone cannot identify the bytes used by the computation. If the file changes, the product should either retrieve the retained version or explain that the original input is unavailable. It should never silently substitute the current file and describe the result as an exact repeat. Content hashes help identify changes; they do not preserve missing files or prove that a dataset is scientifically appropriate.
Software labels have a similar limitation. Docker documents that image tags can be reassigned, while a digest identifies a particular image version. Its guidance also notes the maintenance trade-off: pinning requires intentional updates rather than automatically receiving changed images. See Docker's guidance on pinning base images.
The interface can display a readable environment name while retaining the resolved image digest in the run details. A pinned image still needs to remain retrievable. External services and reference databases need their own version or snapshot strategy; an environment label cannot stand in for them.
Let the researcher choose the kind of repeat
The product needs to distinguish a repeat under recorded conditions from a new analysis based on an earlier run. Those are both legitimate actions. Combining them in one button leaves the researcher to infer which one occurred.
“Repeat recorded run” could restore the original inputs, parameters, and environment references, then check their availability before launching. “Create a variant” could copy those settings into an editable draft and require an explanation of the intended change. These are proposed interface choices, not universal labels every tool must adopt.
The preflight screen should focus on differences and blockers. An unavailable input, unresolved environment reference, or changed parameter belongs near the launch action. Full manifests and logs can sit behind a details view. Asking a researcher to read hundreds of configuration lines before every launch would make the audit trail technically present but practically difficult to use.
For a parameter that changed, show both values and their origins. “Current workflow default” is more informative than “modified.” It explains why the draft differs even when the researcher has not touched the control.
A resumed task is not a fresh execution
A repeat can reuse earlier work. Nextflow, for example, uses task metadata to calculate cache keys; its documented inputs include the task script, inputs, and container image. When resuming, it checks for a matching cached task and retained outputs in the work directory. See Nextflow's caching and resuming documentation.
That behavior is useful when recovering from an interruption or avoiding unnecessary computation. It also creates a distinction the run summary should preserve. A result retrieved from a previous task demonstrates reuse of an artifact, not a fresh execution of that task under the new run's conditions.
For this case, show which stages executed, which reused outputs, and which failed or were skipped. If the researcher is testing the ability to recompute results, provide a way to require fresh execution and make its cost visible before launch. If the task is merely to recover a report, reuse may be the sensible choice. The interface should make the choice understandable rather than treating one mode as inherently superior.
Define what counts as matching
Before running a comparison, decide what agreement would mean. For a deterministic transformation, byte-identical outputs may be the appropriate target. For another workflow, the team may need a numerical tolerance or a comparison of specific derived quantities. The criterion should come from the method and intended use, and it should be recorded before inspecting the new result.
In the threshold example, compare the effective settings first, then inspect which observations were included and how the resulting table changed. A difference caused by deliberately changing the threshold is an analysis variant. Calling it a failed reproduction would confuse an intentional experiment with an execution problem.
Record random seeds where the method uses them, but avoid presenting a seed as a blanket guarantee. The run's environment and comparison criterion still matter. Where the method's behavior is not established, the product should report that uncertainty instead of issuing a universal “reproducible” badge.
A useful result screen names the comparison target, reports the observed differences, and links to the inputs and settings that explain them. Successful process completion belongs on that screen too, but it answers a narrower question: did the computation finish?
Keep the record useful outside the application
The run history should remain intelligible when exported. RO-Crate 1.1 describes a way to package research resources with structured JSON-LD metadata, including contextual information about software, people, and equipment. It offers a foundation for describing related artifacts; the specification does not by itself guarantee that a computation can be repeated. See the RO-Crate 1.1 introduction.
For a small team, a versioned manifest, retained inputs, environment references, and a readable run report may be sufficient. Building a dedicated history interface has a stronger case when several people launch variants, compare outputs, or review results. The maintenance burden includes storage, retention decisions, and ensuring that old references still resolve.
An honest record can outlive the ability to rerun it. If an input must be removed or an environment can no longer execute, preserve the permitted descriptive history and label the limitation. A disabled repeat action with a specific reason is more useful than a button that quietly switches to whatever is available today.
Test the handover to another researcher
Ask a colleague unfamiliar with the original analysis to repeat it from the saved record. Include the changed-default example, an unavailable input, and a run that would otherwise reuse cached outputs. Check whether the colleague can identify each situation before launch and explain the comparison afterward.
These are proposed acceptance exercises, not claimed deployment results. They test whether the product makes its technical records usable at the moment of decision.
The release criterion is concrete: another researcher can identify what ran, restore or account for its conditions, and explain the resulting comparison. Reproducibility becomes part of the interface when those tasks no longer depend on private memory.
Sources consulted
Docker — Pin base image versions