Repository navigation
Say what #720 changed in the unmarried-partner gap's reason - #1157
Merged
Merged
Conversation
The reviewed is_unmarried_partner_of_household_head exclusion said only the 2024 input carries A_EXPRRP and that older vintages take the line, spouse, sex and parent relationship fallback. That described Build J, which predates #720. Since #720 the two pooling tools bind each year to its pinned Census person file and _prepare_year_input restores Census A_EXPRRP before the recode, so no pooled vintage reaches the fallback. The reason (and the release manifest entry regenerated from it) and the A_EXPRRP note now say so, scope the Build J facts to that build, and state that the restore leaves out PERRP, PECOHAB and A_FAMREL although the pinned 2022-2024 Census person files carry them. The A_EXPRRP note gives code 13's make-up there: PERRP 44, 47 and 55. PERRP 43 and 46 partners fall in code 12. Wording only: classification, issue and gating are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review nits on #1157: say "Build J" rather than "the hermetic build" (which the repo also uses for the current build), note that a raw-stage checkpoint built before #720 (the US spec's asec_raw_stage pin, set 2026-08-17) keeps the fallback codes, give the closing sentence a clear referent, and attach years to the PERRP 55 counts. Co-Authored-By: Claude Opus 5.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
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.
What this changes
Wording only, in the reviewed
is_unmarried_partner_of_household_headUS parity gap (ecps_parity_known_gaps.json) and the release manifest reason regenerated from it (tools/build_us_release_input_coverage_manifest.py).Two statements described Build J, which predates microcosm #720, as if they were current:
reasonsaid the older-year relationship fallback "never identifies a partner", implying the pool still uses it. Since Pooled ASEC 2022/2023 vintages lack the NOW_* coverage recodes: reported Medicaid at interview thins to 24.6M vs ~58M survey under 65 on the certified artifact #720,tools/build_us_puf_support_base.pyandtools/build_us_asec_pooled_source_base.pybind every pooled year to its pinned Census person file.asec_pool._prepare_year_inputthen restores CensusA_EXPRRPbefore_with_relationship_recode, so no vintage those tools pool reaches the fallback. Build J'sbase_j.summary.json(2026-07-10) recordsderived:line_spouse_parentfor 2022 and 2023, so the old sentence was true of that build. The new text keeps that history and says what current code does.semantic_non_substitutes.A_EXPRRPsaid "Only the 2024 locked input carries it". That is now scoped to Build J's three HDF inputs. The note adds that the pinned income-year 2025 input carries it, and that since Pooled ASEC 2022/2023 vintages lack the NOW_* coverage recodes: reported Medicaid at interview thins to 24.6M vs ~58M survey under 65 on the certified artifact #720 every pooled vintage carries the Census recode.The reason now also states a fact it previously left unsaid. The #720 restore (
ASEC_CENSUS_PERSON_COLUMNS) excludesPERRP,PECOHABandA_FAMREL, although the pinned 2022-2024 Census person files carry all three. TheA_EXPRRPnote now gives code 13's make-up in those files: PERRP 44 and 47 (unmarried partners without relatives) plus PERRP 55 (housemates or roommates without relatives). PERRP 43 and 46 partners fall in code 12.Not changed: classification (
source_unavailability), issue (#38), gating, and every other evidence field. Whether this exclusion should stay as classified is a methodology call queued for Max (decision d1099, memo in the evidence folder). This PR does not prejudge it.Relation to #1146
#1146 (
spec-symbol-citations-us-uk, open) rewrites this entry'sderived_A_EXPRRPandhermetic_build_contract, which on main still cite driftedasec_pool.pyline ranges and say the pool reads the H5 tables "without refreshing omitted Census columns". This PR leaves those two fields to #1146. The two branches touch different lines andgit merge-treemerges them cleanly at #1146 head0a841e448. Once both land, the entry is consistent. The new text uses only commit-pinned line citations and dottedmicrocosm.*names that resolve, so #1146's citation guard accepts it (checked with itsline_citationsandDOTTED_MICROCOSM_SYMBOLon this branch).Review
The independent review (Subfleet
20261008-175311-review-1157, Opus) approved head0d8d0a56a. It recomputed every figure from SHA-verified files and found no factual errors. It raised seven nits.Commit
7f50ba142applies five of them:It also adds the sixth nit's point. A raw-stage checkpoint built before #720 keeps the fallback codes. The US spec's
asec_raw_stagepin is one such checkpoint: it has been pinned since 2026-08-17 (f85c248), and #720 landed on 2026-09-23.Deferred: the
PECOHABsibling note still says "Only the 2024 locked input". That is true of Build J, but the pinned 2025 input also carriesPECOHAB. Editing that line conflicts with #1146's rewrite of the adjacentderived_A_EXPRRPline, so it waits until #1146 merges, or until d1099 rewrites the entry.Disk on the build machine was under 40 GB when the nits went in, so pytest was not re-run for
7f50ba142. The same assertions were checked directly instead:required_person_columns,hermetic_inputsand therejectionprefix;load_release_input_coverage_manifest;A delta re-review is running against
7f50ba142.Evidence (computed 2026-10-08, members checked against their pins)
A_EXPRRP == 13pppub23.csv,19b56537…)pppub24.csv,21a2b9e0…)pppub25.csv,06921fe8…)Counts are unweighted person records. Census labels come from
api.census.gov/data/2024/cps/asec/mar/variables/{PERRP,A_EXPRRP}.json: PERRP 55 is "Housemate/Roommate without Relatives" and A_EXPRRP 12 is "Nonrel w/own rels in hhld". The 2025 H5 (4c5a3218…) carriesA_EXPRRP(3,816 code-13 records),PECOHABandA_FAMREL, but notPERRP. Its Census memberpppub26.csvwas not on disk and was not checked. The reproduction script and its output are in~/reviews/microcosm-unmarried-partner-gap-2026-10-08/.Checks
test_us_relationship_inputs.py(4 passed, 0 skipped). The 2022-2024 locked H5s are mounted locally, sotest_locked_artifacts_confirm_source_presence_and_absenceran rather than skipping.test_unmarried_partner_exclusion_is_source_unavailabilityasserts the manifest reason equals the gap reason.engine_free/shared/test_release_input_coverage.py,engine_contract/us/test_release_input_coverage.py,test_us_parity_reference.py,test_us_register_consistency.py,test_us_asec_sources.py,test_country_spec.py,microcosm-data test_contract.py: 579 passed in total with the relationship file, 0 skipped, 0 failed.uv run python tools/build_us_release_input_coverage_manifest.py. Its diff is the one reason line.Invariant (test-enforced, unchanged): the manifest's
reviewed_exclusionsreason equals the gap register's reason byte for byte.🤖 Generated with Claude Code