Fail the eCPS parity gate on stale exemptions; remove four rotted entries#337
Open
daphnehanse11 wants to merge 1 commit into
Open
Fail the eCPS parity gate on stale exemptions; remove four rotted entries#337daphnehanse11 wants to merge 1 commit into
daphnehanse11 wants to merge 1 commit into
Conversation
…ries parity_gate skipped known-gap names unconditionally, unlike its sibling gates (default_valued_columns_gate at gates.py:707 and source_stage_input_coverage_gate at gates.py:1499), which both fail on stale reviewed exclusions. That let register entries rot silently once the candidate started producing the exempted layer (the takes_up_medicaid_if_eligible case surfaced in PR #334). The gate now fails on any exemption whose candidate nonzero share is positive, reports exemptions the reference never populates as dormant, and records both in the gate details. Auditing the register against the current release pipeline found four entries stale on arrival — the pipeline deterministically materializes them before the gate runs: takes_up_tanf_if_eligible and takes_up_eitc (contract-seeded take-up, PR #315), ssn_card_type and immigration_status_str (immigration stage, #266). A new register test pins that statically-knowable subset so a stale entry is caught at test time, not first at release-build time. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
parity_gateskipped names in the known-gaps exemption register (ecps_parity_known_gaps.json) unconditionally, with no staleness check — unlike its two sibling gates, which both fail on stale reviewed exclusions (default_valued_columns_gateat gates.py:707,source_stage_input_coverage_gateat gates.py:1499). That let register entries rot silently once the candidate started producing the exempted layer, which is exactly what happened totakes_up_medicaid_if_eligiblewhen PR #334 started materializing the column.Gate change
parity_gatenow fails on any stale exemption — aknown_gapsname whose candidate nonzero share is positive — with a message to remove or re-reason it.stale_exemptionsanddormant_exemptions, flowing into the release manifest through_ecps_parity_gateunchanged.Register audit: four entries removed
Checked every exemption against the current release pipeline. The parity gate runs on the base frame after
with_us_immigration_inputsandwith_us_take_up_inputs(build_us_fiscal_refresh_release.py), and the upstream immigration and take-up gates hard-fail unless these columns are present and non-constant — so four exempted layers are deterministically populated at parity-gate time (all four confirmed inPolicyEngineUSEngine().variables(), so they are measured):takes_up_tanf_if_eligibletakes_up_eitcssn_card_typeimmigration_status_strThe register was seeded (#316) from a parity run of an artifact predating that wiring, so these were stale on arrival. The remaining entries are safe: the other source stages declaring exempted outputs (SCF wealth, ORG wages, SIPP tips, …) are manifest declarations no tool currently executes.
Interaction with #334
#334 deletes the
takes_up_medicaid_if_eligibleexemption from the same register when it materializes Medicaid take-up. The hunks are disjoint, so the two PRs merge cleanly in either order, and they compose consistently: on this branch the candidate does not yet produce that column (treatmentrate_unsourced), so the entry stays; once #334 lands, its own deletion is exactly what the new enforcement would demand. The medicaid case is the motivating example for this change. Closes the follow-up from the #334 review.Tests
TestParityGatecases: stale fails and names the variable; stale fails even when the reference lacks the layer; dormant passes but is reported; a stale exemption does not mask real gaps; clean-exemption details stay empty.test_us_parity_reference.pyasserting no register entry names an immigration output or contract-seeded take-up flag, catching stale-on-arrival entries at test time rather than first at release-build time.test_gates.py,test_us_parity_reference.py, andtest_us_nonzero_shares.pypass (141 tests); ruff check/format clean.Note: the runtime enforcement means the next release build fails if any exemption not statically verifiable here turns out to be populated on the real base H5 — that failure names exactly which entry to remove or re-reason, which is the intended behavior.
🤖 Generated with Claude Code