Certified UK artifact carries less than half of admin UC caseload (3.26m vs ~6.7m; £36.9bn vs £75.8bn) #701

Activity

1. MaxGhenis commented on Aug 17, 2026

   

   MaxGhenis

   on Aug 17, 2026

   ContributorAuthor

   More actions

   Seam analysis before implementing this — conclusion: the right home for each piece already exists or is owned, so this lands as a hand-off rather than a parallel build.

   Where each piece belongs:

   • Facts → the DWP monthly series belongs alongside the uk_national profile work in chronicle#164 rather than a competing package. Ready to drop in, verified against the staged gov.uk tables: UC benefit units (DWP "households on UC" = benefit units, point in time, derived as deducting households ÷ published share from the deductions statistics Table 1): Apr 2025 6.38m; May–Aug 2025 6.60m; Sep–Nov 2025 6.96m; Dec 2025–Feb 2026 7.17m. OBR UC expenditure counterpart: £75.8bn 2025-26.
   • Consumption seam → Consume Ledger UK facts: uk_target_references, mapping module, and a compile-parity gate #622 (Chronicle references/profile consumption/parity gate) and Calibrate the UK national build from Ledger-backed targets #623 (the missing UK national calibration seam) are exactly where these targets plug in; the rowwise path today binds only the local census-household family. Consume Ledger UK facts: uk_target_references, mapping module, and a compile-parity gate #622's no-silent-gaps requirement already covers the policyengine-uk-data#456 defect class — good.
   • Operations → the profile machinery currently supports identity fact operations only. The two targets need three declared operations: calendar-year average (2025 ≈ 6.7m), latest-plateau selection (2026 ≈ 7.2m), and component sum (if the OBR fact arrives split). These look like early entries for the spec-engine operation vocabulary (RFC: the spec engine — schema for full spec-drivenness (review before build) #698) rather than one-off code.
   • Targets (once the seams land): UC caseload = sum of a UC-receipt indicator at benefit-unit level; UC expenditure = sum of universal_credit. Sums only, entity-explicit — DWP "households" are benefit units, so this avoids the dwellings-vs-households class from policyengine-uk-data#457.

   One question for the calibrate owners: the current loss is capped weighted MAPE with fixed row scales (packages/microcosm-calibrate/src/microcosm/calibrate/solve.py:448-493, scales max(abs(target), 1)). Does the cap flatten gradients for large misses the way policyengine-uk-data#456 documents for its bounded torch.min loss? A UC target starting at 0.45× of truth needs pull throughout the range, not just near the target.

   Happy to turn the facts into a stacked contribution on chronicle#164 or a follow-on PR the moment #622/#623 land — the derivation, source CSVs, and measurement scripts are all reproducible from the policyengine-uk-data#452 thread. Full seam map available on request.
2. MaxGhenis commented on Aug 17, 2026

   

   MaxGhenis

   on Aug 17, 2026

   ContributorAuthor

   More actions

   Answering my own loss question from the seam comment, after computing the profile: no #456-class defect here.

   relative_error_loss is min(|estimate − target| / max(|target|, 1), cap) with _DEFAULT_TARGET_LOSS_CAP = 10.0 (solve.py:128). Two properties settle it:

   • An undershoot of a nonnegative estimate has scaled miss ≤ 1.0 (maximum at estimate = 0), so it can never reach the cap — a UC target starting at 0.45× of truth keeps full, constant-magnitude gradient the whole way in.
   • The clip only engages beyond an 11× overshoot, where it functions as a guard rather than a shaping term. And unlike uk-data's torch.min sre, the L1 form's gradient does not decay with distance below the cap.

   So the two targets proposed here will pull correctly under the existing loss once the #622/#623 seams land — no calibrate changes needed for this issue.
3. vahid-ahmadi commented on Aug 20, 2026

   

   vahid-ahmadi

   on Aug 20, 2026

   Contributor

   More actions

   Connecting the #727/#184 review thread to the operations analysis above, because your own monthly figures put a number on what the unresolved basis costs.

   With chronicle#184 merged, the DWP series resolves through _latest_period_selector_match — eligible facts at or before the reference period, then latest wins. Against your listed series (Apr 2025 6.38m; May–Aug 6.60m; Sep–Nov 6.96m; Dec 2025–Feb 2026 7.17m), that means:

   • at the 2023 activation period: no eligible fact, so the target is declared but inert — the UC row on UK scorecard: populace_uk_2023 vs enhanced_frs_2024_25 vs admin benchmarks (2026) #731 stays open after Refresh the UK Universal Credit target contract #727 merges;
   • at the Retarget the UK build to FRS 2024-25: re-pin raw vintages, regenerate parity instruments, re-measure gate baselines #723 retarget (calibration year 2025): latest-wins binds December 2025 = 7.17m, while the calendar-year-2025 average you identified as the intended basis is ≈6.76m (the nine listed months, weighted by their plateaus). December sits about 6% above it.

   So the gap between "the basis we meant" and "the basis the resolver picks" is roughly 6% on the very target meant to close a −52% caseload miss — and it lands as a default rather than a decision. That's the concrete case for the calendar-year-average operation being a blocking dependency rather than a nice-to-have: allowed_value_operations is ["identity"] today, so the contract literally cannot express the average, and the identity path silently resolves to the December plateau instead of failing closed the way an unrepresentable basis should.

   Two things that would keep this from being rediscovered as an unexplained calibration residual:

   1. Treat RFC: the spec engine — schema for full spec-drivenness (review before build) #698's calendar-year-average operation as the gate on activating dwp.uc.households, not on refining it — until it exists, the honest states are inert (today) or explicitly month-pinned with a note saying December was chosen deliberately.
   2. When the operation does land, the latest-plateau selection you also named (2026 ≈ 7.2m) and the calendar-year average differ by the same ~6% for the same reason, so whichever the calibration binds should carry its basis in the declaration — the two are easy to confuse precisely because both are defensible.

   Agreed with your boundary call on chronicle#184, by the way — turning a published monthly stock into an annual figure would have put consumer semantics in the facts layer, which is exactly what the #166 ruling took out of Chronicle. The basis belongs here; it just needs the vocabulary to say it.
4. juaristi22

   added a commit that references this issue on Aug 20, 2026

   Add the UK national calibration step over ledger-backed target refere…

   ...

   0e741e3
5. juaristi22 commented on Sep 9, 2026

   

   juaristi22

   on Sep 9, 2026

   Collaborator

   More actions

   Closing as superseded by #882. The missing UC caseload bindings are repaired; expenditure comparability and certified consumer acceptance are explicitly carried forward in the scope-transfer note. This closure consolidates the remaining work and does not claim a passing certified replacement.
6. juaristi22

   closed this as not plannedon Sep 9, 2026