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. #2013 (with #2001 and #1896) has merged, and this PR now targets main. 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)). It also keeps the conditions main has added since: the claimant's age test on the State Pension Credit qualifying age (s.124(1)(aa)) and the s.124(1)(g) bar where the couple is taken to be on State Pension Credit.

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. A stored award (entered directly or replaced by a reform) 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. An award within half a penny of zero is no award, as main now does for ESA. So a stored zero never bars the claim, and nor does the float residual of reports that exactly match the tariff income (£10.01 + £41.99 against £52).

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 and main's s.124(1)(g) Pension Credit bar.

• 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; a fix is open as 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 stored award (entered directly or replaced by a reform) 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 such an 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, alongside main's qualifying age and Pension Credit proxy, which it reads from the model as the gate does.
3. Monotonicity. Raising any claimant's or partner's hours or JSA never turns an ineligible family eligible. (c) and (f) only bar a claim. The one other path is main's s.124(1)(g) proxy: reported income-based JSA can end the Housing Benefit route to the inferred SI 2019/37 saving when neither member reports Pension Credit, which can lift the (g) bar. That route already fails when either member reports Income Support, so this happens only for a couple in which neither does. Such a family has no award holder and is never eligible. This is a new property.
4. Refactor. jsa_income is unchanged by the helper refactor. On the Enhanced FRS, jsa_income and every other saved array (92 in the run against current main) 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 (17 tests), including the half-penny tolerance endpoints (£100.004 vs £100.006 against a direct £100), a stored zero that never bars the claim, three half-penny zero cases (the formula's own residual; £0.003 vs £0.006 entered; the couple's residual beside another member's £3,000) and the couple's award tolerance (£52.004 vs £52.006 against £52 of tariff income). It also covers 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. At f159918 (after merging main twice; the head, 198adea, changes only a docstring since), the finance/benefit and gov YAML folders pass: 2,474 cases (2,439 at de0ece0, before main's Model a Universal Credit claim by a member of a couple as a single person (UC Regs 2013 reg 3(3)) #2084 added its Universal Credit single-claim cases). Main's s.124(1)(g) and qualifying-age cases in income_support_claimant_partner_gates.yaml pass with this PR's conditions.
  • 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 33 tests above pass. Reverting the JSA zero guard to an exact zero fails all three new half-penny tests. 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, with one new test that pins the ESA couple's award tolerance the same way. Setting either couple's-award guard (JSA or ESA) to > 0 fails its new tolerance test at the eligibility assertion.
• Hypothesis: all three properties pass at f159918, 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, at de0ece0: 44% of the invariance property's 25, 59% of the differential's 27 (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 two 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.
  • test_direct_awards_match_the_reference_deterministically checks both direct-award modes against the oracle for a fixed carer, because random draws reach them only some of the time. It kills a mutant that ignores direct ESA, which the 25-example differential let survive in review round 5.
  • 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 081ec14, the targeted files (properties, direct awards, lifecycle, ESA, parameters, carer premium, code health) passed: 1,745 tests. At f159918, the properties, direct-award, lifecycle, ESA and parameter files pass: 60 tests (58 at de0ece0 and 195c719, before the two tolerance 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)

Against current main. This PR at 195c719 was run against main at the merged commit (9f92d53), each package state in its own environment on a fresh private copy of the dataset (sha256 e433e532…). Every year 2025-2030 changes by £0, with all 92 saved arrays identical in every year. The same comparison at the first merge of main (de0ece0 against f1a9a3c) also gave £0, with all 92 arrays identical. The head (198adea) changes only test files since 195c719, so this run covers its code. 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.

Earlier runs. Four package states: #2013's head (8d8673a), (c) only, (f) only, and this PR (fcbec88). After review, the 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). Each step and each re-run was £0 in every year, with all 91 saved arrays identical.

Why nothing moves (2025, base run on main):

• No benefit unit eligible on main 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. None of them is eligible on main. None has a caring award holder or is a lone parent of a child aged 5 or under, the two prescribed categories (s.124(1)(e)) the diagnostic checks; it does not check Sch 1B para 2 (a placed child).

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.

Round 5 (same reviewer): APPROVE WITH NITS. No runtime defects; the precision fix is confirmed in both limbs and the merges lost nothing from #2013. The nits are addressed:

1. The documentation, the property module and the Axiom summary state the convention for any stored award (entered or reform-replaced) with the half-penny tolerance after storage rounding; the tolerance endpoints are tested.
2. The mutation count now matches the saved logs (two, not three).
3. A deterministic oracle check covers both direct-award modes.

After round 5: merged #2013's 0953c8a, which limits Sch 1B para 2 to placed children under 16 and guards the ESA bar so a stored zero never bars the claim. The JSA limb now has the same guard, pinned by test_a_stored_zero_never_bars_the_claim, which fails on the previous gate.

Round 6b (confirmatory, delta da1a798..081ec14): APPROVE WITH NITS. No runtime defect, and nothing from #2013's merge was lost. The two PR-body nits (a stale Hypothesis statistic; two sentences that described only entered awards) are fixed above. Its informational finding 4, that the zero guard caught only an exact zero so a float residual of the reports still barred the claim, is fixed by the half-penny rule below.

After merging main (de0ece0): two conflicts, in the gate and the property module. Kept this PR's rule and main's qualifying-age test, s.124(1)(g) bar and half-penny ESA zero guard (#2013's after-merge review). The JSA limb now treats an amount within half a penny of zero as no award too, with three new tests. That is the one change beyond a mechanical merge, and an independent review of it is recorded below.

After merging main again (195c719): main's #2084 (a Universal Credit single claim by a member of a couple) merged without conflicts. It changes no Income Support, JSA or ESA code. The tests and the impact comparison above were rerun at that commit.

vahid-ahmadi's review (at 081ec14): both points are done. The merge of main (de0ece0) takes main's has_attained_state_pension_credit_qualifying_age for the claimant's age test and keeps main's s.124(1)(g) on_pension_credit bar. The 23 YAML cases and the property tests pass with them, and the summary no longer describes a stack.

After-merge review (Subfleet job 20261008-123448-is-work-jsa-review-after-merge, Opus 5.5, at de0ece0): APPROVE WITH NITS. No runtime defect. Nothing from either side of the merge was lost, and the JSA half-penny guard has the ESA limb's form and is right in law and in code. Its findings are addressed:

1. The monotonicity docstrings now give the s.124(1)(g) path (f159918, narrowed in 198adea).
2. This review record replaces a placeholder.
3. core#561 is described as open, not merged.
4. The tests and impact are stated at the commits they ran on.
5. The diagnostic's coverage is stated exactly (it does not check Sch 1B para 2).
6. Two wording fixes in this body.
7. Couple's-award tolerance tests at £52.004 and £52.006 for JSA and ESA (f159918). Setting either couple's-award guard to > 0 fails its test.
8. The formula's-residual test cross-references core's float64 sum (f159918).
9. The JSA and ESA limbs differ by design from 2026, when income-based JSA is inactive. That comes from round 1's active check, not from this delta, and belongs with a separate follow-up that fixes the disable_simulated_benefits reform.

Confirmatory review (Subfleet job 20261008-184614-is-work-jsa-review-after-merge-r2, GPT-6.1 Sol, delta 195c719..f159918): APPROVE WITH NITS, safe to merge.

• It confirmed that 195c719 is a clean merge (no file differs from both parents) and that f159918 touches test files only.
• It confirmed the float64 explanation and the monotonicity argument against the gate, the Pension Credit saving and core 3.32.13.
• It reran test_income_support_direct_inputs.py and test_income_support_esa_entered_directly.py (37 passed) and both mutants (each fails at assert eligible(below) after its preconditions pass).
• Its one finding was that the (g) sentence overstated when the saving ends, because reported Pension Credit keeps it on its own. 198adea narrows the docstring to the Housing Benefit route, and invariant 3 above says the same.

🤖 Generated with Claude Code

[vahid-ahmadi]

Thanks Max. This reads s.124(1)(c) and (f) correctly:

• 16 hours for the claimant (IS Regs reg 5(1)) and 24 for the partner (reg 5(1A): "as though for the words '16 hours' there were substituted the words '24 hours'");
• carers are taken out of remunerative work whether they are the claimant or the partner (reg 6(4)(c): "a person to whom paragraph 4 of Schedule 1B applies");
• the partner's JSA bars the claim only if it is income-based ("the other member of the couple is not, and the couple are not, entitled to an income-based jobseeker's allowance").

Verified at 081ec14:

• Law: the point-in-time texts of reg 5 give 24 hours on 6 April 1992, 16 from 7 April 1992, and (1A) in force at 7 October 1996, so both parameter histories are right. (The current page's F1 note on reg 5(1) is mislabelled, but the values hold.)
• Tests: the income_support YAML passes 86/86. Lifecycle 16/16, direct inputs 13/13, properties 4/4, parameters 3/3.
• Probes for 2025, comparing #2013's head with this one:
  • A lone parent with a 3-year-old is still eligible at 15 hours. At 16 hours she becomes ineligible (#2013 left her eligible).
  • A carer claimant whose partner works 23 hours is eligible; at 24 hours, ineligible.
  • A partner who is a carer and works 30 hours does not bar the claim.
  • A partner on contribution-based JSA leaves Income Support at £10,663.43, the same as on #2013.
• Merges cleanly with #2027 and #2075. The body gives aggregates only.

1. Should fix (inherited from #2013, but this PR carries the same gate): #2013 conflicts with main in income_support_eligible.py and income_support_carer_route.yaml. The cause is #2001, which merged on 4 Oct. In the rebase:
   • income_support_eligible.py:101 should take main's has_attained_state_pension_credit_qualifying_age, not is_SP_age.
   • Decide the s.124(1)(g) limb. Main keeps on_pension_credit (main :52-61); the stack drops it.
   • Then re-run the 23 cases and the three properties.
2. Nit: #2001 and #1896 have both merged, so update the stack line in the body: this is now stacked only on #2013.