UC caseload runs ~40% below administrative counts, capping aggregate reform estimates

[vahid-ahmadi]

Problem

The enhanced FRS UC caseload falls well short of the administrative count, and every weighted aggregate built on UC inherits the gap.

Measured while validating PolicyEngine/policyengine-uk#1815 (enhanced FRS 2023/24 v1.40.3):

	model	administrative
UC benefit units	4.2m	~7.2m households
households with deductions	1.9m	3.3m
deducted per year	£1.2bn	~£2.0bn

The deductions module's per-household statistics validate closely against DWP's deductions statistics — incidence 47%, mean monthly deduction £66/£50 across the two cap regimes, at-cap pileup — precisely because the caseload gap divides out of ratios and means. It does not divide out of counts or costs.

Why it matters now

External users (WPI Economics, and charities in the poverty space via JRF-style protected-floor analysis) are the requesters behind PolicyEngine/policyengine-uk#1814. What they want from the model is exactly the aggregate layer: how many households gain, how many people leave poverty, what the reform costs. Those run low roughly in proportion to the caseload shortfall — the Fair Repayment Rate check in #1815 gets the mean gain right (£421 vs £420 published) but 1.01m households better off against ~1.2m published, and that is the best case, since a cap change touches only already-deducting households.

Until this closes, PolicyEngine UK's deductions documentation tells users to quote per-household gains and distributional shape, not totals (validation page added in #1815).

What would help

• Establish whether the gap is take-up modelling, calibration targets, or FRS under-reporting of UC receipt — the three have different fixes.
• Add UC caseload (and ideally UC expenditure) to the calibration targets if they are not already binding, or diagnose why the existing targets are not holding.
• Report the resulting caseload against the administrative series in the dataset validation output, so the gap is visible per release rather than rediscovered per analysis.

Related: #450 (imputing UC deduction attributes at dataset build) sits downstream of this — it moves where the deduction attributes are assigned, not how many UC households exist to assign them to.

[vahid-ahmadi]

Root cause found: take-up is applied to ALL benefit units, not to entitled ones

This is a hard ceiling that no amount of reweighting can lift, and it explains the caseload gap directly.

datasets/frs.py:1417-1421 assigns UC claim status via assign_takeup_with_reported_anchors, with parameters/take_up/universal_credit.yaml = 0.55. Inside that helper (utils/takeup.py:52):

target_count = int(rate * len(draws))

len(draws) is every benefit unit, not the entitled ones. The module's own docstring (takeup.py:5-8) states the opposite intent:

the remaining random fill should hit the target aggregate takeup rate across the non-reporting eligibles

Implementation and documentation disagree. With ~55% of all benefit units flagged and FRS reporters forced in, effective take-up among entitled non-reporters lands near 45-47%, against DWP's published UC take-up of ~85% by caseload.

Because universal_credit_pre_benefit_cap carries defined_for = "would_claim_uc", the set of possible UC claimants is fixed before calibration runs. Reweighting cannot create claimants — it can only inflate the weight of those that exist, by 44%, which immediately breaks the population, age, region and household-type targets.

The targets are fine — it is the microdata that cannot reach them

Worth correcting my framing in this issue: I wrote that UC caseload should be added to the calibration targets. It already is, consistently, from a current DWP vintage:

• targets/sources/dwp.py:165-183, four family types → 6,096,900 households
• targets/sources/dwp.py:144-162, by number of children → 2,998,111, reconciling exactly with the with-children family types
• 104 dwp/uc_payment_dist/* targets → 6,095,654
• constituency targets (utils/uc_data.py, May 2025 provisional) → 6,095,661; LA targets → 6,095,645

Both halves of the loss agree on 6.096m. I should also correct the administrative figure I used: this issue quotes "~7.2m administrative households", but the repo's own targets say 6.096m, and that is the number the model is actually being asked to hit. The model's 4.22m against 6.096m is the sharper statement of the problem, and it changes any caseload scaling factor from 1.72x to 1.44x.

Suggested fix

1. Pass an eligibility mask to assign_takeup_with_reported_anchors and interpret rate as take-up among the entitled, matching the docstring.
2. Set the parameter from DWP's published UC take-up (~0.85). The 0.55 value dates from a 2015 entry and predates the reported-anchor rework.
3. Add dwp/uc/total_claimant_households = 6,096,900 as an explicit national target — 6.096m currently exists only as a sum of splits.
4. Add obr/universal_credit_average_award (£13,006 = £79.29bn / 6.0969m) so caseload and spend cannot compensate for one another.

Knock-on: this likely drives the benefit cap overshoot too

The OBR UC spend targets (£79.29bn) are in the loss and easy to satisfy by inflating awards. Delivering that from 4.22m benefit units needs an average award of £18.8k against a target-implied £13.0k — a factor of 1.44, exactly 6.096/4.22. Benefit cap incidence is convex in the award, so a uniform 1.44x inflation pushes a disproportionate share over the threshold and inflates the excess super-proportionately. That predicts the observed pattern in PolicyEngine/policyengine-uk#1818 precisely: count 2.0x, reduction 3.1x.

This is an inference, not a measurement. It is settled in one step by reading obr/universal_credit_in_cap estimate-vs-target from constituency_calibration_log.csv, which CI already uploads as an artifact on every push (.github/workflows/push.yaml:63-73) — no rebuild required.