Repository navigation
Conversation
Sum each state's regular LIHEAP payment in a new liheap variable, add an Illinois regular heating payment without crisis assistance, add a Michigan Home Heating Credit registry entry, and record each state's cooling treatment in its registry note. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Add regular_payments.yaml to the aggregate-list integrity test, which checks that each member exists, is state-gated and is not dropped between year blocks. Say that Rhode Island plans no regular cooling payment, since its FY2027 plan still allows a leftover-funds cooling grant. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… rent Plan item 3.3 makes these renters eligible. Rewords the energy account comments, adds an in-rent renter case, and checks the national liheap total. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The national `liheap` total evaluates every state's formula over a mixed-state population, which no household test does. Two patterns on main raised errors there: - 26 formula files passed options=[ADD] to an entity call. Core's Microsimulation.calculate_add rejects the keyword an entity call passes. The option is redundant: a plain read already sums a monthly variable over the year through the same Core function. - The DC and Illinois payment formulas look up a matrix by an income level that is 0 for households outside the state. Add the floor Maryland and Kansas already use. Also: - Reword the North Dakota registry note: the state reserves an optional direct cooling payment, so its cooling component is not only equipment. - Add a `liheap` case with Texas, DC and Illinois households in one simulation. - Add a code-health check against options=[ADD] and options=[DIVIDE]. - Check that every state payment in the LIHEAP registry entry is in the list `liheap` sums. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
PolicyEngine/policyengine-core#647 fixes the cause in Core: it lets a Microsimulation accept the keyword an entity call passes with options=[ADD] or options=[DIVIDE]. Once that is released the option works again, so a check that bans it here would be wrong. The 26 formula files stay without the option, which was redundant and lets `liheap` run on today's Core. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ogram prefix Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PR Review: Add Arkansas LIHEAP summer regular cooling assistanceReviewed at head SummaryThe cooling payment itself is right. Arkansas pays one Regular benefit in winter and one in summer, the summer benefit is electric only, and it comes from the same Electricity matrix as electric heat. The two new variables read the right cells for FY2025 and FY2026, the national total can sum both seasons, and the new test files pass in CI. The income-limit cap is also right in its arithmetic. Every figure in the body matches HHS's published Arkansas amounts for FY2025 and FY2026 and 150% of the guideline, and the change follows the pattern already on main for West Virginia and Oregon. What blocks approval:
Counts: 1 critical, 3 should, 5 suggestions. Critical (must fix)1. CI fails on an existing heating test the cap changes:
Should address1. FY2025 cooling amounts rest on a source conflict the PR neither records nor mentions.
2.
3. Three terms of the rent route have no test that would fail without them (by my reading).
Every other new term is pinned; see "Verified correct". Suggestions
Verified correctSummer Regular benefit exists and is separate from heating (sources read directly).
Both seasons in one year. Manual section 3.3, page 46: "An approved household's eligibility will continue for the entire program season (Winter or Summer). Unless otherwise specified, only one Crisis and one Regular benefit can be approved for each household for each season." One winter and one summer Regular benefit is what the rule allows, so listing both Amount and fiscal years.
Hand-checked expectations (from the printed tables).
The income-limit cap.
Eligibility.
Mutation coverage (by my reading). Size above zero: eligible Case 3. Income limit, inclusive: eligible Case 1. Cooling cost: eligible Case 2, unit 2. Electric bill: Case 2, unit 3. Rent route present: Case 5, unit 1. Subsidized exclusion (housing assistance): Case 5, unit 2. UNSPECIFIED: Case 4. NONE and other fuels paid: cooling Case 5. Band and size-group lookups: cooling Cases 1-3. FY2025 cells: cooling Case 4. The National total and registry. The new list entry is a dollar amount on the SPM unit, yearly, gated to Arkansas through Mixed-state and periods. No state-gated value is used as a parameter key. For a non-resident the formula sees countable income 0 and size 0, which give band 1 and size group 1, both present in the matrix. All new variables are yearly; the rent read uses Hygiene. Both new variables have label, reference, Axiom line assessment
CI statusRe-checked at the end: 26 pass, 1 fail, 1 skipped (Contrib tests). None pending.
Branch status
Verdict: REQUEST_CHANGES |
DTrim99
left a comment
There was a problem hiding this comment.
Requesting changes. The cooling payment itself is right: Arkansas pays one Regular benefit in winter and one in summer, the summer benefit is electric only from the Electricity matrix, and the parameter matches both printed matrices cell for cell. The income-limit cap's arithmetic is also right against HHS's Arkansas figures for FY2025 and FY2026. What blocks:
- CI fails, and this PR causes it (Critical 1). The cap changes an existing heating case the PR did not update:
ar_liheap_eligible.yamlCase 6 (FY2025, seven people, $71,016) expects eligible, and the capped limit is $71,010. Baseline (states-shard-3) reports[1. 0. 0.] differs from [1. 1. 0.]; main passes that job. The description's "No case changes eligibility or payment" needs correcting too. - An unrecorded FY2025 source conflict. The FY2025 plan's item 3.6 gives a cooling range of $50 to $287, and the PR pays $60 to $344 from the posted matrix. Main already has
us-ar:liheap-fy2025-benefit-matrixfor the heating side; extend it to the new reader and cite item 3.6. has_cooling_expenseis required from bill payers with no Arkansas source, and the comment presents it as the state's energy-burden rule. Label it a convention or drop it for bill payers.- Three terms of the rent route are pinned by no test (
~tenant_pays_utilities,rent > 0,is_in_public_housing), by my reading.
Fixes and worked households are in the report above.
Addresses DTrim99's round-1 review; upstream main merged first. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Thanks, David. This push, head Critical
Should address
Suggestions
The body and TheAxiomFoundation/rulespec-us#2183 are updated: the head, test counts, interpretations 2 to 8 and 11, companion tests 6, 8 and 10, and a new companion test 13 for Case 6. Tests were not run locally. CI is running at |
Adds Arkansas's summer regular LIHEAP benefit, paid from the existing Electricity matrix.
Fixes #10743
Builds on the national LIHEAP total from #10730, merged on 2026-11-12: this PR adds
ar_liheap_coolingtogov.hhs.liheap.regular_payments.What and why
The adopted FFY 2025 Policy and Procedures Manual says the Regular program "is available during both winter and summer application periods" and "Only electric benefits are available during the Summer Program" (section 2.1, p. 29). It lists the "Electricity Matrix: used for both Winter and Summer Regular Assistance" (section 6.1, p. 78) and allows "one Crisis and one Regular benefit ... for each household for each season" (section 3.3, p. 46). No FY2026 manual was found. The FY2026 plan's cooling section uses the heating income limits (item 3.1) and gives a $60 to $344 range (item 3.6), exactly the range of the FY2026 Electric matrix. The FY2025 plan's item 3.6 gives $50 to $287; the posted FFY 2025 electric matrix, headed "20% OVER BASE", pays $60 to $344. Summer follows the matrix, as the winter benefit does; candidate
us-ar:liheap-fy2025-benefit-matrixnow listsar_liheap_coolingand cites item 3.6.ar_liheap_cooling_eligible: heating's household size and income limit, plus eitherhas_cooling_expensewith a positive electricity bill, or utilities included in unsubsidized rent. Plan item 3.3 (p. 12): "Unsubsidized households with utilities included in their rent may be eligible for LIHEAP assistance if they meet other criteria".ar_liheap_cooling: the Electricity matrix cell for the household's monthly income band and size group, from the same parameters as the winter grant. The amount is fixed, not capped at the bill.heating_type: every value, including NONE and UNSPECIFIED, can be paid.ar_liheap_income_limit, which heating and cooling share, rounds each monthly chart limit to the nearest dollar. That put several annual limits a few dollars above the greater of HHS's 60% state median income amount and 150% of the poverty guideline, the most 42 U.S.C. 8624(b)(2)(B) allows. Each limit now stops there:has_cooling_expenseis required from bill payers. This is a PolicyEngine convention with no Arkansas source: Arkansas's energy burden is a utility bill the household receives (manual section 4.8.1). Unsubsidized renters whose utilities are included in rent need no cooling cost; they are identified by the existingtenant_pays_utilitiesinput (false) with positiverent; no input is added.Test plan
Tests were not run locally. This PR now targets
main, so CI runs them.liheaptotal.ar_liheap_income_limit.yaml,ar_liheap.yaml,integration.yaml). One existing case changes eligibility:ar_liheap_eligible.yamlCase 6 (FY2025, seven people, $71,016) is now ineligible because the capped limit is $71,010; its inputs are kept.us-ar:liheap-income-limit-above-federal-ceiling(ruled) records the cap; the code follows the statute. Candidateus-ar:liheap-fy2025-benefit-matrix(unreviewed) now covers the summer reader.make format(ruff)changelog.d/Not modeled
axiom: TheAxiomFoundation/rulespec-us#2183 queued
🤖 Generated with Claude Code