[MaxGhenis]

Problem

For a Manhattan parent earning $30,000 with a child in full-time care at $14,000 a year, ny_ccap pays $13,916.40. On main at 469ad12cb9 (2.90.2), turning that subsidy on raises household_net_income by $8,321.86 and lowers spm_unit_net_income by $5,594.54.

On main, SPM resources count only the Colorado, Washington and West Virginia subsidies, and the SPM deduction uses pre-subsidy expenses. So in the other 48 states a subsidy cuts SNAP and tax credits, and nothing in the SPM offsets the cut.

Fix

Census subtracts what parents paid for child care (SPM technical documentation, PDF page 17), and its list of noncash benefits (section 4.3.1) has no child care benefit. So from 2024 the model counts a subsidy in the SPM once, as a lower expense.

In a household calculation, the user enters the price of care before any subsidy as spm_unit_pre_subsidy_childcare_expenses, while both dataset builds fill that input with what parents reported spending. So spm_unit_capped_work_childcare_expenses has two rules. In them, W stands for work expenses, C for the earnings cap, E for the input, S1 for the subsidy the simulated policy pays and S0 for the subsidy baseline policy pays.

Where	What E holds	Expense
Household calculation	The price of care before any subsidy	min(W + max(E - S1, 0), C)
Over a dataset	What parents reported spending, which the rule reads as after any subsidy	min(W + max(E - (S1 - S0), 0), C)

Over a dataset, the model grosses the reported amount up by the baseline subsidy at run time and then nets the simulated subsidy from the result. Under baseline policy the formula reads no subsidy and keeps min(W + E, C), the amount Census subtracts. simulation.is_over_dataset picks the rule, and simulation.baseline supplies S0, as it does for medicaid_slcsp_state_denominator.

• In a household calculation, the formula reads childcare_expenses, the model's out-of-pocket variable, for a unit with a child. That variable allocates expenses to children, so for a unit with no child the formula nets child_care_subsidies from the unit's own input.
• From 2024, this PR drops co_ccap_subsidy, wa_child_care_subsidies and wv_child_care_subsidies from spm_unit_benefits and from the four reform copies of that list. The expense has no formula before 2024, so SPM resources keep those subsidies in those years wherever main counts them, and every year before 2024 matches main. The Tlaib copies hold only Colorado's. A YAML case in each reform's file pins 2023 and 2024.
• From 2024, the child_care_subsidies list holds all 51 state programs. The DC, Tennessee and Texas programs pay in 2024, but main's list leaves them out until 2025. Adding them lowers childcare_expenses for those three states in 2024. Its readers see the lower amount that year: the SNAP dependent care deduction, HUD adjusted income, dependent-care credits, and the DC, Tennessee and Texas TANF deductions. Over Populace 2024 the three programs pay nothing, so the default file's 2024 results don't move.

The Manhattan family's expense falls from $14,000 to $83.60, its SPM net income rises by $8,321.86, as its household net income does, and it leaves SPM poverty.

Over a dataset, a unit reporting $14,000 keeps a $14,000 expense under baseline policy. Repealing New York's subsidy raises that expense to $27,916.40 and lowers SPM net income by the same $8,321.86. test_repeal_moves_dataset_and_household_income_by_the_same_amount pins this in New York and Texas.

Adding subsidies to resources instead would depart from the Census definition and fail in two places. It would add income at the earnings cap, where the expense doesn't fall. It would also overcount wherever a program pays more than the family spends. Vermont pays its state rate regardless of the provider's charge, and in the audit it paid $22,828 against a $1,200 bill.

Why the dataset needs its own rule

Both dataset builds fill the input from the ASEC's reported spending, SPM_CHILDCAREXPNS: Populace in microcosm/build/us_runtime/childcare.py and policyengine-us-data in datasets/cps/cps.py. The ASEC asks parents how much they spent on child care, and Census subtracts that amount as it stands. This rule reads the amount as what parents paid after any subsidy, so netting a modeled subsidy from it would count the subsidy twice. Over the default file in 2026, netting cut the SPM expense by $1.135B at 606699d640, and by $7.280B with schedules set at 640753a617. So the builds keep the reported amount, and the model moves it only by the change in subsidy a reform makes.

The baseline arm

The dataset rule reads S0 from the reform's baseline arm. Core builds that arm inside its __init__. Simulation.__init__ and Microsimulation.__init__ then move employment_income, self_employment_income, sstb_self_employment_income, weekly_hours_worked and long_term_capital_gains to their pre-response variables, and fill state_code from state_code_str. At d4d391788d, the arm kept the raw inputs and read 0 from the pre-response variables. In a household situation it paid the Manhattan family $3,498 in New York TANF and no child care subsidy, where a plain run paid no TANF and a $13,916.40 subsidy. Over a dataset that stores raw hours, as policyengine-us-data's CPS build does (cps.py:481), the dataset rule would have carried that gap into the SPM.

#9698, which this branch merges from main, branches the arm again after the moves (_rebuild_baseline_branch). That rebuild bound the copied holders to baseline variables but kept each holder the reform had built in another entity or with other ETERNITY storage. The SPM mixin's constructor, subsample and _baseline_measurement_branch all drop such holders. Under a reform that stores child_care_subsidies for all time, the arm read a New York family's $500 input as S0, where baseline policy pays the family $13,916.40. The family's reform expense came out $14,000.00, where the rule gives $27,416.40. This PR makes the rebuild drop those holders too. When a reform stores a dataset input in another entity or with other ETERNITY storage, the arm now goes without that input and computes the variable under baseline policy, as core's arm does.

This PR also adds tests/core/test_reform_baseline_arm_inputs.py, which pins the rebuilt arm on the dataset path this rule reads, and updates the docstring of _baseline_measurement_branch, which still said the arm keeps the raw inputs.

Invariants

I test these with Hypothesis in policyengine_us/tests/test_spm_child_care_subsidy_invariants.py.

For a household calculation:

1. The model's expense equals the formula above, written from the documentation rather than from the code.
2. 0 <= expense(0) - expense(S) <= S, and a larger subsidy never raises the expense.
3. With taxes and other benefits fixed, a subsidy leaves spm_unit_benefits unchanged and raises spm_unit_net_income by the fall in the expense, so the SPM counts it once.
4. With a subsidy of zero, the expense matches main's formula in every state.
5. From 2024, no *_child_care_subsidies variable, and no program one of them adds, appears in spm_unit_benefits or a reform's copy of it, and all 51 appear in every program block.
6. A differential test turns real programs on and off. The expense falls by the amount the test's reference gives. The change in SPM net income equals the change in household net income, less the subsidy the household measure counts, plus the fall in the expense.

Over a dataset:

7. Baseline policy leaves the expense at min(W + E, C), whatever subsidy the model pays, in a plain simulation and in a reform's baseline arm.
8. Under any policy the expense follows the dataset rule, at the floor and the cap and with or without a child in the unit, with W and C from the policy simulated. A policy that pays the same subsidy and keeps W and C leaves the expense where baseline policy put it.
9. A second differential gives a dataset the amount the household rule says a unit pays at baseline policy, and the two rules then give the same expense under any policy. With real programs and $14,000 as both rules' input, repealing the subsidy moves SPM net income by the same amount under both wherever neither cap binds. The parent's earnings and hours enter as raw inputs, so this case runs the arm rebuild too.

In tests/microsimulation/test_spm_child_care_reported_expense.py, Microsimulation loads the shipped population, so the dataset flag and the baseline arm come from the path a user's run takes. One test checks property 7 on every record of the default dataset. The other runs a real reform on a 500-household slice that holds units with both a modeled subsidy and reported spending. It checks that the baseline arm matches a plain run and that the reform arm follows the rule.

tests/core/test_reform_baseline_arm_inputs.py checks the arm itself. Under a reform that changes nothing, the reform and its baseline arm compute what a simulation with no reform computes, on four pre-response variables and seven outputs from the subsidy to household net income. It runs a dataset of raw columns with two families in every state, and a situation that names New York only through state_code_str. It also checks that the arm owns its policy and holds no value the reform's policy produced, and that every holder in either arm suits that arm's definition of its variable. A third test runs the reform that stores child_care_subsidies for all time: the arm pays what a plain run pays, and the reform's expense follows the dataset rule. test_subsampling_never_changes_which_policy_a_holder_belongs_to in tests/core/test_spm_system.py now checks every holder before it subsamples as well.

The five new invariant cases and the slice test all fail against the formula that nets the subsidy from a reported payment (513aa0bb66). With _rebuild_baseline_branch disabled, all three arm tests and the New York repeal case fail, and a no-change reform gets the expense wrong for 32 of the arm test's 102 households, by up to $13,916.40. With only the rebuild's drop removed, the all-time test and the subsampling test fail.

Intended violation

A subsidy can lower SPM resources at the whole-model level. SNAP, TANF and tax credits read out-of-pocket expenses, so a subsidy can cut them by more than the SPM expense falls. At the earnings cap the expense can't fall at all, and below the cap a benefit cliff can cut more than the expense falls. Household income loses the same benefits but also counts the subsidy, so it can rise while SPM income falls. SPM net income fell in 22 of the 1,395 subsidized cells in the grid below, and test_subsidy_at_the_cap_can_lower_spm_income pins one case.

Audit of all 51 subsidies

I ran these audits on household calculations at 606699d640 against main at 469ad12cb9, and this head keeps that commit's household rule. Main has since changed the Vermont, New Hampshire, Nevada and Texas subsidies (#10584, #10575, #10598, #10636), so those states' counts can differ at the merged head.

• Each state against the aggregate, 2021 to 2026. I ran one working family in every state for 306 state-years, and no run errored. Before this PR, child_care_subsidies left out paying state programs in DC, Tennessee and Texas in 2024, and in DC, North Carolina, Oregon and Texas in 2021 to 2023. From 2024 they agree. This PR leaves 2021 to 2023 as they were, because the SPM expense formula starts in 2024.
• Deduction, 2024 to 2026. In 306 runs across 153 state-years at two expense levels, the deduction matched the formula. That audit compared against the aggregate, so it missed DC, Tennessee and Texas in 2024.
• Grid. 51 states by 6 earnings levels by 6 expense levels gives 1,836 cells, with meets_ccdf_activity_test set. Every state pays somewhere on the grid, and the identity in invariant 6 holds in every cell.
• Nevada. At the audit's base, Nevada paid the audit family nothing. Its activity test read meets_ccdf_activity_test, TANF enrollment, homelessness and protective care, and the family had none of them set. Stop requiring an activity input from Nevada's working parents #10575 has since stopped requiring the activity input from working parents.
• Household list. household_state_benefits lists 23 of the 51 subsidies, and Count all child care subsidies in household benefits #9503 would count all of them.

Population impact

I computed these tables from saved full-file arrays for 2026 (populace_us_2024.h5@populace-us-2024-spm-20260909): main at 469ad12cb9, and this PR's taxes and benefits at 606699d640. Over a dataset this head's baseline expense equals min(W + E, C), and among variables only spm_unit_spm_expenses reads the expense, so the arrays give what this head's rule produces at that base. Main has since changed the Vermont, New Hampshire, Nevada and Texas subsidies, among others, and added cash programs to SPM resources. The branch has merged main twice since those runs, most recently at 4bb2b92b39. Full-file runs at this head and its merge base wait on the host's heavy-run gate and will replace these tables.

Measure	Main	This PR
SPM poverty, all people	14.540%	14.574%
SPM poverty, children	18.825%	18.908%
SPM poverty, adults 18 to 64	13.906%	13.932%
SPM poverty, 65 and over	11.264%	11.264%
Deep SPM poverty, all people	3.355%	3.355%
Deep SPM poverty, children	2.536%	2.536%
SPM net income		$0.527B below main

All of the change comes from the three subsidies leaving resources. Main adds modeled Colorado and Washington subsidies ($270.7M and $255.9M) on top of what those families reported paying, and this PR stops that. From 2025 the two program lists match, so child_care_subsidies, childcare_expenses and SNAP equal main's on every record in 2026, with or without schedules. The deduction differs from main on 0 records, and SPM net income differs on 35. Five records (116,936 people, 64,207 children) enter poverty and none leave. Washington's rate moves from 12.00% to 13.44% on 4 records, and no other state's rate moves by 0.01 point.

With schedules set

The default dataset has no schedule columns, so most programs pay nothing. As a sensitivity, I gave every child under 13 in a unit with child care expenses a full-time schedule on both sides: 8 hours a day, 5 days a week, 21 days a month. I ran main at 469ad12cb9 and this PR's taxes and benefits at 640753a617.

Measure	Main	This PR
SPM poverty, all people	14.612%	14.648%
SPM poverty, children	19.060%	19.148%
Deep SPM poverty, children	2.676%	2.676%
child_care_subsidies	$9.735B	$9.735B
SPM net income		$0.483B below main

Five records (126,465 people) enter poverty and none leave. Washington moves as above, and West Virginia's rate moves from 14.03% to 14.56% on 1 record.

Costs and limits of this rule

• Other programs still net. SNAP, HUD adjusted income, state TANF and LIHEAP income tests, and dependent-care credits read childcare_expenses, which nets the modeled subsidy from the input over a dataset, as on main. This rule reads that input as what parents paid after any subsidy, so these programs net it twice wherever a program pays. Schedule data would widen the gap: with schedules set, child_care_subsidies rises $7.475B, SNAP falls $1.231B and taxes rise $0.462B. Add NSECE childcare attendance candidate and validation tools microcosm#916, a draft, fills those schedule columns, so these programs need the same treatment before any schedule release. That fix gets its own PR.
• Subsidies priced at the payment. Over a dataset the subsidy formulas take E, the reported payment, as the price of care, so S0, S1 and their difference all come from what parents paid. Where a program pays more than the bill, as Vermont's did in the audit, a reform that cuts the subsidy raises the expense by the whole cut, which can exceed what the family paid.
• Full enrollment. The subsidy formulas pay every eligible family, with no take-up rate or waiting list of their own. So the dataset rule subtracts the full change in subsidy from every eligible family's reported amount, before the floor and the cap apply. A family that reported $100 and gains $1,000 in subsidy sees its expense fall by $100.
• Run time. A reform run over a dataset now also computes subsidies in its baseline arm, and a plain run pays nothing extra. Over 5,000 households on a loaded Mac, spm_unit_net_income took 29.6 s in a plain run and 37.4 s in the reform arm of a no-change reform.
• Inputs set after construction. set_input on a reform simulation reaches only that arm. A caller who sets schedule columns on a reform simulation has to set them on simulation.baseline too, or the model computes S0 without them.
• Entry points without an arm. Core builds the baseline arm only for a reform passed as reform=, and apply_reform builds none. A simulation built with reform= keeps its arm, under baseline policy, through any reform applied later. Microsimulation(tax_benefit_system=...) without reform=, or apply_reform on a simulation built without reform=, leaves no arm, so the expense keeps E, and subsidy changes don't move it. In policyengine_us, only tests call the first form.
• A stored expense. policyengine-us-data's CPS build also stores spm_unit_capped_work_childcare_expenses itself, from SPM_CAPWKCCXPNS (cps.py:786), and the model accepts it as an input. Over that file neither rule runs in the stored year, as on main.
• Dataset inputs. The model reads any dataset input as a payment. PolicyEngine/ccdf-calculator's scripts/microsim.py raises this input to an assumed price over a dataset, but it reads subsidies and not the SPM, so this rule doesn't reach it.

Test cost

test_spm_child_care_subsidy_invariants.py stays in REST_REMAINING_HEAVY_TESTS, and it retains one reformed system and builds two more for the real-reform cases. Its tests ran for 206 s in CI at 6946cd74a4, against 102 s alone on a loaded Mac, where the process peaked at 4.5 GB resident. test_spm_child_care_reported_expense.py adds two tests: one reads only the expense and its inputs from a Microsimulation() over the whole file, and the other runs on a slice. In CI they took 7 s and 31 s. tests/core/test_reform_baseline_arm_inputs.py builds three plain simulations and three reformed ones. In CI at 6946cd74a4 its dataset test took 100 s and its situation test 37 s. Alone on the Mac, the all-time test took 9 s, and the whole file took 59 s and peaked at 3.6 GB.

What this PR does not change

• Schedules on microdata. New York's subsidy now counts in household calculations, but in a default population run the model still pays it $0, because the default dataset has no schedule columns. With them unset in 2026, one audited family gets nothing from 31 state programs that pay it once it has a schedule, New York's among them. Of the other 20, 6 pay it less without a schedule, 2 pay more and 12 pay the same. So in a default run the baseline subtracts what parents reported, and a reform that changes New York's subsidy moves nothing until the data carries schedules.
• Years before 2024. The SPM expense has no formula before 2024, so in those years a subsidy reaches the SPM only in Colorado, Washington and West Virginia. The Tlaib reform copies carry only Colorado in those years, as on main.
• Texas copays before January 2025. Texas's local workforce boards each set their own parent share of cost until January 13, 2025, when the Texas Workforce Commission began phasing in a statewide scale. Main's copay parameters (copay/rate/first_child, additional_child and the 7% maximum) start in January 2025 with that scale. The model backdates each parameter's first value to 2015, so a 2024 subsidy uses the statewide scale too. Add Texas CCS Board Contract Year 2024 provider payment rates #10598, now on main, adds BCY 2024 provider rates. I kept Texas in the 2024 list, because leaving it out drops the whole subsidy. Apply Texas Workforce Board parent share of cost scales before TX3C #10623, a draft, adds board scales for Alamo, Borderplex, Brazos Valley, Dallas County, Panhandle and South Texas. This PR's 2024 Texas case uses the model's default county, Anderson, in the East Texas board. Apply Texas Workforce Board parent share of cost scales before TX3C #10623 leaves that board on the statewide scale, so the case's expected $5,793.01 holds whichever PR merges first.

axiom: n/a: Census publishes the SPM as a statistical measure, and rulespec-us encodes no SPM provision.

🤖 Generated with Claude Code