Skip to content

UK spine: child disability under-identification blocks the TCL disability cells (−56.5% / −40.0% across three spine vintages) #808

Closed

Description

@juaristi22

What

The spine under-identifies disabled children inside UC households, and no #796 item covers it. The two DWP two-child-limit disability cells are the deepest support holes left on the calibration surface, and reweighting cannot manufacture the flagged children:

target (2025) published initial support calibrated error
dwp.uc.two_child_limit.children_disabled_child_element 479,460 72,118 208,510 −56.5%
dwp.uc.two_child_limit.children_claimant_pip 235,270 72,943 141,160 −40.0%

Receipts: v11 calibration on spine-j (main seam, runs/uk-623-first-calibrated/spine-assessment-v11/), stable across v9 (spine-c, −59.3/−42.8), v10 (spine-i, −61.6/−45.1) and v11 (spine-j, post-#755) — so it is invariant to the pension-wealth split and to three spine vintages: an FRS disability-identification gap, not a weighting or capital artifact.

The sibling household-level cells (households_disabled_child_element 129,630, households_claimant_pip 65,280) calibrate to <0.4%, so the frame can find the households; what it cannot produce is enough flagged children per household — the child-level DLA/PIP/disabled-child-element identification on the FRS disability stage runs far below DWP's administrative counts.

Why it matters now

These are 2 of the 8 cells blocking uk_target_fit on the first certified microcosm_uk_2024 cut (#796 capstone). They are also load-bearing for any two-child-limit or child-disability reform analysis.

Suggested shape

Audit frs_disability child-level identification against the DWP TCL disability crosstabs (chronicle carries them: dwp.uc_tcl_children_by_disability_*, four rows each), then either a rate-based child-disability draw conditioned on household receipt (the house assign_binary_from_rate pattern) or an imputation from the DWP marginals. Until fixed, the two cells need target-fit adjudication entries to unblock the cut.

Refs: #796 (capstone blocker), #750 (the UC capital lever, now landed and measured — these cells are what it does NOT fix), uk-candidate-eval v9 report §two-child-limit.

Activity

  1. juaristi22 commented on Aug 28, 2026

    @juaristi22
    CollaboratorAuthor

    Diagnosis revision + measurement: the two blocking cells were mis-bound, and are now fixed and green — but the child-level identification gap is real, at ~4×.

    Part 1 — the binding. These two targets come from DWP sheet 04B, which counts every child in the affected household (the 3- and 4-children sibling rows divide to exactly 3.00 and 4.00 children per household; these cells run 3.6–3.7). Our bindings — uniquely among the sheet's children targets — summed uc_is_child_limit_affected (~1.27 affected children per household) against that all-children concept: a structural ~2.8× shortfall no disability flagging could close. #813 re-binds them to is_child like every sibling. v13 measurement (spine-j):

    cell before after initial support
    children_disabled_child_element −56.5% +0.1% 72,118 → 190,414
    children_claimant_pip −40.2% −0.3% 72,943 → 182,933

    Both cells hold green across the #809 lever sweep (0.55/0.70/0.85). The TCL household cells and children_in_* stayed within 0.4%. These cells no longer block the #796 capstone.

    Part 2 — the identification audit (the issue's original concern, measured against the unused chronicle marginal uc_tcl_children_by_disability_child_dla_pip_or_blind = 436,780). On spine-l055 (current main + #813, design weights, proxy universe = children in would_claim_uc benunits with 3+ dependent children — if anything broader than DWP's affected_3plus_children universe, since it ignores exceptions):

    • children with their own DLA/PIP reported > 0: 109,031 weighted, 191 records — ~25% of DWP's 436,780
    • across all would_claim_uc benunits: 326,361 weighted, 629 records
    • DWP's implied prevalence among children in affected households: 436,780 / 1,665,540 ≈ 26%; ours ≈ 3.5%

    The under-identification is invariant to the binding fix: the calibration now hits the published counts by up-weighting the households that do carry flagged children (190k initial vs 479k target still solves), but 191 records carrying that mass is thin support, and any reform analysis conditioning on child DLA/PIP receipt inherits the 4× gap. The frs_disability stage flags a child only when the FRS benefits tape reports an actual DLA/PIP amount for that child — no age branch, no top-up.

    Proposed second increment (the fix the issue originally suggested, now scoped): an anchored-residual child-disability draw — assign_binary_with_anchored_residual keeps every tape-reported recipient true and tops up to a DWP-implied rate, conditioned on household receipt, with the rate translated from this same crosstab (26% among affected-household children) or from the DWP DLA/PIP child caseload statistics as the adjudicated source. Machinery, seed pattern, and test template all exist (stochastic_assignment.py:57-84, take_up_contract.json source blocks, test_uk_frs_stochastic.py). Needs a rate-source adjudication before implementation — the rate must come from a published DWP fact, not from tuning to fit.

    Keeping this issue open for that increment; it is a quality item, not a capstone blocker.

  2. added a commit that references this issue on Aug 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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