Model/docs/baseline-downgrade-followups.md

Follow-ups from the full-SAP baseline-downgrade work (ADR-0037)

Open items surfaced while fixing the full-SAP mapper / portfolio-796 downgrades. Each is separate from the full-SAP fix (fix/baseline-downgrades).

1. RdSAP ventilation mapping is inconsistent across schemas

Severity: accuracy bug for MEV/MVHR dwellings. The mappers handle sap_ventilation four different ways:

• 17_0 + full-SAP — build via _sap_17_1_ventilation, which maps mechanical_ventilation_kind. ✅
• 21_0_1 — rich inline SapVentilation(...) incl. the kind. ✅
• 17_1 / 18_0 / 20_0_0 — built SapVentilation(sheltered_sides=…) and dropped the kind. Fixed in #1333 (mirror _api_mechanical_ventilation_kind).
• 19_0 / 21_0_0 — set no sap_ventilation at all → the EpcPropertyData default (None). They dropped the entire ventilation block (sheltered sides + kind), not just the kind. Fixed in feat/rdsap-19-21-ventilation: both now construct SapVentilation(...) mirroring 21.0.1, but only for the fields each schema lodges — the top-level mechanical_ventilation enum (→ kind) and sheltered_sides (from built_form). Neither lodges the fan/flue/vent counts, so those stay unset (RdSAP Table-5 age defaults — see counts note below).

Either way, an MEV/MVHR cert (mechanical_ventilation ≠ 0) is treated as natural by the affected mappers — wrong §2 ventilation cascade (and heat recovery). Natural certs (code 0/5 → None) are unaffected.

• For natural-ventilation certs (mechanical_ventilation = 0, e.g. UPRN 100020603823 / property 726605) it's benign — unmapped → None defaults to natural in the §2 cascade.
• For MEV/MVHR certs (mechanical_ventilation ≠ 0) the calculator treats the dwelling as naturally ventilated, getting the SAP §2 ventilation cascade (and any heat recovery) wrong → mis-scored SAP.

The granular counts (fans/flues/vents) are not a bug: older RdSAP open-data certs don't lodge them, and the calc correctly uses RdSAP Table-5 age defaults. percent_draughtproofed is mapped (top-level) and read by the calc.

19.0 / 21.0.0 fix (done, feat/rdsap-19-21-ventilation): both build SapVentilation(sheltered_sides=…, mechanical_ventilation_kind=…) mirroring 21.0.1. Guarded by the extended mapper-level MVHR test + a sheltered_sides regression, with the corpus (held 73.3% / MAE 0.774 — it's 21.0.1-only so the change isn't exercised by it) and the 6002-case mapper-corpus staying green. Outstanding SAP-accuracy fast-follow: an Elmhurst-anchored MEV/MVHR RealCertExpectation (the corpus is natural-vent-dominated, so the kind change isn't exercised by it). Blast radius (still to quantify): count portfolio-796 certs on schema 19.0 / 21.0.0 with mechanical_ventilation ≠ 0.

2. FE "Main Fuel: Unknown" is FE-side, not a Model mapper gap

main_fuel_type (the gov fuel code) is populated Model-side — UPRN 10093412452 (709791) → 1, UPRN 100020603823 (726605) → 26 — and is persisted (epc_main_heating_detail.main_fuel_type). So the panel's "Main Fuel: Unknown" is the front-end either not mapping the code → fuel name or reading a field we don't populate. Needs an FE-repo (Drizzle/Next) check, not a Model change.

3. Survivor clusters from the post-fix population sweep

scripts/hyde/case_a_population_sweep.py: the representative sample rebaselined cleanly (0 survivors), but the worst-old-drop sample held 28 survivors (lodged A/B → new C/D, 15–25 SAP) in tight UPRN clusters (new-build blocks), spanning multiple schemas (16.0/16.1/17.1/18.0.0) and heating types. No single mapper-gap signature → likely genuine SAP-2012→10.2 drops for very-high-lodged new-builds, but triage one in Elmhurst to confirm genuine vs a residual calc issue before trusting the cohort.

4. Predicted-property display path (e.g. property 721167)

721167 has no lodged EPC (predicted). Its Heating-Control / Main-Fuel / Ventilation Unknowns come from the prediction synthesis path (domain/epc_prediction/epc_prediction.py), not the lodged-cert mappers and not the landlord-override overlay (overlays_from is simulation-time only, ADR-0032 — it never writes the persisted/displayed EPC). Investigated and fixed on fix/predicted-property-display-unknowns:

• Heating Control — FIXED (Model). _apply_heating_donor copied the donor's calc sap_heating cluster but left the display rows (main_heating, main_heating_controls) on the size-representative structural template — incoherent with the donated system, and "Unknown" whenever the template lodged no control row (exactly 721167: no main_heating_controls energy element persisted). Now carries the donor's display heating + control alongside the calc cluster.
• Ventilation — FIXED (Model). The prediction never synthesised ventilation — it kept the template's sap_ventilation, so a predicted dwelling in an MEV/MVHR neighbourhood was scored + displayed as natural. New _apply_ventilation_mode modes mechanical_ventilation_kind across the cohort (recency/geo-weighted, mirroring glazing). Natural-vent cohorts mode to None and stay natural (§2 default) — so a genuinely natural dwelling like 721167 correctly stays natural; the fix moves only real MEV/MVHR neighbourhoods.
• Main Fuel — NOT a prediction gap. epc_main_heating_detail.main_fuel_type is persisted for predicted properties (721167 → 26 = mains gas, carried from the heating donor). The "Unknown" is the same FE code→name gap as item 2 (the Drizzle/Next repo not mapping the fuel code), not a Model issue.

Both fixes are display-only for the calculator (component-accuracy gate, corpus harness, and prediction e2e all green); persistence already carries main_heating_controls (energy element) and ventilation_mechanical_ventilation_kind, so the synthesised values reach the passport on the next prediction run.