Skip to content

UK spine: preserve FRS benefit-unit capital for UC while retaining WAS household wealth #828

Description

@juaristi22

Problem

The UK spine currently replaces the FRS relationship between reported Universal Credit receipt and benefit-unit capital with a household-level proxy assembled from WAS-imputed wealth. That proxy is useful for general wealth analysis, but it is not the same measurement as the liquid, benefit-unit capital relevant to UC eligibility.

This creates internally contradictory records: a benefit unit can report UC in the FRS while the later WAS-imputed proxy assigns it more than the £16,000 UC capital limit. The model then removes UC support that the source survey directly observed.

This surfaced while evaluating the first microcosm_uk_2024 national candidate on the PR #812 stack. It is a more specific successor to the wealth-side work in #750 and the residual UC investigation in #809.

Evidence

We joined the raw 2024-25 FRS benunit.tab to spine-k by source benefit-unit ID and evaluated capital using the model's current UC proxy.

The join covered all 18,850 source benefit units, including 2,212 raw UC-reporting benefit units. Weighted results for those reporters were:

Measure Above £16,000
FRS TOTCAPB4 benefit-unit capital 0.017 million (0.36%)
Current WAS-derived UC capital proxy 0.478 million (10.09%)
Direct FRS value at/below £16,000 but proxy above £16,000 0.475 million

Of the 0.475 million false-high cases, approximately 0.373 million are driven by allocated savings + corporate_wealth; approximately 0.102 million require property components to cross the limit.

On the full spine-k support:

  • 0.893 million weighted benefit units with reported UC have would_claim_uc = false;
  • 0.939 million reported-UC support is above the £16,000 proxy capital limit; and
  • the union of those two blockers is 1.495 million.

These are aggregate, disclosure-safe measurements; no source records are disclosed.

This is not evidence that the WAS wealth imputation lacks a top tail. The candidate has a substantial and survey-faithful wealth top tail. The defect is measurement grain and source authority: household WAS wealth is being used where the FRS supplies a benefit-unit capital measure that preserves the observed UC relationship.

Why this happens

The stage order currently allows two independent breaks in the observed UC relationship:

  1. The FRS stage carries reported UC receipt, but the later WAS stage populates savings, corporate_wealth, and property variables. uc_assessable_capital then allocates those household assets across benefit units as a residual proxy.
  2. SPI support/fill can rewrite universal_credit_reported after the take-up anchor has been established, without refreshing the corresponding would_claim_uc value.

PolicyEngine-UK already has the intended model seam. uc_reported_capital was introduced in policyengine-uk#1572 as an optional benefit-unit reported-capital override. A nonnegative value is used directly; its default -1 means that no reported value is available and the household proxy should be used.

Microcosm and policyengine-uk-data do not currently populate this variable.

Proposed fix: preserve two measurements for two purposes

Do not replace WAS wealth and do not introduce selective calibration twins.

  1. Carry the FRS TOTCAPB4 benefit-unit capital value through the compact FRS source stage with source/provenance bindings.
  2. Materialize it as uc_reported_capital at benefit-unit grain wherever the source value is available.
  3. Continue imputing WAS wealth into the existing general wealth variables (savings, corporate_wealth, property wealth, and the other wealth channels). Those remain authoritative for wealth-distribution and other asset analyses.
  4. For SPI support rows, preserve or jointly impute the FRS capital field alongside the other FRS-only UC characteristics so a synthetic UC reporter receives a coherent capital/receipt combination.
  5. Recompute or re-anchor would_claim_uc after the final stage that can alter universal_credit_reported.
  6. Leave uc_reported_capital = -1 only where a reported/imputed benefit-unit value is genuinely unavailable. Do not use the sentinel to switch channels between cloned alternatives.

This uses the existing model contract directly:

  • FRS benefit-unit capital governs UC eligibility and tariff income when present;
  • WAS-imputed household wealth remains available for wealth and distributional analysis; and
  • the existing household proxy remains the fallback for genuinely unobserved benefit-unit capital.

Explicitly out of scope

  • Do not clone only records where FRS and WAS values disagree. Existing UK and US clone precedents select a complete domain or a seeded sample ex ante; disagreement-conditioned twins would be a new modeling convention.
  • Do not put -1 on one twin and a reported value on another so calibration chooses the data channel. The sentinel is an availability contract, not a calibration routing variable.
  • Do not suppress or cap the WAS top tail.

Acceptance criteria

  • TOTCAPB4 is carried from the FRS source to a benefit-unit field with source-ID provenance and no household-grain reassignment.
  • Native FRS rows with an available value export nonnegative uc_reported_capital; -1 is reserved for genuine absence.
  • SPI support rows have a receipted rule for uc_reported_capital that preserves its joint relationship with reported UC and family composition.
  • would_claim_uc is refreshed after the last write to universal_credit_reported, with a stage-order regression test.
  • WAS wealth outputs and the existing wealth-tail gates remain unchanged within their declared stochastic tolerances.
  • A same-source regression test confirms that FRS UC reporters are not made ineligible solely because the later WAS household proxy exceeds £16,000 when their direct FRS capital does not.
  • A before/after developer build reports the three blocker aggregates above and the six signed UC/children calibration differences.
  • The rebuilt national candidate is recalibrated and the T0-T6 evaluation battery is rerun before changing or retiring any signed difference.

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions