Add Texas $1,500 per-household rebate as a contributed reform

[DTrim99]

Summary

Implements the Texas $1,500 per-household rebate checks proposed in gubernatorial nominee Gina Hinojosa's "Money in Your Pocket" economic agenda (July 2026) as a contributed reform. Closes #9036.

Modeling assumptions (documented in the module docstring and parameter descriptions)

The campaign proposal specifies neither the eligibility unit nor an income limit. This reform models one $1,500 check per household, no income limit, effective 2027 only — the reading consistent with the campaign's own arithmetic: drawing the Economic Stabilization Fund from ~$27B to a $10B reserve frees ~$17B, almost exactly $1,500 × Texas's ~11.8M households. PolicyEngine is nonpartisan and models the proposal as described.

Implementation

Texas has no income tax, so the rebate is a household-level benefit, not a credit:

• Parameters: gov/contrib/states/tx/rebate/in_effect.yaml (default false) and amount.yaml ($1,500 for 2027, reverting to $0 at 2028-01-01 so the one-time nature is encoded in the parameter itself)
• Variable: tx_rebate (Household, defined_for = StateCode.TX, amount from the parameter — no hard-coded values)
• Net income: modify_parameters appends tx_rebate to gov.household.household_state_benefits (2027 window), flowing into household_benefits → household_net_income
• SPM poverty: spm_unit_benefits override (verbatim copy of current baseline + tx_rebate), flowing into spm_unit_net_income; core's group-to-group add splits the household amount per capita across SPM units
• Registration: two-function factory with 5-year lookahead and module-level bypass instance, wired into reforms/reforms.py

Tests

8 cases, all passing locally: TX household receives $1,500; non-TX receives $0; flows into household_benefits/net income; flows into spm_unit_benefits; zero-income and $500k-income households both receive the full amount (no income test); $0 before 2027; $0 in 2028 in both tx_rebate and spm_unit_benefits (one-time payment does not recur).

Validation

• 10-point contrib-reform checklist: all pass (factory pattern, lookahead, registration, no hard-coding, baseline-verbatim override with no drift)
• Source review vs the press release: no critical findings; assumption-documentation warnings addressed
• Pitfall audit: no circular dependencies or double-counting (the household and SPM aggregation trees are disjoint); the 2028 SPM leak it found is fixed by the parameter sunset
• Benchmark: reproduces the standalone dashboard's estimate (~11.8M TX households × $1,500 ≈ $17.7B on ECPS TX.h5, 2027)

🤖 Generated with Claude Code

[daphnehanse11]

PR Review

Four-validator review (regulatory accuracy, reference quality, code patterns, test coverage) run against a clean checkout of tx-rebate. No critical issues found — the review below is non-blocking.

Verified correct (highlights)

• spm_unit_benefits override has zero drift: the BENEFITS list was programmatically diffed against baseline policyengine_us/variables/household/income/spm_unit/spm_unit_benefits.py — 66 baseline entries all present and ordered identically, with "tx_rebate" the single addition; both conditional tails (deduct_ptc, hud.abolition) match exactly.
• No double-counting, verified empirically: tx_rebate reaches household_net_income once (via household_state_benefits → household_benefits) and spm_unit_net_income once (via the override). A 4-person single-SPM-unit TX household gets exactly $1,500 (no per-person multiplication); a household split into two SPM units gets $750 + $750 (apportioned, total preserved — same behavior as the existing ny_drive_clean_rebate Household-entity entry).
• Proposal↔implementation mapping is defensible and disclosed: the campaign source corroborates $1,500 to "Texas families" funded by a ~$17B ESF draw; the households reading fits the $17B envelope far better than the Census families count. No hard-coded values in formulas; factory/lookahead/bypass/registration all match the CT sibling pattern; modify_parameters stop-date revert confirmed by the 2028 test.
• All 8 tests pass locally; CI fully green.

🟡 Should Address

1. spm_unit_benefits full-copy override is a latent maintenance hazard — policyengine_us/reforms/states/tx/rebate/tx_rebate.py:44-125. The override is a frozen snapshot of a frequently-edited baseline list; when baseline gains a program later, any simulation with this reform active silently reverts it. Precedent exists (Tlaib, BOOST, EDAA reforms do the same), so this is an accepted-if-brittle idiom — at minimum add a comment that the list must be kept in sync with baseline; longer-term, making the baseline list parameter-driven (as household_benefits already is) would let reforms append via modify_parameters instead of copying.
2. 2027 timing and one-time reversion are inferences, not sourced, and amount.yaml doesn't disclose that — policyengine_us/parameters/gov/contrib/states/tx/rebate/amount.yaml:3-6. The cited press release gives no payment year and never says "one-time"; "day one" + the Jan 2027 inauguration is the (reasonable) basis for 2027-01-01: 1_500 / 2028-01-01: 0. The docstring partially discloses this but presents 2027 as fact. Extend the amount.yaml description (and docstring) to mark the 2027 date and the 2028 reversion as modeling inferences.
3. No multi-person or multi-SPM-unit test — policyengine_us/tests/policy/contrib/states/tx/rebate/tx_rebate.yaml. All 8 cases are single-person households, so the central claim ("$1,500 per household regardless of size") and the SPM apportionment have no regression guard. Add (a) a 4-person single-SPM-unit TX case asserting tx_rebate: 1_500 and spm_unit_benefits: 1_500, and (b) a two-SPM-unit case pinning the [750, 750] split so the apportionment is visibly deliberate.
4. No test proves the rebate stacks on real benefits — both SPM cases use $500k income so baseline benefits are zero. A low-income TX case asserting SNAP/SSI remain nonzero alongside tx_rebate: 1_500 would catch any future drift in the copied BENEFITS list (complements item 1).
5. The in_effect: true inputs in every test are inert, and the off state is untested — the YAML reforms: key points at the module-level bypass instance, which skips the 5-year lookahead gate entirely; flipping in_effect: false in a test still pays $1,500. This is the standard contrib-reform test pattern, but consider a comment noting the toggle only gates the production path (create_structural_reforms_from_parameters), and optionally a Python-level test that create_tx_rebate_reform returns None when in_effect is false across the lookahead window.

🟢 Suggestions

1. Reference titles: add the date and source type — e.g. Gina Hinojosa for Texas campaign press release (July 13, 2026) - Money in Your Pocket economic agenda — campaign pages are volatile, and a date anchors which version corroborated the values (amount.yaml:13, in_effect.yaml:11).
2. Show the families→households arithmetic: the docstring asserts the $17B consistency but doesn't show $17B ÷ $1,500 ≈ 11.3M or cite a household count (Census ACS puts TX at ~10.7M households 2019–2023, vs ~11.8M in the PR description). One line plus a citation makes the key assumption self-justifying.
3. Assert the end-to-end net-income effect: Case 3's comment claims net income rises by exactly $1,500 but only asserts benefit aggregates; with fixed income and no TX income tax, household_net_income can be asserted directly. An SPM-poverty integration case (near-threshold household flipping out of poverty) would confirm the resource path has real effect.
4. Tighten absolute_error_margin from 1 to 0.01 — outputs are exact currency values; a margin of 1 masks $1 discrepancies.
5. One-time-ness lives in three coupled places (amount.yaml values, the modify_parameters 2027 window, and the always-on SPM override that's safe only because amount is 0 outside 2027). Changing the payment year requires synchronized edits — worth a comment documenting the coupling.
6. Minor conventions: description placeholder "this amount" rather than "this rebate"; 0000-01-01: 0 in amount.yaml uses the sentinel normally reserved for in_effect (harmless, common practice).

---

Validation Summary

Check	Result
Regulatory accuracy	0 critical, 3 should, 4 suggestions
Reference quality	0 critical, 1 should, 3 suggestions
Code patterns	0 critical, 1 should, 4 suggestions (verbatim-copy check: no drift; 8/8 tests pass)
Test coverage	3 should gaps, 3 suggestions
CI status	All 34 checks passing

(Overlapping findings deduplicated above.)

Next Steps

Non-blocking review — the highest-value pre-merge changes are the spm_unit_benefits sync comment (Should 1), the timing-assumption disclosure (Should 2), and the multi-person/multi-SPM-unit tests (Should 3).

To auto-fix issues: /fix-pr 9037

🤖 Generated with Claude Code

[DTrim99]

Fixes applied (@daphnehanse11 review)

Thanks — no critical issues; applied all should-address items and suggestions.

🟡 Should Address — fixed

1. spm_unit_benefits sync hazard — added a NOTE on the BENEFITS list that it's a frozen verbatim copy of baseline that must be kept in sync (a program added to baseline would be silently dropped otherwise).
2. 2027/2028 disclosed as inferences — the docstring and amount.yaml description now state the payment year and reversion are PolicyEngine inferences (from "day one" + the Jan 2027 inauguration), not stated in the source; also documented the three-place one-time coupling (amount, the modify_parameters window, the always-on SPM override).
3. Multi-person / multi-SPM-unit tests — added Case 9 (4-person single-SPM → $1,500, no per-person multiplication) and Case 10 (two SPM units → [750, 750] apportionment).
4. Stacking test — Case 11 sets snap directly and asserts spm_unit_benefits: 7,500 (snap + rebate), guarding the copied BENEFITS list against drift.
5. in_effect toggle — commented that the module-level bypass instance the YAML tests use skips the lookahead gate; in_effect only gates the production path.

🟢 Suggestions — applied

1. Reference titles now carry the July 13, 2026 date + "campaign press release".
2. Docstring shows the ~$17B / $1,500 ≈ 11.3M households arithmetic with a Census ACS household-count cite.
3. Tightened all absolute_error_margin from 1 to 0.01.
4. One-time coupling documented (see Run black formatting on docs #2).

Notes

• Suggestion 3 (assert household_net_income directly / SPM-poverty case): Case 3's high income makes an exact net-income assertion depend on federal tax computation, which isn't cleanly hand-verifiable; the existing household_benefits: 1,500 assertion already proves the benefit reaches net income. Left as-is.
• Suggestion 6 (0000-01-01 sentinel): kept — it's the standard PE sentinel and harmless.

CI re-running.

[daphnehanse11]

lgtm

[daphnehanse11]

lgtm