Repository navigation
Limit same-person carer benefit awards within couples - #2632
Merged
Merged
Conversation
Contributor
Aggregate impact on certified data: passBase Checks: 0 broken by this change, 1 failing on both sides, 0 fixed. Moves flagged for review: 0 (thresholds in Notes
Moves flagged for reviewNone. Spending by benefit and service
Caseloads
Standard reform costings (change in gov_balance)
Standard reforms: change in each reform's target
Household net income by decileNo household's net income changes in any year. No change in any year: receipts by tax head; government balance, each component counted once; model totals; household income totals; population; poverty rates; people in poverty; inequality; mean household net income in each side's own deciles. Checks failing on both base and head (1)
Counted-once checkEach of 87 components was raised by £1 per unit in 2026-27, and every head of its totals was read household by household: its own head must rise by exactly £1, no other tax head may move, no other benefit may rise, and the model's own total must move by what its heads moved. A head that breaks a rule is measured again twice: with every other head held at its baseline value, and with every other head held at its value after the first £1 while the component rises again. It fails where either still shows the response. 0 failed; 0 were skipped.
Provenance
Dataset: Receipts by tax head: head levels
Spending by benefit and service: head levels
Caseloads: head levels
Government balance, each component counted once: head levels
Model totals: head levels
Household income totals: head levels
Population: head levels
Poverty rates: head levels
People in poverty: head levels
Inequality: head levels
Mean household net income in each side's own deciles: head levels
Standard reform costings (change in gov_balance): head levels
Standard reforms: change in each reform's target: head levels
|
juaristi22
marked this pull request as ready for review
October 24, 2026 14:29
vahid-ahmadi
left a comment
vahid-ahmadi
left a comment
Collaborator
There was a problem hiding this comment.
@juaristi22 thanks, first-round review at 9f0df6abd. The restriction is right in law and well tested, and CI is green. One should, on which partner the default picks, so I'm leaving this as a comment rather than an approval.
What I checked
- Law (legislation.gov.uk, current text). SSCBA 1992 s.70(7ZA): where two or more people would have a relevant entitlement for the same day for the same severely disabled person, only one does, chosen by joint election or, failing that, by the Secretary of State. s.70(7A) defines relevant entitlement as entitlement to Carer's Allowance or to the UC carer element, so it is entitlement, not payment, that is limited. The NI Act 1992 s.70(7ZA) is the same, with the Department deciding. SSI 2023/302 reg 5(3) bars CSP where another person is entitled to CSP, CA or the UC carer element for the same cared-for person; reg 5 has no election rule of its own. DMG 60026 confirms the election is by signed notice and otherwise a decision maker's choice. So applying the limit before the overlapping-benefit reduction, and keeping underlying entitlement for the selected carer, is right.
- Code: read
utils/couple_carer_award.py, both*_pre_couple_limitvariables (straight moves of the old formulas), both*_pre_overlapchanges, the default inpartners_care_for_same_severely_disabled_personand thesupplied_inputs.pyadditions in full. The default now reads the unrestricted candidates, so there is no cycle with the awards it limits. - Tests in a fresh venv at head:
couple_carer_award.yaml20 passed; with variables and utils reset to the merge base15a1d695b, 10 of the 20 fail, so the tests pin the change. YAML underfinance/benefit,gov/dwp,gov/social_security_scotland,gov/local_authorities,household/demographicandintegration: 2,718 passed. The ten carer Python test modules, including the editedtest_legacy_carer_premium_properties.py: 83 passed. - CI at head: all checks pass, and the aggregate report flags no moves, as #2028 expected (the enhanced FRS has reported awards, not caring hours).
- Merge order: this merges cleanly on top of the current merge queue, including #2082, which also edits
test_legacy_carer_premium_properties.py, and with #2593 (supplied_inputs.py).
Findings
-
should: the default can give the award to the partner who cannot be paid.
limit_carer_benefit_to_one_partnerprefers a reported recipient, then the head, then the eldest, without looking at the overlapping-benefit reduction. My household check, England 2026, couple aged 67 (State Pension £12,000) and 60, both caring 40 hours, flag left to default: at head the 67-year-old is head and keeps the CA entitlement, State Pension reduces it to nil, and the 60-year-old gets nothing. CA paid falls from £4,495.40 (base, paid to the 60-year-old) to £0, and household net income from £16,515.40 to £12,020.00. Member order doesn't change it, since the head is the elder. Scotland with CSP is the same: CSP paid falls from £4,495.40 to £0. The law leaves the choice to the couple, and a couple would not jointly elect the partner whose allowance is not payable, so this convention gives a worse result than the household could get, in a common case (an older couple caring for an adult child, one partner over State Pension age). Could the default, after an eligible reported recipient, prefer the partner whose candidate award survives the overlap reduction, then the head, then the eldest? The overlap reduction reads the other personal benefits, not the carer award, so it should not create a cycle. A YAML case for this couple would pin it. If you'd rather keep the current order, a line in the assumptions page saying it can pick the unpaid partner would at least make it visible. (The issue, filed by Max, suggested "otherwise the claimant", which has the same gap.) -
nit: PR body
axiom: needed. #2028 notes TheAxiomFoundation/rulespec-uk#403 already cites s.70(7ZA), so this could readaxiom: TheAxiomFoundation/rulespec-uk#403 queued. -
nit: the two new labels, "Carers allowance before couple and overlap restrictions" and "Carer support payment before couple and overlap restrictions", lose the programme capitals. Their siblings read "Carer's Allowance before the overlapping-benefit adjustment" and "Carer Support Payment before the overlapping-benefit reduction", and #2603 now asks for programme names to keep their capitals: "Carer's Allowance before the couple and overlap restrictions" and "Carer Support Payment before the couple and overlap restrictions".
What looks right: the limit sits before the overlap reduction; two reported awards still mean different care targets; directly supplied payment, pre-overlap and entitlement inputs stay authoritative; and the assumptions page is clear about what is out of scope (care targets across benefit units, the UC carer element allocation).
🤖 Generated with Claude Code
Collaborator
|
@juaristi22 second round at Status of round-1 findings
What I checked this round
🤖 Generated with Claude Code |
vahid-ahmadi
approved these changes
Oct 25, 2026
vahid-ahmadi
left a comment
vahid-ahmadi
left a comment
Collaborator
There was a problem hiding this comment.
Approving at 2b1d71c; see the comment above.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2028
Apply the same-person restriction to inferred Carer’s Allowance and Carer Support Payment awards within a claimant/partner couple. Caring-hours, age, earnings and take-up conditions stay unchanged. Among eligible partners, the model prefers a reported recipient, then the benefit-unit head, then the eldest partner; member order breaks age ties. This is a modelling convention for an unobserved election or decision, not statutory priority. The convention does not maximise the couple's payment. It can select a partner whose overlapping benefits reduce CA or CSP to zero, while suppressing a payment that the other otherwise-eligible partner could receive if selected.
The restriction applies before overlapping-benefit reductions, so a selected carer retains underlying entitlement when an overlapping benefit reduces the payment to zero. The same-person default reads unrestricted candidate amounts and explicitly supplied award inputs, independently of calculated caches. Directly supplied payment, pre-overlap and entitlement inputs remain authoritative. The Scottish Carer Supplement remains separate from the CSP component.
This covers units with exactly two claimant/partner flags. It does not identify care targets across benefit units, allocate awards to other members, resolve malformed units with more than two partner flags, or reconcile the allowance recipient with another person’s UC carer element. The existing qualifying-care proxy and annual date/rate approximations remain documented limitations.
axiom: needed
Reproducer: policyengine_uk/tests/policy/baseline/finance/benefit/couple_carer_award.yaml
Validation: 50 focused tests passed in one post-change batch: 47 YAML cases (20 new and 27 retained controls) and 3 property tests. Generated Hypothesis examples are not additional test counts. The YAML RED run had 10 expected assertion failures and 37 passes; the original property attempt timed out after 180 seconds (UV exit143), with no emitted test conclusions, and is retained separately.
make formatpassed before the commit. No full-suite run, private-data calculation or population score is claimed.Independent local code/test and policy/source review: COMPLETE, with no blocking findings at
9f0df6abde1001c7a6de64bb52c16bc3c28632ae.