Apply the Income Support remunerative work and JSA conditions (s.124(1)(c), (f))

[MaxGhenis]

Fixes #2024

Summary

income_support_eligible did not model two of the SSCBA 1992 s.124(1) conditions:

• (c) "he is not engaged in remunerative work and, if he is a member of a couple, the other member is not so engaged";
• (f) "he is not entitled to a jobseeker's allowance and, if he is a member of a couple, the other member of the couple is not, and the couple are not, entitled to an income-based jobseeker's allowance".

This PR adds both, for the claimant and partner only. It is stacked on #2013, which is stacked on #2001 and #1896, and it keeps #2013's structure: the claimant is whichever of the claimant and partner has the existing award (UC (TP) Regs 2014 reg 6A(1); C&P Regs 1987 reg 4(4)). Retarget to main once those merge.

Law and the rule

(c) Remunerative work.

• Claimant: paid work of at least 16 hours a week (IS Regs 1987 reg 5(1): "not less than 16 hours a week being work for which payment is made or which is done in expectation of payment").
• Partner: 24 hours (reg 5(1A): "In the case of any partner of the claimant paragraph (1) shall have effect as though for the words "16 hours" there were substituted the words "24 hours"").
• Carers: reg 6(4)(c) takes "a person to whom paragraph 4 of Schedule 1B applies" out of remunerative work. That paragraph describes a person (the carer), so it covers a caring partner as well as a caring claimant.
• Candidate claimants: the partner threshold depends on who claims, so the gate tests it for each candidate claimant against the other member of the couple. That stays exact even if a reform puts the partner threshold below the claimant's.

(f) JSA.

• Claimant: must not be entitled to a jobseeker's allowance of either kind.
• Partner, and the couple: must not be entitled to income-based JSA. JSA 1995 s.1(4) counts a joint-claim JSA as income-based. The partner's contribution-based JSA does not bar the claim.

Income-based JSA follows #2013's income-related ESA pattern. It is the award on the claimant's and partner's reported amounts, after the same capital screen as jsa_income, through a new income_related_jsa_award helper that jsa_income now also uses. A jsa_income that holds an award the reported amounts do not give is taken to be theirs. That means neither that award on everyone's reports nor their plain total, which disable_simulated_benefits sets. It covers an award entered directly (when the simulation is built, later, or on a branch) and a reform that removes or replaces jsa_income. The rule reads only the stored value, so no input-provenance tracking is involved. An entered award equal to what the reports give (to within half a penny, compared at the float32 precision the award is stored in) is read through the reports, which say whose it is.

Changes

• income_support_eligible: the two claimant limbs (no remunerative work at 16 hours, no contribution-based JSA) join Apply the Income Support conditions to the claimant and partner only #2013's per-person claimant conjunction, along with the other member's remunerative work at 24 hours. Income-based JSA of either partner bars the claim next to income-related ESA.

• New parameters gov.dwp.income_support.eligibility.remunerative_work.claimant_hours and partner_hours, with their history from legislation.gov.uk point-in-time texts of reg 5:

  Period	Claimant	Partner
  from 11 April 1988 (as made)	24	24
  from 7 April 1992	16	16
  from 7 October 1996 (reg 5(1A) inserted by SI 1996/1944)	16	24

• New income_support_remunerative_work_hours (Person): weekly_hours, a usual week's hours in paid jobs. The Enhanced FRS hours_worked is FRS TOTHOURS (usual weekly hours across current jobs) × 52, and weekly_hours divides by 52. Enter it directly for fluctuating hours, which reg 5(2) and (3B) average over a cycle or recent weeks, and to leave out the reg 6(1) employments that reg 5(6) excludes from the count.

• jsa_income: the screen moves into income_related_jsa_award, unchanged. The JSA active check is inside the helper, so every caller agrees with jsa_income. jsa_income keeps its own early return, so an inactive scheme still reads no reports. The parallel passport-scoping branch (Count only the claimant's and partner's legacy awards in means tests and passports #2027) carries a byte-identical copy.

• No new Simulation machinery. Review rounds 1-3 tried deciding direct entry from core's record of inputs (_user_input_keys), and that proved unsound in policyengine-core 3.32.9: core-built simulations, disk clones, default-named branches, ETERNITY periods, an input-free crash, and O(keys) deletes. Apply the Income Support conditions to the claimant and partner only #2013 and this PR replace it with the value rule above, for ESA and JSA alike; Count only the claimant's and partner's legacy awards in means tests and passports #2027 follows. The core bookkeeping bugs are _user_input_keys drifts from stored values after delete_arrays and clone policyengine-core#559, fixed upstream in Add total wealth #561.

Which reg 5 and 6 rules the model applies

Rule	Status
reg 5(1), (1A): 16 and 24 hours of paid work	modelled
reg 6(4)(c): a Sch 1B para 4 carer, claimant or partner	modelled with is_carer_for_benefits, the same proxy the gate uses for the para 4 category
reg 5(2), (3B): expected weekly hours, or for fluctuating hours the average over a complete recognisable cycle or the five weeks before the claim or a superseding decision (or another more accurate period); a school-year cycle leaves out school holidays and other periods the person is not required to work	approximated by a usual week's hours; enter income_support_remunerative_work_hours directly for cycle or recent-period averages
reg 5(7): paid meal and refreshment time counts	included only so far as survey usual hours include it
reg 5(6) with reg 6(1)(b)-(m): child minding at home, volunteering, training allowance schemes, the self-employment route, retained fire-fighters and similar, councillors, placement carers, sports awards	not identifiable in the data; enter the hours directly
reg 5(3A): days of maternity, paternity, adoption, shared parental, neonatal care or bereavement leave, or illness	not identifiable by day in annual data; enter the hours directly
reg 5(3), (4), (5), (5A): treated as engaged during unexcused or holiday absence, for 7 days of a trade dispute and for the period earnings cover (except earnings disregarded under Sch 8 para 1)	not modelled
reg 6(4)(b): trade disputes, subject to reg 5(4) and (5)	not modelled
reg 6(5)-(8): the four-week run-on, its entitlement-period and joint-claim rules	not modelled

Invariants

These are property-tested. Invariants 1 and 3 hold for every input except at the value convention's boundary. A direct award equal (to within half a penny, at the precision it is stored in) to what the reported amounts give is read through them, so another member's report, or the claimant's own, can change how a direct award is read. The property generators stay off that boundary, and example tests pin it with the intended results.

1. Excluded members. Adding a member who is neither the claimant, the partner nor a child or young person in the family never changes income_support_eligible, whatever that member's work or JSA. The existing Apply the Income Support conditions to the claimant and partner only #2013 property now also draws hours, JSA and a directly entered jsa_income.
2. Differential. income_support_eligible equals an independently written family-by-family reading of the gate. The oracle in test_income_support_eligibility_properties.py now reads (c) and (f), with the JSA tariff and capital limit from the parameters.
3. Monotonicity. Raising any claimant's or partner's hours or JSA never turns an ineligible family eligible, because (c) and (f) only bar a claim. This is a new property.
4. Refactor. jsa_income is unchanged by the helper refactor. On the Enhanced FRS, jsa_income and all 90 other saved arrays are identical in every year 2025-2030.
5. Direct awards by value. The JSA (and ESA) limb depends only on the stored value the simulation reads, so it holds through set_input at any time, deletion, clones and branches. This is covered by example tests, not a property:
   • test_income_support_direct_inputs.py (11 tests): a late set_input, a set_input after the gate was cached, a branch, a late zero overriding reports, an input for another year, a neutralised jsa_income, the raw reported total, large reports compared at storage precision, and the two convention-boundary transitions (an excluded adult's report, or the claimant's own, explaining a direct award);
   • test_entered_directly_lifecycle.py (16 tests): eight cases for both awards, with an excluded adult reporting the award, including an entered award equal to the reports (read through them, as intended).

Tests

• YAML: 23 cases in income_support_work_and_jsa.yaml, each hand-computed from the law. Full YAML suite at the head (da1a798): 1,537 passed.
  • With Apply the Income Support conditions to the claimant and partner only #2013's 8d8673a gate swapped in (all other files from this branch), 8 fail: the lone parent at 16 hours; the partner at 24 hours, with explicit and with inferred roles; the claimant's contribution-based and income-based JSA; both caring partners with contribution-based JSA; the partner's income-based JSA; and a directly entered jsa_income.
  • With this PR's pre-review gate (430bd63), the case with a jsa_income entered for another year fails.
• Direct awards: the 27 tests above pass. With Apply the Income Support conditions to the claimant and partner only #2013's original 8d8673a gate swapped in, 18 of the first 24 fail. The storage-precision test fails on the round-4 gate (bfff081). Apply the Income Support conditions to the claimant and partner only #2013's test_income_support_esa_entered_directly.py passes here too.
• Hypothesis: all three properties pass at the head, with Apply the Income Support conditions to the claimant and partner only #2013's generators (primed and split-couple families, placed children, adults-only excluded members) and direct awards drawn from {0, 4,000}. No total of the reported amounts can equal 4,000.
  • Hypothesis event frequency of "some family eligible", as a share of generated attempts including invalid draws: 55% of the invariance property's 29, 46% of the differential's 26 (25 examples since Apply the Income Support conditions to the claimant and partner only #2013's 79306e7; in Apply the Income Support conditions to the claimant and partner only #2013's mutation runs, the differential at 12 examples missed three seeded defects that it kills at 25), and 46% of the monotonicity property's 13.
  • A separate local run at 150 passing examples per property passed all three at 1ca0ba8, before the value rule.
  • With Apply the Income Support conditions to the claimant and partner only #2013's original gate swapped in, the differential property fails: the shrunk failing family is a single caring award holder with a directly entered income-based JSA.
• Parameter history: test_legacy_benefit_parameters.py checks both thresholds on either side of 7 April 1992 and 7 October 1996.
• pytest (all of policyengine_uk/tests except microsimulation/): 2,052 passed, 19 skipped at 48abd88; 2,036 at 6337f31; 2,024 at fcbec88. At the head (da1a798), the targeted files (properties, direct awards, lifecycle, ESA, parameters, carer premium, code health) pass: 1,740 tests. The value rule removed the Simulation overrides 48abd88 had added, so the head touches no shared simulation code.

Impact (Enhanced FRS 2024-25, real PolicyEngine runs)

Four package states, each run in its own environment on a private copy of the dataset: #2013's head (8d8673a), (c) only, (f) only, and this PR (fcbec88). After review, the current heads were re-run twice: #2013 at 06e186b against this PR at 6337f31, and #2013 at 97b7a1c against this PR at bfff081 (the value rule). Every year 2025-2030 changes by £0 at each step and in the re-run, with all 91 saved arrays identical. That covers Income Support (£0.51bn in 2025; the model pays it until 2025-26), income-related ESA and income-based JSA, Housing Benefit, CTR, Universal Credit, Pension Credit, household net income and poverty.

Why nothing moves:

• No benefit unit eligible before this change has a claimant or partner reporting JSA of either kind, a non-carer claimant working 16 or more hours, or a non-carer partner working 24 or more.
• About 4.7 thousand (weighted) benefit units report Income Support with a non-carer claimant or partner working 16 or more hours. All of them were already ineligible, because the award holder is neither a carer nor a lone parent of a young child (s.124(1)(e)).

The JSON summaries are aggregates. The dataset copies and per-record arrays stay private.

Axiom

axiom: TheAxiomFoundation/rulespec-uk#403 queued (addendum)

The addendum queues s.124(1)(c) and (f), IS Regs regs 5 and 6 and JSA 1995 s.1(4). It has outputs, a review_finding and 24 companion tests: 22 match the YAML cases, and 2 cover the reg 5(4) trade-dispute precedence that PolicyEngine does not model. None of those citations is in the corpus yet. JSA Regs reg 116, which PolicyEngine's income-based JSA screen uses, is encoded-correct (uk/regulations/uksi/1996/207/116.yaml).

Review

Round 1 (Subfleet, GPT-6.1 Sol): REQUEST CHANGES.

1. Blocking: a direct jsa_income was detected through Simulation.input_variables. That missed late or branch inputs and leaked across years. Fixed with entered_directly and regression tests, since superseded by the value rule (round 3). The same defect in Apply the Income Support conditions to the claimant and partner only #2013's ESA fallback was fixed there and merged here.
2. Axiom: reg 6(4)(b) is subject to reg 5(4)-(5). Now explicit in output 9 and the review_finding, with companions 50-51.
3. The hours proxy overstated reg 5(2) averaging, and the table was incomplete. Documentation, table and Axiom counterpart corrected.
4. An inactive JSA scheme read reports before short-circuiting. jsa_income's early return is restored.
5. Boundary and role cases. Added: partner at 23 hours, inferred roles with an excluded grandparent, two caring award holders with contribution-based JSA.
6. Stale Hypothesis statistics. Refreshed.

Round 2 (same reviewer): findings 2, 4, 5 and 6 fixed; 1 and 3 partly fixed, with two new defects found.

1. Blocking: deleting an input left its record, so a later formula result looked direct. Fixed in Simulation.delete_arrays.
2. High: clones and earlier branches shared the input record with their parent. Fixed in Simulation.clone, with entered_directly checking the provenance of the stored value read; both were superseded by the value rule in round 3.
   • Lifecycle tests cover both cases for JSA and ESA.
   • The helper no longer falls back silently when core's record is missing; core ≥ 3.32.9, which pyproject requires, has it.
3. Legal precision: expected weekly hours and the other averaging periods, the Sch 8 para 1 qualification on reg 5(5A), and reg 5(7) and reg 6(7)-(8) in the Axiom brief; companions 50-51 now state the claim.
4. Statistics denominators now count invalid attempts, and the old-gate logs are saved.

Round 3 (same reviewer): REQUEST CHANGES.

• Provenance was unsound. Even with the overrides it failed on core-built simulations, disk clones, default-named branches and ETERNITY periods, crashed on input-free simulations, and made deletes O(keys). Agreed with Apply the Income Support conditions to the claimant and partner only #2013 and Count only the claimant's and partner's legacy awards in means tests and passports #2027: drop it for the value rule, which reads only the stored value. Lifecycle and raw-total tests cover it.
• Legal precision. Done: reg 5(3B)'s excluded periods, reg 5(2)(b)(ii)'s superseding decision, reg 5(7)'s refreshment time, and reg 6(8)'s joint-claim housing-costs amount in the Axiom brief.

Round 4 (same reviewer): REQUEST CHANGES. Round-3 findings 1, 2, 4 and 6 resolved, 5 moot; finding 3 (disk clones share files) is a core storage bug, now PolicyEngine/policyengine-core#558. All round-4 findings are addressed:

1. The float32 stored award was compared with float64 sums, so very large reports looked entered. Both limbs now compare at the stored precision, with regressions in both test files.
2. The invariants were overclaimed. They are now stated with the convention's boundary in the variable documentation, the property module and here, and the boundary transitions are pinned as intended behaviour.
3. The reg 5 table wording now carries reg 5(3B)'s excluded periods and the superseding decision.

🤖 Generated with Claude Code