Dataset imputes 100% of the population as citizens with valid SSNs (breaks SSN/citizenship-conditioned policies, e.g. OBBBA CTC)

[PavelMakarchuk]

Summary

The published US dataset imputes every person as a citizen with a valid SSN. There are no non-citizens, no ITIN/non-SSN filers, and no immigrant population in the data. This makes any reform or program with an SSN / citizenship / immigration-status eligibility condition impossible to evaluate correctly.

Evidence

On the released populace_us_2024.h5 (release populace-us-2024-f0af251-…-20260620), reading the person table:

variable	value	weighted
has_valid_ssn	True	336.7M (100%)
has_valid_ssn	False	0.00M
ssn_card_type	CITIZEN	336.7M (100%)
immigration_status_str	CITIZEN	336.7M (100%)
taxpayer_id_type	VALID_SSN	336.7M (100%)

For reference, the US has roughly 22M non-citizens and ~11M unauthorized immigrants, many of whom file with ITINs / lack work-eligible SSNs. None of that population exists in the dataset.

How it surfaced

Found via the OBBBA reform validation (calibration-diagnostics reform page). OBBBA tightened the CTC SSN requirement, which raises revenue by excluding non-SSN claimants. In PolicyEngine's official OBBBA model (obbba-household-explorer) that "CTC SSN" piece is +$3.3B. In populace, with 100% valid SSNs, the requirement excludes nobody → ≈$0, so populace's CTC reform estimate runs ~$3–4B more negative than PE's official model (populace −85.6B vs explorer −77.6B; JCT line 4 −48.8B).

The CTC case is just the visible symptom — the same imputation gap affects anything SSN/citizenship-conditioned.

Impact (not exhaustive)

• CTC SSN requirement (TCJA child-SSN + OBBBA filer-SSN) — no-op
• EITC SSN requirement — no-op
• ACA / Medicaid / SNAP / SSI immigration-status eligibility — everyone treated as eligible on that axis
• ITIN filers — none represented

Suggested fix

Impute SSN / citizenship / immigration status rather than defaulting everyone to citizen+SSN. The CPS source carries citizenship/nativity (e.g. PRCITSHP), and the non-citizen / unauthorized / ITIN-filing populations have published control totals to calibrate against. At minimum, has_valid_ssn / taxpayer_id_type / immigration_status_str should reflect a realistic non-SSN share so SSN-conditioned reforms can be evaluated.

Filed from reform-validation analysis in PolicyEngine/calibration-diagnostics.

[MaxGhenis]

Confirmed still present on the latest release populace-us-2024-sparse-l0-refit-57k-71a0887-national-only-20260701 (2026-07-01): the artifact stores no immigration/SSN/ITIN columns at all (checked the person table of the release H5 directly), so engine defaults apply — 100% citizens with valid SSNs by omission rather than by imputation.

Implementation note: policyengine-us 1.752.2 no longer exposes has_valid_ssn; verify via the stored columns or the current identification inputs (e.g. has_itin and the immigration-status inputs) rather than that variable name.

Fix shape: a citizenship/SSN imputation stage (CPS ASEC carries citizenship inputs; residual-status modeling has established methods) plus a demographic-composition gate (share non-citizen / ITIN filers vs Census/DHS benchmarks) so this class of gap blocks release rather than surfacing downstream in reform validation.

[MaxGhenis]

Fix is up in #266: a new immigration_status source stage derives ssn_card_type and immigration_status_str from the ASEC citizenship inputs (PRCITSHP + entry year + nativity + program-participation flags via the ASEC-UA residual method), with the EAD split targeted to cited Pew/Presidents' Alliance controls and a release-blocking immigration_composition gate so the all-citizen failure mode can't ship again (the gate also enforces non-constant columns, enum domains, and a plausibility band on the emergent undocumented total).

On the full 2024 ASEC the stage produces 299.4M CITIZEN / 13.3M NONE / 4.7M NON_CITIZEN_VALID_EAD / 8.6M OTHER_NON_CITIZEN — so the OBBBA CTC SSN piece and the EITC/ACA/Medicaid/SNAP/SSI immigration axes get a real population to bite on. The undocumented total is emergent rather than forced; reconciling its level against a published estimate belongs in the calibration lane (follow-up: a Ledger fact with an SE).

The published artifact predates the stage, so this lands in the next release: the fiscal-refresh driver now derives the columns idempotently from any base H5 that still carries the raw ASEC columns (current ones all do) and refuses to publish without them.