f14f76daf8
An attempted slice (S-B30, not committed) hypothesised that `main_heating_fraction=1` on the cert meant "no secondary heating" and overrode Table 11's 10% default. Probe at 300 certs penalised it: SAP MAE 4.69 → 4.85, SAP bias 0.98 → 1.61. The hypothesis was wrong and I should have read the spec before coding. SAP 10.2 Appendix A1 (p. 43) defines `main_heating_fraction` as the allocation between TWO main heating systems when both exist; not as the main-vs-secondary fraction. 99% of corpus certs have =1, meaning "single main, 100% allocation". SAP 10.2 Appendix A4(d) (p. 45) is explicit: "If any fixed secondary heater has been identified, the calculation proceeds with the identified secondary heater" and "Table 11 gives the fraction of the heating that is assumed to be supplied by the secondary system" — no override based on main_heating_fraction. Adds: - Regression test pinning the spec behaviour (test_main_heating_fraction_does_not_override_table11_secondary_default) - Regression test for the already-spec-aligned fallback path - _secondary_fraction docstring explaining why main_heating_fraction is NOT consulted (with reference to the failed attempt) - secondary_heating_type kwarg on make_sap_heating (test-only, was missing — needed to construct the regression fixture) Probe at 300 certs unchanged from prior baseline: SAP MAE 4.69, bias 0.98 PE MAE 43.32, bias 37.69 The hand-trace finding that cert 9036-0827 over-predicts cost remains real, but the secondary-heating fraction is per-spec. The residual ~£33 gap on that cert is most likely missing PCDB efficiency lookup (cert has main_heating_data_source=1 and index_number=10241 — PCDB data — and we fall back to category-default 0.80 vs typical PCDB- listed condensing-boiler 0.90+). Deferred to Session C per ADR-0009. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> |
||
|---|---|---|
| .devcontainer | ||
| .github/workflows | ||
| .idea | ||
| .vscode | ||
| asset_list | ||
| backend | ||
| backlog | ||
| datatypes | ||
| docs | ||
| epr_data_exports | ||
| etl | ||
| infrastructure/terraform | ||
| model_data/requirements | ||
| packages | ||
| recommendations | ||
| scripts | ||
| services | ||
| sfr/principal_pitch | ||
| survey_report | ||
| utils | ||
| .coveragerc | ||
| .dockerignore | ||
| .gitignore | ||
| __init__.py | ||
| AGENTS.md | ||
| ara_backend_design.md | ||
| BaseUtility.py | ||
| CLAUDE.md | ||
| conftest.py | ||
| CONTEXT.md | ||
| devcontainer.sh | ||
| Dockerfile.test | ||
| Dockerfile.test.dockerignore | ||
| Makefile | ||
| MEMORY.md | ||
| package-lock.json | ||
| package.json | ||
| pyproject.toml | ||
| pyrightconfig.json | ||
| pytest.ini | ||
| README.md | ||
| run_backlog.sh | ||
| run_lambda_local.sh | ||
| serverless.yml | ||
| 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