* Electric-immersion DHW: bill at 100%, not the space boiler's efficiency 🟩 A separate electric immersion heater (SAP water-heating code 903) is 100% efficient (SAP 10.2 Table 4a) and the space-heating boiler provides no water heating, so Appendix D2.1 Eq D1 (the boiler seasonal-efficiency cascade) must not apply to it. But `_water_heating_main` resolves DHW to the SPACE main — a gas/oil boiler keeps its PCDB record — so three water-efficiency branches in cert_to_inputs billed the immersion-heated cylinder at the boiler's ~87% summer efficiency (a mongrel: electric fuel price x gas-boiler efficiency): 1. the scalar `water_eff = water_pcdb_main.summer_efficiency_pct / 100`, 2. the SAP §9.4.11 / Table 4c(2) -5pp no-interlock adjustment, and 3. the Eq D1 (winter, summer) seasonal pair from `pcdb_main`. Gate all three on `not dhw_is_electric_immersion`; the correct immersion path (`_water_efficiency_with_category_inherit` -> 1.0, Eq D1 off) then applies, mirroring the Table 3 zero-primary-loss gate already present for WHC 903. General bug — fires for any WHC-903 dwelling whose space main is a PCDB gas/oil boiler. It surfaced via the PasHub campaign's #1600 no-water-heating default (WHC 999 -> 903) on a gas-combi dwelling: 58 Hackle St M11 4WU, SAP 55.30 -> 57.67 (pre_sap 58, verified 59). Guardrails: the gov-API RdSAP corpus IMPROVES 78.8% -> 78.9% within-0.5, MAE 0.625 -> 0.622 (a handful of corpus certs with a boiler space main + electric immersion move closer to accredited) — MAE ceiling ratcheted 0.626 -> 0.625. Regression pinned in test_cert_to_inputs (RED before / GREEN after). pyright 0-new (cert_to_inputs baseline 30). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * PasHub SAP accuracy: thread low-energy lights + draught lobby (from_site_notes) 🟩 Two systematic silent-drops in the PAS Hub `from_site_notes` path, each a field the gov-API/Elmhurst mappers thread but site-notes dropped, letting a favourable default reach the SAP-10.2 calculator. Validated against the correct pashub oracle (property_baseline_performance.effective_sap_score, portfolio 838): cohort within-0.5 55.1% → 62.6%, MAE 0.599 → 0.521. - Low-energy lights: when "exact LED/CFL known = No", PAS Hub lodges an aggregate "Number of fixed low energy lights?" count. Previously dropped (no dataclass field / extractor key / mapper thread) → calculator saw 0 low-energy bulbs and applied the pessimistic L5b/L8c no-data default, under-rating SAP. Now threaded into low_energy_fixed_lighting_bulbs_count, mirroring from_elmhurst_site_notes. ~6% of the cohort; resolves 58 Hackle (−0.43 vs oracle 59 with #1615). - Draught lobby: _map_sap_ventilation set only the legacy `draught_lobby` field, never the canonical `has_draught_lobby` §2 (13) gate the cascade reads, so the surveyed lobby was ignored and infiltration over-stated. Now mirrors Elmhurst. Two other audited levers were REJECTED against the pashub oracle (they matched the gov-cert/RdSAP convention but pashub does not apply them): percent_draughtproofed (cohort 30.8%) and the §A.2.2 assumed secondary heater (19.2%). A heat-network control-code fix (2306→2303 for 16 Bingley) is HELD pending spec/Elmhurst adjudication — it contradicts ADR-0053; see the NOTE on _PASHUB_HEAT_NETWORK_CONTROL_TO_SAP10. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * PasHub heat-network control: room-thermostat-only maps to 2308, not 2306 🟩 The Table 4e Group 3 label "charging linked to use of community heating, room thermostat only" was mapped to 2306 — the linked-to-use *with-TRVs* code (control type 3, space charging 1.00). The label explicitly excludes TRVs, so it is control type 2 / space 1.05 = code 2308/2309 (linked-to-use → DHW 1.00). 2306 asserted TRVs the survey doesn't have and over-rated the cohort's sole heat-network dwelling (16 Bingley Close 56.89 → 54.01 vs pashub oracle 52). Verified against SAP 10.2 Table 4e as encoded in cert_to_inputs.py (_CONTROL_TYPE_BY_CODE 2308→2, space-charging 2308→1.05, DHW 2308→1.00) and the RdSAP control-label vocabulary in MainheatControlAttributes.py. 2303 (the earlier audit's guess) is rejected: it is a flat-rate code (DHW 1.05) whose oracle match was a coincidence of two offsetting spec violations. The residual +2.0 to oracle 52 is the documented SAP-10.2-engine-vs-lodged offset, not a fuel/flags gap (those were threaded by the #1590 follow-up) — supersedes the ADR-0053 / HANDOVER_838 "community fuel/flags" attribution. 16 Bingley is the only heat-network fixture in portfolio 838, so this moves one fixture strictly toward its oracle. Harness ratcheted: within-0.5 0.51→0.58, MAE 0.625→0.521 (observed 58.5% / 0.520 with all three 2026-07-15 levers). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * PasHub SAP accuracy: restore 3 dropped §2 infiltration inputs (from_site_notes) `from_site_notes` uniquely dropped three ventilation inputs that the gov-API and Elmhurst sibling mappers all set, causing a systematic cohort-wide SAP under-rate vs the company's own accredited SAP-10.2 certs (property_baseline_performance.effective_sap_score, portfolio 838): 1. percent_draughtproofed — never set, so §2(15) window infiltration was pinned at its 0.25-ACH worst case on every dwelling. Reconstructed as the area-weighted % of draught-proofed windows (mirrors Elmhurst `draught_proofing_percent`). Dominant term. 2. Upper-storey +0.25 m joist void — omitted; now added, matching `_UPPER_FLOOR_HEIGHT_ADD_M` on the gov-API/Elmhurst paths. This RE-ADJUDICATES #1601 ("keep raw"): that call was confounded by the then-present draught-proofing drop suppressing every verified dwelling. 3. sheltered_sides — left None → calculator's flat default of 2, which over-shelters end/semi/detached (RdSAP §S5 = 1/1/0). Now derived from built form. The three are NON-ADDITIVE — each overshoots alone (which is why all three were previously rejected individually) — but together they land all 7 verified ground-truth dwellings toward truth (none regress) and every built form near zero. Cohort 62.1% -> 83.3% within-0.5, MAE 0.507 -> 0.377. Guardrails: gov-API RdSAP corpus unchanged (78.9%, these are from_site_notes- only helpers). pashub harness 58.5% -> 79.5% / MAE 0.520 -> 0.389; ratchets tightened 0.58->0.78 and 0.521->0.40. pyright zero-new (mapper baseline 39). New focused tests in TestFromSiteNotesInfiltrationFixes cover all three fields incl. area-weighting and the built-form shelter map; goldens updated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .claude/skills | ||
| .devcontainer | ||
| .github/workflows | ||
| .idea | ||
| .vscode | ||
| applications | ||
| asset_list | ||
| backend | ||
| backlog | ||
| datatypes | ||
| deployment/terraform | ||
| docs | ||
| domain | ||
| epr_data_exports | ||
| etl | ||
| harness | ||
| infrastructure | ||
| model_data/requirements | ||
| orchestration | ||
| recommendations | ||
| repositories | ||
| sap worksheets | ||
| scripts | ||
| sfr/principal_pitch | ||
| survey_report | ||
| tests | ||
| utilities | ||
| utils | ||
| .coveragerc | ||
| .dockerignore | ||
| .gitignore | ||
| __init__.py | ||
| ara_backend_design.md | ||
| BaseUtility.py | ||
| CLAUDE.md | ||
| conftest.py | ||
| CONTEXT.md | ||
| devcontainer.sh | ||
| Dockerfile.test | ||
| Dockerfile.test.dockerignore | ||
| Makefile | ||
| MEMORY.md | ||
| modelling_audit.md | ||
| next_claude_prompt.txt | ||
| P960-0001-001431-2.pdf | ||
| package-lock.json | ||
| package.json | ||
| playground.py.local-backup | ||
| pyproject.toml | ||
| pyrightconfig.json | ||
| pytest.ini | ||
| README.md | ||
| run_lambda_local.sh | ||
| serverless.yml | ||
| Summary_001431-3.pdf | ||
| test.requirements.txt | ||
| tox.ini | ||
| UBIQUITOUS_LANGUAGE.md | ||
Model Repository
This repository contains the code pertaining to the development of the data science and machine learning products being utilised by Hestia.
The different folders in this repository relate to services that can be used independently, or can be imported and used as part of a larger application
Getting Started
Prerequisites
Dev Container Setup
This repo uses a Docker Compose-based dev container. The model-backend service joins a shared-dev Docker network so it can communicate with other local services (e.g. a frontend container) running on your machine.
VS Code users: The initializeCommand in devcontainer.json creates the shared-dev network automatically before the container starts. No manual step required — just open the repo and select Reopen in Container.
Non-VS Code / CI workflows: Run the following once before starting the container:
make dev-setup
This is idempotent and safe to re-run if the network already exists.
Folders
backend/
This folder contains the code for the fastapi backend service, which provides an interface to much of the functionality in this repository, for the frontend
model_data/
This folder contains related to the reading and preparation of assessment model data, including pulling out epc attributes
Testing
All tests can be run, against the configuration in pytest.ini running
pytest
This will run the complete panel of tests and report on coverage in the locations specified by the pytest.ini file.
To run tests in a specific service, e.g. inside of model_data, simply run
pytest --cov-config=model_data/.coveragerc --cov=model_data
This will produce the test results and coverage reports