Skip to content

Read and apply the legacy closure for the claimant and partner only #2395

Open

Description

@MaxGhenis

Follow-up from #2031 (and #2119). Out of #2031's scope, which keeps #2119's behaviour unchanged.

What the model does

legacy_benefits_closed (from #2119) decides closure from every member of the benefit unit. Its reports(...) helper is add(benunit, period, [...]) > 0, which sums all members' reports. When it is true:

This has two consequences for a member of the benefit unit who is neither the claimant nor the partner, such as a non-dependent adult who claims in their own right:

  1. Their own report of a closed legacy benefit closes the couple's legacy benefits. For example, a report of income-based JSA once gov.dwp.JSA.income.active is false ends the couple's income-related ESA.
  2. The claimant's or partner's closure ends that member's own award and status.

What the law says

SI 2014/1230:

  • Reg 44(1) issues the migration notice "to a person who is entitled to an award of an existing benefit", informing them that "all awards of any existing benefits to which they are entitled are to terminate".
  • Reg 44(4) also issues it to the other member of a couple.
  • Reg 46(1), where the notified person makes no claim, terminates "all awards of any existing benefits to which the person is entitled".

Nothing extends a notice to a non-dependant claiming in their own right, or makes their notice end the couple's awards.

Proposed change

  • Read the closure from the claimant's and partner's reports only. For example, use add_for_members(..., is_claimant_or_partner), as meets_pension_credit_age_conditions does for UC reports.
  • Apply it to their awards only.
  • Give an outside member their own closure, from their own reports.

That would let #2031's invariant ("an outside member never changes the couple's screen") hold without the closure exception. It would also let an outside member's status follow their own claim.

Size

In the Enhanced FRS 2024-25 runs for #2031, no record has anyone outside the couple reporting income-related ESA or income-based JSA in 2025-2030, so the ESA and JSA figures there are unaffected. Reports of Income Support or tax credits by such members were not counted.

Tests to update

policyengine_uk/tests/legacy_award_work_reference.py (legacy_benefits_closed) and test_legacy_award_work_properties.py::test_member_outside_the_family_never_changes_the_couples_screen encode the current reading. So do the two YAML cases "A non-dependent adult's own ESA/JSA ends once the family's legacy benefits have closed" in the ESA and JSA remunerative-work files.

Activity

  1. MaxGhenis commented on Oct 13, 2026

    @MaxGhenis
    CollaboratorAuthor

    Independent reproduction on main 1d3abecef (2026-10-13). It was found by review r3 of #2261, which does not touch the closure.

    Synthetic benefit unit in London in 2027: a claimant aged 30 who reports £5,000 of income-related ESA, and another adult aged 40 (is_claimant_or_partner: false).

    Other adult reports legacy_benefits_closed esa_income (claimant's own award)
    nothing false £5,000
    £1,000 of Income Support true £0
    £1,000 of income-based JSA true £0

    So the Income Support report closes the couple's legacy benefits in the same way as the JSA example above. Script: repro_legacy_benefits_closed.py (synthetic households only).

    On size, for the gap noted under "Size": #2261's Enhanced FRS 2024-25 runs (base 1d3abecef) also counted Income Support reports. No member outside the couple and its dependants reports Income Support, income-based JSA or income-related ESA in any year 2025-2030. That is about 18,000 people (weighted), in 74 survey benefit units. Tax credit and Pension Credit reports by such members were not counted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions