open-standards/wai/extensions/energy-binding.md

WAI Extension: Energy Binding

Status: Draft. Binds the energy a reconstruction cost to that reconstruction, as a companion to C2PA 2.4's c2pa.environmental-sustainability assertion — supplying the acquisition class, the coverage, and the outcome binding the standard assertion has no field for. Reference impl: the energy_binding module of wai-rs (feature provenance), emitted into a real signed manifest by c2pa_emit (feature c2pa_emit). Companion to Reproducible-Reconstruction Binding and the acquisition protocol in Energy Measurement. Keywords MUST, MUST NOT, SHOULD, MAY are RFC 2119/8174.

1. Why a companion assertion

C2PA 2.4 defines c2pa.environmental-sustainability, carrying energy_kwh (per ISO/IEC TR 20226:2025) alongside carbon and water figures. The dominant signed-provenance container in media now has a place to put joules.

Three properties it does not have, and this extension supplies:

1. It is self-declared. measurementMethod is optional, and an unattributed number cannot be compared with any other number. In practice the optional field is the one that stays empty.
2. It carries no acquisition class. A hardware counter reading and a modelled constant occupy the same field and are indistinguishable to a reader, though they are different claims about the world.
3. It is not bound to any reproducible output. The assertion is about an asset; a validator can check every signature in a manifest and still not know what the figure was measured over.

The third is the load-bearing one. A signature proves who said a number, never that the number is about anything checkable.

2. What the binding is

An energy binding is the tuple

{ reconstructionHash, alg, microjoules, acquisition, [evidence], coverage, workUnits, method }

where [evidence] is present exactly when acquisition is a refined hardware class, OnChipCounter or CalibratedInstrument (energy-measurement §2.3–§2.5); legacy HwShunt carries none:

field	present for	meaning
uncertainty	OnChipCounter, CalibratedInstrument	{ relativePpm, windowUs } — the declared standard (k = 1) relative uncertainty in ppm and the integration window in µs
counterFiltering	OnChipCounter	On / Off / Unknown
calibrationRef	CalibratedInstrument	identifier of the calibration certificate

carried as a third-party C2PA assertion under the reverse-domain label science.transaction.wai.energy.reconstruction, alongside — never instead of — the standard c2pa.environmental-sustainability assertion.

reconstructionHash is the SHA-256 of the canonical decoded pixels, the same digest reconstruction-binding commits to. Both assertions in one manifest therefore name the same decode by construction, and a manifest whose two digests disagree is self-refuting.

3. What this makes checkable, and what it does not

Where the reconstruction is at decode-equivalence — reproducible byte for byte on every conforming sink (determinism-tiers §2) — a verifier holding the codestream can do the following with any conforming decoder, and over wai.image.jpegai's exact-decoder reconstruction only with that decoder under the conditions in determinism-tiers §5 (reconstruction-binding §2):

• re-decode under the pinned descriptor,
• hash the pixels and confirm the energy figure is about those bytes,
• recompute workUnits from the descriptor rather than trusting it,
• and re-derive the rate.

What remains unverifiable is the measurement: the joules, and every field that describes how they were obtained — acquisition and its evidence, coverage, method, and the values of any report about the figure (energy-measurement §6). No verifier can re-measure any of them; each is its signer's statement. Some can be checked for consistency without re-measuring anything: the declared uncertainty against the resolution floor (§4), a calibration reference against the certificate it names (energy-measurement §2.5), and a report's bracket against the figure and the declared uncertainty it must give, and against the liveness rule (energy-measurement §6.2). Consistency is not truth. That is the point of the construction, and the honest limit of it. An energy claim about an output nobody can reproduce is not checkable at all. An energy claim about an output anyone can reproduce is checkable except for its measurement — and knowing precisely which fields those are is the difference between a measurement and an assertion.

An implementation MUST NOT describe an energy binding as proving the energy figure. It binds the figure to a reproducible outcome; it does not attest the measurement.

4. Normative rules

• The binding MUST carry an acquisition class (CalibratedInstrument / OnChipCounter / ModelBased / Estimator, per energy-measurement §2) and a coverage statement (Whole / Partial, §5 there). A refined hardware class MUST carry its evidence as above, and a new binding MUST NOT use the legacy HwShunt label.
• A refined hardware class's declared uncertainty MUST cover the figure's own rounding (energy-measurement §2.3): microjoules is a whole number of microjoules, so it is uncertain by at least 0.5/√3 µJ (≈ 0.289 µJ), and microjoules × uncertainty.relativePpm MUST be at least 288 676.
• A verifier reading a binding MUST accept HwShunt — it is what bindings signed before the hardware class was refined say, and it carries no evidence fields — and MUST reject a refined hardware class without its uncertainty, a refined hardware class whose microjoules × relativePpm is below 288 676, a CalibratedInstrument without its calibrationRef, and evidence fields beside a class that carries none. The floor needs nothing but the body and is computed in integers, so every verifier reaches the same verdict. A C2PA validator checks the signature over the body; these rules are about what the body says, and no validator applies them on the implementation's behalf.
• method MUST be present and name the published protocol the figure was obtained under. This is deliberately stricter than the standard assertion's optional measurementMethod.
• A figure of zero MUST NOT be recorded. A reconstruction that measured 0 µJ did not consume nothing; it failed to measure, and the honest artifact is the absence of an energy assertion rather than a zero in one.
• microjoules is an integer and is authoritative. energy_kwh in the standard assertion MUST be treated as a derived interop value: one microjoule is 2.8 × 10⁻¹³ kWh, so a whole image decode lands near 10⁻⁹ kWh, where the trailing digits of the float are artifacts of the conversion rather than of the measurement.
• An implementation MUST NOT populate carbon_kgco2e or water_litres from an energy figure and a grid-average factor while presenting the result as measured. Those are modelled quantities; emitting them beside a measured joule figure, in the same assertion, with no per-field provenance, is how a model comes to be read as a measurement.
• A Partial figure MUST NOT be presented as the reconstruction's total.
• A binding's identity is BLAKE3("wai:energy-binding-id\x01" ‖ JCS(body)), where body is the companion assertion's body as a JSON value and JCS is RFC 8785. A body holding an integer above 2⁵³ − 1 has no identity. A report about the binding's figure (jwp-receipts §2.4.8–§2.4.9) names it by this identity under the figure profile wai:energy-binding-id (energy-measurement §6.1). No member is added to the body, so a body written before this rule has the same bytes and an identity. No Ed25519 key signs a binding's figure, so an operating-point claim may name it and a measurement claim may not (jwp-receipts §2.4.8).

5. Relationship to the standard assertion

Interoperability is the reason both are emitted. A validator that understands only C2PA 2.4 reads energy_kwh and a populated measurementMethod. A validator that understands this extension additionally learns how the figure was acquired, how much of the work it covers, and which reconstruction it describes — and can check the last of those itself.

6. Emitting a manifest

The assertion shapes above are emitted into an actual signed C2PA manifest by the c2pa_emit module of wai-rs. Four decisions in that emitter are normative for anyone writing their own, because each is a place where the obvious implementation produces a manifest that validators reject, or that overstates what a decoder knows.

6.1 The inception action is c2pa.opened, not c2pa.created

A manifest MUST NOT describe a reconstruction with c2pa.created.

C2PA 2.x requires every c2pa.created action to carry a digitalSourceType, and that vocabulary describes how the content came to exist — captured, drawn by a human, generated by a model. A decoder does not know that. It reconstructed pixels from a codestream, and whatever was encoded could have been any of them. Selecting trainedAlgorithmicMedia because a codec has a neural stage would assert that a compressed photograph is AI-generated content, which is false, and the vocabulary has no member meaning "decoded; origin not visible from here".

A decode is in any case not a creation. It is a conversion of an existing asset into another representation, which C2PA already models: the codestream is a parentOf ingredient, the manifest opens it, and c2pa.converted records what was done. No action asserts a digitalSourceType, so no claim about the original's origin is made anywhere — which is precisely the position a decoder is in.

6.2 The codestream is carried as the parent ingredient

An emitted manifest MUST carry the codestream as a parentOf ingredient.

§3 turns on a verifier being able to re-decode. A manifest that carries the reconstruction digest but does not name what produces it hands the verifier a digest and no way to reach it. The digest says which decode the joules were measured over; the parent ingredient says what to decode to get there. Both halves, or the check §3 describes is not actually available.

6.3 The bindings are created assertions, not gathered

The bindings MUST be marked as attributed to the signer.

C2PA distinguishes assertions the signer stands behind from material gathered elsewhere and carried along — the same distinction between a claim and hearsay that the acquisition ladder draws inside the figure itself. These are first-party statements: the signer measured the joules and hashed the pixels.

This is load-bearing rather than editorial. A validator looks for the inception action among the created assertions, so an actions assertion left gathered yields a manifest that signs without complaint and every validator then rejects as assertion.action.malformed — a failure that surfaces only on the far side of a signature.

6.4 What a signature does not settle

An emitted manifest signed by an untrusted certificate reaches ValidationState::Valid — well-formed, signature intact, asset unmodified — and not ValidationState::Trusted, which additionally requires a certificate chaining to a known authority. An implementation MUST NOT present the first as though it were the second.

The gap between them is the whole of who says so, and it is orthogonal to everything §3 makes checkable: a perfectly reproducible reconstruction signed by nobody in particular is still a claim from nobody in particular.

7. The operating point, and why a joule figure alone is not enough

7.1 Degradation-blindness

A receipt that records the joules a decode spent, and nothing about how much work it was asked to do, is degradation-blind. A sink can always spend fewer joules by decoding worse, and a figure that cannot distinguish efficient from degraded rewards the wrong behaviour precisely where the number is meant to carry weight.

This is not hypothetical. ISO/IEC 23001-11 defines a decoding operation reduction request (DOR-Req) with which a receiving device asks the remote encoder for a less complex bitstream, so that its own decoder does less, and notes that its metadata can save more energy "at the expense of some QoE degradation". Its energy quantities are expected or potential savings stated in advance, not energy that was spent (determinism-tiers §2), and a WAI receipt without §7.2's fields records only what was spent, with nothing about the operating point it was spent at. energy-measurement.md §5's recomputable-work-unit rule blocks the substitution at the byte-exact tier, but not at entropy-consistency, and not for the conventional codecs WAI already carries.

The rules below make the operating point part of the claim, so the joule figure is scored against something rather than merely reported.

7.2 Request, commitment, delivery

Where one party requests an operating point and another acts on it, all three MUST be sealed, as op_requested, op_committed and op_delivered, in an operating-point claim about the figure spent at that operating point (jwp-receipts §2.4.9). The claim names that figure by its figure profile (energy-measurement §6.1) and leaves the receipt that seals it unchanged:

field	meaning
op_requested	the operating point the requesting party asked for
op_committed	the operating point the acting party said it would use
op_delivered	the operating point actually used

In the 23001-11 case in §7.1 the receiver requests and the sender acts: a receiving device sends a DOR-Req, and the remote encoder answers with a DOR-Resp saying how it decided to answer.

An operating point is a class-scoped descriptor — frame rate, spatial resolution, a complexity target — and this extension does not define its vocabulary. The claim names the vocabulary its parameters are drawn from by URI, and writes each operating point as an object from parameter to unsigned integer, so whether two operating points are equal is a comparison of canonical bytes. What this extension fixes is that the three are distinct fields, because the interesting cases are exactly the ones where they differ, and that whether the commitment was met is derived from them, never stated.

• A claim MUST NOT carry op_delivered without op_committed (operating_point_delivered_alone). A delivered figure with nothing to score it against is the degradation-blind case §7.1 describes.
• op_committed MUST be recorded as what the acting party stated, even where it differs from the request. A commitment that silently becomes the request is not a commitment. No verifier can check what was stated; the claim is its signer's account of it.
• Where op_delivered differs from op_committed, the claim records both and states nothing about whether the commitment was met. A reader MUST NOT report the commitment as met unless it derives that op_delivered equals op_committed (jwp-receipts §2.4.9).
• An operating point MUST NOT be recorded against an unmetered figure or a figure labelled with the legacy HwShunt. An operating-point claim restates a figure with a refined or model class: a claim restating HwShunt is refused (energy_legacy_acquisition), and one naming a figure that carries the unmetered marker or no class is refused against it (figure_disagrees, figure_unclassified).
• A receipt over a payload that an encoder altered to save energy, whether at a receiver's request (such as a decoding-operation-reduction or attenuated-video request) or on its own account, covers that payload, and MUST NOT be presented as covering the payload it stands in for — see determinism-tiers §2, What a tier covers.

This converts a recorded number into a number measured against a promise. Neither the prescriptive standards nor the measurement standards provide that pair: one says what should be spent, the other what was, and nobody scores the second against the first.

Staged delivery registers the vocabulary urn:wai:staged-delivery:1, whose one parameter is wai-stage:layers, the number of layers a prefix of a stage set holds (staged-delivery). A stage claim (jwp-receipts §2.4.10) records the stage requested, committed, delivered and presented as points of it. Its signer observes what arrived rather than scoring an operation against a request, so it may record a delivered stage with no commitment beside it.

7.3 The residual

When a declared complexity or operating-point descriptor and a measured energy figure both cover the same reconstruction, the claim about that figure MUST carry the prediction the descriptor gives: the prediction member of an operating-point claim (jwp-receipts §2.4.9), holding the energy the descriptor implies for that work, the model that computed it, and the hash of the descriptor. The residual — the signed difference between the energy measured and the energy the descriptor implies — is not written. Every reader derives the same one, joules_micro − predicted_joules_micro, so it can be neither stated inconsistently with the two figures nor dropped once the prediction is sealed.

• predicted_joules_micro MUST be stated for the same work as the figure (energy-measurement.md §5), or the residual compares two different things and means nothing. A verifier checks that the claim names the figure; it cannot check what work the prediction was made for.
• A residual MUST NOT be reported without the acquisition class of the measured term. An operating-point claim restates the figure's class and is refused where the figure has none (figure_unclassified). A residual against an Estimator figure is a difference between two predictions.
• An implementation MUST NOT omit a prediction because the residual is large. The large ones are the informative ones; omission converts a falsifiable claim into an unfalsifiable one. No verifier can tell an omitted prediction from one never made, so this rule binds producers.

The residual is what makes the predictive half checkable. A complexity descriptor is a prediction about energy, and until something records what actually happened against it, the prediction is never wrong. This closes that loop in the artifact rather than in a report.

7.4 Companion capability

Green-metadata semantics are not yet registered as a capability. When they are, they are registered the way wai.meta.hdr10plus and wai.meta.dovi are: the capability names the descriptor class — complexity metrics, quality recovery, display adaptation — and the sink supplies the decoder. No carriage is adopted: ISOBMFF and DASH carriage of green metadata belongs to another layer, and WAI naming a descriptor does not make WAI responsible for moving it. Until then, an operating-point claim names the vocabulary of its operating points and the model behind its prediction by URI (jwp-receipts §2.4.9).