Build J: full eCPS-exported-column coverage as a HARD release gate + asset-column restoration (SSI reforms score $0)

[MaxGhenis]

The failure (Max's directive: "DO NOT STOP UNTIL WE HAVE THIS! it must be an actual gate!!")

An SSI asset-limit reform ($10k/$20k) scores exactly $0.000B on the newly certified default (Build I) — probe-verified, not inferred — because ssi_countable_resources is 0 for every record: the asset input columns were dropped at the base pool and are absent from the export. This is the #361/#356/#340/#278 family: 94 input columns the sparse national-only release never persists, so the engine silently defaults them and every reform that binds through them scores $0. Build I restored 7 of 94 (IRA/SE-pension intents, hours family, immigration/ssn) — none of the assets. The incumbent July 1 default had the identical hole; certification never blocked on it because export-mass parity (35 weighted-mass columns) is not column coverage.

Deliverable 1 — the HARD GATE (ship first; it must fail today's builds by design)

Extend the #350 mechanism (US_RELEASE_REQUIRED_PERSON_SOURCE_COLUMNS + assert_required_us_release_source_columns, which hard-fails the export before write_dataset) from its current 5 SNAP columns to a declared full coverage contract:

• Required set = every input column the reference eCPS exports (the Sparse national-only release never persists input columns for tips/overtime/auto-loan/education/retirement-contribution/casualty/misc bases (absent-from-H5, engine defaults to 0) #340 inventory: 94 columns incl. assets Sparse-57k certified release drops SSI asset input columns; SSI resource-test reforms score $0 on bundle 4.18.8 #356, tips/overtime/auto-loan/education/retirement-contribution/casualty/misc-itemized/childcare Sparse national-only release never persists input columns for tips/overtime/auto-loan/education/retirement-contribution/casualty/misc bases (absent-from-H5, engine defaults to 0) #340, IRA/HSA Sparse-57k certified release zeroes untargeted input bases (IRA/HSA/SE-pension/childcare); CDCC and ALD reforms silently score ~$0 on bundle 4.18.8 #278), maintained as a versioned manifest in-repo — additions to the engine's input surface extend it (the Assign data-construction inputs added by recent policyengine-us merges (SNAP ABAWD discretionary exemptions, CHIP take-up) #323 assignment flow).
• Gate = presence as an H5 key AND non-degenerate signal (constant-at-default requires a reviewed exclusion with an issue link, same Gate releases on input columns stuck at the engine default #286 "cannot rot" semantics — stale excuses fail the gate).
• Reform-coverage smoke: a pinned set of reform probes that must score nonzero where the policy mechanically binds (first entry: SSI asset limits $10k/$20k — currently +$1.6B on dense-native per the populace#356-era dense runs; also no-limit ≈ +$16.1B). A $0 on a bound reform fails the release.
• No certification without this gate passing. No exceptions list longer than the reviewed-exclusion mechanism allows.

Deliverable 2 — restore the asset columns (the data)

Assets are SCF-imputed in the retired pipeline; port that stage into populace (the #293/#350/#352 port pattern Daphne established), so ssi_countable_resources derives correctly. Then the remaining #340 families (tips/overtime/education/retirement-contributions/casualty/misc-itemized/childcare — childcare's raw CPS signal already sits unused in the file) and #278 leftovers. Base pool rebuild carries them; dense + sparse re-run under the gate.

Sequencing (Build J)

1. Gate PR (fails current artifacts — that is the point; merge with the gate ON).
2. Asset-stage port + base rebuild + probe passes (SSI reform scores plausibly vs the dense-native reference numbers).
3. Remaining families in tranches; each tranche shrinks the reviewed-exclusion list.
4. Re-certify dense + sparse under the full gate; default flip only when the SSI probe (and the rest of the smoke set) is green.

Refs: #340, #356, #361, #278, #350 (mechanism), #286 (cannot-rot semantics), #323, #359 (Build I verdict carrying the caveat), policyengine.py#463 (the flip this gate should have blocked).

[MaxGhenis]

Blocker for the Build J run: #377 — main still carries the takes_up_tanf_if_eligible degenerate-input reviewed exclusion while the take-up stage seeds that column nonconstant, so the default build aborts at the degenerate-input gate (before target materialization) with the same stale-exclusion failure that hit Build I's first sparse attempt on 2026-07-08. The three-line fix exists on build-i-run (055642662ea) but was never ported to main. Land #377 before launching the Build J chain, or every attempt dies after the source stages.

[MaxGhenis]

Build J re-certification run — BLOCKED at the #334 Medicaid take-up gate (fail-closed on a real source hole); asset stage confirmed working en route

Ran the #368 final phase per plan: full gated rebuild on main @ 561c198 (#369 coverage gate + reform smoke, #373 SCF asset stage, #384 TANF fix + preflights, #385 release-native loading, SNAP train #350/#352/#353) — base pool rebuild -> rmloss100 selection carry-over -> sparse release with ALL gates on and no bypass flags. The run stopped exactly where the gate architecture says it must: the first release-scale execution of #334's Medicaid take-up gate failed closed because Rhode Island has no CMS December-2024 enrollment target — a genuine hole at the CMS source, not an ops failure and not a populace defect. STAGING/LOCAL ONLY throughout; nothing touched prod HF or latest.json.

Environment: worktree branch build-j-recert, policyengine-us 1.764.6 / core 3.26.11 (exact Build I match), seed 0, period 2024, v8 facts 94b7155f, export-mass reference c2065b64, SCF donor rscfp2022.dta (zip 3bb4d890 / member 6b8dd2d9, both matching the #373 pinned digests).

What completed and passed

step	result
Base pool rebuild (Build F command, main's builder)	rc=0, sha 0b50660a21e0… — base data identical to Build F/I's 18833fb6 (summary byte-identical except the self-referential sha+path; base_household_weight_total 134,690,323.34024483 exact; builder 0-diff). The sha delta is HDF5 serialization non-determinism, benign.
Selection carry-over (#330 identity join, rmloss100 152baca3)	PASS: n_selected 57,240, n_unmapped 0, n_ambiguous 0 — the release selects exactly the Build I support.
Registry compile (v8 facts)	d71c59514e3a / 5,533 specs — identical to Build H/I, even with #334 in the code (its medicaid_enrollment targets were already among the 5,533; the stage is new, the targets are not). Build I comparison stays like-for-like.
#373 scf_wealth signal gate	PASSED (the run proceeded past its raise-point into Medicaid materialization) — the three SSI countable-resource asset columns (bank_account_assets, stock_assets, bond_assets) materialized with signal on the 57k frame. The #368 asset restoration works at release scale.
#384 register-consistency + take-up preflights, coverage manifest load	Passed (no raise before the Medicaid stage).

The block (verbatim)

RuntimeError: Release gates failed: Medicaid take-up failed: states without CMS
enrollment targets: ['44'] — the feed is incomplete; those states would ship
anchored-only enrollment.

Run populace-us-2024-buildj-sparse-rmloss100-01aed9e-20260710T023838Z, rc=1 at 02:42:52Z, ~4 minutes in, before calibration.

Root cause (full evidence in #386): the CMS PI dataset itself — the pinned ledger artifact — carries RI 202412 = 0, footnoted "Unable to Provide Data due to System Limitations" on both the preliminary and final rows. RI did not report December 2024 and CMS never backfilled it (the April 2026 release still carries the 0). The gap is exactly one state-month (RI 202411 = 273,400; 202501 = 279,404). Ledger package and v8 feed are faithful to the source; the registry correctly compiles no spec from a zero count, so 50 of 51 states have targets and RI does not. The gate is unconditionally hard (no bypass flag exists — correct per this issue's own no-bypass doctrine), has no reviewed-exclusion register, and runs before calibration in both arms, so the dense arm would fail identically (not launched; no wasted compute).

This is the #368 gate philosophy vindicated on its first real outing, from an unexpected direction: a merged-but-never-release-tested stage (#334) refused to ship a silently wrong state (RI would have reverted to anchored-only enrollment, invisibly) and instead stopped the release with a precise, diagnosable message.

Verdict: NOT CERTIFIABLE in this run — blocked, pending a #386 decision (not an artifact-quality failure)

No calibration ran, so there are no Build J loss/within-10%/income-tax/export-mass/SSI-probe numbers to put against the Build I bar (0.030833 / 0.8888 / +0.22% / 0-of-35). The blocker is a one-state data-availability decision that belongs to #334's design owner, deliberately not made here (no synthesized value, no nearest-month splice, no cross-source splice, no invented exclusion). Options are laid out in #386: nearest-reported-month anchor, an issue-linked reviewed-exclusion register for unreported states, or a T-MSIS-sourced same-month value.

Resume is mechanical once #386 is decided: all launchers, the carry-over verifier, and the gate extractor are staged and committed on build-j-recert (experiments/build_j_recert/, runtime mirrors in _buildj-runtime/); if the fix changes facts, the relaunch swaps --ledger-facts to the re-exported feed and records the new registry version — otherwise it is a stage-side change and the same v8 invariants hold.

Cache-key so far: base 0b50660a (data == 18833fb6); pe-us 1.764.6 / core 3.26.11; seed 0; period 2024; feed v8 94b7155f; registry d71c59514e3a (5,533); selection 152baca3 (57,240; join 0 unmapped / 0 ambiguous); zero-support exclusions abb106af (revalidation not reached); export-mass ref c2065b64. Working log PROGRESS_BUILDJ.md on build-j-recert; runtime ~/PolicyEngine/_buildj-runtime/.