PolicyEngine / PolicyEngine/policyengine-uk-data

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

Open
#452 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
1
Forks
2
Avg merge
1d 14h
Merged PRs (30d)
4

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the enhanced FRS 2023/24 v1.40.3 validation behind PolicyEngine/policyengine-uk#1815 and inspect the existing UC calibration targets. Compare modeled UC caseload and expenditure with the administrative series, determine whether the gap is take-up, calibration, or FRS reporting, and make the dataset validation output report the comparison for each release.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
data, data-engineering
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.