ds-notebook-reproducibility

What problem does it solve?

Notebook results often change because of hidden state, stale caches, parameter drift, execution order dependence, or non-pinned external helper code, making it impossible for another analyst to reproduce findings confidently.

Core Features & Use Cases

• Required reproducible structure: enforce parameters at the top, a single source of truth for extracts/joins, and dedicated sections for extraction, validation, estimation, robustness, and conclusion.
• Determinism and state hygiene: set seeds for stochastic steps, avoid mutable hidden globals across cells, keep exploratory logic clearly separated, and ensure final outputs rerun without stale state.
• Rerun readiness checks: validate via restart-and-rerun for final/strict claims and use compact, visible progress/status outputs to prevent “frozen” reruns and progress-bar spam.
• Use case: When you must hand off an analytics notebook to another analyst (or to future-you) and need the same numbers, figures, and exported tables after rerunning from a clean kernel.

Quick Start

Ask your AI coding assistant to rewrite your notebook to follow the ds-notebook-reproducibility structure and to ensure a clean kernel restart + full rerun produces the same final outputs.