LA Band D target is silently dropped now, and will compute as a sum-vs-level mismatch once council_tax_band_d_amount exists #483

Activity

1. vahid-ahmadi commented on Sep 18, 2026

   

   vahid-ahmadi

   on Sep 18, 2026

   CollaboratorAuthor

   More actions

   Microcosm has already adjudicated this exact question, and its verdict resolves the open design choice above.

   packages/microcosm-build/src/microcosm/build/uk/uk_data_target_parity.json carries a concern covering policyengine_uk_data.targets.sources.la_council_tax:

   {
     "concern_id": "local_council_tax_band_d_rate",
     "classification": "non_linear",
     "status": "reviewed_exclusion",
     "reason": "Band D currency amounts are per-rate, not additive household controls.",
     "fence": {
       "origin": "uk-data published Band D rates but did not wire them into the additive LA loss matrix.",
       "purpose": "Avoid treating a rate as an additive target.",
       "verdict_basis": "Keep excluded until a rate-aware non-linear objective exists."
     }
   }

   So Microcosm reached the same conclusion independently — a Band D currency amount is a rate, not an additive household control — and deliberately declined to port it, with a signed fence. Its status vocabulary defines reviewed_exclusion as "Deliberately not ported after review, with a complete fence."

   That makes option 1 (drop the target) the right resolution here, not option 2 (a mean-returning compute route). A weighted mean would make the number stop being wrong, but it would still be binding a rate into an additive objective, which is the thing Microcosm fenced against. Option 3 (retarget onto total_council_tax_net) is separately blocked on their side anyway — the local_council_tax_net concern sits at blocked_source, "The pinned feed has no comparable 2025 local-authority council-tax net series across the 361-area roster."

   Two further things from that register worth carrying into any fix:

   1. The band-count family is ported_local_declared and actively bound — local_council_tax_band_counts says the Microcosm council_tax/band_a..i contract rows "bind 2,511 authority cells on the taxbase basis with the 296 English band-H cells and Shetland's band-H cell signed deferred (microcosm#929)". So voa/council_tax/{code}/{band} is the council tax target surface that legitimately calibrates. That one is a count, and counts are additive.

   2. This is a live constraint on Extend LA council tax to all eight bands (MHCLG Table 9, 2026-27) #482. That PR adds band_A_amount..band_H_amount columns. Those are amounts, i.e. rates — so they must not be wired into the loss matrix as additive targets. Extend LA council tax to all eight bands (MHCLG Table 9, 2026-27) #482 deliberately emits no targets from the new columns and flags that as a follow-up; per this register, the correct follow-up is "no additive target", not "add eight more". Worth stating explicitly so a later contributor doesn't helpfully wire them in.

   Proposing to fix this by dropping the ons/council_tax_band_d/{code} emission from la_council_tax.py and leaving a comment recording why, so the rate stays available as data for liability computation without entering the objective.

   /cc @juaristi22 — flagging since this sits on the Microcosm parity surface and the fence is yours; tell me if dropping rather than fencing-in-place is the wrong shape for your register.

   🤖 Generated with Claude Code
2. vahid-ahmadi

   added a commit that references this issue on Oct 8, 2026

   Drop ons/council_tax_band_d/{code} target emission (#483)

   ...

   27aef71