Notebook-fidelity date-volatility fix

2026-05-30 · nstat/notebook_fidelity_audit.py, parity/notebook_fidelity.yml · branch fix/notebook-fidelity-date-volatility

The problem

The notebook-fidelity audit generator embedded generated_on: str(date.today()) in parity/notebook_fidelity.yml, so the file's text content changed every calendar day — even when the underlying audit data was unchanged. Two consequences:

Spurious git diff any time anyone ran make regen-notebook-fidelity, polluting commits.
Recurring CI/test failure on machines with the MATLAB reference checkout: test_notebook_fidelity_audit_matches_generator_when_matlab_repo_is_available compares the committed YAML against a fresh regenerator output via string equality; the dates inevitably diverged.

The fix

Drop the field entirely from the generator and from the committed YAML. The field had no consumer (verified by repo-wide grep); git log is the authoritative "when was this last touched."

The other parity YAMLs (manifest.yml, class_fidelity.yml, simulink_fidelity.yml) keep their generated_on fields — those are stable hand-set audit dates, semantically different from a wall-clock regen stamp.

- "generated_on": str(date.today()),
+ # No generated_on — embedding wall-clock dates caused daily drift.

Verification

Check	Result
`test_notebook_fidelity_audit_matches_generator_when_matlab_repo_is_available`	PASS (was failing)
All 8 tests in `test_notebook_fidelity_audit.py`	PASS
`make regen-notebook-fidelity` idempotence	stable output (no daily churn)
`make test` failure count	6 → 5 (only this one resolved; remaining 5 are pre-existing scipy `_lazywhere` in statsmodels/nemos)

Files changed

nstat/notebook_fidelity_audit.py — drop the generated_on line and the now-unused from datetime import date.
parity/notebook_fidelity.yml — drop the corresponding generated_on: '2026-05-26' line.