Six Ways to Compute 99%

Chapter one

Four ways to compute availability, and why the choice is contractual

Availability is not one metric. It is a family, and which member of the family applies to a given site is a question about that site's executed agreement, not about engineering preference.

Calculation 1 · The four, stated

-- Time-based. The exclusion set is where the argument lives. A_time = (period_hours - unavailable_hours + excluded_hours) / period_hours -- Production-based. The counterfactual is where the argument lives. A_prod = actual_MWh / (actual_MWh + lost_MWh_due_to_unavailability) -- Capability. The DENOMINATOR is where the argument lives. -- available_capacity summed over INSTALLED units, never over healthy ones. A_cap = SUM(available_capacity_MW) / SUM(installed_capacity_MW) -- Performance-ratio linked. Two references, both fallible. A_pr = PR_measured / PR_reference

Why the choice cannot be made by engineering

Each construct produces a different number from identical plant behaviour, and the differences are not small. A site with half its inverters offline but full grid connection scores near 100% on a naive time-based construct and near 50% on a capability construct. Both are correct implementations of their own definition.

Only the executed agreement can say which one is owed. Where the monitoring platform computes one and the contract requires another, the reported number and the contracted number are different quantities that happen to share a name and a unit — and the difference has never been quantified, because nobody has been asked to.

The question to ask internally this week. Does the availability figure you report to each counterparty use that counterparty's construct, or your internal one? In our experience the two are frequently different, the delta has never been computed, and nobody in the organisation is aware there are two numbers.

Chapter two

Computability — the state before the number

Before asking what availability is, ask whether it can be computed at all. On the assessed portfolio, for a substantial fraction of sites, the honest answer was no.

Four states, per site

The distinction between blocked and undefined matters commercially. Blocked is a bilateral gap — both parties signed something evaluable in principle and neither supplied the inputs. It is fixable by agreement. Undefined means the agreement does not, on its face, define the thing it guarantees, and fixing it is an amendment.

The rule that follows

A site that is not ready publishes no availability figure, and no comparison against guarantee.

It publishes its state, the specific blocker, and the input that would resolve it. That is more useful than a number, and it is the only defensible output.

The failure this rule exists to prevent

On the assessed platform, a comparison against guarantee was populated for eleven blocked sites and one partial site — twelve sites whose contractual figure could not be computed. Six of them read exactly +1.0.

A variance of exactly one point, on a site whose construct cannot be evaluated, is not a measurement. It is an artefact of a default. And it was rendered in the same column, in the same format, as genuine variances from sites that were computing correctly.

Calculation 2 · Gate the guarantee comparison on computability

SELECT c.site_id, c.computability_state, c.blocking_input, -- the figure itself, only where the construct is evaluable CASE WHEN c.computability_state = 'ready' THEN a.availability_pct END AS contractual_availability, -- and the comparison, gated the same way CASE WHEN c.computability_state = 'ready' THEN ROUND(a.availability_pct - g.guarantee_pct, 2) ELSE NULL END AS vs_guarantee, CASE WHEN c.computability_state <> 'ready' THEN 'not computable: ' || c.blocking_input END AS withheld_reason FROM availability_computability c LEFT JOIN availability_monthly a USING (site_id, period) LEFT JOIN site_guarantee g USING (site_id) ORDER BY c.computability_state, c.site_id;

Note that withheld_reason is a column, not a footnote. It travels with the row into every consumer — a report, an export, a board pack — which a footnote does not.

Chapter three

Reading the construct out of the executed document

Five questions, per site, answered from the executed agreement rather than from what everyone assumes it says.

1. What exactly is the denominator, in the contract's own words? Installed capacity, contracted capacity, capacity available for dispatch, or an asset count. These give different answers and the agreement usually specifies one.

2. Which exclusions apply, and can each be identified in your data? Force majeure, grid outage, curtailment by the offtaker, scheduled maintenance within an agreed window. An exclusion you cannot identify in the data is an exclusion you cannot take.

3. Is every coefficient the equation needs actually populated somewhere? This is the question that returned no most often.

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 three, in detail

Several sites specified a regression-based expected-output model whose coefficients the agreement left to be mutually agreed after execution. The coefficients were never agreed. The practical consequence:

▸ The contractual figure cannot be computed by either party.

▸ Any figure being reported is therefore computed some other way — by definition, not the contracted way.

▸ The guarantee is unenforceable by the offtaker and undemonstrable by the owner. It protects nobody.

▸ The party who raises it first controls how it is characterised.

The asymmetry worth internalising. Discovered internally, an uncomputable guarantee is a remediation project on your own timeline, resolved by a short bilateral agreement on coefficients. 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.

Exclusions you cannot identify

An exclusion is worth nothing unless the data can evidence it. On the assessed fleet the curtailment record could not support a curtailment exclusion at all: the flag indicating curtailment was false on every row across ten thousand rows, the directed-curtailment quantity was null on every row, and coverage extended to three site keys of which one was not a fleet site.

During a live curtailment event at one site — output walking from 300 MW to 37.5 MW inside fifty minutes — the record continued to report not curtailed. Any exclusion claimed on that basis would fail on inspection, and the failure would be discovered by the party inspecting it.

Ours, and the correct handling. The remediation set that flag to NULL wherever no determination had been made. False asserted "not curtailed," which is a claim the data never supported — and a false all-clear during a real curtailment is worse than no reading. A companion view now names, per site, exactly which input is missing.

Chapter four

The denominator that doubled overnight

Six sites showed availability moving 100% → 50% → 100% across three days. No physical event occurred. The numerator never moved.

The observation

A forty-nine point excursion below guarantee, on a site where nothing happened. Repeated at five other sites. On one site the denominator briefly became 300 — the site's AC nameplate in megawatts, substituted for a count of inverters.

The root cause

The asset crosswalk table carried two different populations in one table: inverters, and the modules that make them up. It already distinguished them with a boolean flag. The ingest was not applying the filter.

Whether a given snapshot picked up the inverter population or the combined population depended on which rows the load happened to touch — hence the exact multiples, and hence the reversion when the next load behaved differently.

Ten of seventeen sites were mixed in this way. Counting on the flag gives a correct fleet-wide inverter population of 2,293. A separate view reported 1,993 — a three-hundred-unit discrepancy that resolved entirely to one site, where a view filtered on an asset type that means "inverter" at every other site and something else entirely at that one.

Naming is not a reliable guide and must not be used as one. At one site the rows named as inverters are the inverters. At another, the rows named as modules are the ones carrying the inverter flag. Any logic inferring population from a naming convention will be right most of the time and silently wrong at the exceptions — which is the worst available outcome, because it is invisible in aggregate.

The fix, and the twenty rows that were not fixed

A single function became the sole source of the site inverter count, and a guard trigger stamps the population flag on every row at write time.

Then the hard part. Twenty historical rows were withheld rather than recomputed. The reasoning is worth stating in full, because the temptation to backfill is strong and wrong:

A wrong denominator means the online count was taken over the same wrong population. Correcting the denominator alone does not repair the ratio — it produces a new ratio between two quantities that were never measured over the same set.

The correct output is NULL with the reason on the row: denominator population uncertain for this date; figure withheld. Twenty days of withheld availability is a defensible record. Twenty days of recomputed availability is a fabricated one, and the fabrication is undetectable afterward.

Calculation 3 · Denominator stability — run this on your own history

-- A denominator should only change when assets are commissioned -- or decommissioned. Any other movement is a data defect. WITH d AS ( SELECT site_id, as_of_date, denominator_count, LAG(denominator_count) OVER (PARTITION BY site_id ORDER BY as_of_date) AS prev FROM availability_daily ) SELECT site_id, as_of_date, prev, denominator_count, denominator_count - prev AS delta, ROUND(denominator_count::numeric / NULLIF(prev,0), 3) AS ratio, NOT EXISTS (SELECT 1 FROM asset_commissioning_events e WHERE e.site_id = d.site_id AND e.event_date = d.as_of_date) AS unexplained FROM d WHERE prev IS NOT NULL AND denominator_count <> prev ORDER BY unexplained DESC, ABS(denominator_count - prev) DESC;

Read the ratio column first. Exact ratios — 2.000, 0.500, 1.500 — are the signature of a population swap rather than a physical change. Commissioning moves a denominator by ones and twos. It does not double it overnight and halve it back.

Chapter five

Nameplate, and the reference that poisons everything downstream

Nameplate is the reference used by capability availability, by performance ratio, by plausibility bounds, and by every per-MW commercial calculation. A wrong nameplate is wrong in four places at once, and the four disagree in ways nobody traces back.

Observed discrepancies

Comparing contracted capacity against the capacity held in the operational platform, most sites agreed within one percent. Two did not: one showed a 31% gap, another an 8.5% gap in the other direction.

The 31% site was a performance-ratio-linked availability site. That is the worst possible place for the discrepancy to land: the nameplate is in the denominator of the performance calculation, so a 31% error flows directly and proportionally into a contractual number.

Why nameplate discrepancies are structural rather than careless

The same site has several legitimately different capacity figures, and they are not interchangeable:

Hybrid sites make it worse. Where an agreement prices a generation and storage site as a single line, the operational platform frequently holds only the generation half — so the two disagree by exactly the storage nameplate, and the difference looks like an error rather than a scope mismatch.

The design rule. Four named capacity fields, never one. Each carries its own provenance and its own source document reference. Any calculation naming "nameplate" without qualifying which one is refused at review.

And a site with no capacity reference is a gap on a list, not an exemption. On the assessed fleet, a site with no nameplate row had a corrupt meter contributing 39% of the fleet rollup with nothing to check it against — the plausibility void of EC-WP-1100, arriving through the availability reference table.

Chapter six

Expected output — why peer referencing beats a curve

Production-based availability needs a counterfactual: what would have been produced but for unavailability. How that counterfactual is derived determines how the metric behaves when instruments fail.

The two methods

Curve-based is more elegant and, with healthy instruments, more precise. On paper it wins.

Then eleven days happen in which the measured-irradiance feed reports zero at every site while rows continue to arrive on cadence. A curve method fed a zero does not fail — it succeeds. It publishes eleven days of confident expected-power figures and every derate classification underneath them.

On the assessed fleet the same defect surfaced in completed-day form: four site-days in seven where measured insolation was recorded as zero against real generation, the clearest being 1,059.6 MWh generated against zero reported sunlight.

A method that gets less precise when the world gets uncertain beats one that stays precise and stops being true.

Calculation 4 · Peer-referenced expected output, with coverage

-- Expected output for a unit = median normalised output of its peers. -- Coverage is published, not assumed. WITH peers AS ( SELECT p.interval_ts, p.site_id, p.unit_id, p.output_kw / NULLIF(p.rated_kw,0) AS normalised FROM unit_output p WHERE p.state = 'generating' ), ref AS ( SELECT interval_ts, site_id, PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY normalised) AS peer_median, COUNT(*) AS peer_n FROM peers GROUP BY interval_ts, site_id ) SELECT u.interval_ts, u.site_id, u.unit_id, u.output_kw, ROUND(r.peer_median * u.rated_kw, 1) AS expected_kw, r.peer_n AS peers_in_reference, -- refuse the comparison on a thin reference set CASE WHEN r.peer_n < 5 THEN NULL ELSE ROUND(100.0 * u.output_kw / NULLIF(r.peer_median * u.rated_kw,0), 1) END AS pct_of_expected, CASE WHEN r.peer_n < 5 THEN 'withheld: peer reference below 5 units' END AS withheld_reason FROM unit_output u JOIN ref r USING (interval_ts, site_id);

Two properties make that query defensible. The peer count is published on every row, so a reader can see when the reference thinned. And the comparison is withheld below a floor rather than computed against two surviving units — the denominator-drift failure of EC-WP-1100, caught at the point it would otherwise enter.

Where curve methods remain correct

Peer referencing needs peers. A single-inverter site, or a fleet where all units share one failure mode, has none. The honest position is not that one method is superior but that the method must be stated with the number, and where a curve method is used its irradiance input needs an independent plausibility check ahead of it — the completed-day reconciliation of generation against reported insolation, run daily.

Chapter seven

What an availability figure must carry

Seven fields. A figure missing any of them cannot be defended in a dispute, whatever its arithmetic.

The test. Hand your monthly availability figure to someone with access to your raw data and the executed agreement, and ask them to reproduce it. Every question they have to ask you is a field missing from the list above — and in a dispute, the person asking will not be someone you can answer informally.

Reporting the internal and contractual figures side by side

Where an internal method is carried alongside the contractual one — which is reasonable and often operationally necessary — both are published, labelled, with the delta computed and explained.

What is never acceptable is one column labelled "availability" whose method varies by site depending on what could be computed. That column will be summed, averaged and reported, and the resulting fleet figure is an average of quantities measured different ways.

Chapter eight

Ten questions for your own portfolio

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.

Six constructs, one guarantee, and a platform that returns a position rather than a score. What follows is what the RenewOps contract layer does with an availability figure it cannot compute — which, on the fleet measured, is most of them.

Computability is the output, not availability

The contract layer returns, per site, one of four states with the specific blocker named:

On the fleet measured, eleven of twenty-three sites read blocked, and the dominant cause is the one in Chapter two: coefficients left "mutually agreed upon" in the executed agreements and never populated. The panel says so. It does not fill them in with a market convention, and it does not average around them.

Why a position beats a score. A score compresses "I computed this and it is 97.2" and "I could not compute this so I assumed the coefficient" into the same cell. A position cannot. Blocked is not a bad number; it is the absence of a number, attributable to a specific line in a specific agreement, and it routes to counsel rather than to operations.

No rollup was invented

The upstream source returns availability per asset. Whether a given agreement averages by asset count or weights by nameplate is a term of that agreement, so RenewOps does not choose. The site figure publishes as an unweighted mean, named as unweighted, with the per-asset minimum and the count below threshold beside it. A reader who needs the contractual weighting has everything required to apply it and is told plainly that it has not been applied.

Three figures, side by side, with the gap labelled

The platform's own inverter-count availability is published beside the upstream contractual figure and the upstream technical figure. One site on one day reads 66.0 per cent, 84.76 per cent and 51.45 per cent.

None of the three is wrong at its own source. They answer three different questions, and the screen's job is to say which is which rather than to pick a winner and hide the others. The platform's own figure carries a standing disclaimer stating it is not the contractual figure.

The column that is used in nothing. The technical availability figure is ingested, stored, and exposed — and consumed by no calculation anywhere in the platform, because its behaviour contradicts its name. It reads 0.00 per cent at night and 11.58 per cent at midday against a contractual 98.47 per cent on the same asset and day. Until somebody with authority defines what it measures, it is held rather than used. Storing a figure and refusing to compute on it is a legitimate state, and it is a more honest one than finding a use for it.

Twenty rows withheld, and not estimated

The inverter denominator was corrected fleet-wide by counting only rows carrying an inverter flag — the upstream source holds both inverters and their sub-modules in one population, and ten of seventeen sites are mixed. Naming is explicitly rejected as a guide: at one site the rows named as inverters are the inverters, and at another it is the rows named as modules that carry the inverter flag. Only the flag is authoritative.

The consequence is the part worth reading. Twenty historical availability rows were computed against the wrong denominator, which means the online count was taken over the same wrong population. The percentage cannot be corrected. Those rows are withheld, return blank, and carry the reason on the row. They are not estimated, not interpolated, and not quietly dropped from the series so the chart looks continuous.

A figure pulled early is not a settled figure

Contractual availability is not final on the day. Where the contractual and technical figures agree to three decimal places, no exclusions have yet been applied — which means a "yesterday" figure pulled too early is a pre-exclusion number wearing a post-exclusion label. The behaviour is flagged and under observation, with the collection window likely to move back a day.

The ingest itself is idempotent on its natural keys and accepts a date argument for backfill, and the pipeline was verified by two independent pulls reproducing the same six site figures exactly. A number that cannot be reproduced on demand is not a measurement.

The dates behind the guarantee

A contractual calendar carries 490 obligations — 287 hard dates and 203 recurring intervals — alongside the regulatory calendar's 209. Two behaviours in it belong to this reference:

▸ Provisional dates are badged, not hidden. 84 of the 287 dated rows rest on an unconfirmed anchor. They load with their computed dates and a badge reading date provisional · anchor not confirmed, with the anchor text printed beneath the row. Nine sites have no usable anchor at all — including two agreements executed with the effective date left blank, which is a legal finding rather than a data problem.

▸ A cadence is not a date. 163 obligations that recur without a fixed day are loaded as recurring windows carrying the decision still owed and a confidence rating, rather than being turned into 163 deadlines nobody agreed to.

The temptation with an unpopulated coefficient is to use the market convention, because the market convention is usually right. It is also not what anybody signed, and the first time that distinction matters will be in a dispute.

What the contract layer does not yet do

No contract or guarantee data exists inside RenewOps as structured terms. The exposure figures in this reference came from reading executed agreements by hand. An obligations matrix that holds the terms as data is identified as the next step and is not built. Until it is, computability positions are produced by a person reading an exhibit, and the platform holds the result rather than the reasoning.

The upstream source holds twenty-three site trees; the platform's fleet holds twenty-five. The two lists are not the same, and the overlap has not been reconciled. That is stated before anything is ingested fleet-wide, rather than discovered afterwards in a number that does not add up.

Figures measured 24–26 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