Add pre-OBBBA SNAP ABAWD work requirements counterfactual reform

[daphnehanse11]

Fixes #8943

Summary

Adds a contributed counterfactual-baseline reform modeling 2026/2027 SNAP rules as if the OBBBA (P.L. 119-21, §10102) ABAWD work requirement exemption and age provisions had not passed.

Since the OBBBA provisions are now encoded in the current-law baseline, this provides the inverse lever of the pre-passage gov/contrib/reconciliation/snap_abawd_work_requirement reform: toggling gov.contrib.snap.pre_obbba_abawd_work_requirements.in_effect restores prior law against the post-OBBBA baseline.

Implementation

The baseline ABAWD formulas (meets_snap_abawd_work_requirements, meets_snap_work_requirements) already branch on the person-level is_snap_abawd_hr1_in_effect variable, using a parameters("2025-06-01") pre-HR1 snapshot for the prior-law path. The reform overrides is_snap_abawd_hr1_in_effect with a formula that returns false for periods where the contrib toggle is true and otherwise mirrors the baseline logic, restoring in every state (including CA/HI/AK delayed adoption):

• exempt ages 18–54 subject / 55+ exempt (vs 18–64 subject post-OBBBA)
• dependent-child age threshold of 18 (vs 14)
• homeless, veteran, and former foster youth exemptions (removed by OBBBA)

The per-period override (rather than neutralize_variable) ensures a future-dated toggle does not apply retroactively to earlier simulated years. Follows the standard contrib factory pattern (in_effect toggle, 5-year lookahead, module-level bypass=True instance, registration in reforms.py).

Review round (multi-angle, findings addressed here)

An 8-angle adversarial review surfaced and this PR addresses:

1. Retroactivity bug (fixed): the original neutralize_variable approach ignored the toggle's start date — a toggle dated 2028 reverted 2026 results. Now period-gated and covered by a test.
2. Medicaid interaction (documented + tested): medicaid_community_engagement_pass_through_eligible reads is_snap_abawd_hr1_in_effect, so the pass-through follows the counterfactual SNAP rules. This is the intended behavior (in a no-OBBBA-SNAP-WR world, the Medicaid pass-through references actual SNAP rules); documented in the module docstring and covered by a test (57-year-old work-program participant flips eligible).
3. Scope narrowed (documented): OBBBA §10102 also rewrote area waivers; post-OBBBA waiver geography (waived_county_fips) is not reverted. Parameter description, changelog, and docstring now claim only the exemption and age provisions.
4. Data-layer caveat (documented): discretionary exemption flags are assigned at microdata construction among the post-OBBBA covered population and are not re-drawn under the counterfactual.
5. FRA sunset caveat (documented): the pre-OBBBA path is a frozen 2025-06 snapshot, so the FRA's scheduled 2030-10-01 sunset is not modeled; the reform targets pre-2030 windows (e.g., 2026/2027).
6. Bypass fragility (mitigated): the baseline is_snap_abawd_hr1_in_effect now documents that it must remain the sole access point for the underlying federal/state parameters.

Verification

• 12 YAML tests pass (tests/policy/contrib/snap/pre_obbba_abawd_work_requirements.yaml): age exemption in 2026/2027, non-exempt control, parent of a 15-year-old, homeless/veteran/former-foster-youth exemptions, CA after delayed adoption, period gating (reform applied, toggle off ⇒ current law), baseline-contrast cases (no reform ⇒ post-OBBBA rules), and the Medicaid pass-through interaction. 5 pytest unit tests cover the autoloader (bypass, default-inactive, and the 5-year lookahead window edges). Federal cases pin state_code: TX since the default state (CA) is pre-HR1 through 2026-05 in baseline.
• All 111 existing baseline work-requirement and Medicaid CE pass-through tests pass.
• End-to-end via structural registration: TX 60-year-old non-worker in 2026-01 is ineligible in baseline, eligible under the reform; a 2028-dated toggle leaves 2026 at current law.

Microsimulation note

On the default CPS-based dataset, this reform (and the baseline OBBBA work requirement itself) produces no population-level SNAP delta, because weekly_hours_worked_before_lsr defaults to 40 for every person when the dataset lacks hours data — everyone trivially satisfies the 20-hour ABAWD test. Population-level analysis of SNAP work requirements requires microdata with real hours and exemption assignment (tracked under the #8820 data work / PolicyEngine/populace#24).

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (f9e58e7) to head (de896b6).
⚠️ Report is 166 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #8944   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            3         1    -2     
  Lines           55        14   -41     
=========================================
- Hits            55        14   -41     

Flag	Coverage Δ
unittests	100.00% <ø> (ø)

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.

[PavelMakarchuk]

This can be a pure parametric reform

is_snap_abawd_hr1_in_effect is the sole reader of the four baseline booleans it consults (gov.usda.snap.work_requirements.abawd.in_effect plus the CA/HI/AK hr1_in_effect params — confirmed by grep), and all three downstream consumers (meets_snap_abawd_work_requirements, meets_snap_work_requirements_person, medicaid_community_engagement_pass_through_eligible) branch on nothing but that variable, taking the frozen parameters("2025-06-01") pre-OBBBA snapshot on the false path.

So setting those four booleans to False collapses the select() to all-false — identical to the reform's where(in_effect, False, baseline) override, with no side effects since nothing else reads them.

Empirical proof of equivalence

I ran the PR's structural reform (variable override + contrib toggle ON) against a pure parametric reform (the four booleans → False) across 30 scenarios × 6 outputs = 180 comparisons — all identical:

Dimension	Cases	Result
State paths (TX/CA/HI/AK — the four select() branches)	4	✅
Delayed-adoption timing (2026-01, 2027-01)	2	✅
Age threshold (55+ pre vs 65+ post)	ages 30/55/60/70	✅
Child-age threshold (14 post vs 18 pre)	child 13/15/17	✅
Restored exemptions (homeless, veteran, former foster youth)	3	✅
Indian-exemption tightening (the asymmetric case in the docstring)	1	✅

Outputs compared: is_snap_abawd_hr1_in_effect, meets_snap_abawd_work_requirements, meets_snap_work_requirements_person, meets_snap_work_requirements, medicaid_community_engagement_pass_through_eligible, and end-to-end is_snap_eligible.

The parametric form:

Reform.from_dict({
    "gov.usda.snap.work_requirements.abawd.in_effect":               {"2026-01-01.2100-12-31": False},
    "gov.states.ca.cdss.snap.work_requirements.abawd.hr1_in_effect": {"2026-01-01.2100-12-31": False},
    "gov.states.hi.dhs.snap.work_requirements.abawd.hr1_in_effect":  {"2026-01-01.2100-12-31": False},
    "gov.states.ak.dpa.snap.work_requirements.abawd.hr1_in_effect":  {"2026-01-01.2100-12-31": False},
}, "policyengine_us")

Why reconsider the structural approach

The structural version produces bit-for-bit identical results while adding ~115 lines of reform code, a duplicated select() block that must be kept in sync by hand (flagged with # keep in sync in the diff — a maintenance hazard if a fifth delayed-adoption state is ever added), and a 5-year-lookahead autoloader with its own unit tests. It also introduces the retroactivity bug the PR then had to fix — which only existed because of the structural neutralize_variable approach; a parametric reform gets period-gating for free from the reform-dict date range.

The one thing the structural approach buys is the single gov.contrib.* toggle (consistent with the inverse pre-passage reform). If a named single lever is desired, a lighter middle option is to have baseline is_snap_abawd_hr1_in_effect return False when the contrib in_effect param is set (~2-line edit) rather than overriding the whole variable — this preserves the one-lever UX and drops the duplicated logic + autoloader.

Recommendation: convert to the pure parametric reform above, or the ~2-line contrib-gated variant if the single toggle is a hard requirement.