Why
Microcosm's Universal Credit caseload target (dwp.uc.households, the calendar-year average adjudicated in microcosm#735) selects source_concept: dwp.uc_benefit_units. The only facts carrying that source concept are DWP's UC deductions statistics Table 1 monthly total (total_units, rounded to 10,000 and updated quarterly); their April–December 2025 mean is 6,758,889, the value the calibration records. The Stat-Xplore UC_Households family-type cube (#188, #239) is the series the family-type, number-of-children and award-band partitions bind, and it does not carry its published Total row as a fact: the five family-type rows have to be summed to recover it.
The two series disagree: summing the family-type rows gives 6,519,200 (April 2025) to 7,154,040 (December 2025) against the deductions total's 6,380,000 to 7,170,000, above it in seven of nine months and +1.45% on the 2025 average (6,858,287 vs 6,758,889). Microcosm therefore checks a partition against a total from a different, rounded, quarterly-stepped table — the sum-consistency concern microcosm#736 records (uk-data#466).
A second, mechanical effect: every Stat-Xplore UC fact is canonicalised to dwp.uc_benefit_units, so a consumer selector on that concept now also matches all 184 split facts at the latest month, which is what makes the caseload row fail to compile on the current feed (microcosm#834 plan §5c, A16). Microcosm pins its selector down; Chronicle's part is the Total row.
Request
Add the Stat-Xplore UC_Households Total row (all family types, Great Britain) to the family-type package as its own monthly fact, April–December 2025 and onward as the histories extend, with:
- the same entity (
benefit_unit), geography (K03000001), period typing (month) and provenance as the split rows;
- a
source_measure_id that is distinct from the split rows' benefit_units (e.g. total_benefit_units), so a consumer can select the total without also matching the partition;
- no derived arithmetic on Chronicle's side: the row is what Stat-Xplore publishes.
Same shape as #188. The per-month values should reconcile to the sum of the five family-type rows within publisher rounding, which a package test can pin.
Consumer
microcosm#834 (increment I0) binds the caseload to DWP deductions Table 1 with a tightened selector for now and moves it to this row when it lands, so the caseload and its partitions come from one cube.
Why
Microcosm's Universal Credit caseload target (
dwp.uc.households, the calendar-year average adjudicated in microcosm#735) selectssource_concept: dwp.uc_benefit_units. The only facts carrying that source concept are DWP's UC deductions statistics Table 1 monthly total (total_units, rounded to 10,000 and updated quarterly); their April–December 2025 mean is 6,758,889, the value the calibration records. The Stat-XploreUC_Householdsfamily-type cube (#188, #239) is the series the family-type, number-of-children and award-band partitions bind, and it does not carry its published Total row as a fact: the five family-type rows have to be summed to recover it.The two series disagree: summing the family-type rows gives 6,519,200 (April 2025) to 7,154,040 (December 2025) against the deductions total's 6,380,000 to 7,170,000, above it in seven of nine months and +1.45% on the 2025 average (6,858,287 vs 6,758,889). Microcosm therefore checks a partition against a total from a different, rounded, quarterly-stepped table — the sum-consistency concern microcosm#736 records (uk-data#466).
A second, mechanical effect: every Stat-Xplore UC fact is canonicalised to
dwp.uc_benefit_units, so a consumer selector on that concept now also matches all 184 split facts at the latest month, which is what makes the caseload row fail to compile on the current feed (microcosm#834 plan §5c, A16). Microcosm pins its selector down; Chronicle's part is the Total row.Request
Add the Stat-Xplore
UC_HouseholdsTotal row (all family types, Great Britain) to the family-type package as its own monthly fact, April–December 2025 and onward as the histories extend, with:benefit_unit), geography (K03000001), period typing (month) and provenance as the split rows;source_measure_idthat is distinct from the split rows'benefit_units(e.g.total_benefit_units), so a consumer can select the total without also matching the partition;Same shape as #188. The per-month values should reconcile to the sum of the five family-type rows within publisher rounding, which a package test can pin.
Consumer
microcosm#834 (increment I0) binds the caseload to DWP deductions Table 1 with a tightened selector for now and moves it to this row when it lands, so the caseload and its partitions come from one cube.