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/domain
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
..
src/domain slice S-B15: meter_type drives tariff selection (replaces heating-code heuristic) 2026-05-18 16:21:58 +00:00
pyproject.toml slice 13: to_rows(properties) returns pd.DataFrame 2026-05-16 16:43:28 +00:00
README.md added potential file scaffolding: 2026-05-15 10:56:53 +00:00

README.md

domna-domain

Shared domain types — Property, Properties, BaselinePerformance, Plan, PlanPhase, Scenario, ScenarioPhase, ScenarioSnapshot, Recommendation, OptimisedPackage, EpcPropertyData, etc.

Boundary: types only. No persistence, no IO, no business logic. Other packages and services depend on domna-domain; this package depends on nothing internal.

Domain definitions live in ../../CONTEXT.md. New types added here must match the glossary terms.

Layout

src/domain/
├── __init__.py
├── property.py             # Property, Properties, PropertyIdentity
├── site_notes.py
├── landlord_overrides.py
├── baseline_performance.py # lodged + effective pair (ADR-0004)
├── plan.py                 # Plan, PlanPhase, OptimisedPackage
├── scenario.py             # Scenario, ScenarioPhase, ScenarioSnapshot (ADR-0005)
├── recommendation.py
├── geospatial.py
├── solar.py
├── anomaly_flags.py
└── ml/
    ├── __init__.py
    ├── transform.py        # EpcMlTransform (versioned per §8.3)
    └── schema.py

When datatypes/epc/domain/ folds in, the EPC schema types move under src/domain/epc/.