Consolidate the populace reform-validation registry into the scorecard (retiring cal-diag's External checks tab)

Proposal (David + agreed direction: one home for external comparisons)

calibration-diagnostics grew a parallel mini-scorecard before this repo existed: the External checks tab (/populace/reforms) compares each certified populace release against the reform-validation registry — state fiscal notes (KS/CT/ID/CO/GA/IA/MD/MI/ND/OK/CA, curated in populace #513/#519), the OBBBA JCX-35-25 suite, ARPA/CBO approximations, JCT/Treasury tax expenditures, IRS SOI + EITC Central actuals, Census state SPM rates, and a mechanical UBI check — recomputed at each release's exact engine pins.

That is mode 2 of this repo's design ("a level is a score of the null reform"), so we're removing it from cal-diag and ingesting it here. Draft PR incoming with the adapter + the five historical release artifacts (f0af251 → Build O), which adds a dimension the current populations don't have: per-release regression history in pe_results (same claim, one result per certified release, engine-exact).

Plan

1. This repo: scorecard_db/ingest_reform_validation.py + sources/populace-reform-validation/ (draft PR). 222 claims / 530 results; first rows on the reserved TAX_EXPENDITURE metric; jct.tax_expenditures.* rows marked consumed_as_target (they are labeled calibration targets in the artifact), Census SPM held_out per the poverty doctrine.
2. calibration-diagnostics: remove the reforms page, overrides, 6-hourly workflow, and tools/reform_validation/ once (1) lands; leave a pointer to the scorecard. cal-diag #112 (Modal-backed backfill, reviewed by @PavelMakarchuk) stays open in the meantime — its Modal app + liveness logic is the natural per-release pe_results producer to re-home here.
3. populace: registry + producer stay put (release-exact, engine-adjacent). Follow-up issue there proposes the payload embed each row's executable reform dict + publisher slug, upgrading claim keys from policy_ref descriptors to framework="policyengine_us".

Open design questions for @MaxGhenis

• JCX-35-25 collision: the 2026-08-02 harvest already carries claims for the same JCX-35-25 chapter lines our OBBBA suite scores. In the draft they key off different reform descriptors ({"policy": "obbba_reduced_rates"} vs the harvest's slugs), so they coexist as duplicates. Should the registry's OBBBA rows resolve to harvest claims (ingest_platform-style byte-exact probe) and contribute only pe_results, or stay a separate source until reform descriptors unify?
• Publisher slugs: state rows currently derive {st}_fiscal_note / {st}_admin slugs; happy to align with whatever vocabulary you want (ca_lao-style per-office slugs need per-row curation the artifact doesn't carry yet).
• State agency actuals ({st}_admin BENEFIT_COST rows) default to held_out — worth verifying none are on the certified target surface before publishing them as validation wins.
• Automation: once cal-diag's workflow dies, does the spawn-or-harvest scheduled job (Modal 64GB, release-manifest engine pins, artifact → ingest → commit) live here? That's the #112 machinery, review already done.

🤖 Generated with Claude Code

Start with ingest_reform_validation.py and sources/populace-reform-validation/; review the draft adapter and five historical release artifacts, including the 222 claims and 530 results. Completion requires resolving the JCX-35-25, publisher-slug, held-out, and automation questions, then coordinating cal-diag retirement and scorecard ingestion.