Energy uprating starts from the data year, not the price-level year the build stores #1867

Follow-up to #1859 / #1860. #1860 is not the fix it claimed to be, and I wrote it. Raising this rather than leaving a double count in place.

The problem

uprating_indices.yaml uprates from the dataset's data year (2024 for enhanced_frs_2024_25). But the energy variables are not stored at 2024 price levels.

In policyengine-uk-data 1.56.16, imputations/consumption.py calibrates electricity and gas to NEED 2023 mean kWh by income band, converted to pounds at Ofgem Q2 2026 unit rates. Its docstring states the stored values represent FY26/27 price levels, and that the variables are deliberately not CPI-uprated so no price-level adjustment is needed at simulation time.

So applying CPI from 2024 re-applies 2024→2026 price changes that the build has already priced in — roughly 5.8pp of the 7.9% uplift.

Evidence, measured on the certified bundle

The Ofgem cap parameter falls over this period, which makes the stored price level testable:

Modelled mean household electricity + gas is £1,584 in every year of the current bundle. If the stored level were 2024 prices it would have to sit near the 2024 cap; it sits just below the 2026 one. That is the April 2026 price level the docstring describes.

Meanwhile domestic_energy_consumption, which has been on the CPI list since before 2.90.2, reads:

Same underlying data, +7.9% applied on top of an already-2026 price level.

What this means for #1859 and #1860

#1859 observed that electricity_consumption and gas_consumption were flat while domestic_energy_consumption rose, and treated the flat pair as the defect. It was the other way round: the flat pair was right (accidentally — they were absent from the YAML rather than deliberately excluded), and the combined variable was carrying a double count.

#1860 restored the documented identity electricity + gas == domestic by making the pair match the combined variable's behaviour. The identity now holds, but at the wrong price level for all three.

Credit to @juaristi22, who caught this reviewing a downstream study; she reviewed #1860 and did not catch it either, and nor did I.

Suggested fix

Uprating needs to start from the price-level year the build stores, not the data year. Options, in rough order of preference:

1. Let the dataset declare a price-level year per variable (or per variable group), and have apply_single_year_uprating / reset_growthfactor_uprating start there. This fixes the class of problem, not just energy.
2. Failing that, remove domestic_energy_consumption, electricity_consumption and gas_consumption from the CPI list and document that they are stored at FY26/27 prices — restoring the identity at the build's own price level.

Option 2 is a one-line revert of #1860 plus one deletion, and is correct today. Option 1 is the durable fix.

Either way the code-health guard added in #1863 should gain an exception entry with the reason, so the absence is deliberate and documented rather than looking like the gap #1859 reported.

Downstream

impact-iran-war-living-standards defines every scenario percentage relative to the pre-conflict April–June 2026 baseline, which is exactly the price level the build stores — so that study should not take the 7.9% uplift. I had been reporting a pending +4% correction to its headline on the strength of #1860. That figure is an overstatement, and I am correcting it there.