Validation Records

Mixed electricity + gas utility bill, end-to-end accounting

Input: EnergyCAP mixed electricity + gas bill sample (Fairfax County procurement, Appendix D) — download the original file

Publicly posted procurement appendix from Fairfax County (Virginia, USA): a real EnergyCAP bill-import layout with data examples — actual utility billing data, not synthetic — mixing gas rows (USE:THERM / USE:CCF meter columns) and electricity rows (USE:KWH) with USD amount columns. We extracted the full mixed block of 12 gas + 7 electricity rows and uploaded it as one file, the way an energy manager's export arrives.

All 19 rows of the mixed block were accepted in a single upload with no pre-processing. Rows were split by meter column, normalised to one reporting unit, assigned to Scope 1/2 with EPA-traceable factors, and the dollar amounts were preserved line-by-line for bill reconciliation.

Checks performed

• Row completeness. 19/19 rows ingested from one mixed upload: 12 gas + 7 electricity, auto-split by meter column.
• Unit normalisation. therm and CCF both normalised to Nm³ using EPA default heat values. Spot check: 359.9 therm → 1,019.55 Nm³, matching hand calculation (×2.832861).
• Scope assignment. 12 gas rows → Scope 1 (factor EF-NATGAS-US-EPA-2025); 7 electricity rows → Scope 2 (eGRID subregion factor; Dominion service territory = SRVC).
• Totals cross-checked by hand. Scope 1 = 270.92 tCO2e (144,645 Nm³ × 1.873 tCO2e/Nm³ thousand-scale, hand calc 270.9 ✓). Scope 2 = 48.97 tCO2e over 181,028 kWh.
• Bill reconciliation. Amount fields preserved intact (e.g. USD 1,717.08 identical to the source row) so accounting teams can reconcile against the original bill.
• Regression guard. This public file is pinned as a regression fixture — every future pipeline change is re-verified against the same real bill, and the unit-conversion values above are asserted verbatim in the test suite.

Known boundaries

• If your bill states a measured Btu/cf heat value, convert to the standard unit on your side before uploading — the system applies EPA default heat values.
• Bills showing cost without metered quantity are rejected with an explanation: emissions must come from metered usage, never from spending.

Multi-tenant isolation and field-level confidentiality

Input: Due-diligence probe suite against a demo tenant

A due-diligence style probe run against the auth-enabled stack: one scoped API key for a demo tenant, then attempts to reach other tenants' data both through the UI and by calling endpoints directly.

Every request is scoped server-side by the token's tenant allowlist. Out-of-scope access returns a uniform 403 and forged keys a 401; the browser never receives other tenants' identifiers. Confidentiality levels hide raw consumption fields in real time, and every hidden field is written to an audit log that an external reviewer can inspect.

Checks performed

• Scoping in the token. Each customer receives its own API key; the exchanged 1-hour token embeds a hard tenant allowlist, enforced at the API layer.
• UI scoping. After logging in with one customer key, the tenant list contains only that tenant — the filter runs server-side, so other tenants' names are never sent to the browser.
• Direct-endpoint probe. Calling another tenant's endpoint with a valid scoped token returns HTTP 403; a forged or wrong key returns 401. Real out-of-scope tenants and non-existent tenants receive byte-identical responses, so one token cannot enumerate the customer list.
• Field-level confidentiality. Dropping the tenant's confidentiality level takes effect immediately without re-login: raw consumption values disappear while emissions values and benchmark bands remain — the split between "what a reviewer needs" and "what stays commercial".
• Hiding is auditable. Every field hidden from a reviewer is logged (endpoint, hidden field paths, timestamp), so an external auditor can verify what was withheld instead of assuming.

Known boundaries

• Run performed on a demo tenant with production security configuration; the probe methodology is available on request.

Emission factors and knowledge base traceability

Input: Factor seed files and 64-page knowledge base

Every figure the platform produces resolves to an emission-factor entry and, for methodology questions, to a knowledge-base page. Both are versioned — this is what "auditable numbers" means in practice.

306 emission factors with named official sources, each graded A/B/C by source quality; a 64-page industry knowledge base with per-page source citations and confidence ratings, maintained ahead of the 2026-10 acceptance run.

Checks performed

• Factor count and sources. 306 factors: China MEE national announcements, PlasticsEurope official LCI package, EIGA/IMO/ICAO international standards, US EPA and eGRID subregion tables. No factor without a named source.
• Version control. Every factor file lives in git — a change to any value or source leaves a reviewable history of who changed what and why.
• Knowledge base citations. 64 pages, each tagged with its sources and a confidence rating; methodology answers cite down to document-number level (e.g. ministerial letter numbers, regulation numbers).
• Conservative upgrades. When an official body publishes new factors, the system flags the drift and a human verifies before replacing — "absent" is preferred over "unsourced".

Known boundaries

• The knowledge base is written for factory managers and importers, not auditors; where a source is a projection rather than a regulation, it is marked as such.

Run your own bill through the same pipeline

The strongest validation is the one you perform: upload one month of your electricity or gas bill and read the resulting inventory, factor provenance and report draft before deciding anything.