junte/assessment-model
1
0
Fork 0
mirror of https://github.com/Hestia-Homes/assessment-model.git synced 2026-07-27 22:45:03 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
assessment-model/docs/adr/0002-effective-performance-is-canonical-current.md
Khalim Conn-Kowlessar 83f65567cf docs: reporting glossary terms + ADR-0010 compliance-window filter 
Gross/Net cost, Project delivery, Current stock, Likely downgrade/upgrade
(band movement) added to CONTEXT.md from the reporting-redesign grilling
session. ADR-0010 records the compliance-window filter as a report-view
parameter, not a Scenario constraint. Also commits the previously
untracked ADR-0001/0002 docs.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-07 22:08:35 +00:00

3.3 KiB
Raw Blame History

2. Effective performance is the canonical "current" for display and reporting

Date: 2026-06-23

Status

Accepted (supersedes the "reporting stays on lodged" position recorded mid-migration in docs/wip/new-modelling-ui-handover.md).

Context

property_baseline_performance carries two baselines per property: Lodged performance (lodged_* — what was submitted to the government EPC register) and Effective performance (effective_* — what the modelling engine actually scored against, after a Rebaseline). See the glossary in CONTEXT.md. They diverge whenever rebaseline_reason != none — most commonly pre_sap10, where the lodged certificate used an older SAP version. In today's data 509 of 510 new-approach properties are rebaselined, so the two baselines disagree for almost everyone.

The plans (post-retrofit SAP/EPC, savings, valuation uplift) are all scored against the effective baseline. If a property's displayed "current" is the lodged figure, a plan reads as flat or as a downgrade — e.g. lodged C/78 vs an effective baseline of C/71 with a post-retrofit of C/71.4. The first cut of the migration switched only the per-property building-passport views to effective and deliberately left the portfolio list + reporting aggregates on lodged "to match the gov register." That left reporting's "current" disagreeing with every property row's "current."

Decision

Effective performance is the canonical "current" everywhere we show or aggregate a property's present-day state — per-property views and reporting. Lodged performance is shown only as an explicit secondary "Lodged EPC" surface.

  • Per-property resolvers (resolvePropertyHeadline, resolveDetailsEpcMeta, resolveNewConditionReport) return effective_* for new-approach properties.
  • Set-based fragments gain effectiveSapSql / effectiveEpcBandSql; the portfolio property table and the reporting analytics (AVG(sap), EPC-band distribution) both read them. The original lodged_* fragments remain solely to feed the dedicated "Lodged EPC" column/badge.
  • The "Lodged EPC" surface renders only when a real certificate exists (source = lodged); a predicted property shows the "estimated from nearby homes" signal and no lodged figure, even though its lodged_* columns are populated with mirrored estimates.
  • Legacy (pre-cutoff) properties are unaffected: the fragments fall back to the property row columns, and the provenance signal is none.

Consequences

  • Reporting totals no longer reconcile to the gov EPC register; they reflect the modelled (effective) baseline. This is intentional — the register view is available per-property via the Lodged EPC column. If a register-fidelity reporting view is ever needed, it is a separate surface built on the retained lodged_* fragments, not a reversion.
  • "Current" in the UI now means Effective performance, contradicting the glossary's advice to avoid "current performance" for Effective. Recorded as a flagged ambiguity in CONTEXT.md so the next reader doesn't "correct" it.
  • The split is the seam that matters: per-property object resolvers and the two display fragments are effective; the lodged fragments still exist and must not be deleted while the Lodged EPC surfaces use them.