Missing Is Not Zero

Chapter one

The failure that looks like health

For eleven consecutive days, a fleet we were assessing reported measured irradiance of exactly zero at every site.

Not missing. Zero.

The rows arrived on their normal cadence the entire time. Row counts were nominal. No staleness check fired, because nothing was stale. No communications alarm raised, because the links were healthy. No tile went grey, because there was nothing absent for a monitoring system to notice. There was simply a wrong number — present, punctual, at every site, for eleven days.

Every performance-ratio and insolation-quality calculation downstream consumed those zeros as measurement. Eleven days of numbers that were precise, internally consistent, confidently rendered, and false.

Here is the part worth sitting with. Had those sensors failed properly — nulls, no rows, a dead link, a flatlined heartbeat — somebody would have caught it within the hour. Every monitoring stack in the industry is built to catch that. The failure survived because it looked like health.

Why this is not a vendor defect

It is tempting to file this under poor software and move on. That would be a mistake, and an expensive one, because it would leave the reader believing a better vendor solves it.

The platform in question was fully deployed, commercially supported, and behaving exactly as specified. It was asked to display the value in a field. The field contained zero. It displayed zero. Nothing in its specification, and nothing in the specification of any comparable product we have assessed, requires it to hold an opinion about whether the zero in that field was measured or manufactured.

That question — is this number the kind of number it appears to be — is not a feature the industry has built for. It is a category. And it is the category that every finding in this document belongs to.

The distinction this whole document rests on

A monitoring platform answers what is the value? An evidence system answers what kind of value is this, how old is it, what is it divided by, where did it come from, and would it survive being cited? Almost every fleet in North America has the first. Almost none has the second. The gap between them is where every serious problem we have found in ten years of this work actually lives.

Three systems that have never spoken

Widen the frame and the gap has a shape. There are three systems in every renewable fleet, and they do not talk to each other.

The monitoring stack knows what the plant is doing, in five-minute intervals, in enormous detail, and it is usually very good at that.

The contract knows what the plant is required to do — the availability construct, the guarantee, the exclusions, the measurement window, the termination trigger. It lives as a PDF in a document management system and nothing reads it.

The compliance program knows what the standards demand and what evidence would satisfy them. It lives in a spreadsheet, a shared drive, and one person's memory.

Every serious problem sits in the gaps between those three. A guarantee nobody can compute. Evidence that was never captured because nobody told the monitoring system it was evidence. An obligation that goes overdue because the field recording completion existed in the schema but nothing in the application could write to it.

None of that is a monitoring problem, and you cannot buy your way out of it with a better historian. It is a reconciliation problem.

What this document is for

Not to sell you anything, and not to argue that your platform should be replaced. It probably should not be. This document exists to give you a vocabulary for a class of defect that currently has no name in this industry, and a set of tests that will tell you within a day or two whether you have it.

Our experience is that everyone does. The interesting question is not whether but which of the six, and how far downstream each one has already travelled.

Chapter two

A taxonomy, and why symptom-sorting fails

Twenty-plus findings sorted by symptom produce a punch list. Sorted by mechanism they produce six classes, and the six classes tell you where to look next.

The distinction matters more than it sounds. A punch list is finite and closes. A taxonomy generalises: once you can recognise denominator drift in a capability score, you will find it in a soiling ratio, a peer-comparison coverage figure and a fleet availability rollup without being told to look.

The six classes

How the classes interact

They are not independent. In practice they compound, and the compounding is what makes them expensive.

Substitution feeds denominator drift: a zero-filled sensor is often excluded from a peer set, silently shrinking the comparison population. Plausibility void feeds substitution: without a bound, a garbage value is stored rather than refused, and the next process to encounter it may replace it with a default. Provenance erasure makes all five of the others harder to diagnose, because once the epistemic status of a value is gone from the record, the only way to establish it is forensic.

Figure 1 · How one sensor failure propagates

A pyranometer degrades and begins reporting zero rather than failing open. Substitution — the zero enters the record as a measurement. Plausibility void — no bound exists that would flag daytime irradiance of zero at a site simultaneously generating at half nameplate, so nothing refuses it. Denominator drift — the affected site drops out of a peer-referenced comparison, shrinking the reference set without any screen saying so. Provenance erasure — the resulting performance ratio is stored in the same column as ratios computed from healthy sensors, with no marker distinguishing them. A month later, a report is built on that column. Nobody involved did anything wrong.

What the taxonomy deliberately excludes

This document is not about outages, sensor drift, calibration error, network reliability or the ordinary difficulty of running plants. Those are well-understood problems with well-understood owners and a mature toolset.

Every class here is specifically about a system's representation of its own knowledge — what it claims to know, how confidently, and whether that claim survives inspection. That is a narrower subject, and as far as we can tell it is one nobody in this industry has been made responsible for.

A reasonable objection, answered early. "Our engineers know which sensors are unreliable." Very likely true, and it does not help. The knowledge lives in people, not in the record. It does not survive their leaving, it is not available to the report generated at month-end, and it cannot be produced when someone asks for the basis of a reported figure eighteen months later. A defect that is known but unrecorded is, for every purpose that matters at audit or in a dispute, undetected.

Chapter three · Class one

Substitution

Substitution The absence written as a value

A measurement that does not exist is written into the record as a number that does. The number is almost always zero, for a reason that has nothing to do with engineering.

Mechanism

Zero is the type-default of a numeric column. When an acquisition path cannot obtain a value — the sensor is faulted, the tag is unmapped, the poll timed out, the transform threw — the value that lands in the row is whatever the code produced by default. In a strongly typed pipeline with nullable columns that is NULL. In most real pipelines it is 0, because somewhere in the path a variable was initialised and never assigned.

The consequence is asymmetric and that asymmetry is the whole problem. NULL propagates: any downstream aggregate touching it either returns null or is forced to declare how it handles the gap. 0 does not propagate — it participates. It sums, it averages, it divides, it plots. It is a fully qualified member of every calculation it enters, and it announces nothing.

Why it survives

Because every detection mechanism a monitoring stack has is looking for the wrong thing. Staleness checks look at row timestamps; the rows are arriving. Communications alarms watch link state; the link is up. Range checks look for values outside physical bounds; zero is inside every physical bound for a quantity that can legitimately be zero at night. Row-count monitors see a full complement.

And there is a second-order reason, which is that zero is a plausible reading for most of the quantities involved. Irradiance is genuinely zero at night. Power is genuinely zero when a plant is off. Curtailed megawatts are genuinely zero most of the time. The substitute is camouflaged by the legitimate case.

Missing does not mean zero. It means we do not know. Those are different claims, and a system that cannot tell them apart cannot be cross-examined about anything.

Observed case — eleven days of fleet-wide zero-fill

The measured-irradiance feed wrote exact zeros at every site in the fleet for eleven consecutive days. Rows arrived on the normal cadence throughout. The finding surfaced not through any alarm but through a reconciliation: on a large number of site-days, measured insolation was recorded as exactly 0.00 while metered generation on the same site and the same day was substantial — hundreds of megawatt-hours in the clearest cases.

That pair of facts is impossible. A site cannot generate at scale under zero irradiance. The pair had been sitting in the database, adjacent, for eleven days, and nothing in the platform was constituted to notice that two of its own columns contradicted each other.

Two more instances of the same class, same fleet

Detection test

Substitution is the easiest of the six to find, because it leaves an arithmetic fingerprint: an exact zero adjacent to a value that makes it impossible. Run the contradiction, not the range check.

-- Test 1: irradiance zero while the plant generates -- Any row returned is a substitution candidate, not a measurement. SELECT site_id, reading_date, insolation_kwh_m2, generation_mwh FROM daily_performance WHERE insolation_kwh_m2 = 0 AND generation_mwh > 0 ORDER BY reading_date DESC; -- Test 2: exact-zero density by column and by day. -- A real quantity produces a smooth distribution near zero. -- Substitution produces a spike AT zero and a gap just above it. SELECT date_trunc('day', ts) AS d, COUNT(*) AS rows_total, COUNT(*) FILTER (WHERE value = 0) AS exact_zero, COUNT(*) FILTER (WHERE value > 0 AND value < 1) AS near_zero FROM measurement_history WHERE signal_role = 'irradiance_poa' GROUP BY 1 ORDER BY 1 DESC;

Reading the second test. A genuine quantity that spends time near zero — irradiance at dawn and dusk — produces many near-zero values for every exact zero. A substituted column produces the opposite: a large exact-zero count with almost nothing in the band just above it. That ratio is the tell, and it holds across signal types.

Run the same shape against every numeric column that feeds a reported figure. In our experience the exercise takes an afternoon and finds at least one instance in every fleet we have looked at.

The design rule

Missing renders as unknown, never zero. Enforce it at three layers, because enforcing it at one is how it comes back.

Ingest: a value that could not be obtained is written as NULL, never defaulted. If the pipeline cannot express that, the pipeline is the defect.

Storage: add a database constraint or trigger that refuses the known-impossible combination outright — a dead-zero state on a channel that cannot legitimately be zero in the current operating context. Refuse it at write time; do not clean it up later.

Display: null renders as an em-dash with a reason beneath it, never as a number and never as a blank cell. A blank cell reads as fine. A dash reads as we do not have this, which is the truth.

The display half of that rule is the one that gets abandoned first, and it is abandoned for aesthetic reasons rather than technical ones. A wall of dashes looks like a broken product to anyone who does not know what they are looking at. Holding the rule requires a decision, once, that the screen will be honest even when honesty is unflattering.

Chapter four · Class two

Denominator drift

Denominator drift The metric that rewards the fault

A derived metric defines its denominator over the set of currently-healthy assets. When an asset fails it leaves the numerator and the denominator at the same instant, and the metric improves.

Mechanism

Every derived metric is a ratio, and every ratio is an argument about what the correct comparison population is. That argument is made once, usually early, usually by one engineer under time pressure, and then it is never revisited — because the number it produces looks reasonable, and a number that looks reasonable is never audited.

Drift occurs when the population is defined dynamically in terms of asset state rather than statically in terms of asset existence. Expected output summed across generating inverters drifts. Expected output summed across installed inverters does not. The two definitions differ by a single word and produce opposite behaviour under fault.

Why it survives

Because the metric never looks broken. It stays inside its normal band, it moves smoothly, it responds to real changes in plant behaviour. It is not noisy, it does not spike, it does not go null. It is simply, quietly, answering a different question from the one everyone believes it is answering.

And the failure is invisible from inside the metric. You cannot detect it by staring at the score. You detect it only by comparing the score against a fact the score does not contain — which nobody does, because the score exists precisely so that nobody has to.

Observed case — the capability score at 100

Site capability was scored against expected output computed as the sum of possible power over generating inverters. The observed results:

Read the first and last rows together. A site running 48% of its inverters scored a flawless 100 with no flags. A site running 96% of its inverters — genuinely mild underperformance — scored 30 and was flagged for attention.

The metric built to surface lost capability got arithmetically better every time capability was lost, and the operations team's attention was being directed almost exactly backwards. Nobody had made a mistake in any ordinary sense. Somebody chose a denominator once, years earlier, and it was never cross-examined.

Three more instances, same fleet

▸ Soiling ratio computed from surviving sensors. A third of the fleet's soiling sensors were faulted. At two sites, three of five sensors were down and the published site ratio was computed from the two survivors — with nothing on the screen indicating a reduced population. The worst measured soiling loss fleet-wide was under three percent, which is implausibly low for the season and geography, and which is exactly what you would expect if the most-soiled sensors were the ones that had failed.

▸ Peer-comparison coverage presented as fleet-wide. An inverter health deviation metric covered 24% of installed inverters. Four large sites had zero units scored. The screen presented the result as a fleet view.

▸ A fleet MW rollup with no denominator at all. Fleet output was summed across whatever sites happened to be publishing, with the count of publishing sites stated nowhere. The same tile read across a range of site counts within a single afternoon and no viewer could have known.

Detection test

Drift is found by adversarial recomputation: compute the metric a second way, against a population that cannot move, and compare.

-- Recompute against the STATIC population and diff. -- Large positive drift_pct = the denominator is shrinking with the fault. WITH installed AS ( SELECT site_id, COUNT(*) AS n_installed FROM asset_registry WHERE asset_type = 'inverter' AND commissioned IS TRUE GROUP BY site_id ), reporting AS ( SELECT site_id, COUNT(*) AS n_generating FROM asset_state_now WHERE asset_type = 'inverter' AND state = 'generating' GROUP BY site_id ) SELECT i.site_id, i.n_installed, r.n_generating, ROUND(100.0 * r.n_generating / i.n_installed, 1) AS pct_online, s.capability_score, s.capability_score - ROUND(100.0 * r.n_generating / i.n_installed, 1) AS drift_pct FROM installed i JOIN reporting r USING (site_id) JOIN capability_score_now s USING (site_id) ORDER BY drift_pct DESC;

Reading it. Any site where capability_score materially exceeds pct_online has a denominator that is not the installed base. A site at 48% online scoring 100 returns a drift of +52, which is not a subtle signal.

The same shape works for any ratio. Identify the population the metric claims to cover, count it from the registry, count what actually contributed, and print both.

The design rule

Every tile carries its own denominator, on its face. Not in a tooltip, not in a footnote, not one click away. On the tile, in the same visual unit as the number.

The moment a qualifier is one interaction away from the number it qualifies, somebody screenshots the number without it and pastes it into a board deck. That is not a hypothetical; it is the normal life cycle of every figure your platform produces.

Second half of the rule, equally important: the denominator is the installed population, not the healthy one, and where a metric genuinely must exclude assets, the exclusion count is displayed alongside — "of 83 installed, 43 excluded: not generating."

Chapter five · Class three

Clock collapse

Clock collapse Two questions, one timestamp

A control room needs two different times about every alarm. Most systems store one, and the one they store is the less useful of the two.

Mechanism

The two questions are not variations on a theme. They are independent, and an operator needs both simultaneously.

Collapse occurs when one column serves both. Because the ingest sweep rewrites its column on every pass, the surviving semantic is observation, and onset is destroyed. The system retains the less informative of the two and loses the one operators actually reason with.

Worse: the sweep typically re-stamps every alarm it sees, including the ones it is in the middle of closing out. So the column is not even a reliable observation time for the alarm — it is a heartbeat of the process, painted onto every row it touched.

Why it survives

Because the collapsed column looks correct, and looks correct in the most reassuring way possible: it is always fresh. A screen sorted by it always appears current. Nothing looks stale, nothing looks stuck, and the display gives every impression of being closely coupled to reality.

The failure only becomes visible when two screens using different columns are placed side by side — and then it is usually misdiagnosed, because the screen that is right is the one that looks wrong.

Observed case — 620 alarms, one timestamp

An operations lead reported, three times across a week, that the alarm board appeared frozen while the sequence-of-events display was updating constantly. Measured against the live table:

The board was correct the entire time. Both of the last two rows were true simultaneously: the feed was alive, confirmed 1.3 minutes earlier, and nothing new had happened in 39 minutes. That pair is the actual state of a healthy plant on a quiet afternoon.

The bucketed board stamped onset, so it showed ages of one hour, three hours, ten hours, eleven days, twenty-eight days — correct for a latching board. The sequence-of-events display stamped last observation, so twenty-five consecutive rows read the same second. Not twenty-five events: one sweep, painted onto twenty-five alarms that had been standing for hours. Neither screen said which clock it was using, so the operators concluded the board was dead and trusted the wrong one.

A calm board should be information. Too often it is silence with a timestamp on it.

The second-order failure — counting closed items as live

Collapse rarely stays in the display layer. Because the sweep keeps the column fresh on rows it is closing, any "asserted in the last 24 hours" filter built on that column counts resolved alarms as active. On the same fleet:

Critical agreed exactly, which is the detail that let the defect live for so long: anyone spot-checking the numbers checked Critical, found agreement, and moved on. A critical alarm asserts once and stays asserted, so the sweep has nothing to re-stamp. Below Critical, alarm types that raise and auto-resolve constantly refreshed the column every cycle, and the filter accumulated roughly 38,000 closed alarms reported as live — feeding map pins, operator queues, communications-health panels and protection registers.

Detection test

-- Test 1: timestamp clustering. Concentration = collapse. SELECT COUNT(*) AS alarms_standing, COUNT(DISTINCT last_seen_at) AS distinct_last_seen, COUNT(DISTINCT first_seen_at) AS distinct_onset, MAX(last_seen_at) AS newest_confirmation, MAX(first_seen_at) AS newest_onset FROM alarms WHERE state = 'active'; -- Test 2: are closed items reaching the live filter? SELECT priority, COUNT(*) FILTER (WHERE state = 'active') AS on_board, COUNT(*) FILTER (WHERE last_seen_at > now() - interval '24 hours') AS in_24h_filter, COUNT(*) FILTER (WHERE last_seen_at > now() - interval '24 hours' AND state <> 'active') AS closed_but_counted FROM alarms GROUP BY priority ORDER BY closed_but_counted DESC;

Reading test 1. If distinct_last_seen is far smaller than the alarm count, that column is a process heartbeat, not an alarm attribute. If distinct_onset is similar to the alarm count, onset is intact and the fix is a display and query change rather than a data-loss problem. If both are small, onset was never captured and the repair is deeper.

Reading test 2. Any non-zero closed_but_counted is a live defect. Check every consumer of that filter before changing it — repointing the query without inventorying its consumers moves the problem rather than fixing it.

The design rule

One column, one question — and label both on the face of the screen.

Store onset and last-observation separately. Never let a sweep write to onset. Label the columns in the interface as Onset (ET) and Last confirmed (ET), not "time" or "updated" or "last seen," each of which can mean either.

Then publish the pair as a first-class fleet measurement: feed confirmed 1.3 min ago · newest onset 39 min ago. Once that pair is on the wall, a stopped feed can no longer hide behind a quiet room, which is the entire point of the exercise.

Chapter six · Class four

Staleness masquerade

Staleness masquerade Old rendered as current

The data is correctly stored, correctly timestamped, and correctly retrieved. The display drops the part of the timestamp that would tell you it is fourteen months old.

Mechanism

A display formats a timestamp as time-of-day. On a screen refreshed every few seconds, showing seconds and omitting the date is a defensible choice — until a value stops updating. From that moment the display is indistinguishable from a live one, and the older it gets the more confidently wrong it becomes.

This is the purest of the six classes, in the sense that the underlying data is entirely correct. Nothing was substituted, no denominator moved, no column was overwritten. The defect exists solely in the rendering, which is why it survives code review and database audit alike.

Why it survives

Because it is invisible to every automated check. The record is well-formed. The timestamp is accurate. A query returns the right value with the right time. Only a human looking at a screen can see the failure, and the failure is specifically designed — by accident — to be invisible to a human looking at a screen.

There is also a habituation effect. Operators see the same card in the same place every shift. A card that has read the same value for a year does not draw attention; it becomes furniture.

Observed case — the wall of stale state cards

Voltage-regulation state cards across the fleet displayed a time of day and no date. The cards read as current. Verified against the underlying state table:

Eight cards on one wall spanning fourteen months of staleness, every one of them presenting as the current state of a regulating asset. The eleven-day card and the 424-day card were visually identical.

The fix is one line of formatting code. The reason it is worth a chapter is that the defect had persisted for more than a year in a monitored, supported, actively used system, and would have persisted indefinitely, because nothing in the system was capable of reporting it and nothing in the operators' routine was capable of noticing it.

Two more instances, same fleet

▸ A soiling station printing a clean result at 27 days old. The card read measured 1.000, 0.0% loss — a perfectly plausible figure, from a sensor that had last reported nearly a month earlier. Age was displayed nowhere.

▸ A performance feed seven days stale with no indication. Actual generation had stopped landing a week before review. Every downstream ratio continued to render against the last values received, and the screen offered no age.

Detection test

Staleness masquerade cannot be found in the data, because the data is fine. It is found by computing age for every displayed quantity and ranking it — a report the system almost certainly does not have, which is why the defect exists.

-- Age of the newest row per feed, per site. Sort descending and read the top. SELECT feed_name, site_id, MAX(observed_at) AS newest_row, now() - MAX(observed_at) AS age, EXTRACT(epoch FROM (now() - MAX(observed_at)))/86400 AS age_days FROM feed_observations GROUP BY feed_name, site_id HAVING now() - MAX(observed_at) > interval '2 hours' ORDER BY age DESC;

Scope this per feed, not per site. The single most common gap we find is a staleness rule defined at site level: as long as any feed from a site is arriving, the site is considered healthy, and an individual channel can be dead for a year inside a site that reports as live. Site-level staleness is close to useless. Channel-level staleness is the control that matters.

Then do the manual half, which takes twenty minutes and is worth more than the query: walk the screens and list every timestamp displayed anywhere in the product. For each one, write down whether it shows a date and whether it shows an age. Every entry with neither is a live instance of this class.

The design rule

Every displayed value carries its age, and every timestamp carries its date.

Age, not just timestamp — "as of 10:32 · 11 days ago" does work that "10:32:37 AM" cannot, because it does not ask the reader to do arithmetic against a date they may not have noticed.

Past a defined threshold the value stops rendering as a value. It becomes "last known — 11 days" in a visibly different treatment. A last-known value is often still operationally useful; what is never acceptable is a last-known value wearing the costume of a live one.

Chapter seven · Class five

Plausibility void

Plausibility void Impossible rendered live

A value arrives on time, from a healthy link, in the right column, and is physically impossible. Nothing refuses it, because nothing in the system holds a bound it could have been checked against.

Mechanism

Monitoring stacks validate three things well: that data arrived, that the link is up, and that the value parses as the right type. They rarely validate the fourth: that the value is physically possible for this asset.

That fourth check requires something the other three do not — a per-asset reference. Voltage class, nameplate rating, expected operating band. Generic range checks cannot supply it: a 200 MW reading is unremarkable on a 300 MW site and impossible on a 20 MW one. Without the per-asset reference there is no bound, and without a bound there is nothing to refuse.

The void is usually a data-model gap rather than a logic gap. The check is absent because the reference table it would need is incomplete, and the reference table is incomplete because nothing ever failed loudly enough to require filling it in.

Why it survives

Because implausible values are often excluded from the screens where a human would catch them, and included in the aggregates where nobody can. A corrupt reading four orders of magnitude high does not sit on a trend line where an engineer would spot it; it sits inside a fleet sum, where it is one contributor among twenty and its influence is invisible.

There is also a diffusion-of-responsibility effect specific to this class. Site engineers look at their own site and see nothing wrong, because the corrupt tag is not one they watch. Fleet operators look at the rollup and see a plausible total. The person who would notice is whoever compares the two, and no such person exists in most organisations.

Observed case — one meter, 39% of the fleet

A revenue meter on a storage site published values orders of magnitude above the site's physical capability and was rendered LIVE, with link state reported as OK.

Two-fifths of the reported fleet output came from one corrupt instrument, and the fleet tile rendered a number that looked entirely ordinary.

The root cause was a data-model gap, not a logic failure: the site had no row in the nameplate table. There was no rating anywhere in the system against which 1,180 MW could have been recognised as impossible. One trust view did flag the site; the view that governed the operational display did not, and reported the readings as trustworthy.

One thing we checked and rejected, because it matters. The obvious hypothesis is a binary register scaling artefact — a 16-bit rollover producing a clean multiple. We tested it. Only 61 of 298 recent samples landed on a 65,536 boundary, which is far too few. Do not apply a correction factor to values like these. A correction factor applied to a non-systematic corruption manufactures plausible wrong numbers, which is materially worse than obvious wrong numbers. Fix the tag mapping at source, and until it is fixed, refuse the values.

A quieter instance — mixed units in one column

Power factor across the fleet, in a single snapshot, contained values expressed as percent (99.98, 99.96), as per-unit (0.03, 0.19), and as signed percent (−99.87, −99.44) — all in the same column, all rendered identically. Every fleet average computed over that column was arithmetic performed on three incompatible units. No individual value was implausible for some convention, which is exactly why nothing caught it.

Detection test

Plausibility testing needs a reference. Start by finding out where you do not have one — that gap is usually the finding.

-- Step 1: which sites can we not check at all? -- Every row returned is an asset with NO plausibility reference. SELECT s.site_id, s.site_name FROM registry_sites s LEFT JOIN site_nameplate n ON n.site_id = s.site_id WHERE n.site_id IS NULL; -- Step 2: for sites we CAN check, find the impossible. -- 1.15x nameplate is a deliberately generous bound. SELECT h.site_id, h.observed_at, h.mw, n.nameplate_mw, ROUND(h.mw / NULLIF(n.nameplate_mw,0), 2) AS times_nameplate FROM telemetry_history h JOIN site_nameplate n USING (site_id) WHERE h.mw > n.nameplate_mw * 1.15 ORDER BY times_nameplate DESC; -- Step 3: unit consistency within a column. -- More than one bucket populated = mixed units. SELECT site_id, COUNT(*) FILTER (WHERE ABS(power_factor) <= 1.0) AS looks_per_unit, COUNT(*) FILTER (WHERE ABS(power_factor) > 1.0) AS looks_percent, COUNT(*) FILTER (WHERE power_factor < 0) AS signed_values FROM electrical_history WHERE observed_at > now() - interval '7 days' GROUP BY site_id;

Step 1 is the important one, and it is the step most teams skip. The question is not only "which values are impossible" but "for how much of my fleet is the question unanswerable." A site with no reference row is not passing the plausibility check — it is exempt from it, permanently and silently.

The design rule

Every signal role carries a plausibility rule, and every refusal is recorded.

Define the bound where the meaning lives — on the signal role, derived from voltage class and nameplate — not in the display layer. Then:

Refuse at ingest, do not clean up later. An implausible value is rejected before storage, with an audit row naming the value, the bound and the reason. A corrupt value that reaches storage will eventually reach a report.

Missing reference is a finding, not an exemption. An asset with no nameplate row appears on a gap list until somebody supplies one. It does not quietly opt out of validation.

Never silently correct. If a systematic scaling error is confirmed — genuinely confirmed, not assumed from one clean example — fix the mapping at source. A correction factor applied to an unconfirmed pattern manufactures plausible wrong numbers, and plausible wrong numbers are the most expensive output any system can produce.

Chapter eight · Class six

Provenance erasure

Provenance erasure Inferred rendered as issued

Two values sit in the same column. One was issued by the entity of record. One was inferred from the plant's own history because no issued value was available. On screen they are identical. Only one of them can be cited, and nobody can tell which.

Mechanism

Values in an operational database differ in kind, not only in magnitude. A setpoint may be measured, modelled, inherited from a prior configuration, inferred from the plant's own behaviour, or issued by an external authority. Those are five different epistemic statuses with five different evidentiary weights.

A typical schema stores all five in one numeric column with no companion field recording which is which. The moment that happens the distinction is gone from the record, and it cannot be recovered by inspection — a seeded band and an issued schedule are the same datatype holding a similar number.

This class is the most consequential of the six, because it is the one that converts a data problem into an evidence problem. The other five make numbers wrong. This one makes correct numbers uncitable, which is a different and worse failure: you cannot fix it by recomputing, and you discover it at the moment you are being asked to produce the basis for a figure.

A setpoint band the platform inferred from your own plant history is not a schedule your operating entity issued. On most screens the two look identical. Only one is citable — and if the screen does not say which, you cannot safely cite either.

Why it survives

Because seeding is a reasonable engineering decision that becomes a problem only later, and in a different department. Standing up a platform across a fleet, some sites will not have an issued schedule available on day one. Seeding a plausible band from historical median is the correct call — it makes the screen operable and it harms nothing.

The defect is not the seeding. The defect is that the seeded value was never marked as seeded, so eighteen months later, when a compliance lead needs to demonstrate operation within an issued schedule, there is no way to distinguish the sites where that can be demonstrated from the sites where it cannot.

Observed case one — five of twenty schedules citable

Twenty voltage schedules were present in the platform. On review, five had been issued by the operating entity of record. The other fifteen had been seeded from each site's own historical median.

To the platform's credit, the seeded values had been labelled indicative only — which is precisely the design rule this chapter argues for, implemented correctly. The finding is what that label revealed: three-quarters of the fleet's schedules were not evidence, and on an unlabelled platform that fact would have been undiscoverable without a document-by-document reconstruction.

One site made the operational stakes concrete: a regulation loop setpoint of 164.5 kV against a metered reading of 34.7 kV and a schedule of 34.1 kV. A setpoint of a different order from the quantity it regulates is a configuration error, and it had gone unremarked because no screen compared the three.

Observed case two — the evidence source that did not exist

At every site carrying automatic voltage regulation, the service-status field was NULL across all rows, and the corresponding display read -- on every card in the fleet.

This is provenance erasure in its most complete form. The question is not whether the displayed value is trustworthy — there is no value. The requirement that turns on that status has a clock, and the clock had nothing behind it anywhere in the platform. The correct action is to state that plainly in the compliance narrative and identify the source that would supply it, rather than to discover it during an audit.

Observed case three — sixty-five intervals that could not compute

A recurring-obligation calendar showed 65 of 65 intervals reading cannot compute — last performed not recorded. The completion fields existed in the schema. Nothing in the application could write to them.

So the calendar could display obligations and could not record their performance. A compliance calendar in which completion cannot be recorded is not a calendar; it is a list. And a next-due date computed from a blank last-performed is not conservative — it is arbitrary.

Detection test

-- Test 1: does a provenance column exist at all? If not, that is the finding. SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'voltage_schedules' ORDER BY ordinal_position; -- Test 2: where a source column exists, how much is authoritative? SELECT COALESCE(source_type, 'UNRECORDED') AS provenance, COUNT(*) AS n, ROUND(100.0*COUNT(*)/SUM(COUNT(*)) OVER (), 1) AS pct FROM voltage_schedules GROUP BY 1 ORDER BY n DESC; -- Test 3: compliance-relevant fields that are entirely empty. -- A 100% null rate is not sparse data. It is an absent evidence source. SELECT COUNT(*) AS rows_total, COUNT(service_status) AS rows_populated, COUNT(*) - COUNT(service_status) AS rows_null FROM regulation_state; -- Test 4: recurring obligations that cannot compute a next-due date. SELECT obligation_id, standard_family, interval_months, last_performed_at, CASE WHEN last_performed_at IS NULL THEN 'cannot compute' ELSE 'computable' END AS status FROM compliance_obligations WHERE recurrence = 'interval' ORDER BY status, standard_family;

Test 1 is usually decisive. If no provenance column exists in the schema, the answer is not that provenance is poor — it is that provenance was never captured, and every value in the table is of unknown epistemic status until reconstructed from external documents.

The design rule

Every compliance-relevant value carries its provenance on its face, and the unavailable case is stated rather than blanked.

Store status alongside value. A source field, an authority, and a date obtained, mandatory on write. A value without provenance is refused rather than accepted with a null source.

Render status with value. Issued values carry an issued marker. Inferred values carry indicative only — not evidence. The reader must never have to ask which they are looking at.

Distinguish the three empties. No evidence source exists is not the same as not yet obtained, which is not the same as a blank cell. A blank reads as fine. Say which of the three it is, on the screen.

Completion is a record, not a state. Who performed it, when, how many days early or late; a written reason required to reopen, retained permanently; refuse an unattributed entry and refuse a future date. Anything less is a checkbox, and a checkbox is not evidence.

Chapter nine

Five rules that close all six classes

None of these is difficult to implement. All of them are difficult to hold, because each one makes the product look worse in a demonstration.

Rule one — missing renders as unknown, never zero

Enforced at ingest (null, never defaulted), at storage (a constraint that refuses the known-impossible), and at display (a dash with a reason, never a number and never a blank). Enforcing it at one layer is how it returns; each layer catches what the others miss.

The display half is the one abandoned first, and for aesthetic rather than technical reasons. A dash reads as a broken feature to anyone who does not know what they are looking at. Holding the rule requires deciding once, explicitly, that the screen will be honest even when honesty is unflattering — and then defending that decision the first time somebody senior asks why a tile is empty.

Rule two — every tile carries its own denominator

On its face, in the same visual unit as the number. Not in a tooltip, not in a footnote, not one interaction away.

The reason is not pedantry. The normal life cycle of any figure your platform produces is that somebody screenshots it and pastes it into a deck. Whatever is not inside the crop does not survive. A denominator one click away is a denominator that will be absent from every decision the number ever informs.

And define the population statically. Of 83 installed is a denominator. Of those currently generating is a moving target that will eventually flatter exactly the situation you built the metric to catch.

Rule three — every number shows its provenance and its age

Four provenance states cover nearly everything: measured (an instrument read it), modelled (computed from other quantities), inferred (derived from the asset's own history because nothing better was available), and issued (provided by an external authority of record). Only measured and issued are evidence without qualification.

Age travels with provenance because it modifies it. A measured value four seconds old and a measured value four hundred days old are not the same claim, and a display that renders them identically is making a false statement about its own knowledge.

Rule four — when it cannot compute, it says so and says why

Three parts, and the third is the one that makes it useful rather than merely honest.

1. Say that you cannot. Not a zero, not a blank, not a dash without explanation.

2. Say why. Coefficients not populated. Reference asset has no rating. Feed last confirmed 11 days ago.

3. Name what would resolve it. The specific input, document or decision that turns "cannot" into "can." Without this, a refusal is an excuse; with it, a refusal is a work order.

This is the same discipline a good auditor applies to their own findings, and it is worth saying plainly why: an auditor who writes "unable to determine" without stating what would have determined it has produced nothing anybody can act on.

Rule five — refusals are recorded and visible

The rule nobody ships, and the one to examine first if you are evaluating a platform — ours included.

Every value the system declined to compute or display, with its reason, in a ledger any user can open. A panel that prints "0 of 1 evaluable" instead of a comfortable zero. A database trigger that rejects a dead-zero state rather than storing it. A count that states its exclusions rather than absorbing them.

Rule five is what keeps the other four from decaying. Rules one through four are invisible when they are working — a correctly rendered dash looks like nothing at all — so they erode silently under delivery pressure. A visible refusal ledger makes the discipline observable, which makes its absence noticeable.

The economic argument, stated once

Each rule trades a small, immediate, visible cost — an emptier screen, a longer conversation in a demonstration — against a large, deferred, invisible one: a report built on a number nobody can defend. The first cost is paid by the person building the product. The second is paid by whoever is holding the file when someone asks a hard question, which is usually a different person, usually much later. That asymmetry is why the rules are hard to hold, and it is the only reason they need writing down.

Chapter ten

What each class costs when it meets a data request

Every class in this document is survivable while nobody asks. The cost arrives on somebody else's schedule — a dispute, an audit, a diligence request, a lender's question — and by then the record is what it is.

The contractual dimension

On the assessed fleet, sixteen sites guaranteed availability and the number was computed six structurally different ways — not six formulas expressing one idea, but six constructs with different denominators, exclusions and measurement windows. Every solar site guaranteed 99%. None meant the same thing by it.

On several sites the contractual equation depended on coefficients the agreement left to be mutually agreed upon. They were never populated. Neither party could have computed the guarantee they had both signed, and neither had tried. Two further exhibits referenced attachments that were not present in the executed copy.

Set against that, one site terminated on any miss below its guarantee with no cure period — and that site's availability construct was among those that could not be computed.

The asymmetry worth internalising. The party that discovers a computability gap first controls how it is characterised. Discovered internally, it is a remediation project on your own timeline. Discovered by a counterparty during a dispute, it is a credibility problem attached to a number you have been reporting for years. The gap is identical. The position is not.

The compliance dimension

Provenance erasure is where a monitoring problem becomes an evidence problem, and the transition is worth stating precisely.

A monitoring platform is not an evidence system. It is not required to be, and most are not sold as one. But operational data is routinely relied upon as the substrate for compliance demonstration — voltage regulation, protection maintenance intervals, model validation inputs, unit performance reporting — and the relied-upon assumption is that the values it holds are what they appear to be.

The three failures we would look for first, in any fleet:

▸ Setpoints and schedules with no recorded source. If it cannot be shown to have been issued by the entity of record, it is not evidence of operating to an issued schedule, whatever the plant actually did.

▸ Status fields that are null across every row. A uniformly empty compliance-relevant field is not sparse data. It is an evidence source that does not exist, and it is better identified now with a plan than during an audit without one.

▸ Recurring intervals with no completion record. An interval whose last-performed date was never captured cannot compute a next-due date, and a program that cannot compute next-due cannot demonstrate that it performed on schedule.

Consistent with the notice at the front of this document, we name no requirement, version or effective date here. Which requirements attach to which of these gaps depends on registered function, asset configuration and audit period, and belongs in a deliverable prepared against the current enforceable source — not in a professional reference.

Chapter eleven

A self-assessment protocol

Two days of work, no vendor required. Run in order — each stage narrows what the next has to look at.

Stage 1 — the screen walk (2 hours, no database access)

Print or screenshot every operational screen. For each displayed number, answer four questions in a spreadsheet. Do not fix anything yet.

1. What is this number divided by, and is that stated on the screen?

2. How old is this number, and is the age stated on the screen?

3. If the source stopped feeding, what would this show?

4. Is this measured, modelled, inferred or issued — and does the screen say?

Question three is the highest-yield question in this document. Any tile whose answer is "the same as it shows now" is a confirmed instance of substitution or staleness masquerade, established without touching a database.

Stage 2 — the four queries (half a day)

Run them against production, read-only. All four are cheap. None requires a schema change or a maintenance window.

Stage 3 — the contract read (one day, and the one people skip)

Take one executed agreement. Find the availability construct. Then answer, in writing:

1. What exactly is the denominator, in the contract's own words?

2. Which exclusions apply, and can each be identified in your data?

3. Is every coefficient the equation needs actually populated somewhere?

4. Does the exhibit reference an attachment, and is that attachment in the executed copy you hold?

5. Does the number you report to this counterparty use this construct — or your internal one?

Question five is where the money is. In our experience the two are frequently different, the difference has never been quantified, and nobody in the organisation is aware there are two numbers.

Stage 4 — write the register

One row per finding: what was observed, where, when, which class, and the specific question that would resolve it. Mark each finding confirmed or deferred — never "probably," never "appears to." A deferred finding with a precise question is more useful than a confirmed-sounding finding that is actually a guess, and the discipline of choosing between those two words will improve the register more than any other single practice.

What good looks like at the end of two days. A register of ten to twenty-five findings, each with a source and a timestamp, sorted into the six classes, with a named owner and a resolving question for each. That document is worth more than any dashboard, and it did not require buying anything.

What to do first with what you find

Order matters, and the intuitive order is wrong. Fix in this sequence:

1. Anything feeding an external report. Contractual availability, regulatory submissions, lender reporting. These have counterparties and deadlines.

2. Anything feeding an operational decision. Capability scores, dispatch, work-order prioritisation. These misdirect attention every day they persist.

3. Display-only defects. Real, and cheap to fix, and they can wait a week. A stale card that nobody acts on costs less than a wrong number in a monthly report.

The instinct is to start with the display defects because they are quick. Resist it. The reported figures are where the exposure lives.

Chapter twelve

What RenewOps does about this

The reconciliation layer.Reads your monitoring stack. Checks it against ratings, agreements and the documents of record. Declines to publish what it cannot defend.

The five rules in Chapter nine are not aspirations. Each one is a behaviour you can look at. This chapter is what they look like in RenewOps, measured on the dates stated — including the rule RenewOps is currently failing.

RenewOps is the reconciliation layer Energy Compliance builds: it reads from the monitoring stack a fleet already runs, checks what it finds against the plant's ratings, the executed agreements and the documents of record, and declines to publish what it cannot defend.

Rule one · Missing renders as unknown, never zero

Three populations of false zeros were converted to unknown on 25 August 2026: rows in the curtailment history carrying a maximum-possible-power of zero, the measured-insolation column feeding the performance-ratio calculation, and a telemetry voltage column. Every one of those rows had been a real absence wearing a number.

The curtailment flag is a harder case, and it is the one worth studying. Where no determination was made, the flag is set to unknown, not to false. A false all-clear during a real curtailment is worse than no reading, because an operator acts on it and a settlement analyst later reconciles against it.

The one that reads as a bug and is not. An infinite insulation-resistance reading at nine sites now renders blank. Infinity there is the absence of a fault path — nothing to measure against — and on screen it had been rendering as an extremely healthy value. The worst possible misreading of a healthy-looking number is that it is a healthy number.

Deferred, and stated as such. The eleven days of irradiance already written as zero are still written as zero. Stopping new false zeros and remediating historical rows are two different decisions, and the second one is open. Those rows currently feed everything downstream of them.

Rule two · Every tile carries its own denominator

Site availability publishes as an unweighted mean, named as unweighted, with the per-asset minimum and the count below threshold beside it. No site rollup was invented, and the reason is worth stating plainly: whether an agreement averages by asset count or weights by nameplate is a term of that agreement. It is not a display choice, and a platform that picks one silently has substituted its own construct for the contract's.

Every DC-loss row carries a coverage note stating how many paired hours it rests on. A day whose inverter coverage swings more than twenty per cent labels itself UNEVEN COVERAGE. A comparison bucket requires comparable coverage on both sides before it will compare at all. Alarm parent rows carry the full child count and the priority mix.

The largest open item against this rule. An authoritative fleet definition exists, carrying a separate flag for each thing a tile might really be counting. As of 26 August 2026, no tile cites it. Screens still state fleet counts that differ from one another. The definition is the hard part and it is done; putting the qualifier on the face of each tile is the easy part and it is not.

Rule three · Every number shows its provenance and its age

Every state stamp carries the full date and an explicit age in days. One feed reads 796 days. Before the fix the card printed a time of day and nothing else, which concealed feeds up to 424 days stale — and it fooled the reviewer who was in the middle of documenting the defect. That is the strongest evidence available that it would fool an operator, and it is the reason the fix routes every stamp in the product through one formatter rather than repairing the cards one at a time.

Values resolve to the latest non-null reading per signal, each carrying its own as-of, rather than to the newest row. The difference is not cosmetic. Reading the newest row made one site publish "0 of 352 units reporting" when the units were reporting on a slower cadence than the row that arrived last.

Two battery sites carry an explicit ROLLUP LIVE, UNITS SILENT verdict. The site-level number updates every fifteen minutes while every one of its units — 276 at one site, 42 at another — stopped answering days ago. The rollup is not wrong at its own source. It is simply not evidence of what a reader would assume it is evidence of, and the verdict says so on the row.

Where the plausibility gate refuses a reading, the raw value is kept beside the blank. The record of a bad reading is the evidence that the gate is needed.

Rule four · When it cannot compute, it says why

Rule five · Refusals are recorded and visible

The plausibility gate refused 367 samples at one site in twenty-four hours on the day it landed, with zero false positives anywhere else in the fleet. The worst raw values it caught were around 13,700 MW and 9,280 kV — on a plant whose rating makes both impossible.

It runs three independent tests. A per-site power ceiling set from the plant's own rating. An absolute bulk-system voltage ceiling, plus a per-site band derived from the voltage schedule of record. And a shape test that rejects a twenty-four-hour span wider than one and a half times its own centre.

The refusal that refuses itself. Where a site's own voltage schedule is suspect, RenewOps declines to use that setpoint as a banding input and surfaces the site in a coverage view instead. Six sites currently carry no assertable band and are stated as open per-site questions rather than defaulted to something plausible. A plausibility check banding against a number it does not trust is not a check.

The tracker wind channel is gated to a physically possible band with every rejected sample named in an audit view. All 162 controllers at one site reported 758 m/s — roughly Mach 2.2 — and wind stow is decided off that signal.

Two alarm-catalogue promotions are deliberately held, with the reason held as data rather than as a comment in somebody's ticket. A priority override the classifier cannot read is refused on write, rather than accepted and stored where it would silently do nothing. A publish refuses unless four separate assertions pass — child counts reconcile, duplicate keys read zero, every dependent view rebuilds with its permissions re-asserted, and both layers complete their refresh.

The rule the product did not pass

A gate exists that should bar any site reporting under ninety-five per cent of its inverters from receiving a GOOD capability grade. The code is deployed. It is confirmed present in the running bundle. It does not fire. One site currently shows GOOD 100 with 50 of 75 inverters — 66.7 per cent. The cause was unknown as of 25 August 2026 and the next step is instrumenting the two inputs in the browser.

The same score is still computed per browser session, per operator, and is not persisted. An unauditable score is not evidence of anything, and two operators looking at the same site can hold two different numbers with no way to reconcile them.

Both belong in this chapter rather than in a release note. A chapter about design rules that quietly omitted the rule the product is currently failing would be an instance of the exact behaviour this reference spends eleven chapters arguing against.

A platform that refuses is more useful than a platform that guesses, and it is considerably harder to sell. That is the trade this product makes, and it is the reason the refusal ledger is a feature rather than an apology.

Figures in this chapter were measured between 24 and 28 August 2026 on a live production instance and are dated in the text. They describe that instance on those dates. They are not a specification, a roadmap, or a claim about any other fleet.

Reference

Glossary

The firm

About Energy Compliance, Inc.

Energy Compliance, Inc. is an independent regulatory compliance and advisory firm serving the energy sector, with a focus on NERC, FERC, and RTO/ISO compliance and a particular concentration in the ERCOT and Texas PUCT markets. The firm helps registered entities and prospective registrants navigate the full compliance lifecycle — registration, program design, evidence development, RSAW production, mitigation, and audit defense.

The approach is research-analyst-first. Every conclusion is tied to an authoritative source, every narrative is evidence-backed, and every deliverable is built to survive regulator scrutiny. Engagements are led by a single senior practitioner with regulator-side experience. We do not staff for billable hours. We staff for outcomes. Where automation can replace manual work, we build the automation. Where senior judgment is required, the senior is in the room.

That discipline extends to a portfolio of compliance technology, of which RenewOps — the reconciliation layer described throughout this series — is one part.

Rob Smith — Founder & Principal

More than thirty years on every side of the North American Bulk Electric System. Control-room operations as Reliability Coordinator, Transmission Operator and Power System Operator. Senior compliance auditor and subject matter expert for NERC Reliability Standards — auditing grid facilities, evaluating mitigation adequacy, and supporting the development of violation notifications and settlements as part of FERC-directed enforcement actions, from inside the regulator's process. Overseas, a regulatory audit in the Sultanate of Oman conducted against the Sultanate's Sector Law and Grid Code.

MSL, Corporate Compliance — Fordham Law · MS, Energy Management · BAS, Mechanical Engineering (Metallurgy minor), University of Florida · BAS, Energy Management · AAS, Power Plant Technology and Electrical Transmission System Technology, Bismarck State College

Auditing teaches one habit that never leaves: before you believe a number, ask what it would look like if it were wrong.

Where to start

An assessment points our defect battery at your live monitoring stack and hands you the findings — each with a source, a timestamp, and the question that resolves it — whether or not you buy anything afterward. Nobody buys a reconciliation layer before they know they need one, and the only honest way to find out is to look.

Fleet Exposure Read

Your availability constructs reconciled against your executed agreements, returning a per-site computability position — ready, partial, blocked, or undefined — with the specific blocker named for each site that cannot compute.

Monitoring Truth Assessment

The full defect battery against your live monitoring stack. Every finding returns with a source, a timestamp, and the question that resolves it. Where we cannot verify something, it comes back marked deferred with the specific question, not softened into a maybe.

Evidence Provenance Review

Your compliance-relevant signals traced to source and sorted into citable and not, with the seeded, the derived, and the self-referential separated out from the issued.

RenewOps

The reconciliation layer itself, deployed against your fleet: contract terms parsed to structure, signals resolved to roles, every tile carrying its own denominator, its own provenance, and its own age — and refusing to compute, visibly, when it cannot.

Energy Compliance, Inc.

[email protected] · energycomplianceinc.com · 763.438.4427Bloomington, Minnesota

To discuss how any of this applies to a specific fleet, or to request other references from the Energy Compliance library, visit energycomplianceinc.com.

Rigorous Compliance.Defensible Programs.

energycomplianceinc.com