mirror of
https://github.com/Hestia-Homes/Model.git
synced 2026-07-12 13:29:04 +00:00
docs: ADR-0037 + Full-SAP Assessment term for the baseline-downgrade family
Captures the grill-with-docs decisions for the full-SAP-17.1 mapper completion: rebaseline-to-10.2 (restores Rebaselining trigger (a)), calc-affecting fields coupled with the sap_version flip, and growing Elmhurst-anchored validation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
c89ab7692d
commit
2d18e9a3b0
2 changed files with 30 additions and 0 deletions
|
|
@ -35,6 +35,10 @@ _Avoid_: energy rating, EPC grade, EPC score
|
|||
The versioned RdSAP or SAP schema that describes the structure of an EPC's raw data (e.g. `RdSAP-Schema-21.0.1`).
|
||||
_Avoid_: schema version, EPC format
|
||||
|
||||
**Full-SAP Assessment**:
|
||||
A cert produced by a **full SAP** calculation rather than the reduced **RdSAP** procedure — lodged with `assessment_type = "SAP"` and a measured-openings structure (`sap_opening_types`, per-opening U-values), typically on an older spec (`SAP-Schema-16.x/17.x`, `sap_version` ~9.9x = SAP 2012). Structurally distinct from an **RdSAP Assessment** (reduced categorical fabric, no measured openings), so it has its own mapper (`from_sap_schema_17_1`), routed to by **structure not label** (a structurally full-SAP cert is mapped here regardless of a mislabelled `schema_type`). Because full-SAP certs lodge pre-10.2 figures they are **rebaselined** to SAP 10.2 like any pre-SAP10 cert (Rebaselining trigger (a)); a mapper that drops their `sap_version` silently suppresses that rebaseline and leaves **Effective Performance** stuck on the lodged value (ADR-0037).
|
||||
_Avoid_: SAP cert (ambiguous — every EPC is a SAP-derived cert), on-construction EPC (overlaps but not synonymous)
|
||||
|
||||
**Domestic Certificate**:
|
||||
An EPC issued for a residential dwelling, as opposed to a commercial one.
|
||||
_Avoid_: residential EPC, home EPC
|
||||
|
|
|
|||
26
docs/adr/0037-full-sap-cert-family-rebaselines-like-rdsap.md
Normal file
26
docs/adr/0037-full-sap-cert-family-rebaselines-like-rdsap.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
# Full-SAP cert family rebaselines to SAP 10.2, validated by growing Elmhurst-anchored coverage
|
||||
|
||||
## Context
|
||||
|
||||
Certs come in two structural families: **RdSAP** (reduced-data) and **full-SAP** (measured openings, `assessment_type = "SAP"`, e.g. `SAP-Schema-16.x/17.x`, lodged under SAP 2012 / `sap_version` ~9.9x). Full-SAP certs route through `_from_full_sap` → `from_sap_schema_17_1`, a WIP mapper that left `sap_version`, `property_type`, `built_form`, `secondary_heating` and the display `EnergyElement`s (`main_heating`/`window`/`lighting`/`hot_water`) unmapped — even though the raw cert carries them all.
|
||||
|
||||
Because `sap_version` was `None`, **Rebaselining** trigger (a) (`sap_version < 10.2` → Effective = Calculated, see CONTEXT.md / ADR-0013) could not fire, so **Effective Performance wrongly stayed equal to the lodged SAP-2012 value** while the Plan modelled the SAP-10.2 calc. Result: an "impossible" post-works downgrade (effective B/84 vs post-works C/80.14) on ≈**3,824 of 34,917** portfolio-796 plans (100% `effective == lodged` signature), an all-"Unknown" property-details panel, and zero recommendations. `property_type = None` also mis-classifies the dwelling in `heat_transmission` (`_is_house`/`_is_flat_or_maisonette`), so the calc value itself was degraded.
|
||||
|
||||
## Decision
|
||||
|
||||
Complete `SapSchema17_1` + `from_sap_schema_17_1` for the **calc-affecting** fields (`sap_version`, `property_type`, `built_form`, `secondary_heating`) **and** the display `EnergyElement`s in **one slice**, mirroring `from_rdsap_schema_17_1` inline (the repo's one-mapper-per-schema convention; equivalence guarded by test, not a shared helper). This makes the full-SAP family rebaseline to SAP 10.2 exactly as pre-10.2 RdSAP certs already do — **restoring documented behaviour, not a new policy**.
|
||||
|
||||
The `sap_version` flip and the categorical completion are **coupled**: neither ships alone, because flipping Effective to a calc fed a `None` `property_type` would replace a wrong-high lodged score with a confidently-wrong-low calc one.
|
||||
|
||||
## Validation
|
||||
|
||||
The full-SAP path has **no accuracy corpus** (the gauge is RdSAP-21.0.1 only) and the lodged SAP-2012 value is not a valid SAP-10.2 target (Validation Cohort rule). We accept the path on **sufficient, growing coverage** rather than full corpus parity:
|
||||
|
||||
- mapper-completeness unit tests (SAP-17.1 fixture → fields mapped),
|
||||
- the RdSAP-21.0.1 accuracy corpus staying green (the main path is untouched — ratchet not loosened),
|
||||
- **≥1 Elmhurst-anchored full-SAP `RealCertExpectation` gating the merge** (Jun-te's Elmhurst skill provides the accredited SAP-10.2 ground truth), coverage growing cert-by-cert over time,
|
||||
- a post-fix **population sanity sweep** flagging survivors (Effective ≥2 bands / >15 SAP below Lodged) for separate triage — surfaced, never silently shipped.
|
||||
|
||||
## Consequences
|
||||
|
||||
Deploying and re-running flips ~3,824 portfolio-796 Effective baselines from lodged-SAP-2012 to our-SAP-10.2; many legitimately drop a band. FE/product should expect a **visible population-wide baseline shift** — this is correct Rebaselining, not a regression. The RdSAP-path downgrades (Case B: ~8,160 plans, avg drop 0.7) are a **separate cause**, not addressed here. Tracked under the `fix/baseline-downgrades` umbrella, this being the first (full-SAP) sub-branch.
|
||||
Loading…
Add table
Reference in a new issue