Say which joint occupiers each FRS non-dependant family resides with

[MaxGhenis]

Model side: PolicyEngine/policyengine-uk#2035 (issue PolicyEngine/policyengine-uk#2029).

Stacked on #512 (base frs-shared-household-rent), which is stacked on #506 and #503.

Summary

policyengine-uk#2035 adds a benefit-unit input, non_dependant_normally_resides_with. It is set on a non-dependant's family in a household whose rent is shared by joint occupiers, and says which of them the family normally resides with. It decides whose non-dependant someone is for:

• the Housing Benefit size criteria;
• the young individual's shared accommodation test (HB Regs 2006 reg 13D(2)(a)(i));
• the apportionment of non-dependant deductions (HB reg 74(5), CTR SI 2012/2885 Sch 1 para 8(5)).

The values are EVERY_JOINT_OCCUPIER (default), HOUSEHOLD_HEAD_FAMILY and OTHER_JOINT_OCCUPIERS.

This PR sets the input from the FRS household relationship grid (R01–R14 on the adult and child records). In a household with at least one sharer (liable_for_share_of_household_rent, #512), the joint occupiers are the household reference person's family and the sharers. Every other family is a family of non-dependants.

Family of non-dependants	Value
A member is related to members of the HRP's family, and of no other joint occupier	HOUSEHOLD_HEAD_FAMILY
A member is related to members of the household's only sharer, and of no other joint occupier	OTHER_JOINT_OCCUPIERS
Anything else	EVERY_JOINT_OCCUPIER (default)

"Anything else" covers:

• friends of the household;
• a family related to two or more joint occupiers;
• the relative of one sharer among several, which the input cannot single out (OTHER_JOINT_OCCUPIERS would at least drop the HRP's family, but would still add the other sharers, so neither value is right);
• every family in a household with no sharer.

Why relationships decide it

• Shared. LHA Guidance Manual (April 2014) para 2.110: joint tenants John and Alex share a friend, Peter. Peter counts in each one's size criteria, and his deduction is apportioned.
• One tenant's. Para 2.093, example 2: Susan, the sister of joint tenant Sarah, is treated as Sarah's non-dependant only.
• Case law. "Normally resides with" is a question of fact (JP v Bournemouth BC [2018] AACR 30, para 34). It quotes AM v SSWP [2011] UKUT 387 (AAC), para 16: one looks "at the relationship between the parties, in context".

The FRS gives us the relationships, not the facts of each household. So the rule is a proxy: a family that is related to exactly one joint occupier is taken to live with that joint occupier.

"Related" means any FRS relationship code except 18, "other non-relative". That covers:

• partners;
• relatives by blood, adoption or marriage (including in-laws and step-relations);
• grandparents and other relatives;
• foster relations.

Two inclusions go beyond a narrow reading of "relative": foster relations (5, 9, 13), and partner codes across benefit units (1, 2, 20). A young adult who stays on with former foster carers lives in their household. JP turns on the household relationship, not on blood. Neither inclusion changes any family in the 2023-24 or 2024-25 FRS.

The grid, checked against the data

All of these come from the UKDS 2024-25 data dictionary and aggregate counts of the EUL files.

• Direction. R0k on a record is that person's relationship to person k ("Relationship to person k"; codes 1–18 and 20). A child's code for the HRP is 3, son/daughter, for 6,996 of 7,252 children (96%) in 2024-25.
• Blanks. A record's own column is blank, and so are columns for person numbers not in the household.
• Agreement between records. The reverse code is the inverse for 99.99% of ordered pairs of household members in 2024-25, and 99.75% in 2023-24. A tie on either person's record therefore counts.
• Coverage. The grid stops at person 14. Fewer than 10 households have more than 14 people.
• HRP placement. The HRP is in benefit unit 1 in every 2024-25 household.

How many families it touches

Counts with fewer than 10 survey households behind them are suppressed.

FRS	Households with a sharer	... with a family of non-dependants
2024-25 (this build)	97 (306k weighted)	suppressed (fewer than 10)
2023-24	91 (308k weighted)	suppressed (fewer than 10)

Every split of those families by value is suppressed.

The input matters little for the 2024-25 data. It is here so the model applies 2.093 where the survey shows it, and for later FRS years.

Impact

Real microsimulations on policyengine-uk#2035's head (68647f9b6), the only model that reads the input:

• Branch: the enhanced FRS built from this branch (db02d65). Production settings as for Mark the benefit units that share their household's rent #512's build: 512 epochs, one OA clone, the policyengine-uk 2.93.0 lock. Build time 61 minutes, exit 0; the only errors are the existing HMRC salary-sacrifice CSV downloads that return 410.
• Base: the same file with the column dropped, which is what Mark the benefit units that share their household's rent #512 writes.

The two runs have identical households, benefit units and weights.

	2025-26	2026-27
Housing Benefit	no change (£13.666bn)	no change (£14.181bn)
Council Tax Reduction	no change (£2.122bn)	no change (£2.174bn)
Universal Credit	no change (£76.099bn)	no change (£80.267bn)
Household net income, HBAI incomes (BHC and AHC), poverty (BHC and AHC)	no change	no change
HB size criteria (housing_benefit_LHA_allowed_bedrooms), LHA category, young-individual test (housing_benefit_claimant_has_non_dependant), HB and CTR non-dependant deductions	change for fewer than 10 survey households (suppressed)	change for fewer than 10 survey households (suppressed)
UC size criteria and non-dependant deductions, HB additional bedrooms, the five local CTR schemes' deductions	no change	no change

So in the 2024-25 data the rule changes HB size criteria and HB and CTR deductions for fewer than 10 survey households, but no household's HB or CTR amount. Families liable for a share of the rent: 157k weighted in 2025-26 and 158k in 2026-27 (97 survey households).

Survey households are counted by a fingerprint of rent and sorted ages. Every SPI-synthetic and capital-gains copy in the enhanced FRS has the fingerprint of an original FRS household, and the 16,288 originals share 8,525 fingerprints, so a fingerprint count is a lower bound on the survey households behind a cell.

The model behind these runs is #2035 at 68647f9b6. Its later commits (Income Support eligibility, adoption placement) don't touch anything that reads this input.

Not changed by this PR

The new column feeds nothing else in the build: no uk-data code reads it, and the build's policyengine-uk (2.93.0, from the lock) has no variable for it. Checked three ways.

• Base FRS dataset. frs_2024_25.h5 from this branch (db02d65) against Mark the benefit units that share their household's rent #512's own build (a9e3371, 1 Oct, same raw files and environment): every shared column of the person, benefit unit and household tables is identical. The only addition is this column.
• Enhanced FRS. The branch build and its base (the same file with the column dropped, as Mark the benefit units that share their household's rent #512 writes it) differ in that column only. The column has no missing values and only valid enum names.
• Older policyengine-uk. policyengine-uk 2.93.0 (the build's lock) on the base and branch files gives identical household Housing Benefit, Council Tax Reduction, Universal Credit and net income in 2026-27. It skips dataset columns it has no variable for (build_from_single_year_dataset and _pre_encode_enum_columns both continue past them).

This is why the impact above compares one build with and without the column, rather than two builds. Two builds of the same commit give different weights (#507), so their difference would bury an effect this small.

Invariants (tested)

policyengine_uk_data/tests/test_frs_non_dependant_residence.py uses synthetic frames only, with no survey data.

Worked examples:

• LHA 2.093 example 2 (the sister of the HRP, and the sister of the only sharer);
• 2.110 (a shared friend);
• a relative of one sharer among two;
• a nephew of two joint occupiers;
• a household with no sharer;
• a tie recorded on one record only;
• a tie carried by a child in the family;
• codes for people not in the household;
• no leakage across households.

Properties (Hypothesis, up to five benefit units, 20 people and four households per example):

1. Matches a family-by-family reference implementation of the rule. This is a differential test: about one example in eight moves a family off the default.
2. Scope. Only families that are neither the HRP's nor a sharer, in households with a sharer, leave the default.
3. OTHER_JOINT_OCCUPIERS only with exactly one sharer.
4. Row order does not matter, for benefit units or people.
5. Only family codes matter. Code 18, 0, −1 and missing are interchangeable.

Three mutations of the function are each caught:

• reading one record only;
• OTHER_JOINT_OCCUPIERS with several sharers;
• counting code 18 as a tie.

This PR adds hypothesis to the dev extra and to uv.lock. The lock's own version entry also moves from the stale 1.56.16 to 1.57.4.

Run locally at db02d65 (policyengine-uk 2.93.0 environment, Hypothesis 6.168.3):

• test_frs_non_dependant_residence.py: 14 passed;
• with Mark the benefit units that share their household's rent #512's, Carry the rent boarders and lodgers pay the householder as person inputs #506's and Stop counting rent paid by boarders and lodgers as their property income #503's FRS tests, the survey-year and prerequisite tests and test_is_parent_from_frs.py: 1,268 passed;
• ruff format --check .: clean.

CI runs only after this PR's base reaches main.

Merge order

1. Stop counting rent paid by boarders and lodgers as their property income #503, Carry the rent boarders and lodgers pay the householder as person inputs #506 and Mark the benefit units that share their household's rent #512 land first.
2. The column changes outputs only under a policyengine-uk that has #2035. Older versions ignore it (see "Not changed by this PR").
3. Merging builds and uploads a new dataset, so it is a data release.

axiom: n/a: data input (the rules are in policyengine-uk#2035; rulespec-uk#406)

🤖 Generated with Claude Code