Reproducibility containers — anyone can re-run your analysis

When you publish a Result, you can attach a reproducibility container — a Python or R environment plus an entrypoint script — that anyone in the world can re-execute against your datasets. The platform runs the container fresh, hashes its output, and shows a side-by-side diff against your originally-published outputs.

**Why this exists:**
The reproducibility crisis is a "we can't re-run your code" crisis. Containers make code AND environment immutable; the registry pins the dataset hashes. So a third-party re-run is genuinely deterministic.

**Supported runtimes (Slice 5):**
- Python 3.11 (`python:3.11-slim` base) — most common.
- R 4.x — coming.
- Others (Julia, MATLAB-compatible Octave): on request.

**How to publish a container:**
On the Reproduce tab → New Reproduction Spec:
1. Choose runtime + base image.
2. Upload your `requirements.txt` (or `renv.lock` for R).
3. Upload your analysis script (the entrypoint).
4. Select which experiment datasets the container can read.

The platform builds the image once and stores it. Anyone — including you — can hit "Re-run" and the engine spins it up fresh, captures stdout, hashes the output, and posts a Reproduction record with status (passed / mismatch / failed) + a matchScore from 0.0 to 1.0.

**Compute cost passes through at +15%:**
Reproduction runs cost real CPU/memory. The cost passes through to your org usage at +15% (the platform-wide chargeback rate). For solo researchers, costs are typically pennies per run.

**Why mismatches are a feature, not a bug:**
If 7 of 10 re-runs match and 3 don't, that's incredibly useful information — it surfaces non-determinism in the analysis (RNG seeds, file-system ordering, GPU-vs-CPU drift). Discovery doesn't hide mismatches; it shows the diff and lets reviewers decide.