You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
8 migrated datasets still hold audit_annotations.yml entries, and nothing enforces the manifest-or-annotation rule
scripts/audit_annotations.yml's own header rule says migrated datasets (those with lectures/*.yml manifests) do not get entries in datasets: — the manifest is their source of truth. Independent validation for #84 (Phase 1) cross-checked the invariant and found it violated by 8 datasets, all status: repointed in migration.yml and all carrying manifests:
The hansen_singleton pair from wave B2′ was retired correctly — this debt is from earlier waves, surfaced by the #84 cross-check.
Why it rots silently: build_audit.py uses an annotation only as a fallback (manifest or annotation) when building descriptions/provenance, so the stale entries are inert at runtime, and no check — including --strict — flags a dataset that has both. A green strict audit therefore says nothing about this invariant.
Two-part fix:
Delete the 8 stale datasets: entries (their manifests already carry the information; a quick diff of each entry against its manifest before deletion would catch anything the annotation has that the manifest lost).
Add the invariant to build_audit.py --strict: any filename appearing both as a lectures/*.yml manifest and as an audit_annotations.ymldatasets: entry is an inconsistency. That makes the header rule enforceable instead of aspirational — the same reasoning as the migration.yml flip test in VALIDATION: independent review of the 2026-08-13 Track B migration work (waves B1' and B2') #84 §5: a rule that cannot go red is not evidence when green.
Two harmless near-misses noted for completeness, requiring no action: NEWQDATA.csv is mentioned inside an api: note and fig_3.xlsx inside a committed_unreferenced note — prose mentions, not datasets: entries.
8 migrated datasets still hold audit_annotations.yml entries, and nothing enforces the manifest-or-annotation rule
scripts/audit_annotations.yml's own header rule says migrated datasets (those withlectures/*.ymlmanifests) do not get entries indatasets:— the manifest is their source of truth. Independent validation for #84 (Phase 1) cross-checked the invariant and found it violated by 8 datasets, allstatus: repointedin migration.yml and all carrying manifests:assignat.xlsx·caron.npy·chapter_3.xlsx·dette.xlsx·fig_3.xlsx·longprices.xls·mpd2020.xlsx·nom_balances.npyThe hansen_singleton pair from wave B2′ was retired correctly — this debt is from earlier waves, surfaced by the #84 cross-check.
Why it rots silently:
build_audit.pyuses an annotation only as a fallback (manifest or annotation) when building descriptions/provenance, so the stale entries are inert at runtime, and no check — including--strict— flags a dataset that has both. A green strict audit therefore says nothing about this invariant.Two-part fix:
datasets:entries (their manifests already carry the information; a quick diff of each entry against its manifest before deletion would catch anything the annotation has that the manifest lost).build_audit.py --strict: any filename appearing both as alectures/*.ymlmanifest and as anaudit_annotations.ymldatasets:entry is an inconsistency. That makes the header rule enforceable instead of aspirational — the same reasoning as the migration.yml flip test in VALIDATION: independent review of the 2026-08-13 Track B migration work (waves B1' and B2') #84 §5: a rule that cannot go red is not evidence when green.Two harmless near-misses noted for completeness, requiring no action:
NEWQDATA.csvis mentioned inside anapi:note andfig_3.xlsxinside acommitted_unreferencednote — prose mentions, notdatasets:entries.