Measure household_weight from typed frame weights in the parity universe#428
Merged
Conversation
Build M's sparse run failed the eCPS parity gate on household_weight: the reference (a finished export) carries the calibrated weight column at 22.6% nonzero share, while the candidate keeps weights as typed pipeline state and us_nonzero_shares read the deliberately absent table column as an all-zero layer. The coverage gate already mirrors the H5 adapter (which materializes the typed vector as household_weight on write); the parity share computation now applies the same mirror, so both gates and the export tell one story. A table column still wins when present. The check entered the parity reference with #399's 158-column expansion — Build J's 65-entry reference predates it, so this was another first-full-scale exercise. Fixes #427. 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.
Build M sparse attempt 4 cleared the entire take-up battery, then failed the eCPS parity gate:
household_weight: reference populates 22.6% of records, candidate is all-zero.Not a data defect — an asymmetry between two gates. Frame weights are typed pipeline state, not a table column; the H5 export adapter materializes them as
household_weighton write, and the input-coverage gate explicitly mirrors that (release_input_coverage.py: "Mirror that export behavior here so the gate covers what is persisted"). The parity share computation (us_nonzero_shares) never got the same mirror, so it read the deliberately absent column as an all-zero layer — while the retired reference, being a finished export, carries it populated. The entry came in with #399's 158-column expansion; Build J's 65-entry reference predates it.Fix: apply the identical mirror in
us_nonzero_shares(typed household weights measured as thehousehold_weightlayer; a real table column still wins when present). The coreparity_gateis binary (reference-populated ⇒ candidate-nonzero), so no reference or exemption-register change is needed — an exemption was in fact rejected by the sync guard, correctly: restored inputs can't be fenced, they have to be measured right.Verification: mirror test fails pre-fix and passes post-fix; table-column-precedence test; nonzero-shares + parity-reference + input-coverage suites all green; CI-ruff and format clean.
Fixes #427.
🤖 Generated with Claude Code