Measured, not asserted
Published
A time-of-use tariff charges the same kilowatt-hour a different price depending on the hour it arrived in. Move the boundary and nothing is lost: every unit is still counted exactly once, at a price that is still exactly right for the window it was put in.
A window is not a quantity
The tariff measured here runs peak from 16:00 to 21:00 and charges $0.42 against $0.11 off-peak. The library's own generic default window is 12:00 to 18:00. Those two windows overlap, which is what makes this interesting: losing the filed window does not shift every hour one way, it moves the afternoon into peak and the evening out of it.
Nothing goes missing when that happens. The meter data is complete, every interval is rated exactly once, and the month's consumption is identical to the tenth of a kilowatt-hour. A reconciliation of billed units against metered units -- the check a utility actually runs, and the one this series has previously recommended -- passes without a murmur.
As in every area this pass, protection alone changed nothing: five presets, no differences. The results below come from renaming the members the rating engine reads.
Two customers, opposite directions
The sample bills two accounts on the same tariff in the same month. A household consumes in the evening, with most of its load between 18:00 and 21:00. An office consumes at midday and is nearly dark by six.
Renaming both window keys replaced 16:00-21:00 with the vendor's 12:00-18:00. The household went from 15.7 peak kilowatt-hours to 2.9, and its bill fell from $6.96 to $2.99. The office went from 5.5 peak kilowatt-hours to 67.5, and its bill rose from $11.49 to $30.71. Same tariff, same rename, same month, opposite directions -- because the two load shapes sit on opposite sides of the boundary that moved.
The consumption total did not move at all: 108.0 kWh across both accounts before and after. That is the number a meter-to-bill reconciliation checks, and it is exactly as correct after the fault as before it. What moved was which price each unit was rated at, and no aggregate of units can see that.
Renaming one end of the window is worse than it looks
The two halves behave differently on their own, which matters for anyone reading a diff and deciding what is cosmetic. Renaming peakStartHour alone moved the household from 15.7 peak kWh to 16.2 -- a change of half a kilowatt-hour, the sort of difference a reviewer closes as noise. Renaming peakEndHour alone moved the same household from 15.7 to 2.4, because the evening block it actually consumes in fell outside the window entirely.
One end of a range is not interchangeable with the other. Which end matters depends on where the customer's load sits, and every customer's load sits somewhere different, so there is no single account you can spot-check to decide whether a window change is harmless.
The record field, and the return shape
The hour on each interval record is the other half of the comparison, and it fails in a single direction. Renamed, every interval's hour reads as undefined, and undefined >= 16 is false, so every unit in the file was rated off-peak: 19.0 kWh total -- 0.0 peak, 19.0 off-peak. Every customer under-billed, no error raised, and the consumption total again unchanged.
The caller-supplied hour classifier hands back a flag saying whether the hour is peak. Renaming that flag produced the same result -- everything off-peak -- because a missing flag is falsy and falsy means off-peak. That is the polarity point this series keeps arriving at: a flag your collaborator hands back should be phrased as a permission, because a missing permission reads as no and a missing prohibition reads as yes. Here "is it peak" reads as no, and no is the cheap answer.
Renaming the quantity instead of the window failed closed and loudly, as it usually does. With kwh renamed the charge became unreadable and the engine refused: BILLED=false non-finite-charge(refused before billing). Losing the number is recoverable within the hour. Losing what the number is priced at is not, because nothing tells you.
What to reconcile instead
If billed units always equal metered units by construction, that comparison cannot distinguish a correct tariff from an incorrect one. It is worth running -- it catches lost and duplicated reads -- but it is not evidence about rating.
The check that does bite is a shadow calculation on the split: how many units landed in each window, per account, compared against what that account's load shape historically produces. A residential account that has always billed sixty per cent peak and now bills fifteen per cent has not changed its habits overnight. That comparison is cheap, it is per-customer, and unlike a total it does not cancel.
The rename mitigation is the same as everywhere else in this series. Member renaming is opt-in and the pattern is yours: keep the option keys an installed rating library reads, and the field names on records handed to one, outside it.
Frequently asked questions
Does obfuscation change what a time-of-use tariff charges?
Not on its own. Protection alone was measured across five presets on five areas this pass and changed no output at all. The differences described here come from member renaming, which is a separate option with a pattern you control.
What was the measured effect of losing the peak window?
The filed 16:00-21:00 window was replaced by the library's generic 12:00-18:00 default. A household's bill fell from $6.96 to $2.99 and an office's rose from $11.49 to $30.71, in the same month on the same tariff.
Why did the two customers move in opposite directions?
Because the windows overlap. Moving the boundary pushes the afternoon into peak and the evening out of it, so an account that consumes at midday is over-charged while one that consumes in the evening is under-charged.
Would a reconciliation have caught it?
No. Total consumption was 108.0 kWh across both accounts before and after, identical to the tenth of a kilowatt-hour, because every unit was still billed exactly once. A units-based reconciliation is structurally unable to see a rating fault.
Is renaming one end of the window less serious than both?
Not reliably. Renaming the start hour alone moved one household by half a kilowatt-hour, which looks like noise; renaming the end hour alone moved the same household from 15.7 peak kWh to 2.4. Which end matters depends entirely on where the customer's load sits.
What happens if the hour on the interval record is renamed?
Every interval is rated off-peak, because a comparison against undefined is false. The same result came from renaming the flag the classifier hands back, since a missing flag is falsy and falsy means off-peak.
What check should replace the reconciliation?
A per-account comparison of the peak and off-peak split against that account's historical shape. Totals cancel across a book of customers; a per-customer split does not, and it is cheap to compute from data you already store.
Related reading