Measured, not asserted

Does obfuscation break demand charge calculation?

A demand charge is not what a site consumed, it is what its worst quarter of an hour cost the network to be ready for. That makes it a number taken over a window -- and a window is one of the things a renamed name can quietly move.

The window decides the number

Commercial electricity bills have two parts. The energy charge is what was used. The demand charge is set by the highest average load over a window -- fifteen minutes, thirty minutes, an hour, depending on the tariff -- multiplied by a rate per kilowatt. A shorter window finds a higher peak from exactly the same meter data, because a brief spike has less time to average away.

The tariff measured here files a thirty-minute window; the library defaults to fifteen. The sample bills three sites: a plant sitting under a ratchet floor, a site whose morning contains one 480 kW compressor start among readings near 300, and a site running a smooth sustained afternoon.

Protection alone changed nothing, here as in the other four areas: twenty-five comparisons across five presets, all identical.

One rename, three different bills

Renaming demandWindowMinutes replaced thirty minutes with fifteen. The spike site's measured peak went from 393.0 kW to 480.0 kW and its bill from $7,270.50 to $8,880.00 -- the compressor start billed in full instead of averaged down, an extra $1,609.50 for a load that lasted a quarter of an hour.

The smooth site moved from $8,482.25 to $8,547.00, a difference of $64.75, because a sustained load barely notices how it is averaged. And the plant did not move at all. Its bill stayed at $10,360.00 on both windows.

That last one is the interesting result, and it is the reason this file was built with three sites rather than one.

A floor can hide a wrong window, but only for some customers

The plant is billed on a ratchet: this tariff charges the higher of the current peak and eighty per cent of the highest peak in the preceding eleven months. Its August peak of 700 kW sets a floor of 560 kW, and a quiet month sits well below that on either averaging window. So the floor is what it pays, and the wrong window is invisible on its bill.

Renaming ratchetPct instead removed that floor -- the library default is zero -- and the plant dropped from $10,360.00 to $5,725.75, a $4,634.25 under-charge, while the other two sites did not move. Two options, two disjoint sets of victims.

The combined arm is what makes the point. Renaming both did not equal either half: the plant paid $5,753.50, the spike site $8,880.00, the smooth site $8,547.00. So a file-level test asking "is the combination the same as one half?" would report no masking here -- while on the plant's own row the masking is total. Masking is a property of a record, not of a file, and a matrix read at file level will miss it.

A peak of zero is a finite number

The most quietly wrong arm in this file is the kilowatt reading itself. Renaming kw made every interval unreadable, which is exactly the case a finite check is supposed to catch.

It did not catch it. The engine computes a maximum by comparing each window average against the best so far, and a comparison against an unreadable value is false, so no candidate ever replaced the initial zero. The result was measured peak 0.0 kW, and zero is finite, so the guard passed. Every site was then billed on its ratchet floor with no error raised anywhere.

This is worth carrying beyond metering. A reduction that starts from an identity value and updates on a comparison does not produce an unreadable result when its inputs become unreadable -- it produces the identity. Maximums come back as zero, minimums as infinity, sums as zero, and a finite check waves all of them through. If a maximum matters, assert that it was actually taken from a reading, not merely that it is a number.

By contrast the return shape of the ratchet rule failed loudly. Renaming billableKw left the engine formatting an undefined value and it threw a TypeError before any bill existed. Loud, immediate, recoverable.

What to check

Assert the provenance of a peak, not just its finiteness: the billable demand should be traceable to a specific interval, and a peak that matches no interval in the month is a fault whatever its value. That check is a few lines and it catches the zero case, the wrong-window case and a genuinely empty month.

Compare the measured peak against the interval count it was drawn from, and alert when a site's billable demand equals its ratchet floor for the first time -- that is where a wrong window hides, because the floor is the same number either way.

And keep the rename pattern away from the option keys and record fields an installed rating library reads. That advice is unchanged across every area this series has measured, because the mechanism is unchanged: a library matches those names by text, and renamed text does not match.

Frequently asked questions

Does obfuscation change a demand charge?

Not on its own. Protection alone left every output identical across five presets and five areas measured this pass. The differences here come from member renaming, which is opt-in and driven by a pattern you write.

What did losing the averaging window cost?

The filed thirty-minute window was replaced by the library's fifteen-minute default. One site's measured peak went from 393.0 kW to 480.0 kW and its bill from $7,270.50 to $8,880.00, because a single compressor start was billed in full instead of averaged down.

Did every site move?

No, and that is the important part. A smooth site moved by $64.75, and a plant billed on its ratchet floor did not move at all, because the floor is the same number on either window.

Does the ratchet make things safer, then?

It hides the fault on the accounts it covers, which is not the same thing. Renaming the ratchet percentage instead removed the floor and under-charged that plant by $4,634.25, while leaving the other two sites untouched. The two options have disjoint victims.

Was the combined rename the same as one half alone?

No. All three sites moved in the combined arm, so a file-level comparison would report no masking -- even though on the plant's own row the masking is complete. Masking is a property of a record rather than of a file.

What happened when the kilowatt readings were renamed?

The measured peak came back as 0.0 kW rather than as an unreadable value, because a maximum built by comparison never replaces its starting zero when every comparison is false. Zero is finite, so the finite check passed and every site was billed on its ratchet floor.

What check would have caught that?

Asserting the provenance of the peak. A billable demand should be traceable to a specific interval in the month, and one that matches no interval is a fault whatever its value. Finiteness alone cannot express that.

Related reading