← Module 14 overview
Module 14 · Week 15 synthesis & peer review · Reproducibility & AI Audit · adaptive competency DV22

Repair the reproducibility failures

Mission progress0%

Begin by reconstructing the evidence lineage.

Module 14 · Step 2 of 9 · Guided10–12 min

Why this lab Repair reproducibility failures and watch the pipeline rebuild itself.

Debug four failures involving random state, local file paths, execution order, and package drift. Each repair must make the analysis portable rather than merely making it run on one machine.

Before the debugger · what makes an analysis reproducible

A script that ran once without errors on your machine is not yet reproducible. It is reproducible when a clean run, in a fresh session on another machine, regenerates the same result from versioned inputs, the code and a recorded environment. Four habits get it there:

  1. Random state. Anything that samples or simulates gives a different answer on each run unless you call set.seed(2026), or any fixed number, immediately before the random sampling, and record that seed with the code.
  2. File paths. A path such as C:/Users/analyst/Desktop/final.csv exists only on one machine. Use a project-relative path such as data/scores-2026-09.csv that points to a versioned snapshot of the data stored with the project.
  3. Execution order. Run the script top to bottom in a clean session. It must create every object it uses before the line that needs it; an object left over from an earlier console session will not exist for anyone else.
  4. Package environment. Packages change between versions and can change your output. Record the package versions, for example with sessionInfo() or a lockfile, and restore that environment before regenerating.

Reproducibility debugger loading…