Apply the Income Support conditions to the claimant and partner only

[MaxGhenis]

Fixes #2023

Summary

income_support_eligible applied three Income Support conditions to every member of the benefit unit. SSCBA 1992 s.124(1) names only the claimant and, for some conditions, the partner. This PR applies each condition to the people the law names. It is stacked on #2001, which is stacked on #1896, so it stays a draft until they merge.

The independent review of #2001 found the three defects (finding 2). They reproduce on #2001's head (63b633c). In each case a caring single claimant has one extra adult in the benefit unit with is_claimant_or_partner: false:

Extra adult	Before	After	Law
Aged 70	not eligible	eligible	s.124(1)(aa): "he has not attained the qualifying age for state pension credit"
Reports £5,000 income-related ESA	not eligible	eligible	s.124(1)(h): "he is not entitled to an employment and support allowance and, if he is a member of a couple, the other member of the couple is not entitled to an income-related employment and support allowance"
Reports Income Support; the claimant does not	eligible	not eligible	No new claims (UC (Transitional Provisions) Regs 2014 reg 6A(1)), so the award must be the claimant's

What changed

The claimant is the partner with the existing award. Three provisions combine:

• UC (TP) Regs 2014 reg 6A(1): "a person may not make a claim for housing benefit, income support, or a tax credit". This has been in force since 25 July 2022, and the 2025 text is the same.
• Claims and Payments Regs 1987 reg 4(3): a couple choose which of them claims.
• Reg 4(4): a partner who takes over an award does so by claiming: "where one of a couple is entitled to income support under an award and, with his agreement, his partner claims income support that entitlement shall terminate".

The model takes the award holder to be the claimant or partner who reports Income Support. That is a model convention: if both report it, either can be the claimant. That person must:

• be under state pension age (s.124(1)(aa); SPCA 2002 s.1(6));
• fall within a prescribed category the model covers (s.124(1)(e), reg 4ZA, Sch 1B):
  • para 1, a lone parent of a young child;
  • para 2, new here: "a single claimant or a lone parent with whom a child is placed" by a local authority, using is_looked_after_by_local_authority as the proxy;
  • para 4, a carer;
• have no ESA of either kind (s.124(1)(h), first limb).

In addition:

• Income-related ESA. Neither the claimant nor the partner may have income-related ESA (s.124(1)(h), second limb). An income-related award covers the couple, so it bars Income Support whichever partner has it. The model reads it as the award on their reported amounts after the esa_income capital test. Both calculations share one helper, income_related_esa_award.
• ESA the reports do not explain. The gate looks at the value of esa_income:
  • Reads the reports. If the value is what the reported awards give, the gate reads the claimant's and partner's reports. That means either the award after the capital test (the formula) or their plain total (the disable_simulated_benefits reform).
  • Treats it as theirs. Any other value is taken to be the claimant's or partner's award: one entered directly, or one set by a reform that replaces or removes the variable.
  • Effect. Another member's reported ESA cannot switch this off, and neutralising esa_income (abolishing income-related ESA) removes the bar.
  • Intended boundary. An entered award equal to what the reports give is read through them. The comparison is to within half a penny, in the float32 precision esa_income is stored in. So another member's report can change how a direct entry is read: £4,000 entered with no reports bars the claim, but if an excluded adult also reports £4,000 it does not.
  • Earlier attempts. One decided by whether esa_income was a simulation input, using core's record of inputs (_user_input_keys). Reviews of this PR and Apply the Income Support remunerative work and JSA conditions (s.124(1)(c), (f)) #2025 showed that record goes wrong across delete_arrays, clone, disk storage and core-built simulations. A UK Simulation built with no inputs (for example from a Scenario alone) has no record at all, and the gate raised AttributeError. That approach is gone, and simulation.py is unchanged by this PR.
• Capital. The capital test is unchanged.
• Placed children. youngest_child_age_for_legacy_benefits now leaves out a child flagged is_looked_after_by_local_authority. That flag is the model's proxy for a child placed with the family, or living away in a local authority's care, who is not a member of the claimant's household (IS Regs 1987 reg 16(4)-(6)). Such a child is no longer a "young child" for para 1, but brings a single claimant within para 2.

Four behaviour changes come from reading the conditions as written. All four move £0 on the Enhanced FRS (below).

1. A mixed-age couple keeps Income Support when the younger partner has the award.
   • Before, the gate barred the claim if any member was over state pension age.
   • s.124(1)(g) bars it only if the partner "is entitled to state pension credit". SPCA 2002 s.4(1A): "A claimant is not entitled to state pension credit if he is a member of a couple the other member of which has not attained the qualifying age".
   • is_pension_credit_eligible already requires every claimant and partner to be over state pension age; it does not model the SI 2019/37 art. 4 savings. So (g) holds in the model whenever the claimant is under that age.
   • Reading Pension Credit in the gate would create a dependency cycle. I reproduced it with a synthetic mixed-age family working 30 hours in 2024: income_support_eligible → is_pension_credit_eligible → is_guarantee_credit_eligible → pension_credit_income → working_tax_credit → wtc_entitlement → tax_credits → working_tax_credit_pre_minimum → tax_credits_reduction → tax_credits_applicable_income → income_support → income_support_entitlement → income_support_eligible.
2. The claimant's own contributory ESA bars the claim (s.124(1)(h): "not entitled to an employment and support allowance", of either kind; WRA 2007 s.1(7) defines both kinds). Before, the gate checked only income-related ESA. A partner's contributory ESA does not bar the claim.
3. A partner cannot take over the other partner's award.
   • A carer cannot take over a non-caring partner's award.
   • A younger carer cannot take over an older partner's.
   • Pay the legacy carer premium per qualifying claimant or partner; IS carer route through them only #2001's case "IS carer route when the partner is the carer" now puts the award on the caring partner.
4. A single claimant with a placed child qualifies through para 2. This includes a lone parent whose only young child is placed.

Fix at the gate, not in esa_income's summation

esa_income sums every member's esa_income_reported. I checked all of its readers (git grep -nw esa_income -- policyengine_uk) before deciding where to make the fix:

• Income and spending totals. An excluded member's own award is still real money in these: esa, household_benefits, hbai_benefits, hbai_household_net_income, gov_spending, pre_budget_change_household_benefits, the disable_simulated_benefits reform and benefit_cap_reduction.
• Means tests and passports. These use the benefit unit's award as income or as a qualifying benefit:
  • housing_benefit_applicable_income and council_tax_reduction_applicable_income, through add_for_members, which adds benefit-unit variables as they are;
  • council_tax_reduction_relevant_income_based_benefit;
  • the CTR non-dependant exemption in _legacy.py;
  • the exempt-benefit passport in tax_credits_applicable_income;
  • is_scp_eligible;
  • maintenance_loan_entitled_to_benefits;
  • is_benefit_cap_exempt_health_disability;
  • the qualifying-benefit lists for targeted childcare, cost of living, Winter Fuel and PAWHP.
• Unused reads. is_benefit_cap_exempt_earnings and is_benefit_cap_exempt_other compute an esa_income sum but do not use it in their result.

Restricting the sum would remove an excluded member's award from household income. So the fix is in the Income Support gate. The other means-test and passport readers keep their current behaviour; whether each should count only the claimant's and partner's award depends on its own rules, and is a follow-up.

would_claim_IS still reads every member's report. That cannot change eligibility, because the gate now needs the claimant's or partner's own report.

Not changed: s.124(1)(c) (remunerative work) and (f) (JSA) are not gates here. #2025, stacked on this PR, adds them.

Invariants

• No excluded-adult effect. Adding an adult who is neither the claimant, the partner nor a young person in the family never changes income_support_eligible. Their age, ESA, Income Support and caring do not matter. There is one declared exception: a directly entered esa_income that the new adult's report makes equal to what the reports give. That entry is then read through the reports, and a test pins it.

• Matches a family-by-family reading of the gate (differential test). income_support_eligible is true exactly when:

  • one of the claimant and partner reports Income Support, is under state pension age, is in a covered prescribed category and has no contributory ESA;
  • neither has income-related ESA (on their reported amounts after the capital test, or an esa_income the reports do not explain);
  • capital is within the limit.

  This checks the bounded model gate, not legal entitlement. Caring is is_carer_for_benefits (receipt or 35+ hours), ESA and Income Support are reported awards, placement is a proxy flag, the other Sch 1B categories are not modelled, and the means test is out of scope.

Tests

• YAML. income_support_claimant_partner_gates.yaml has 23 cases, and Pay the legacy carer premium per qualifying claimant or partner; IS carer route through them only #2001's income_support_carer_route.yaml puts the award on the caring partner.

  • Expectations are worked from the law within the model's bounded gate.
  • Of the 27 cases across the two files, 11 fail on Pay the legacy carer premium per qualifying claimant or partner; IS carer route through them only #2001's formula and 6 on this PR's first head (5bbbc3c).

• test_income_support_esa_entered_directly.py (15 tests) covers:

  • an esa_income entered in the situation, set after construction, set on a branch or a clone, or entered for another year;
  • a deleted input, and nested branches;
  • a zero entry, a neutralised esa_income, and the plain reported total with a binding capital test;
  • the intended equal-value case, and a report that changes how an entry is read;
  • large awards compared in the stored float32 precision;
  • a simulation with no inputs.

• Hypothesis: test_income_support_eligibility_properties.py. Both properties run 25 examples, about 70 seconds together.

  • Invariance. The added adult is not in education. Most are primed with what used to bar or open the claim when every member counted: over state pension age, income-related ESA, an Income Support report, or caring. The test checks that the model gives that adult no role in the family.

  • Differential. It reads the gate family by family. Families include:

    • primed carers;
    • lone parents of older children;
    • split couples, where the award holder fails a condition and the qualifying partner has no award;
    • children placed by a local authority;
    • capital entered as assessable capital or household savings;
    • directly entered ESA (£0 or £4,000; £4,000 is never a report total).

  • Mutation check. Four deliberately broken gates, with properties run without shrinking:

    Mutant	IS YAML failures	ESA regression failures	Invariance	Differential
    Award and conditions on any partner	2	0	pass	fail
    ESA reports from every member	3	10	fail	fail
    Direct esa_income ignored	3	8	pass	fail
    Any member over state pension age bars	4	0	fail	fail

    At 12 examples, the differential passed the first three mutants, so it now runs 25. Logs: ~/reviews/is-eligibility-gates-2026-10-01/mutants/ (RESULTS.md).

• Full suites at 97b7a1c. YAML: 1,514 passed. pytest: 2,032 passed, 45 skipped. Later commits only change:

  • the differential example count;
  • comments;
  • the float32 comparison;
  • documentation;
  • two ESA regression tests.

  The targeted suites pass at the head.

Enhanced FRS impact: £0 in every year

These are real microsimulation runs on private copies of the Enhanced FRS 2024-25 (sha256 e433e532…). Each package state was run for 2025 to 2030:

1. Pay the legacy carer premium per qualifying claimant or partner; IS carer route through them only #2001's head;
2. the three gates restricted to the claimant and partner;
3. step 2 plus either partner as claimant;
4. 973cfba;
5. 8d8673a;
6. 06e186b;
7. 97b7a1c;
8. 3402629, this head's logic. Later commits are tests and comments only.

Every step changes nothing. Income Support, Housing Benefit, council tax reduction, Universal Credit, Pension Credit, esa_income, household net income and poverty are identical, and no benefit unit's eligibility changes. Income Support is £0.51bn in 2025 and £0 from 2026, when the model stops paying it.

Why nothing moves (base run, 2025):

• Excluded members. About 18k people are neither claimant, partner nor dependant. None of them is over state pension age, has ESA or reports Income Support.
• Mixed-age couples. No mixed-age couple reports Income Support. No benefit unit in which the claimant or partner reports Income Support has any member over state pension age.
• Award holder. In every eligible benefit unit, the claimant or partner who reports Income Support is the one who meets the conditions.
• Contributory ESA. About 3k benefit units (weighted) report Income Support with a claimant or partner on contributory ESA. None of them has a carer claimant or partner, and none is a lone parent, so they were already ineligible.
• Placed children. The dataset has no is_looked_after_by_local_authority or esa_income column, so para 2 and the direct-ESA rule cannot move it.

So this PR corrects household calculations and non-standard benefit units; it does not move published totals.

The scripts are in ~/reviews/is-eligibility-gates-2026-10-01/impact/. Only the JSON summaries and the figures here are aggregates; the dataset copies and the per-record arrays the scripts save stay private.

Axiom

axiom: TheAxiomFoundation/rulespec-uk#403 queued (addendum, updated for the award-holder rule and Sch 1B para 2). It adds the following to the s.124 module that issue already queues, with companion cases 17-33:

• s.124(1)(aa), (g) and (h);
• UC (TP) Regs 2014 reg 6A and C&P reg 4(4);
• Sch 1B paras 1, 2 and 4 as the covered categories.

SPCA 2002 s.1(6) qualifying age is encoded-correct in uk/statutes/ukpga/2002/16/1.yaml. The corpus does not yet hold s.124, SPCA s.4, WRA 2007 s.1 or UC (TP) reg 6A, so the encoder path is blocked until they are ingested.

Follow-ups

• Other readers of the benefit-unit awards esa_income, jsa_income and income_support (the means tests and passports listed above, plus would_claim_IS) still count an excluded member's award. Each needs checking against its own rules.
• s.124(1)(c) (remunerative work) and (f) (JSA) are not modelled here; Apply the Income Support remunerative work and JSA conditions (s.124(1)(c), (f)) #2025, stacked on this PR, adds them.
• The other Sch 1B categories are not modelled, including para 2A (placement for adoption).

Merge

This PR is stacked on #2001, which is stacked on #1896. PE-UK CI runs only on PRs into main, so checks start once both have merged and this PR is retargeted (gh pr edit 2013 --base main, then gh pr ready 2013).

🤖 Generated with Claude Code