# 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](../../CONTEXT.md#baseline-performance). 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.
