ElecTrace methodology for on-site electricity accounting

ElecTrace accounts for on-site electricity use and packages the supporting record.

Purpose and application

The method applies to generation and demand within a confirmed supply boundary. It calculates physical use in each interval, applies the selected allocation rule when output is shared, and keeps the data and supporting material with the result.

Cases may use anonymised operational data, aggregated records, models or user-provided inputs. Each source is identified on the page, and authorised feeds can be connected to the same workflow.

The Impact Study compares equipment, carbon factors, fuel use and imported embodied-emissions totals. It runs separately from the Evidence Record.

The confirmed supply topology and settlement point define the physical boundary.

Electrical boundary and physical matching

Generation and demand qualify when both are inside a confirmed supply boundary and the electricity has not crossed that boundary's public-grid import or export settlement point. Distance to the nearest transformer does not define the boundary.

A private-wire network may cover more than one building when its meter hierarchy and electrical topology support a common boundary. The active topology version must identify generation assets, site meters, beneficiary meters and the settlement point.

For each interval, on-site matched electricity is the smaller of generation and total demand. Generation left after matching is export. Demand left after matching is grid import. All internal energy values use integer Wh and must conserve in every interval.

UTC is canonical; local time is a display layer.

Interval resolution and time policy

Records store interval start and end times in UTC. The UK interface displays Europe/London time and identifies GMT or BST. This keeps repeated or missing clock hours at daylight-saving transitions unambiguous.

DEMO-60@1 uses native 60-minute aggregated input. UK-ONSITE-30@draft requires authentic 30-minute input. The method does not disaggregate a coarse interval to create evidence at a finer resolution.

Generation, demand and any allocation inputs must cover the same interval before they can be matched. A monthly total cannot fill an unknown interval without an explicit estimation method and a lower evidence status.

Every stream keeps its source class and quality state.

Data provenance, missing values and estimates

Supported source classes include metered, aggregated, modelled, profile-scaled, estimated and user-provided. A value does not become metered because it follows the same JSON shape as a meter export.

The ingestion process checks schema, units, meter identity, direction, timestamps and duplicates before it normalises accepted energy to integer Wh. It also records the source payload hash and the active topology version.

Missing or invalid intervals are frozen for evidence use and the interface lists what must be corrected. Estimated values may be saved and shown when their method is explicit. They retain an estimated label and a lower evidence level.

Physical allocation, claim rights and attribute status are related but different questions.

Allocation, contractual rights and environmental attributes

The current engine supports pro_rata_demand_v1, priority_v1 and contract_share_v1. Each rule caps a beneficiary's allocation at its demand, prevents double allocation and conserves all matched Wh.

Contractual entitlement records who has the right to the allocated electricity and the contract version used by the rule. Missing rights evidence does not erase the physical match. It prevents the record from showing a complete claim state.

Environmental-attribute status records whether a certificate or equivalent attribute was retained, transferred, sold, retired or remains unknown. An unknown attribute status is not a meter-accuracy failure, but it may prevent an exclusive claim.

Hashes bind the committed package and support independent consistency checks.

Canonical data, hashing and package verification

Canonical JSON gives the same structured input the same byte representation. SHA-256 identifies that representation. Each interval and nonce forms a Merkle leaf, and the Merkle root binds the ordered interval set.

An inclusion proof checks that one interval belongs to the set represented by a root. The independent verifier recalculates the matching result, canonical hashes, Merkle root, proof paths, manifest hash, period, rule version and totals. It does not trust a saved success flag.

A confirmed record is fixed; a correction creates a linked version.

Drafting, confirmation, correction and supersession

A monthly period moves through collecting, draft, reviewable, confirmed, frozen or superseded states. Frozen intervals cannot support a successful claim until the listed data or evidence problem is resolved.

A site operator confirms topology, meter operation and operational exceptions. A claim reviewer confirms contractual entitlement and environmental-attribute status. Each confirmation records the account, displayed name, role, attestation text, UTC time, workspace, record ID, manifest hash and method version.

The system does not update a confirmed record in place. A correction creates a new record and hash, links the earlier version, stores the reason and actor, and requires confirmation again. The earlier package stays available and verifiable but is marked as superseded.

The public result is smaller than the authorised evidence workspace.

Public summary and private evidence

An authorised workspace may hold interval data, meter topology, contracts, attribute records, quality issues, confirmations and correction history. Access is scoped to the pilot and its assigned users.

A public case study may disclose only an authorised aggregate, the method version, evidence level and manifest hash. Detailed intervals, beneficiary demand and topology remain private unless the site approves a wider disclosure.

The human-readable report is a view of the underlying Evidence Record. It cites the same record ID, period, rule, status and manifest hash; it is not confirmed as a separate result.