Model/backend/epc_api/json_samples
Jun-te Kim bb5746c9b5 Recognise "complete" as a MAIN building part, and anchor lone parts 🟪
Six properties failed task 4d006fab (portfolio 854 / scenario 1334) with
DegeneratePredictionError. None has a lodged EPC, so each was predicted from a
neighbouring-cert cohort — and every cohort cert lodges its single building part
as `identifier: "complete"`. from_api_string accepted only "Main Dwelling" /
"Main building", so "complete" fell to OTHER, _has_main_part returned False, and
prediction refused to proceed.

"complete" is what SAP 9.91/9.92-era software writes for an unextended dwelling:
semantically identical to "Main Dwelling". Casing varies within a single postcode
(cert 8824-7422-1180-6934-1902 lodges "complete", 199 Highfield Road "Complete"),
so matching is now case-folded.

The API's `identifier` is free text with no schema enum — api.yml declares the
whole cert body `additionalProperties: true` and documents no field of it, and
`identifier` is absent from the 17 vocabularies at /api/codes. So the recognised
set can only grow by discovery, and each miss has cost an incident ("Main
building" → task a40e71c4; "complete" → task 4d006fab). Hence three changes, not
one:

- "complete" → MAIN, case-insensitively.
- Bare "Extension" → EXTENSION_1. The regex required a digit, so 668 corpus
  occurrences silently dropped a real extension from the structure. This reverses
  a prior deliberate pin whose stated rationale (RdSAP10 §1.2's 4-extension cap)
  does not apply — there is no out-of-range number in a bare "Extension".
- _anchor_lone_building_part: a cert lodging exactly ONE part describes the whole
  dwelling whatever it is called, so an unclassified lone part becomes MAIN.
  Multi-part certs are untouched — there the identifier carries real information
  and guessing would invent structure the cert does not state.

Also removes a false claim from DegeneratePredictionError's message: it asserted
the template was "lodged with a null part identifier", which was hardcoded, never
checked against a real cert, and wrong. It misdirected this investigation.

Verified against the live gov API: all 13 cohort certs across BL1 8EB, BL3 6XJ
and BL4 0RA now resolve a MAIN part. The full modelling e2e was NOT run (no local
AWS creds for the geospatial lookup) — this clears the blocking error, it does not
prove the predictions are good.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-28 15:12:01 +00:00
..
CEPC-7.0 adding hacky handling for matching on lmk key or uprn 2026-04-09 14:47:54 +01:00
CEPC-7.1 adding hacky handling for matching on lmk key or uprn 2026-04-09 14:47:54 +01:00
CEPC-8.0.0 adding hacky handling for matching on lmk key or uprn 2026-04-09 14:47:54 +01:00
RdSAP-Schema-17.0 Map RdSAP-Schema-17.0 certs to EpcPropertyData 🟥 2026-06-12 12:40:04 +00:00
RdSAP-Schema-17.1 Dispatch and map RdSAP-Schema-18.0 certs end-to-end 🟥 2026-06-11 11:12:53 +00:00
RdSAP-Schema-18.0 Dispatch and map RdSAP-Schema-18.0 certs end-to-end 🟥 2026-06-11 11:12:53 +00:00
RdSAP-Schema-19.0 Map RdSAP-Schema-19.0 certs to EpcPropertyData 🟥 2026-06-12 12:19:16 +00:00
RdSAP-Schema-20.0.0 added test for a 1000 examples 2026-06-09 16:02:21 +00:00
RdSAP-Schema-21.0.0 adding hacky handling for matching on lmk key or uprn 2026-04-09 14:47:54 +01:00
RdSAP-Schema-21.0.1 added test for a 1000 examples 2026-06-09 16:02:21 +00:00
real_life_examples Recognise "complete" as a MAIN building part, and anchor lone parts 🟪 2026-07-28 15:12:01 +00:00
SAP-Schema-16.0 adding hacky handling for matching on lmk key or uprn 2026-04-09 14:47:54 +01:00
SAP-Schema-16.1 adding hacky handling for matching on lmk key or uprn 2026-04-09 14:47:54 +01:00
SAP-Schema-16.2 adding hacky handling for matching on lmk key or uprn 2026-04-09 14:47:54 +01:00
SAP-Schema-16.3 adding hacky handling for matching on lmk key or uprn 2026-04-09 14:47:54 +01:00
SAP-Schema-17.0 adding hacky handling for matching on lmk key or uprn 2026-04-09 14:47:54 +01:00
SAP-Schema-17.1 inviestigation with hyde values 2026-06-15 12:13:11 +00:00
SAP-Schema-18.0.0 adding hacky handling for matching on lmk key or uprn 2026-04-09 14:47:54 +01:00
SAP-Schema-19.0.0 adding hacky handling for matching on lmk key or uprn 2026-04-09 14:47:54 +01:00
SAP-Schema-19.1.0 adding hacky handling for matching on lmk key or uprn 2026-04-09 14:47:54 +01:00
SAP-Schema-19.2.0 adding hacky handling for matching on lmk key or uprn 2026-04-09 14:47:54 +01:00