mirror of
https://github.com/Hestia-Homes/Model.git
synced 2026-06-08 11:17:27 +00:00
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> |
||
|---|---|---|
| .. | ||
| domain | ||
| fetchers | ||
| repos | ||
| utils | ||
| 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/.