Displayed Is Not Citable

Chapter one

Data, evidence, and the gap between them

Operational data becomes evidence when it can answer four questions about itself. Most operational data can answer none of them.

Only the first is typically stored, which is entirely reasonable for a system built to operate a plant. It becomes a problem the moment that system is relied upon as the substrate for a compliance demonstration — which happens by default, silently, because the data is there and nothing else is.

The four statuses

The whole of this chapter reduces to one observation: a database column has one type, and these four have four different meanings. Storing them together without a companion status field destroys the distinction irrecoverably, because a seeded band and an issued schedule are the same datatype holding a similar number.

The rule. Status is stored alongside value, mandatory on write, and rendered alongside value, always. A write path that accepts a compliance-relevant value without a source is the defect — not the missing source on the row that results.

Why seeding is not the villain

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 engineering call: it makes the screen operable and it harms nothing.

The defect is never the seeding. It is that the seeded value was not marked as seeded — so eighteen months later, when someone needs to demonstrate operation within an issued schedule, there is no way to separate the sites where that can be demonstrated from the sites where it cannot, short of a document-by-document reconstruction.

Chapter two

The tautology — scoring against a band derived from yourself

Three sites read exactly 100.0% in band. Not approximately. Exactly. The band had been computed from the median of the series being scored against it.

The mechanism

Where no issued schedule existed, the platform derived a band from the site's own historical voltage — a reasonable operational default. That band then became the threshold against which the same site's voltage was scored for in-band percentage.

A series compared against a band constructed from its own central tendency will fall inside that band almost always, and where the band is wide enough, always. The resulting figure is not a measurement of compliance. It measures nothing, and it renders in the same column, in the same format, as figures from the five sites that were being scored against a genuine issued schedule.

Calculation 1 · Detect self-referential scoring

-- A band derived from the scored series is a tautology. -- 100.0% exactly, with a seeded source, is the signature. SELECT s.site_id, s.schedule_source, -- issued | seeded | absent s.setpoint_kv, s.band_low_kv, s.band_high_kv, v.pct_in_band, v.samples, (s.schedule_source <> 'issued') AS band_self_derived, (v.pct_in_band = 100.0 AND s.schedule_source <> 'issued') AS tautological, CASE WHEN s.schedule_source <> 'issued' THEN 'INDICATIVE ONLY - not evidence of schedule compliance' END AS caveat FROM voltage_schedule s JOIN voltage_in_band_monthly v USING (site_id, period) ORDER BY tautological DESC, band_self_derived DESC;

The mirror-image failure

The same fleet produced the opposite error at another site: 37.6% out of schedule — a dramatic-looking non-compliance figure — because the site was being scored against a collector-bus band while its actual schedule applied to a different bus at a materially different voltage class.

Both errors have the same root. The scored quantity and the band came from different places and nothing recorded that they were supposed to correspond. One direction produces a reassuring number; the other produces an alarming one. Neither is a measurement.

Ours, and the correct handling. One site's schedule setpoint had itself been seeded from a corrupt meter — a value three orders of magnitude above the site's actual operating voltage, still marked enabled. The plausibility layer refuses to use that setpoint and surfaces the row in a coverage view. It was deliberately not deleted: schedules pass only through a function that demands a directive reference, so retiring it is a decision with a named owner rather than a cleanup.

The best compliance writing in the platform

Worth naming what worked. The schedule table carried a suspect_note field — plain-language text explaining, per row, why a given schedule was or was not trustworthy. Not a flag, not an enum: a sentence a compliance lead could read and act on.

That field did more for the defensibility of the fleet's voltage evidence than any calculation in the platform, and it cost nothing but the discipline of writing down what was already known.

Chapter three

Qualifiers that do not survive the export

The platform knew which schedules were seeded. It knew which meters were suspect. It knew which sites were explicitly disabled. None of that reached the monthly report.

The finding

Three compliance-facing endpoints — a monthly evidence extract, a statistics view, and the monthly report itself — returned no source column, no suspect flag, and no explanatory note. The information existed one join away and was not consulted.

Worse: the monthly report ignored the enabled flag entirely, publishing in-band percentages for two sites that had been explicitly disabled on the grounds that they were being measured on the wrong bus. Both published high nineties. Both figures were meaningless and neither carried any indication of it.

A qualifier that does not travel with the number is not a qualifier. It is a private opinion held by a database.

Why this happens, structurally

Compliance exports are usually built later than the operational views, by someone selecting the columns that look relevant. Status columns do not look relevant — they are not the number — so they are not selected. The export is then reviewed for whether the numbers are right, and the numbers are right.

The design rule. An evidence export carries the qualifier or it does not carry the value.

Implement it as a constraint rather than a convention: the export view selects value and status as a pair, and a value whose status is missing renders as withheld with the reason. Then test it the only way that works — generate the export and read it as an auditor would, asking of each figure: what is this, where did it come from, and can I cite it? Every question the export cannot answer is a column that should have been in it.

The view that got it right

One view in the same platform carried schedule_is_compliance_grade alongside every excursion, plus a plain-English statement of the obligation the excursion related to. A reader of that view could tell immediately whether an excursion was citable evidence or an operational observation.

The difference between that view and the three defective endpoints was not sophistication. It was that somebody had asked what the output was for.

Chapter four

The evidence source that does not exist

At every site carrying automatic voltage regulation, the service-status field was null across every row. The display read a dash on every card in the fleet.

Why this is the most complete form of the failure

The other findings in this paper concern values whose status is unclear. This one concerns a value that does not exist. The requirement it relates to has a clock, and the clock had nothing behind it anywhere in the platform.

The correct action is not to find a substitute. It is to state the position plainly in the compliance narrative and identify the source that would supply it — a plant control system point, a manual log, an operating record — and then go and get it. Discovering this during an audit is the expensive path to the same conclusion.

Three empties, three meanings

The three are operationally different and must render differently. A field that is temporarily unavailable is a monitoring issue. A field for which no source exists is a program gap requiring a decision, a budget and an owner — and it will never receive one while it renders as a dash among other dashes.

Calculation 2 · Find the fields with no source

-- A 100% null rate on a compliance-relevant field is not sparse data. -- It is an evidence source that does not exist. SELECT 'regulation_state.service_status' AS field, COUNT(*) AS rows_total, COUNT(service_status) AS populated, COUNT(*) - COUNT(service_status) AS null_rows, ROUND(100.0*(COUNT(*)-COUNT(service_status))/NULLIF(COUNT(*),0),1) AS pct_null, CASE WHEN COUNT(service_status) = 0 THEN 'NO EVIDENCE SOURCE - program gap, needs an owner' WHEN COUNT(service_status) < COUNT(*) * 0.5 THEN 'sparse - monitoring gap' ELSE 'populated' END AS verdict FROM regulation_state;

Run that shape against every compliance-relevant field you hold. The fields returning no evidence source are your program gaps, and the list is almost always shorter than people fear and more specific than they expect.

Acknowledgement deadlines, and evidence of timeliness

Five regulation state changes on the same fleet were acknowledged after their deadline. That finding is only possible because three things were captured: when the state changed, when it was acknowledged, and what the applicable window was.

Most platforms capture the first two and not the third, so lateness is computable only by someone who already knows the requirement — which means it is computed during an audit rather than before one. The window belongs in the data, expressed in plain language alongside the obligation, so that timeliness is a query rather than an expert judgement.

Chapter five

The obligation calendar — and the field nothing could write

209 obligations loaded. 65 recurring intervals. Zero with a last-performed date, so not one next-due date was computable. The field existed. Nothing in the application could write to it.

What was loaded

Three structural observations

Applicability is upstream of everything. Thirty-three unanswered gates suppressed seventy of eighty-six dated obligations. Until an entity establishes which requirements apply to which registered functions and assets, a calendar cannot tell it what is due. Applicability analysis is not preparation for compliance work; it is the first compliance work.

An interval with no baseline cannot compute. A next-due date is last-performed plus interval. With last-performed empty, the correct output is cannot compute — last performed not recorded, which is what the platform correctly displayed. A default would have been worse: a next-due date computed from a blank is not conservative, it is arbitrary, and it will be believed.

Deferrals are first-class. Thirty-seven open deferrals, recorded as data rather than living in email, is a materially stronger position than thirty-seven items quietly omitted. A deferral with a reason and an owner is a managed position. The same item undocumented is a gap.

Completion as a record, not a checkbox

Calculation 3 · What a completion must capture, and what it must refuse

-- hard date -> closes THAT occurrence only. Next month is its own row. -- interval -> sets LAST PERFORMED, which makes next-due computable. CREATE FUNCTION compliance_complete_obligation( p_obligation_id text, p_performed_on date, p_note text ) RETURNS TABLE (out_obligation_id text, out_next_due date) LANGUAGE plpgsql AS $$ DECLARE v_actor text := current_operator(); -- session, never a parameter BEGIN IF v_actor IS NULL THEN RAISE EXCEPTION 'unattributed completion refused'; END IF; IF p_performed_on > current_date THEN RAISE EXCEPTION 'completion date in the future refused'; END IF; -- ... writes completed_at, completed_by, performed_on, note -- ... and, for intervals, last_performed_at END $$;

Four properties make that a record rather than a checkbox: it captures who from the session rather than from a parameter; it captures when performed separately from when recorded; it refuses an unattributed call; and it refuses a future date. Reopening requires a written reason that stays on the record permanently — nothing is quietly un-completed.

The bug that shipped, and the lesson in it

Ours. The first version of that function shipped broken. Declaring RETURNS TABLE (obligation_id text, ...) creates an output variable of that name, which collides with the table column of the same name:

42702 — column reference "obligation_id" is ambiguous. It could refer to either a PL/pgSQL variable or a table column.

Both refusal paths passed in production. Unattributed operator: refused correctly. Future date: refused correctly. Everything tested was green.

The one thing not tested was the success case. It was caught only by completing a real obligation.

The correction renamed the output columns and schema-qualified every column reference, and the self-test now exercises the success path against a real row and reverts it. That reversion matters: the verification data was cleared afterwards, so the performance view reads empty. A fabricated performance record on a compliance calendar is worse than no feature at all — it is the one place where test data becomes an assertion that work was done.

The general lesson generalises past this bug. Testing that a control refuses correctly is only half a test. A function that refuses everything passes every negative test ever written.

Chapter six

Reporting readiness, field by field

Periodic operational reporting fails in a specific way: not all at once, but three fields at a time, discovered at submission.

The remedy is a standing, field-level readiness position rather than an annual scramble. For each field in the reporting set, one of five states — and for anything not live, the specific route to resolution.

The fifth state carries the most value, because it routes work correctly. A field that needs a registry lookup, a field that needs an engineering document, and a field that needs somebody to make a decision are three different tasks for three different people — and lumping them into "missing data" sends all three to the wrong person.

The discipline that makes this work. A field in defect is withheld from submission, not submitted with a caveat. A known-wrong value in a regulatory submission is a materially different act from an omission with a stated reason, and the difference is not one of degree.

Chapter seven

Controlled documents as evidence

A procedure library is an evidence source. That imposes four requirements most document stores do not meet.

Two findings from one load

Ninety-nine of 121 documents still carried a template document number rather than a real one — two had genuine numbers. That was raised ahead of the library's effective date rather than discovered afterward, which is the entire value of looking.

The library was future-dated. Every document carried an effective date ahead of the load. The library existed and was not yet in force — a distinction the retrieval layer must carry into every answer it gives.

The classification decision

None of the ingested documents was a reliability standard. They were the entity's own procedures, which implement standards. An earlier load let automatic detection read internal document numbers as standard numbers and filed eight procedures as standards.

Had that stood, a question about what a standard requires would have been answered with the entity's own procedure. That is provenance erasure at its most consequential: an entity citing itself as the source of a requirement. A procedure describes what an entity chose to do. A standard describes what is required. In an evidence conversation, confusing them is fatal to the position.

The rule. Document type is declared explicitly at ingest, never inferred from the document's own contents. Any linkage to a standard is a separate field. Automatic detection may propose a classification; it may never assign one.

Chapter eight

Ten questions for your own evidence position

The other failures in this series make numbers wrong, and a wrong number can be recomputed. This one makes correct numbers uncitable — and the underlying operation may have been perfect.

Chapter nine

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.

Provenance is the difference between a number you can show and a number you can cite. This chapter is the provenance discipline as RenewOps implements it — including the eight sites out of twenty-five that currently earn a citable figure, and the seventeen that do not.

Every voltage schedule carries a provenance class

All twenty-five sites are classified, on 25 August 2026, into one of six states:

Eight of twenty-five sites receive a citable in-band percentage. All eight come from a complete documented schedule. One site that had been publishing 62.9 per cent against a placeholder band on the wrong bus now publishes nothing at all and reads WRONG BUS instead.

Seeded is labelled, permanently

A band auto-detected from a site's own historical median is not a schedule, and RenewOps labels it INDICATIVE ONLY wherever it appears. Only five of twenty schedules were compliance grade when the classification was applied. Monthly evidence output now requires complete documented provenance before it will produce a figure — a band the operating entity never issued is not evidence of conformance to a band the operating entity issued.

What that fixed. Before the classification, compliance exports carried no provenance flags at all and published in-band percentages for wrong-bus sites and for sites explicitly disabled — including tautological readings of exactly 100.0 per cent, where the band had been derived from the median of the very series being scored against it. A perfect score against yourself is the cleanest illustration in this reference of a number that is arithmetically correct and evidentially worthless.

Citations are recorded as citations

Each schedule row quotes its source inline: the file, the path, the server-modified date, and the document key. The source document's own defects are recorded on the row rather than repaired in it. A garbled extract stays garbled and says so, because silently cleaning a source document destroys the only evidence that it needed cleaning.

The write door

The schedule of record may only be set through one controlled path, which demands a directive reference, refuses an implausible setpoint, writes history, and stamps the source. It is never written directly.

Two honest notes on that control. First, as of 25 August 2026 it had no caller — schedules arrived through document load, so the path is correct and unexercised. Second, a corrupt seeded setpoint sitting at an impossible value was left in place rather than edited, and the plausibility layer refuses to use it as a banding input. Changing a voltage schedule is a person's decision made against a directive. It is not a data-quality cleanup, and RenewOps is built so that it cannot become one.

The evidence it declined to create. Two live sites have complete documented schedules and deliver no voltage telemetry. No schedule row was written for either. A band against a dead channel yields either silence or a 100 per cent excursion the moment a tag appears — and both of those are fabricated evidence, one reassuring and one alarming.

A dead field inside a live row

Per-field liveness is recorded with the age of each field and its count of unanswered polls, because a row reads live when any one of its fields is fresh. Behind that, fields dead between 41 and 293 days sat concealed behind between 289 and 413 unanswered polls. The schedule- versus-controller comparison now returns CANNOT COMPARE on a dead point rather than agreement — it had been producing a pass on evidence that does not exist, which is the worst of the three possible outcomes.

The obligation nobody could mark done

Recurring intervals compute a next-due date only from a recorded last-performed date. With no baseline recorded, all sixty-five regulatory intervals read cannot compute — last performed not recorded. Not a default. Not the start of the calendar year. Not silently overdue. Recording the date once makes the interval computable, and the prompt to record it is itself raised by the rules engine.

Marking an obligation complete behaves differently by type. A hard date closes that occurrence only, leaving the next untouched. A recurring obligation records LAST PERFORMED — the field that unblocks the next-due computation. Both refuse an unattributed call and both refuse a completion date in the future. Reopening requires a written reason that stays on the record, and a completed view shows who recorded what, when, how many days early or late, and every reopen with its reason.

The test data that was deleted. After the completion function was verified, the test rows were cleared, leaving the performed list deliberately empty. A fabricated performance record on a compliance calendar is worse than no feature at all, because the fabrication is indistinguishable from evidence and will be produced as evidence by somebody acting in good faith.

Notifications that never claim to have been sent

Notifications compose into an outbox and hold as held-without-recipient until an address is configured. They are composed, readable, and never reported as sent. A compliance system that reports a notification as delivered when no delivery occurred has manufactured the one fact the obligation turns on.

Can the evidence survive the platform?

On 28 August 2026 a restore was proven onto a clean, empty database from the exported files alone: 136 tables, 202 views, 95 functions, 18 materialized views, 255 indexes, 163 policies. Zero schema errors, zero function errors, and all 220 relations execute.

Two things must be said about that result. The export was not self-sufficient and did not say so — it granted to roles it never created, so it failed on its first statement against an empty database. Anyone attempting a restore before that date would have concluded the export was broken. It was not broken; it was incomplete in a way that nothing recorded, which is the harder failure. And the materialized views must refresh in dependency order: refreshed alphabetically, four of eighteen fail, which breaks ten ordinary views — and nothing on screen says the numbers are stale. The screens simply report nothing.

Deferred, and stated precisely. What was proven on 28 August 2026 is a schema and objects restore from a schema-only export. A data restore has not been demonstrated. This reference does not describe the result as a proven backup of the evidence, and neither should anybody citing it.

Provenance is not a metadata field. It is the difference between a record that survives being questioned and one that only survives not being questioned.

The gap that remains

Content is guarded well across every controlled write in the platform. Identity is not. Who set a schedule, approved an override, marked an obligation complete or answered a prompt is recorded from a string the caller supplies. Every attribution in the system is therefore a claim rather than a verified fact, and an evidence layer that has solved provenance of values while leaving provenance of actors open has solved half the problem.

Figures measured 24–28 August 2026 on a live production instance and dated in the text. They describe that instance on those dates and are not a claim about any other fleet.

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