Reading a Benchmark Exception: Evidence Origin, Status, and What Would Close It

A public benchmark describes a population of comparable projects, not any one specific project. A real project can have a genuine reason to sit outside the typical range.

DurationX’s methodology treats this as an expected, disclosed event rather than an error: a project exception. This article walks through exactly what that means, what evidence origin changes and does not change, and what the two deterministic checks behind it actually test — grounded in the real, current code and a real worked example, not a hypothetical.

What a project exception is

When a declared assumption lands outside the applicable public benchmark — most commonly a CAPEX figure below or above the matched cost-curve point — the audit does not silently accept or silently penalize it. It records four fields, together, as the exception:

• Benchmark position — where the declared figure sits relative to the matched public reference (for example, “aggressive”).
• Customer exception rationale — why the project team believes the departure is justified.
• Evidence origin — whether the rationale’s support is customer-provided, vendor-provided, or independently produced.
• Next evidence required — the specific artifact that would substantiate or close it.

Two fields never move once this exception exists: verification_status stays customer-declared, and residual_uncertainty stays high — always, regardless of which evidence origin is named. This is a deliberate methodology choice (specs/02-scoring-and-methodology.md §10.5): naming a vendor or an independent calculation as the basis for a rationale is not the same as DurationX having independently checked that calculation.

Evidence origin, and what it does not mean

Evidence origin is one of three values: customer, vendor, or independent. It is the only place in the whole audit where a real vendor- or independently-sourced tag can appear at all — every other assumption in the report is either a customer declaration or a derived calculation.

What it changes: how strongly the exception’s traceability is classified (the next section). What it never changes: the readiness score, the confidence score, or the exception’s own frozen evidence fields above. A confidence display driven by an evidence-origin difference alone would blur the line between “this is well-documented” and “this has been independently verified” — the audit keeps that line explicit instead. See Methodology, Section 3 for the same confidence-basis rule stated in full, and the parallel calibration evidence in How to Read DurationX’s Calibration Evidence.

The two checks: RCP-11 and ACR-10

Two deterministic mechanisms, in two layers, do the actual work. Neither is a new numeric score; both point to facts the audit has already computed.

RCP-11 — does the rationale match a real deviation?

One of eleven cross-assumption reconciliation checks (worker/src/cross-assumption-reconciliation.ts) compares the declared rationale against the actual, matched benchmark deviation it claims to explain. It resolves to exactly one of three states:

• Consistent — a rationale and evidence origin are declared, and a real, flagged benchmark deviation exists for them to explain.
• Flagged — a mismatch in either direction: a rationale is on file but nothing actually deviates, or a deviation exists with no rationale on file.
• Not evaluable — no CAPEX benchmark comparison applied to this project, or there is nothing to reconcile (no deviation, no rationale).

ACR-10 — how strong is the traceability?

One of thirteen audit controls (worker/src/audit-control-register.ts) then reads RCP-11’s result plus the exception’s own declared evidence origin and assigns exactly one of four control statuses:

Ranking vendor/independent evidence above a customer-only declaration mirrors an existing, already-shipped rule elsewhere in the audit: the evidence request generated for a benchmark exception already asks for materially different proof depending on origin (a vendor quote or framework agreement vs. an independent calculation vs. a bare internal one). This exact mapping is recorded as an owner-reviewable default, not silently assumed — see Docs/DECISION_REGISTER.md §4.93.

Neither check is scoring logic. Both are read-only projections over facts the readiness engine already computed — confirmed, not merely claimed: a controlled test freezes a real scoring result, computes the reconciliation pack and audit control register against it, and asserts the frozen readiness score is byte-identical before and after (worker/scripts/audit-control-register-smoke.mjs, assertion §17).

Worked example, from the real sample

The sample project is a 70 MW / 40-hour compressed-air energy storage case. Its CAPEX benchmark position is flagged aggressive against PNNL 2024 at 100 MW × 24 h — the nearest permissible published duty point — and the declared exception reads exactly as follows, taken directly from that report:

Applying the two checks above to exactly these facts: a rationale and an evidence origin are declared, and a real, matched CAPEX deviation exists for it to explain, so RCP-11 resolves to “consistent.” The declared origin is customer rather than vendor or independent, so ACR-10 resolves to “Conditional.” This is the second row of the table above: a real, traceable exception that still rests on the customer’s own statement. Had the same rationale named a vendor quotation or an independent recalculation as its basis instead, the same deviation would resolve to “Supported” — not because the underlying number changed, but because the traceability behind it would be stronger.

Note what does not happen: the readiness score is unaffected either way. The CAPEX-position finding is scored neutral_by_policy in this rubric version — disclosed, never silently penalized, and never silently rewarded for being well-sourced.

What evidence would close it

The exact artifact that would close a given exception is stated on the exception itself — in the worked example above, a dated internal calculation with its inputs, scope, owner, and approval status. In general, moving from “Conditional” toward “Supported” means replacing a bare internal statement with a named external source: a vendor quotation or executed agreement, or an independent calculation performed by a party other than the project team. This does not certify the number is correct — it strengthens the traceability of the claim, which is what the audit discloses and what the next diligence step can then examine directly.

Scope and current limitations

This mechanism is implemented and independently tested today: 119 fixture-based assertions across all eleven reconciliation checks and all thirteen audit controls (worker/scripts/audit-control-register-smoke.mjs), including the specific “supported exception” and “customer-only exception” cases this article describes. Every check behind the thirteen audit-control categories already runs against every delivered report today, mapped onto the scoring, cross-assumption reconciliation, and human review steps that already exist. The itemized, control-by-control register — the same thirteen results shown individually, each with its own evidence references — becomes part of the authenticated report drill-down once a report is produced under the report format built to carry it; it is not yet a rendered field on every delivered report or on the current sample. See Methodology, Section 2 for the complete, thirteen-category control list and the identical honesty note stated in full.

This article does not conclude, and DurationX’s audit does not conclude, whether any specific project’s benchmark exception is actually correct. It states what evidence is on file, how traceable it is, and what would strengthen it — a question for the next diligence step’s own specialist review, not a substitute for it.