PolicyEngine / PolicyEngine/policyengine-uk-data
UC caseload runs ~40% below administrative counts, capping aggregate reform estimates
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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