Model/packages
Khalim Conn-Kowlessar 6b934710d0 slice S-B25: description-based dispatch for as-built / assumed cavity
The RdSAP schema's `wall_insulation_type = 4` ("as-built / assumed")
covers two distinct cert populations that previously both routed to
the Cavity-as-built row (U=1.5 at band E):

  686 certs: "Cavity wall, as built, no insulation (assumed)" — U=1.5 ✓
 1171 certs: "Cavity wall, as built, insulated (assumed)" — should be 0.7
  147 certs: "Cavity wall, as built, partial insulation (assumed)" — 0.7

The description string disambiguates. The legacy production map at
recommendations/rdsap_tables.py:753 routes the latter two to "Filled
cavity" — we match that interpretation here for parity with the cert
assessor and the production recommendation engine.

`_cavity_described_as_filled` adds the description check; the existing
filled-cavity dispatcher in u_wall now fires on either signal:
- wall_insulation_type == 2 (S-B23 — explicit filled-cavity code)
- description contains "insulated" or "partial insulation" without
  the "no insulation" negation marker (S-B25 — assumed cavity-fill)

Parity probe at 300 certs, seed=7:
  PE MAE  46.78 → 45.74 (-1.04)
  PE bias 41.78 → 40.19 (-1.59)
  Band F bias +23.2 → +12.6 (-10.6)
  Band G bias +31.8 → +25.1 (-6.7)
  Band H bias +30.7 → +15.5 (-15.2)

Improvements localise to bands F-H (1976-1995), the era when Building
Regs mandated cavity insulation for new-builds — making "as built,
insulated (assumed)" the modal description. SAP MAE drifted up
+0.12 (cost-side residuals surfacing now that envelope is closer to
spec; tracked for follow-up).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-18 21:06:10 +00:00
..
domain slice S-B25: description-based dispatch for as-built / assumed cavity 2026-05-18 21:06:10 +00:00
fetchers added potential file scaffolding: 2026-05-15 10:56:53 +00:00
repos added potential file scaffolding: 2026-05-15 10:56:53 +00:00
utils added potential file scaffolding: 2026-05-15 10:56:53 +00:00
README.md added potential file scaffolding: 2026-05-15 10:56:53 +00:00

Shared packages

Workspace packages consumed by services/*. Each package is its own Python distribution with its own pyproject.toml; services import via the workspace dependency mechanism ({ workspace = true }).

Package Purpose
domain/ Shared domain types — Property, BaselinePerformance, Plan, Scenario, EpcPropertyData, etc. No persistence, no IO, no business logic.
repos/ Persistence layer — one repo per aggregate. Owns the SQL. Depends on domain.
fetchers/ External API clients (gov EPC, Ofgem, Google Solar, etc.). Depend on domain for response shapes.
utils/ Cross-cutting infra — logging, S3, CloudWatch URL builders, SQS task helpers.

Adding a new shared package

Only when a real second consumer materialises. Don't pre-shatter (repos-epc, repos-property, ...) — split when a deployment needs to drop a dep, not before.

See ../ara_backend_design.md §11 for the broader monorepo layout and ../CONTEXT.md for the domain glossary that names the types living in domain/.