ReproGuard is alpha. Every release so far has spent more effort removing false positives than adding checks — that ordering is intentional and stays the rule. The non-goals at the bottom matter as much as the plan above them.
Four rules, applied in order. Anything that doesn't survive all four doesn't ship.
A check that cries wolf gets disabled within a week, and once disabled it never protects anyone again. A missing check only costs the finding it would have caught. So noise reduction outranks new codes, every release.
Every finding carries a location, a plain-language description, a suggested fix and a confidence value. There is no ML scoring model and no opaque ranking — the score is a published formula you can recompute by hand.
Default scans never run your code. Notebook execution exists
behind --execute because it is the only way to catch
some failures — and it is also slow, environment-dependent, and
sometimes unsafe.
If a construct can't be understood, ReproGuard stays silent rather than emitting a plausible-looking finding. Silence is honest; a wrong finding costs trust.
Four releases, in order. The later ones are mostly cleanup — which is the point.
environment.yml and lock-file dependency
parsing
checks.ignore
--baseline,
--fail-new)
.reproguard.yml
reproguard init / explain /
list
--since scans — seconds instead of
minutes on PRs
--fail-trendDEP004 — unpinned in-notebook
pip install calls
SEC013 — credentials embedded in URL query strings
-o - for piping into other
tools
HAND001 script-gating correction
Ordered by expected value per unit of risk. Nothing here is a commitment to a date.
--fix codes — widen
auto-remediation beyond output stripping
dvc status integration — detect data that changed
without re-training, beyond the static REPO007 file
check
Directional, not scheduled. Each of these is a product in its own right.
Aggregate scan history across repositories. The local
trend history is the foundation this would be built
on.
Programmatic scanning and result retrieval, so ReproGuard can sit inside a larger release pipeline instead of only a CLI step.
Scan whole Airflow and Kubeflow pipelines for reproducibility risk, not just individual notebooks and scripts.
Hook into Great Expectations or whylogs so findings carry real data-quality context.
Things ReproGuard will not become. Saying no is what keeps the signal high.
ReproGuard tells you a data read is unreproducible. It does not version the data. Use DVC or LakeFS for that.
It does not record runs, metrics or artifacts. Use MLflow or Weights & Biases.
No lineage graphs, no catalog, no freshness SLAs. Use DataHub or Monte Carlo.
Nothing here watches a deployed model for drift. Use Evidently, Arize or WhyLabs.
Style, naming and import ordering are somebody else's job. Use Ruff and Black.
The secret checks are a pre-production safety net for committed credentials, not a replacement for a real secrets scanner or a SAST pipeline.
ReproGuard's job ends where production begins: it answers "will this thing run and mean the same thing for the next person?" — nothing more.
The most useful bug report is a false positive with a minimal reproduction. Those get fixed first because they're the ones costing you trust.
Open an issue with the smallest snippet that reproduces it, plus the real-world reason the code is fine. That reason usually becomes the gating rule.
Include the pattern and why it matters pre-production. Broad categories get a check; one-offs usually belong in a custom rule instead.
If a gate is unusable on a real repository, that's a bug. Describe the repo shape and what you needed the gate to do.