Skip to content

Pin the scotgov council-tax stock targets to Scotland (activates the nine held CTAXBASE references) - #754

Merged
MaxGhenis merged 1 commit into
mainfrom
scotgov-council-tax-stock-pins
Aug 23, 2026
Merged

Pin the scotgov council-tax stock targets to Scotland (activates the nine held CTAXBASE references)#754
MaxGhenis merged 1 commit into
mainfrom
scotgov-council-tax-stock-pins

Conversation

@MaxGhenis

Copy link
Copy Markdown
Contributor

Summary

Nine UK calibration targets — scotgov.council_tax_stock.band_aband_h and .total — have been held as no_fact_at_or_before_period since the target surface was regenerated, although Chronicle has carried their facts (the CTAXBASE September 2025 chargeable dwellings, package scotgov-council-tax-bands-2025) all along. The blocker is the geography pin derivation in tools/generate_uk_target_references.py::_geography_id_for_target: the substring rule sees no "scotland" in "scotgov", falls through to the UK pin (K02000001), and the pin is merged into the selector (target_reference_authoring.py _target_selector) and matched against fact.geography.id — which Chronicle correctly stamps S92000003 for the Scotland row. Zero matches ever.

The fix is scoped to the stock family, as the review of the chronicle-side packages recommended: a scotgov.council_tax_stock. prefix rule returning Scotland, deliberately not a blanket scotgov.* rule (which would also re-pin scotgov.scottish_child_payment_spending, a source_projection target whose activation is a separate decision). The family accounting now counts both stock publishers (VOA for England and Wales, CTAXBASE for Scotland).

Regenerated uk/target_references.json and uk/target_reference_membership.json with the committed generator against the same feed vintage the surface was built from (rebuilt byte-identically from chronicle 1cab809 — main at the surface's regeneration date — with build-bundle --suite uk + build-consumer-artifact; 107,550 facts, sha256 226358e73e7c449e71a3f6dc91a72e8e3941e0f14265943d81c990edb21c2a6c, matching the 226358e7… the feed commit recorded). Membership movement is exactly the nine stock targets flipping to active with their CTAXBASE September 2025 values (band A 498,707 … band H 14,481, total 2,623,149) and month-to-year uprating holds (2025-09 → 2025):

  • active: 388 → 397
  • no_fact_at_or_before_period: 27 → 18
  • council_tax_stock family: 9 → 18 active declared rows

No other target's status, pin, candidate counts or resolved value changes.

A regression test pins the scoped rule: the nine stock ids resolve to S92000003, scotgov.scottish_child_payment_spending keeps its UK pin, and the full set of Scotland-pinned targets equals the stock family plus the ids the substring rule already matched.

Context and remaining holds

Chronicle PR PolicyEngine/chronicle#189 adds the nation-level council tax billed/collectable totals and CTR costs and documents this activation question. The four obr.council_tax_*/obr.domestic_rates holds are deliberately untouched here: they fail on the same pin-vs-stamp mechanics (nation pins vs the OBR rows' K02000001 stamp), but activating them interacts with the already-active obr.council_tax UK total, which is Table 4.1 row 19 — the three nation rows (£49.569bn FY2025) plus NI domestic rates (£0.494bn) plus a council tax accruals adjustment (£0.862bn) that has no counterpart in the bound household variable — so the UK binding should be redesigned before the decomposition activates (chronicle's stacked PR PolicyEngine/chronicle#192 adds the row-15/17/18 facts that make that redesign expressible). The remaining 14 holds (dwp.pip.*, slc.*, scotgov.scottish_child_payment_spending) show the same pin-class signature (matched_fact_count_overall: 0 with GB/UK pins) and deserve the same case-by-case treatment.

Tests

  • test_scotgov_council_tax_stock_pins_are_scotland_and_the_rule_is_scoped (new).
  • test_uk_target_reference_membership_report_is_packaged, test_country_spec.py and test_uk_national_calibration.py reference-count pins updated for the regenerated surface (397 active, 18 no-fact holds, council_tax_stock family 18).
  • uv run pytest and uv run ruff check . green.

🤖 Generated with Claude Code

The nine scotgov.council_tax_stock.* calibration targets have been held as
no_fact_at_or_before_period although Chronicle carries their facts: the
substring geography rule sees no "scotland" in "scotgov", pins them to the
UK, and the pin is merged into the selector and matched against
fact.geography.id, which Chronicle correctly stamps S92000003 for the
CTAXBASE September 2025 chargeable-dwelling rows. Zero matches ever.

Scope the fix to the stock family (a blanket scotgov rule would also re-pin
the scottish_child_payment_spending projection, a separate decision), count
both stock publishers in the family accounting, and regenerate the target
surface with the committed generator against the same feed vintage the
surface was built from (chronicle 1cab809, build-bundle --suite uk +
build-consumer-artifact; 107,550 facts, sha256 226358e73e7c449e71a3f6dc
91a72e8e3941e0f14265943d81c990edb21c2a6c). Membership movement is exactly
the nine stock targets: active 388 -> 397, no-fact holds 27 -> 18, family
9 -> 18 declared rows, nine new month-to-year uprating holds; no other
target's status, pin or resolved value changes, and no existing reference
is modified.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@MaxGhenis
MaxGhenis marked this pull request as ready for review August 23, 2026 19:32
@MaxGhenis
MaxGhenis merged commit c7be819 into main Aug 23, 2026
4 checks passed
MaxGhenis added a commit that referenced this pull request Aug 23, 2026
…he union

Main moved the same attested surfaces today (#744, #674, #754), so the
merge re-cuts them over the union tree in one reviewed step, the d70ea39
pattern: release_input_coverage_manifest.json regenerated (145 required /
0 exclusions unchanged), the UK spec_sha256 re-pinned, and the three
gate-battery digests recomputed into the microcosm-data contract and its
test mirror.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant