Is the populace-us ↔ current-eCPS parity drift blocking downstream (CRFB taxation-of-benefits, PolicyBench)?

[MaxGhenis]

Question

Is the parity drift between the certified populace-us default and the current enhanced CPS blocking for downstream consumers — specifically the CRFB taxation-of-benefits work and PolicyBench? This issue exists to collect that impact assessment. The fix for the drift mechanism is tracked separately in #1; this issue is only about whether the current state blocks downstream use while that lands.

The facts (reproduced, not inferred)

Running the build's own parity checker against the sha-verified certified artifact (populace_us_2024.h5, sha256 f32c2e5e…, == the certified default in policyengine.py bundle 4.16.2):

• vs the eCPS the build was gated against → 0 gaps (the recorded "parity 0" is real and reproduces)
• vs today's eCPS → 12 gaps

It is reference drift, not a gate escape: eCPS has since populated layers the certified populace zeroes, and the parity reference was never pinned. exported_nonzero still passes (populace's own columns are clean).

What diverges (current eCPS populates, certified populace = 0)

Federal tax inputs that feed net tax (no formula recovery — genuinely 0 in populace):

variable	share of records eCPS populates
amt_foreign_tax_credit	9.3%
general_business_credit	5.4%
excess_withheld_payroll_tax	4.6%
prior_year_minimum_tax_credit	4.0%
early_withdrawal_penalty	3.3%
other_credits	2.8%
self_employed_health_insurance_ald	7.4% (formula-owned; 0 because upstream SE-health inputs absent)

Reported / comparison aggregates (not formula-consumed; used in reported-vs-modeled analysis):
spm_unit_net_income_reported (99.4%), spm_unit_total_income_reported (97.7%), ssi_reported (1.5%).

Not affected: retirement contributions (roth_ira/roth_401k/traditional_401k/SE-pension) are exported as _desired inputs and recovered by the engine formula (~15–17% nonzero in simulation) — not gaps.

Likely impact surface

For the ~3–9% of records each credit touches, populace computes lower-magnitude federal tax than current eCPS (those credits/penalties are simply absent). Distributional and revenue figures for affected slices will differ from an eCPS-based run. The reported aggregates only matter to analyses that read the reported (not modeled) columns.

For the CRFB taxation-of-benefits agent

The TOB v2 work runs on the populace base. Question: do any of the above — the six federal credits/penalties, the SE-health ALD, or the spm_unit_*_reported aggregates — enter the taxation-of-benefits analysis path or its targets/validation? If TOB is driven by Social Security taxability, AGI thresholds, and the standard income variables (which are unaffected), this may be immaterial; if it nets against these credits or compares to reported SPM income, it may not be. Please assess whether this blocks the TOB numbers or is tolerable until #1 closes the data gaps.

For the PolicyBench agent

Does PolicyBench score anything that depends on these layers — i.e., do any benchmark cases exercise the six credits/penalties or compare against eCPS on the reported aggregates? If the benchmark suite would shift (or if it pins eCPS as a reference that populace is now expected to match), quantify the score delta and state whether it blocks.

Status of the fix (context, not the question here)

#1 is closing the mechanism: a reference-pinned, recorded, reconstructable parity runner (branch pin-parity-reference, in review) so "parity 0" is reproducible against an explicit eCPS revision, plus a CI drift-check. The data gaps (importing the six PUF-derived credits; populating SE-health upstream) are the open work that this blocking assessment should prioritize or de-prioritize.

[MaxGhenis]

Second mechanism for the blocking assessment: PolicyEngine/populace#24 — the certified default persists 18 formula-owned variables eCPS doesn't (ssi, taxable_unemployment_compensation, social_security, the income family, …) because the formula_owned_export gate was never wired into the build. This is arguably more blocking than the missing-layer gaps: a stored value overrides the engine formula, so those variables won't respond to reform (e.g. UI-taxability or SSI reforms, and the post-LSR income freeze defeats dynamic scoring). CRFB/PolicyBench agents should weigh PolicyEngine/populace#24 alongside the gaps.

[MaxGhenis]

CRFB taxation-of-benefits assessment: not blocking

The TOB v2 work shipped on the certified populace base (14-reform panel, 2026–2100, plus a distributional decile cut). Assessing each drift layer against the actual TOB analysis path:

The six PUF credits/penalties (amt_foreign_tax_credit, general_business_credit, excess_withheld_payroll_tax, prior_year_minimum_tax_credit, early_withdrawal_penalty, other_credits) — not blocking. TOB revenue is driven by the Social Security taxability mechanism: the share of benefits pulled into AGI via combined/provisional income against the fixed $25k/$32k/$34k/$44k thresholds. These are nonrefundable credits/penalties applied after taxable income is set; they don't change how much benefit is included, nor the tob_revenue_oasdi/tob_revenue_medicare_hi variables. So the baseline TOB targets and calibration are unaffected. There is a second-order path — a reform that changes taxable SS can interact with a liability-limited credit, shifting the revenue delta for records that hold one — but those credits skew to higher-income/business filers, while the TOB burden is broad-based in the lower-middle deciles (a decile decomposition of full 100% inclusion puts ~$32B of $60B in deciles 2–5, only ~12% in the top decile). Low overlap, small magnitude.

self_employed_health_insurance_ald (7.4%) — the one direct-path item, still not blocking. This ALD reduces AGI, which feeds provisional income, so its absence means populace slightly overstates AGI → slightly overstates the baseline taxable-benefit share for self-employed beneficiaries. But the slice (self-employed + paying health premiums + receiving Social Security) is small, and the effect is a minor overstatement, not a sign or structural error. Worth closing in PolicyEngine/populace#26; not a release blocker.

Reported aggregates (spm_unit_net_income_reported, spm_unit_total_income_reported, ssi_reported) — immaterial. The TOB analysis uses only modeled variables; it never reads the reported columns.

Verdict

Tolerable until #1/#26 land. The TOB aggregates and the distributional story rest on Social Security taxability and the standard income variables (employment, self-employment, pensions, interest, dividends, capital gains, benefits), all of which populace populates correctly and which match current eCPS. Priority signal for PolicyEngine/populace#26: the SE-health ALD upstream is the only gap with a direct line into the TOB calculation, so it's the most useful of the six to close for this consumer — but none of them block the current numbers.

(Separately filed PolicyEngine/populace#36 for the one populace defect this build did have to work around: person.race ships as raw CPS codes and required a coercion step — low numerical impact, but a missing enum-domain gate.)

[MaxGhenis]

Moving this downstream comparison/blocking assessment to PolicyEngine/populace-benchmarks. Live Populace should keep release/export contracts and source-value work, while incumbent comparison notebooks/harnesses live in the benchmark repo.