From 645789456e10dcde4ee24891f889370342af1d6e Mon Sep 17 00:00:00 2001 From: Jun-te Kim Date: Fri, 3 Jul 2026 10:19:05 +0000 Subject: [PATCH] =?UTF-8?q?docs(corpus):=20find=20the=20third=20driver=20?= =?UTF-8?q?=E2=80=94=20mixer-shower=20default,=2091%=20of=20gap=20now=20tr?= =?UTF-8?q?aced?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Walked the water-heating worksheet section: assumed occupancy (42) matched exactly (2.4234 both sides), but (43) average daily hot water use was 117.41 L/day (Elmhurst) vs 110.73 L/day (ours) — same occupancy, different shower/bath demand. Root cause: the cert's shower_outlets field is genuinely unlodged, which the mapper correctly maps to 0 mixer showers per its documented, already-validated "no entry = no shower" convention. Elmhurst's build shows a "Non-electric shower" fixture anyway — its UI silently defaults one when the build script doesn't explicitly configure "0 showers" to match the cert. Verified: a single 7 L/min vented mixer reproduces Elmhurst's (42a) monthly series exactly (4 d.p., all 12 months) and closes hot water to 2616.04 vs Elmhurst's 2616.03. Corpus-wide check across 170 certs sharing this "bath present, no shower data" pattern shows no systematic bias (mean dSAP +0.12, median -0.04) — confirms the mapper convention is correct on average; this is a build-entry artifact on this one cert, not a mapper bug (no code change warranted). Combining all three found causes (window orientation, Table 11, shower default): SAP 72.4567 vs Elmhurst's precise 72.0681 — residual 0.39, ~91% of the original 4.26-point gap now precisely explained. Co-Authored-By: Claude Fable 5 --- .../test_real_cert_sap_accuracy.py | 34 +++++++++++++++---- 1 file changed, 28 insertions(+), 6 deletions(-) diff --git a/tests/domain/sap10_calculator/test_real_cert_sap_accuracy.py b/tests/domain/sap10_calculator/test_real_cert_sap_accuracy.py index 24dde9482..0bc3a95a7 100644 --- a/tests/domain/sap10_calculator/test_real_cert_sap_accuracy.py +++ b/tests/domain/sap10_calculator/test_real_cert_sap_accuracy.py @@ -907,12 +907,34 @@ _EXPECTATIONS: Final[tuple[RealCertExpectation, ...]] = ( # (Elmhurst Jan (83)=56.9 W vs our real-orientation 123.4 W). Verified: # forcing our engine to ALSO use a single synthetic North window (i.e. # replicating the build's simplification, not a cert or engine fact) - # plus the forced Table 11 above reproduces 72.62 -- matches Elmhurst's - # 72 almost exactly. Conclusion: the calculator is faithful (it already - # matches lodged exactly using the cert's REAL window orientations); - # both residuals are Elmhurst-worksheet-reconciliation artifacts (a - # deliberate spec choice + a build-entry simplification), not mapping - # or calculator bugs. PINNED to the observed exact match vs lodged. + # plus the forced Table 11 above reproduces 72.62 (precise Elmhurst + # value is 72.0681, not the rounded "72" -- true residual after Table + # 11 + windows was ~0.55, not ~1.6). Third cause found by walking the + # rest of the worksheet monthly: (43) Average daily hot water use is + # 117.4056 L/day (Elmhurst) vs our 110.7281 L/day -- SAME occupancy + # (42)=2.4234 both sides, so the gap is in shower/bath demand, not + # occupancy. Root cause: cert's `mixer_shower_count` is unlodged (raw + # `shower_outlets=None`), which `_mixer_shower_flow_rates_from_cert` + # maps to 0 showers (see its docstring: gov-API "no shower_outlets + # entry" convention, validated on cert 2225) -- but Elmhurst's build + # shows a "Non-electric shower" fixture (1 vented mixer @ Table J4), + # since its UI silently defaults one when the build script never + # explicitly configured "0 showers" to match the cert. Verified: a + # single 7 L/min vented mixer reproduces Elmhurst's (42a) monthly + # series EXACTLY (4 d.p., all 12 months) and closes hot water to + # 2616.04 vs Elmhurst's 2616.03 (Δ0.005). Corpus-wide check (170 + # certs sharing "bath present, no shower data lodged") shows NO + # systematic bias (mean dSAP +0.12, median -0.04, 46.5% over-rated) -- + # confirms the mapper's 0-showers convention is correct on average; + # this is a THIRD build-entry artifact, not a mapper bug. Combining + # all three (windows + Table 11 + 1 shower): SAP 72.4567 vs Elmhurst's + # precise 72.0681 -- residual 0.39, ~91% of the original 4.26-point + # gap (76.33 vs 72.07) now precisely explained. Conclusion: the + # calculator is faithful (matches lodged 76 exactly using the cert's + # REAL windows and REAL shower data); all three residuals are Elmhurst + # -reconciliation-build artifacts or deliberate spec choices, not + # mapping or calculator bugs. PINNED to the observed exact match vs + # lodged. RealCertExpectation( schema="RdSAP-Schema-21.0.1", sample="uprn_100061275133",