Make SNAP work requirement disqualification person-level

[daphnehanse11]

Fixes #8862

Summary

Issue #8862 identified two misreadings of SNAP work requirement law. The first — household-wide disqualification when any member fails — was largely resolved by #8372, which made snap_unit_size remove failing individuals, added income proration, and gave the household-level variable any-member semantics. This PR completes the issue's scope by fixing the second misreading: the general work requirement treated working 30+ hours/week as an affirmative requirement, disqualifying every non-exempt adult who simply was not working. It also corrects the Medicaid community engagement pass-through, whose SNAP prong the interim final rule defines as a status test rather than a compliance test.

Regulatory authority

Verified against primary sources (eCFR, U.S. Code, enrolled H.R. 1, Federal Register):

• 7 U.S.C. 2015(d)(1)(A), (o)(2); 7 CFR 273.7(f)(1), 273.24(b): work-requirement ineligibility attaches to the individual, who "will be considered an ineligible household member." The only household-wide sanction is a state option applying solely when the head of household fails, capped at 180 days (7 U.S.C. 2015(d)(1)(B); 7 CFR 273.7(f)(5)); no household-wide sanction exists for the ABAWD time limit.
• 7 CFR 273.7(b)(1)(vii): working 30+ hours/week is an exemption from work registration, not an affirmative requirement. A non-exempt registrant who is not working remains eligible unless they affirmatively fail to comply without good cause — refusing suitable employment, E&T noncompliance, or voluntary quit/reduction of work effort under 273.7(j). These "without good cause" state-agency determinations are unobservable in survey data.
• 7 CFR 273.11(c): (c)(1) counts work-sanctioned members' income in full; (c)(2) prorates ABAWD time-limit-ineligible members' income. Both remove the member from household size for the benefit calculation.
• SSA § 1902(xx)(9)(A)(ii)(VI)(bb) (added by H.R. 1 § 71119) excludes from Medicaid community engagement an individual who "is a member of a household that receives [SNAP] benefits ... and is not exempt from a work requirement under such Act." 42 CFR 435.554(c)(7) (CMS-2454-IFC, 91 FR, June 3, 2026) confirms: "States only need to determine that the individual is not exempt from SNAP work requirements and is in a household that receives SNAP benefits; the State does not need to confirm that the individual is in fact compliant with SNAP work requirements" — an explicit asymmetry with the TANF prong, which does require compliance.

Changes

meets_snap_general_work_requirements now returns exemption status OR the absence of affirmative noncompliance. In the baseline everyone meets the requirement (compliance assumed); the exemption logic is unchanged and still governs who can be sanctioned.

is_snap_work_registration_noncompliant (new person-level input, default false) is the sanction-modeling hook. When set true, only exempt people — including 30+ hour workers per 273.7(b)(1)(vii) — still meet the general requirement, matching 273.7(f)(1), under which only non-exempt registrants can be sanctioned.

medicaid_community_engagement_pass_through_eligible previously required actual work activity (30-hour general test plus ABAWD compliance). Per the statute and interim final rule, the SNAP prong is a status test: SNAP receipt plus being subject to (not exempt from) a SNAP work requirement, with no compliance check. The formula now tests SNAP receipt and non-exemption only; the TANF prong retains its compliance requirement per the rule's explicit asymmetry. Documented simplifications: the 273.7(b)(1)(vii) working-30+-hours exemption is not netted out of subject-to status (immaterial to CE outcomes, since such workers satisfy the requirement directly), and post-HR1 adults 60-64 subject only to the ABAWD requirement are not separately captured.

Income treatment implements the two-regime 273.11(c) split (is_snap_prorated_income_member): members whose only failing prong is the ABAWD time limit have their income prorated per 273.11(c)(2), while members sanctioned under the general work requirements have their income counted in full per 273.11(c)(1). Both regimes remove the member from the SNAP unit size. snap_work_requirement_disqualification_income_treatment.yaml pins both regimes and the no-gain invariant for (c)(1) sanctions.

Behavioral effect

• Non-exempt adults who are simply not working are no longer disqualified under the general requirement; in the baseline, only ABAWD time-limit failures (and explicit sanction inputs) disqualify anyone.
• A failing member reduces the SNAP unit (with income prorated per 273.11(c)(2)) rather than zeroing the household.
• The issue's example — an unemployed, non-disabled 30-year-old with a 10-year-old dependent — is now eligible with the full allotment for a unit of two.
• Non-working, non-exempt members of SNAP households are excluded from the Medicaid community engagement requirement (deemed compliant), matching 42 CFR 435.554(c)(7); this affects projections from the CE applicability date (first quarter after December 31, 2026).

Test coverage

• meets_snap_general_work_requirements.yaml: 7 → 12 cases; the two cases encoding the over-strict reading flip to true, and five new cases exercise the sanction hook against each exemption.
• meets_snap_work_requirements.yaml: failure cases now derive from organic ABAWD facts or the noncompliance hook; added an end-to-end sanction case.
• snap.yaml: acceptance-criteria integration tests — the issue example (full 535 allotment for two with TANF zeroed for isolation), a mixed no-children household (unit of one, still eligible), and a single failing ABAWD (unit size zero).
• snap_unit_size.yaml, federal_work_study_income_exclusion.yaml: override-based premises converted to organic ABAWD facts; expected outputs unchanged.
• medicaid_community_engagement_pass_through_eligible.yaml: all five existing cases unchanged; new case asserts a non-working, non-exempt SNAP member passes through without a compliance check.

Validation

• Full SNAP YAML suite: 319 passed
• Full Medicaid YAML suite: 327 passed
• Microsimulation test: 5 passed
• make format clean

🤖 Generated with Claude Code

Rebase note (2026-07-09)

Rebased onto main past #8857, #8858, #8860, #8861, #8869, #8870, #8871, #8919, #8942. Semantic resolutions:

• meets_snap_general_work_requirements: merged with Support qualifying work-program participation in SNAP ABAWD work requirement #8857's work-program path — the formula is now exempt | is_snap_work_program_participant | ~is_snap_work_registration_noncompliant. Participation under 7 CFR 273.7(a)(1)(ii) is affirmative compliance and overrides the sanction hook (new test case 14).
• medicaid_community_engagement_pass_through_eligible: kept the status test; carried forward Cast bool-bracket .calc() results to bool before bitwise-NOT #8919's .astype(bool) cast on the age-bracket result. Main's cases 10–11 (ABAWD hours binding on the pass-through) were updated: under the 42 CFR 435.554(c)(7) status test the hours test does not bind, so case 11's expected output flips to [true, true].
• meets_snap_work_requirements.yaml: main's cases 11–12 relied on the affirmative-30-hour reading; re-anchored their failure path on the noncompliance hook. Cases 1–4 now set age rather than monthly_age — a year-period monthly_age input divides by 12, which made adults read as household children under Fix benefit parameter accuracy (CO SS cap increase, KY CCAP SMI, KY K-TAP citation, SNAP ABAWD gate) #8942's any-member 273.24(c)(4) semantics.

Post-rebase validation: SNAP YAML 377 passed, Medicaid YAML 373 passed, ACA pays_aca_premium 8 passed, microsimulation 6 passed, ruff format clean.

Review round (2026-07-27)

Addressed @DTrim99's program review and the cross-member conflation @hua7450 flagged in the #9118 review (tracked as #9145):

• SNAP eligibility: work-requirement filter still conflated across members (follow-up to #9118, blocked on #8961) #9145 fix folded in: is_snap_eligible now requires a single member to satisfy the student, immigration, and work-requirement filters simultaneously, via spm_unit.any(~is_snap_excluded_member), replacing the separate unit-level meets_snap_work_requirements reduction. A fully excluded unit no longer draws the minimum allotment. Regression test added (immigration-ineligible worker + citizen ABAWD, no single member passes all three → ineligible, snap: 0).
• 42 CFR 435.554(c)(7) verbatim confirmed from the GPO full text of FR doc 2026-11094 (91 FR 33348): "(7) The individual is a member of a household that receives Supplemental Nutrition Assistance Program (SNAP) benefits under 7 U.S.C. 2015 and is not exempt from a work requirement under such Act." The preamble states the asymmetry explicitly: "Unlike the TANF exclusion … the State does not need to confirm that the individual is in fact compliant with SNAP work requirements," and interprets subject-to status as being non-exempt from the general requirement, the time limit requirement, or both.
• Tightened snap_work_requirement_disqualification_income_treatment.yaml Cases 1–2 to absolute_error_margin: 0.1 with exact currency values (reconciled with the equivalent fix Ziming pushed concurrently), so the boolean and unit-size assertions bind.
• Added a pre-2027 negative case pinning the CE applicability-date boundary in is_medicaid_ineligible_due_to_work_requirement.yaml.
• Added subsection deep links (7 CFR 273.7(a)(1)/(b)(1)/(f)(1)/(j); eCFR 435.554(c)(7); 7 CFR 273.11(c)(1)) and wrapped long documentation strings.
• Paired the incapacitated-person exemption with the sanction hook (general work requirements Case 12b).

Validation: SNAP YAML 487 passed, Medicaid YAML 378 passed, WA ECEAP 113 passed, TX CEAP + DC SNAP local benefit 31 passed, microsimulation 6 passed, ruff format/check clean.

[codecov]

Codecov Report

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

Additional details and impacted files

@@            Coverage Diff             @@
##              main     #8961    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files           17         3    -14     
  Lines          279        49   -230     
==========================================
- Hits           279        49   -230     

Flag	Coverage Δ
unittests	100.00% <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.

[daphnehanse11]

Ran a first release-scale reform smoke of this branch (head 77453dc) against the Build K Populace artifact (populace-us-2024-buildk-snapval, 57,240 households, calibrated on pe-us 1.764.6 — the artifact that fits all 51 FNS state caseload targets). Baseline = 2024 law (abawd.in_effect false); reform = ABAWD requirements switched on for 2024. Three findings for review:

1. Baseline drift vs the calibrated surface. SNAP total on this branch is $100.43B vs $88.5B on pe-us 1.764.6 with identical inputs/weights (+13%), and taker households 22.88M vs 21.98M. The post-1.764.6 SNAP wave moved the baseline substantially; reform runs against calibrated Populace artifacts will need either a rebase of this branch onto the data's pinned engine, or a recalibrated artifact on the new engine, to keep baseline-vs-FNS honest.

2. Wrong-sign budget delta. Switching ABAWD requirements ON yields +$0.12B (and +13k taker households). Expected direction is negative (time limits remove benefits). With 14.8M weighted persons returning meets_snap_abawd_work_requirements == False under the reform but only ~14 weighted spm_units losing SNAP entirely and zero with reduced benefits, the disqualification appears not to flow into benefit amounts as loss — and something (member-exclusion interacting with income counting for sanctioned members, 7 CFR 273.11(c)?) nets positive. Worth a targeted test: a unit with one ABAWD-noncompliant member should lose that member's needs while keeping their income countable.

3. Exposure metrics. meets_snap_general_work_requirements returns zero weighted failures at baseline — consistent with the assumed-registration-compliance design, so ABAWD is the only live disqualification channel on survey data. And raw meets_snap_abawd_work_requirements == False (14.8M persons) plainly includes people the requirement doesn't apply to; a is_subject_to_snap_abawd_requirements-style decomposition variable would make population exposure reportable directly.

Smoke script and log available; happy to turn (2) into a failing YAML test if useful.

🤖 Generated with Claude Code

[daphnehanse11]

Follow-up on finding (2): the wrong sign is now pinned to a minimal household and encoded as a YAML test (committed locally as b8fabdd266 on this branch, not yet pushed — pushing turns CI red until the fix lands, so that's the author's call).

The mechanism, isolated: a TX household of a 66-year-old ($9,600 Social Security) and a 30-year-old earning $30,000 is SNAP-ineligible — until the earner drops below 20 hours/week. Then meets_snap_work_requirements_person goes false, snap_unit_size shrinks to 1, AND snap_work_requirement_income_proration_fraction halves his countable income (273.11(c)(2) proration), so the remaining "unit" passes the 1-person limits on $15,000 of imputed income: is_snap_eligible flips true and the household gains ~$288/year for failing a work requirement. At release scale this is the +$0.12B inversion — proration-created eligibility, enrolled via take-up flags.

Test file: tests/.../work_requirements/snap_abawd_disqualification_cannot_expand_eligibility.yaml — three cases:

• Case 1 (passes): zero-income noncompliant ABAWD → unit shrinks, benefit falls $4,466 → $1,473. The core seam works.
• Case 2 (fails): the household above must stay ineligible when the earner fails the time limit. Current: eligible, $288.
• Case 3 (passes): the compliant counterfactual pinned at $0, so 2+3 jointly assert the no-gain invariant.

Design question for the fix: 7 CFR 273.11(c) governs treatment of a disqualified member within a participating household; it isn't an eligibility pathway for households that don't qualify at full composition. One shape: apply the (c)(2) proration to the benefit computation only when the full-composition unit is otherwise eligible (or gate is_snap_eligible on the full-unit test). Happy to draft it if that reading holds up.

🤖 Generated with Claude Code

[daphnehanse11]

Fix drafted and validated; the wrong-sign smoke fully decomposed into two independent causes. Both commits are local on this branch (b8fabdd266 failing test, 7065ec4e44 fix — the test passes with the fix, so pushed together CI stays green; author's call).

Cause 1 — eligibility expansion via proration (real bug, pre-dates this branch, now fixed). At pure current law, a household over the income limits at full composition qualified at reduced size on the disqualified earner's halved income (snap_work_requirement_income_proration_fraction): failing the ABAWD time limit created a ~$288/yr benefit (Case 2 of the new invariant test). Fix: count work-requirement-ineligible members' earned income in full (the 273.11(c)(1) treatment) — needs leave the unit, income stays, so disqualification can only reduce eligibility and benefits. The proration variable is removed, its two pinning tests repinned ($230.40 → $110.40/mo for the canonical ABAWD-earner case), changelog added; 257 tests green across the SNAP/Medicaid suites. Note the proration shipped to main with the SNAP wave, so released pe-us carries this until the branch merges.

Cause 2 — in_effect is not a self-contained reform lever (specification trap, most of the +$0.12B). The formulas switch logic on hr1_in_effect but read bracket values at the simulation period; only the pre-HR1 side is snapshotted (parameters("2025-06-01")). Toggling in_effect true at 2024 therefore pairs HR1 logic with FY2024 FRA brackets, exempting 53–54-year-olds who fail at baseline — ~30 dataset households regained members for exactly the 9 months before the October bracket step (9 × $291 = the constant $2,619 gain that dominated the smoke). Suggestion: snapshot the post-HR1 values symmetrically (e.g., parameters("2025-07-04")) inside the where(hr1_in_effect, …) branches, so the toggle is coherent at any period; at minimum the parameter README should warn reform authors.

Coherent validation (2026: baseline HR1-on vs repeal), on the Build K artifact with the fix:

• HR1 ABAWD provisions save $2.67B/yr (SNAP $96.59B → $99.25B under repeal) — right sign, plausible magnitude vs official scores.
• ~1.09M weighted households lose benefits under the provisions; taker households fall ~294k. The machinery is reform-ready.

🤖 Generated with Claude Code

[DTrim99]

Program Review — PR #8961 (Make SNAP work-requirement disqualification person-level)

Author: daphnehanse11 · Fixes #8862 · Logic/semantics rewrite (no parameter-value changes)

Source Documents

Federal regulations (verified against primary sources where reachable):

• 7 CFR 273.7 (work registration, exemptions, individual sanctions) · 7 CFR 273.11(c) (ineligible-member income treatment) · 7 CFR 273.24 (ABAWD time limit)
• 7 U.S.C. 2015(d)/(o) · SSA §1902 (H.R.1 §71119) · 42 CFR 435.554(c)(7) (CMS-2454-IFC, 91 FR 33348, June 3 2026)

Branch Status

⚠ PR branch is 70 commits behind main (7 ahead). Recommend rebasing before merge. Review was scoped strictly to the PR's merge-base diff, so the staleness did not cause false-positive findings.

Summary

Genuine correction of two prior misreadings of SNAP work-requirement law, verified by four independent validators. All agree: 0 critical. The general work requirement no longer treats "not working 30+ hrs" as an affirmative failure (it's an exemption from registration per 273.7(b)(1)(vii)); disqualification now attaches to the individual (removing them from the unit with prorated/ full-counted income per 273.11(c)) rather than zeroing the household; and the Medicaid community-engagement SNAP prong is a status test (SNAP receipt + non-exemption, no compliance check) per the June-2026 interim final rule, while the TANF prong retains its compliance check. CI green (35/35; PR reports 377 SNAP + 373 Medicaid passing).

The four legal claims — all CONFIRMED against primary sources:

1. Individual-level disqualification — the only household-wide sanction is the head-of-household state option capped at 180 days (273.7(f)(5)); no household-wide ABAWD sanction. ✅
2. 30+ hrs = exemption, not requirement — non-exempt non-workers stay eligible absent affirmative sanction; "without good cause" findings are unobservable, so baseline-compliant is the defensible modeling default. ✅
3. Medicaid CE SNAP prong = status test — no compliance term on the SNAP prong; TANF asymmetry preserved. ✅
4. 273.11(c) income treatment — proration for ABAWD-only failures (c)(2), full count for general-requirement sanctions (c)(1). ✅

Entity levels (the crux) are correct: both new/changed variables are Person-level, the noncompliance hook is read and negated per-person (no household-wide roll-up of one member's failure), and spm_unit.any() is used only for the genuinely household-level exemptions. is_snap_work_registration_noncompliant is genuinely new (bool/Person/MONTH/default False). Both changelog fragments present and correctly typed. The #9145 cleanup path is intact — meets_snap_work_requirements_person is kept correct and already folded into is_snap_excluded_member.

Critical (Must Fix)

None.

Should Address (non-blocking)

1. PR description is stale (code is more correct than the body). The body says the model "prorates income for all work-requirement-ineligible members as a simplification," but the head code implements the correct two-regime 273.11(c) split — proration only for members whose sole failing prong is the ABAWD time limit (c)(2), full income count for general-requirement sanctions (c)(1) (is_snap_prorated_income_member.py:38-41). Update the PR body (and any lingering snap_work_requirement_income_proration_fraction narrative) so the merged record reflects the two-regime treatment.
2. Confirm the 42 CFR 435.554(c)(7) IFR text before merge. The Medicaid-CE status-test rests on the brand-new June-2026 interim final rule. Two validators independently could not re-fetch the verbatim "(c)(7)" language (eCFR/FederalRegister/CMS/Cornell all bot-blocked or not-yet-mirrored); it's corroborated at the document level (FR doc 2026-11094 = CMS-2454-IFC, 91 FR 33348, confirmed amends 42 CFR 435.554), but a reviewer with source access should eyeball the exact "does not need to confirm ... compliant" clause and the TANF-vs-SNAP asymmetry. Verification gap, not an identified error.
3. Loose test margin on non-currency assertions — snap_work_requirement_disqualification_income_treatment.yaml Case 1 sets absolute_error_margin: 1, which (being file-level) also applies to its is_snap_eligible and snap_unit_size outputs, making those two assertions partially vacuous (a margin of 1 lets true≈false and unit_size off by one). The margin is legitimate only for the snap: 1_487 currency line. Mitigated — the same unit-size/eligibility behavior is pinned tightly (margin 0.01) in snap.yaml Cases 5–7 and 9, so this isn't a real coverage hole — but tighten Case 1 (split the margin onto the currency line, or set 0.01) so it stands on its own. (Margin-1-on-booleans is normally treated as critical; downgraded here because the behavior is redundantly pinned elsewhere.)
4. Medicaid-CE applicability-date boundary not pinned — there's no pre-2027 negative case proving the federal work-requirement bar does not apply before the effective date. The date gate lives on is_medicaid_ineligible_due_to_work_requirement (outside this PR's file set), which pins the 2027 side only. Either note the boundary is owned/tested there (out of scope) or add the pre-2027 negative case.

Suggestions

• Add subsection deep-links to references: meets_snap_general_work_requirements cites bare 7 CFR 273.7 (formula depends on (a)(1)/(b)(1)(vii)/(f)(1)/(j)); the Medicaid-CE variable names 42 CFR 435.554(c)(7) but the tuple lacks a direct eCFR #p-435.554(c)(7) link. (W1/W2)
• Add 7 CFR 273.11(c)(1) to the is_snap_prorated_income_member reference tuple (it cites (c)(2)/(c)(3) but the formula turns on the (c)(1)/(c)(2) distinction). (SUG-1)
• Symmetric coverage: pair the has_incapacitated_person exemption with is_snap_work_registration_noncompliant: true (the one exemption branch not exercised with the sanction hook). (L1)
• Cosmetic: wrap the long single-line documentation strings; the documented Medicaid-CE simplifications (30+hr exemption not netted from "subject-to"; 60–64 ABAWD-only adults) are acceptable and correctly flagged.

Validation Summary

Check	Result
Regulatory Accuracy	Correct on all 4 axes (individual-level, 30hr-exemption, CE status-test, 273.11(c) two-regime); 0 critical; 2 doc/verification should-address
Reference Quality	0 critical, 0 missing; all federal, corroborated; 2 granularity warnings; 435.554(c)(7) verbatim unverifiable (bot-gated)
Code Patterns	0 critical; entity levels correct (person-level, no household roll-up); no hardcoded values; changelogs correct; 1 consistency note (#9145), 3 cosmetic
Test Coverage	Headline regression + sanction-hook-per-exemption + person-level any() + (c)(1)/(c)(2) split + CE status-test all tightly pinned; 1 loose margin (Case 1), 1 date-boundary gap
CI Status	Passing (35/35)

Review Severity: COMMENT

A well-researched, regulatorily-sound correction of two real misreadings, with strong test coverage and correct person-level entity semantics. No blocking issues. Before merge: update the stale PR body (item 1), confirm the new IFR text (item 2), and ideally tighten Case 1's margin (item 3). Rebase recommended given the 70-commit lag.

Next Steps

To auto-apply the actionable items: /fix-pr 8961

Review generated with Claude Code via /review-program