junte/Model
1
0
Fork 0
mirror of https://github.com/Hestia-Homes/Model.git synced 2026-06-08 11:17:27 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
Model/packages
History
Khalim Conn-Kowlessar 4c50c1b0fb slice S-B15: meter_type drives tariff selection (replaces heating-code heuristic) 
Per user guidance: trust the cert's lodged meter_type as the source of
truth for tariff selection, rather than inferring tariff from heating
code lists. SAP10 meter_type enum (verified empirically on the 250k
corpus: 75% type 2, 14% type 1, 11% type 3):

  1 = Off-peak (Economy-7 / dual rate)
  2 = Single (Standard)
  3 = Off-peak (24-hour heating)

The transform.py docstring describes 1=Standard / 2=Off-peak but that
contradicts the 75% type-2 distribution (UK demographics don't put 75%
of dwellings on off-peak). The inverted reading parity-tests correctly.

Tariff routing rules:
  - Space heating: off-peak rate when main fuel is electric AND meter is
    off-peak; else standard main-fuel rate.
  - Hot water: off-peak rate when water fuel is electric AND meter is
    off-peak; else water-fuel rate.
  - Lighting + pumps + fans: always standard electricity (Table 12a
    notwithstanding — cert software empirically uses standard here).

100-cert parity probe:
  MAE 4.40 → 4.39   (flat in aggregate; structurally cleaner code)
  RMSE 5.63 → 5.56
  bias +0.16 → -0.17
  within ±10: 96% (unchanged)

The meter_type seam replaces the e7_eligible_main_codes set on
PriceTable. Conceptually cleaner: tariff is a property of the meter,
not the heating system.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-18 16:21:58 +00:00
..
domain slice S-B15: meter_type drives tariff selection (replaces heating-code heuristic) 2026-05-18 16:21:58 +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

README.md

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/.