Count housing subsidies as CPUC does, and tighten the dataset, default and batch guards

[MaxGhenis]

Four fixes from an external review of the SPM integration on upstream/main, plus three more found by an adversarial review of this branch.

1. Count housing subsidies as the CPUC form does

gov.states.ca.cpuc.income_sources counted spm_unit_capped_housing_subsidy — the Census SPM's housing subsidy capped at the housing portion of the SPM threshold less the tenant payment. That is a poverty-measurement construct, and it made a utility discount depend on which SPM geography the request selected.

Reproduced. A Los Angeles renter, 2024 earnings $40,700, rent and PHA payment standard $36,000, receiving housing assistance. Changing only spm.geography_kind:

Output	National	County
Housing assistance	$23,790	$23,790
HUD tenant payment	$12,210	$12,210
Capped housing subsidy	$0	$310.88
CPUC countable income	$40,700	$41,010.88
ca_care_eligible	true	false

Requesting CARE with no SPM configuration raised SPM_GEOGRAPHY_REQUIRED, though no SPM output had been asked for.

The source does not support the cap. PG&E Form 01-9077, the CARE/FERA application, footnotes its income guideline tables:

*Total gross annual household income includes all taxable and non-taxable revenues from all people living in the home, from whatever sources derived, including, but not limited to, wages, salaries, interest, dividends, spousal and child support payments, public assistance payments, Social Security and pensions, housing and military subsidies, rental income, income from self-employment and all employment-related, non-cash income.

— PG&E Form 01-9077, CARE/FERA Program Application (Rev. 6.26). The same footnote appears on the CPUC-filed tariff sheet, Revised Cal. P.U.C. Sheet No. 61313-E (Electric Sample Form 79-1055, Advice 7905-E, effective 1 June 2026). Both PDFs were fetched and read; grepping either for net of|capped|cap the|tenant share|rent portion|poverty measure|deduct|minus|offset returns nothing substantive. The form names the category and stops — it never says "gross" or "amount received", and it states no valuation rule at all.

So the entry becomes housing_assistance. Countable income for that renter is now $64,490 under national selection, county selection and no SPM configuration alike, and computes with no county input. The dead bha.berkeleyca.gov mirror (DNS no longer resolves) is replaced by PG&E's own URL plus the tariff sheet.

Please weigh this before merging. housing_assistance is not a report of receipt: is_eligible_for_housing_assistance is receives_housing_assistance | (is_renter & is_income_eligible) and takes_up_housing_assistance_if_eligible defaults to true. A 40-year-old Los Angeles renter, 2026 earnings $35,000, rent $24,000, sending receives_housing_assistance: false, is modelled with $11,580 of assistance, taking CPUC countable income from $35,000 to $46,580 and ca_care from $585 to $0. That is consistent with how the rest of the list already works — snap, tanf, ssi and wic are this model's amounts, not an applicant's reported ones — and the capped entry consulted the same modelled amount. But the cap incidentally suppressed it (that household's capped subsidy is $0), so the change is user-visible. It is pinned in test_cpuc_counts_modelled_housing_assistance_for_a_non_recipient_renter so anyone who wants the entry gated on receipt has a named test to change.

In microsimulation the change is immaterial — the effect above is specific to the household/API path. Measured over the certified default build (2026, weighted, CA), running the parameter file swapped on disk in three separate processes:

Housing entry	ca_care_income_eligible	ca_care_eligible	Mean CA countable income
housing_assistance (this PR)	2,712,528	5,611,876	$209,072
spm_unit_capped_housing_subsidy (before)	2,712,528	5,611,876	$209,062
entry removed entirely	2,743,814	5,611,876	$208,956

Income eligibility is unchanged to the person, and mean countable income moves $10. The certified build supplies receives_housing_assistance and takes_up_housing_assistance_if_eligible as inputs, so take-up is not imputed there, and for genuinely assisted units the SPM cap seldom binds — the capped figure was already close to the full subsidy. Dropping the entry altogether would move income eligibility by 31,286 (+1.15%), so the entry does carry weight; it is the valuation that microsimulation barely notices.

Other consumers of spm_unit_capped_housing_subsidy, left as they are. The form says nothing about any of them.

Consumer	Why unchanged
spm_unit_benefits → spm_unit_net_income	The SPM resource measure itself; the cap is the measure's own definition
household_benefits (gov.household.household_benefits) → household_net_income	Same measure, household level
gov.household.cbo_means_tested_transfers → CBO household income	CBO's own income concept; I did not read CBO's housing-subsidy valuation this session and have no basis to change it
Tlaib ECPA / EDAA / BOOST and tx_rebate reforms	Poverty-measure-shaped benefit substitutions

2. Reject derived poverty aliases from stored datasets

The dataset guard rejected only the calculator's FORMULA_OWNED_INPUTS, so a dataset supplying in_poverty, in_deep_poverty, deep_poverty_line, deep_poverty_gap or person_in_poverty was accepted unchanged, and the documented poverty calculation could publish a different rate from spm_unit_is_in_spm_poverty for the same population. DERIVED_POVERTY_OUTPUTS now sits beside the calculator contract and the union is rejected, with a closure test asserting no further pure function of the poverty chain can be stored.

3. Verify the default dataset resolves to the certified build

DEFAULT_DATASET pins a Hugging Face tag, a mutable pointer: re-tagging, or a truncated download, would hand the model another schema-valid H5 and change every standalone-country result with nothing rejecting it. DEFAULT_DATASET_SHA256 now sits beside the URI and is checked after resolution — for the country default only, since an explicit dataset= names the caller's own artifact. A mismatch raises with the URI, the resolved path and both hashes. The ~830 MB digest is memoised on (path, size, mtime), so a default Microsimulation pays it once per process.

4. The batch runner's exit status is authoritative

test_batched.py decided a batch by parsing pytest's summary line: absent an "N failed" count it called the batch passed, then terminated the child without reading its status. pytest prints no failure count for an errored run, so 1 passed, 1 error with child exit 1 was reported as passing and make test-yaml-* exited 0 on it. An interrupted run is worse: with policyengine-core's argv, a session whose second test raises KeyboardInterrupt exits 2 beneath 1 passed in 0.10s — measured — which the old parse also scored a pass.

The status cannot simply be waited for. Once pytest.main() returns, interpreter teardown frees the tax-benefit systems the run cached, and that is slow: measured here, one small state took 18.2s to exit after printing its summary, and the large state batches took over 30s. Waiting turned every big green batch red. So the command now runs through a shim that writes pytest's return value to stdout the instant it has one, before teardown — measured, that marker arrives in the same read as the summary line, so it costs no wall clock. The runner reads the marker, terminates the child exactly as before, and decides the batch on the reported status. A child that dies before reporting is judged by its process status, which is what an OOM kill leaves behind.

Exit 5 (no tests collected) is a failure here, unlike in run_selective_tests.py: that runner selects paths from a changed-file list, where a changed test helper legitimately collects nothing, while this one enumerates the YAML suite itself, so an empty batch means the suite or the enumeration is broken. Every batch line now carries its exit status as release evidence.

.yml is enumerated alongside .yaml everywhere the runner lists files — policyengine-core collects both (tools/test_runner.py:413), so listing only *.yaml would drop a .yml test from any file-level batch, the heavy-subdirectory split among them, while the batch still reported green. No .yml test files ship today, so no current batch changes.

Found reviewing this branch

• The monitoring loop was unbounded, in this revision and before it: the 30-minute budget sat below the loop, reachable only once the child had already exited, so the wait it guarded returned instantly and never fired. Reading the status from the runner also left pytest's session-finish window open. Both are enforced inside the loop now. A/B on a child that prints a summary then sleeps: the previous revision was still running after 40s; this one returns with a status.
• batch_status's docstring claimed pytest exit 2 prints no summary count. It does (above). Corrected.
• _static_variable_reads discarded any variable whose class body held no direct entity call — 884 of the system's 6,173, among them poverty_line, which is adds = ["spm_unit_spm_threshold"] and no formula at all, a live member of the chain the guard protects. The closure test was blind to the idiom the next alias would most likely use. It now trusts a formula-less variable's adds/subtracts and the helpers that name their reads as string literals: 5,665 variables resolve, and the closure still passes.

Verification

Every suite below was run in this worktree on Python 3.14 with the pinned .venv; exit codes are the runner's own.

Suite	Result
tests/core + tests/unit + tests/code_health	429 passed, exit 0
CA CPUC YAML + partner CA care/fera fixtures	96 passed, exit 0
policy/baseline/gov/states, 16 batches (test-yaml-no-structural-states)	17 batches, all exit 0, 3,322 files
partner YAML target (test-yaml-no-structural-other-partners), all five invocations	exits 0 0 0 0 0
policy/baseline/household + tests/variables	exit 0, exit 0
policy/contrib/congress per-subdir + policy/reform per-file	exit 0, exit 0
make format (ruff format + check)	clean

Partner contract fixtures under tests/policy/baseline/partners/** pass unchanged and were not edited (git diff upstream/main -- .../partners/ is empty).

Not addressed here

Astra's P1 #2 and #3 and P2 #4 and #5 — later apply_reform mutating a shared parameter tree, a reformed clone's calc() routing to the original, private-variable registration through shared Entity objects, and shared parameter trace caches — are spm.py/policyengine-core concerns outside this branch.

The CPUC ESA Policy & Procedures Manual §2.2.2 lists housing subsidies among receipts not counted as household income, footnoted to D.14-08-030 OP 40. Its own scope line reads "the ESA Program", the Attachment Q footnote naming that rule is written for "the ESA and CARE Programs" jointly, and OP 40 itself could not be retrieved (docs.cpuc.ca.gov's search endpoint returns HTTP 000; the APEX proceeding page needs a browser session). So whether the exclusion reaches CARE is genuinely unresolved. This PR keeps the application form's treatment — housing subsidies count — and only corrects how they are valued. Settling the include-versus-exclude question needs OP 40.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.30%. Comparing base (f56fabe) to head (cafcd94).
⚠️ Report is 27 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##              main    #9464      +/-   ##
===========================================
- Coverage   100.00%   92.30%   -7.70%     
===========================================
  Files           17        2      -15     
  Lines          264       26     -238     
  Branches        10        1       -9     
===========================================
- Hits           264       24     -240     
- Misses           0        1       +1     
- Partials         0        1       +1     

Flag	Coverage Δ
unittests	92.30% <100.00%> (-7.70%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[MaxGhenis]

Superseded by #9467, which carried this work to main (see its provenance table).