open-standards/wai/research/energy-exposure-mapping.md

Media energy exposure: where WAI's per-object energy figure sits

A preparation document and not a submission. It maps WAI's energy measurement and binding onto the four bodies now specifying media energy: DVB, 3GPP SA4, MPEG (ISO/IEC 23001-11) and the IETF. It also notes one regulatory review window. Inputs to DVB require DVB membership. Inputs to 3GPP SA4 require membership of a 3GPP Organisational Partner. Comments on an ISO/IEC CD go through an SC 29 national body. WAI holds none of these today. The IETF is the one venue here open to any participant without membership.

This note cross-references rather than repeats. For the table of existing instruments and the reasoning that predictive metadata is not prior art against a measured binding, see 2030-transport-landscape §5. For the GREEN accuracy identities, see §3.5 there. The §1 table below updates four of the landscape's rows, because their stages have moved. The mechanisms mapped are energy-measurement, energy-binding, jwp-receipts and moq-streaming-format §5. The companion record 2026-09-global-sweep grades the wider field.

Which tree. WAI's side is described as it stands in the tree at link 10 of the landing chain: a linear chain of pull requests on the forge, each targeting main, merging in order. As of 2026-09-30 none is merged into main. The links this note relies on are link 01 (feat/wai-video-workflow, PR #82), link 02 (wai/land-02-determinism-tiers, PR #103), link 08 (wai/land-08-energy-classes, PR #109) and link 10 (wai/land-10-receipt-classes, PR #112); each link contains the ones before it. Everything attributed to a link is proposed in that link's pull request and is not in main. Where main differs, the text says so.

⚠ unverified marks anything not seen in a primary source.

---

1. The bodies and what each one carries

body / instrument	stage (verified)	granularity	measured or predicted	signed
DVB BlueBook S100, Study Mission report on Energy Aware service Delivery and Consumption	study report, Nov 2023. A CM-EE (Commercial Module) subgroup was announced on 17 Nov 2023 (2026-09-global-sweep §2.4). On 10 Sep 2025 the DVB chair wrote of "a working group on energy efficiency" launched in 2024 that "so far we have struggled to bring this group and topic to life", and invited participation; the article does not name CM-EE.	use cases and draft requirements; no specification	—	—
3GPP TR 26.942, Study on Media Energy Consumption Exposure and Evaluation Framework	V20.0.0 (2026-06, Rel-20), under change control; V19.0.0 (Rel-19). Phase-1 study FS_MediaEnergyGREEN (UID 1030004); phase-2 WI 1080050.	per UE, slice, DNN, PDU session, Service Data Flow; Application Server reports add application session, configuration and service location	network-function energy in joules from the 5G Core Energy Information Function (EIF); UE side left non-normative	no integrity or attestation mechanism in the text
ISO/IEC 23001-11 4th edition, Energy-efficient media consumption (green metadata)	CD text, WG 3 N1864, dated 2026-08-28, listed on mpeg.org 2026-09-21; CD ballot. The MPEG 153 output was a WD (mpeg.org lists it 2026-03-02), so landscape §5.1's "4th ed. at CD (WG 3 doc N01742)" is superseded.	per picture / per DASH Segment / per representation	predicted: complexity metrics, estimated decoding-operation ratios, display power indications	no
ISO/IEC 23001-19, carriage of green metadata	IS: advanced to publication at MPEG 153 (landscape §5.1; the MPEG 153 meeting page, read for 2026-09-global-sweep §2.1). The mpeg.org part page's newest document, dated 2025-10-24, is titled Potential improvement of ISO/IEC DIS 23001-19 — the DIS stage before that promotion — so the page and the meeting record are consistent. The N1864 CD text refers to it as "ISO/IEC 23001-19:2025".	ISOBMFF track / DASH adaptation set	carries 23001-11	no
draft-ietf-avtcore-rtcp-green-metadata-17	2026-09-09, RFC Editor queue, Proposed Standard. This supersedes landscape §5.1's "IESG evaluation at -16".	RTP session	request and notification of resolution/frame rate	no integrity mechanism beyond SRTP/SAVPF
draft-ietf-green-power-and-energy-yang-04	2026-09-09, WG document (the landscape cites -03)	device and sub-component	measured or estimated, with graded accuracy identities	no (an individual provenance augmentation exists, draft-madpr-green-provenance-00)
WAI: energy-measurement, energy-binding, JWP receipt profiles	Draft extensions in this tree	per object (one decoded clip, image or envelope)	as specified at link 10 (link 08, PR #109): a figure of one acquisition class — read from a calibrated external instrument (CalibratedInstrument) or from a counter the measured silicon keeps (OnChipCounter), each with a declared uncertainty, or model-based, or a coarse estimate; legacy HwShunt is accepted and never emitted (energy-measurement §2) — published only with a clean bracket and its quality ratio (§4, §6 there). As carried at link 10: every wai-rs and wai-quantum receipt family can sign the class, with the declared uncertainty for a hardware class; no receipt carries the quality ratio or the other bracket values (§7, L1, L9). On main, only the video receipt and the C2PA energy binding sign a class.	per profile. At link 10 the class is always signed in the energy binding, the video receipts and an energy claim (link 10, PR #112), and is an optional signed label in the older receipt families. The JWP group receipt signs a total with no class; the JWP object receipt's figure is outside its signature; the MoQ WAI_RECEIPT property has no signature of its own (§7, L1).

---

2. Against DVB S100's four use cases

Quoted requirement text is from S100 §7, read in full. S100 records "None in DVB" as existing coverage for use cases 1 and 3. For use case 2 it notes reporting APIs that were not designed for energy, and for use case 4 it lists existing codec, multicast-ABR and native-IP specifications.

Use case 1: Common energy consumption measurement. Draft requirement: "a common reporting framework on energy consumption allowing to provide metrics from all components of the delivery chain and used by all industry players." The service-provider view adds that third-party suppliers should use the same framework.

• What WAI offers: a reporting contract for one component, the decode (or production) of an object. A published figure must carry its acquisition class with the class's evidence, the idle mean and SD, the busy mean and SD, sample counts, the window, the completion count, the thread count and how the window opened, the attribution-quality ratio, the build profile and a recomputable work unit (energy-measurement §6). A figure below the publication bar may not be published as an absolute value, and a failed bracket is emitted as unmetered (§4 there). That is the record format a framework could carry for a decode component, including one run by a third party. In the tree at link 10 the class and, for a hardware class, its declared uncertainty are signed in every wai-rs and wai-quantum receipt family that carries them (§7, L1); the bracket values themselves are in no receipt (L9). A signature binds the reporting party to the per-object figure and its class. It does not show that an instrument produced them (L2).
• What it is not: a framework for the delivery chain. WAI measures nothing on the network, CDN, display or device idle, so it cannot answer the end-to-end question this use case asks.

Use case 2: Energy consumption exposure. Draft requirement: "open APIs allowing to report energy consumption of each component in the delivery chain."

• What WAI offers: a payload such an API could return, plus an in-band carrier for MoQ delivery. The per-object WAI_RECEIPT property (moq-streaming-format §5) carries joules_micro, acquisition and, at link 08, acquisition_evidence. None of these is signed (§7, L1). At link 10 an energy claim can carry a signed copy of an object's figure and class (jwp-receipts §2.4.5).
• What it is not: an API. SPEC.md §1 scopes WAI as a container and capability-dispatch standard, and nothing in the tree specifies a service.

Use case 3: Energy as a criterion for source or quality selection. Draft requirements: "indicate energy efficiency of a media instance in DVB-I" and "select a video representation in DASH according to its energy efficiency like it is already done according to its bitrate."

• Already answered, predictively, by MPEG. The 23001-11 4th-edition CD, clause 8 Energy-efficient media selection, defines decoder-power indication metadata per DASH representation: dec_ops_reduction_ratio_from_max (u(8)) and dec_ops_reduction_ratio_from_prev (s(16)), computed from the "estimated number of decoding operations". It also defines display-power indication metadata. Both are carried per 23001-19. A DVB input on this use case should reference that clause, not restate it.
• What WAI's text adds: the check on that prediction. energy-binding §7 specifies sealing op_requested, op_committed and op_delivered, and requires the residual between a declared complexity descriptor and the measured energy of the same reconstruction. A representation chosen because it predicted fewer operations could then be scored against what it cost. This exists only as text: no receipt or binding in wai-rs or wai-quantum has these fields (§7, L10).
• What it lacks: a binding to DASH or DVB-I. WAI's multi-rendition envelope (SPEC.md §7.1) could carry a measured figure per rendition, but no text says so.

Use case 4: Modernisation. This is not WAI's layer. The only link is that a per-work-unit measured figure is how an efficiency claim for a new technology gets evaluated. That is 3GPP's Key Issue #3 below.

---

3. Against 3GPP TR 26.942 (V20.0.0)

Read from the V20.0.0 text. The TR's conclusions (§8) and recommendations (§9) are what an input would respond to.

Key Issue #1: Energy-related information exposure. The TR recommends new stage 2 and stage 3 specifications for an Energy Information AF. Network energy is reported in joules in an energyInfo object (TS 29.122 clause 5.3.2.3.20), at SDF / PDU-session / UE granularity (§7.14.5.3, §9.2.2). WAI: nothing at the network layer. Its figure sits one level below, as a per-object figure beside a per-flow aggregate.

Key Issue #2: Monitoring and measurement. The TR concludes that "because the metrics differ from one UE OS to another, there will not be normative work on UE energy-related information collection and metrics" (§8.3). For server-side interfaces (IPMI/DCMI, Redfish) it notes that "no formal end-to-end certification exists for the accuracy of these power metrics across vendors". Such data can be used "for operational estimates, comparative data … but not for the purpose of customer billing or legally binding reporting to regulators" (§4.2.9).

• What WAI's text offers: a way to qualify a figure without normalising the metric. The acquisition class says what kind of source produced it, and in the tree at link 10 it separates an on-chip counter, which carries no traceable uncertainty — the TR's point about server power metrics — from a calibrated external instrument (energy-measurement §2.2). The declared uncertainty says how far the figure can be leaned on (§2.3 there); the quality ratio says whether the bracket was clean enough to publish; and a failed measurement is emitted as unmetered rather than as a low number (§4 there). At link 10 the reference meters seal a hardware class only when the bracket passes §4's bar and the uncertainty can be declared, and seal unmetered otherwise (energy-measurement §2.8; the meters' module documentation). No receipt carries the quality ratio itself, which the measuring tool prints (L9). On main only two receipt profiles sign the class.
• Honest limit: WAI's reference protocol is a lab bracket. It runs a saturating multi-threaded burst on an otherwise idle machine (§3 there), which is not an in-session measurement on a user's device. Qualifying a number is not the same as measuring the one KI #2 asks for.

Key Issue #3: Evaluation framework. The TR concludes that "no methodology has yet been identified allowing evaluation of the energy usage/savings of multimedia standards features and proposals". It makes "no specific recommendation at this time to initiate normative work" (§8.4). It frames the problem as characterising efficiency "in a repeatable and technology-agnostic way".

• What WAI offers: a candidate element for decode. The work unit is recomputable from the codestream. For WAI's integer capabilities the reconstruction is built to be byte-exact across architectures. That is checked only on well-formed streams, for the capabilities the CI goldens cover, on the CI legs that ran. On main, since about 2026-08-28, those legs are linux x86-64, linux arm64 and macOS arm64, where every job that finished passed; the windows leg has not run, because its runner host is offline (syfai-input §2, G8; read 2026-09-27). Within those bounds, a third party can recompute what describes the output and the work: the reconstruction, its hash and the work unit. The joules rest on the reporter, and so does every field that says how they were measured: the acquisition class and its evidence, the idle and busy figures, sample counts, window, quality ratio and build profile (L8). A comparison between codec proposals is therefore repeatable in its outputs and work, and only as good as each reporter's bracket in its energy. Whether the figure and its class are inside a signature depends on the profile, and a signature shows who reported them, not that an instrument produced them (§7, L1, L2).
• Honest limit: this holds only for WAI's byte-exact capabilities. It covers neither the network nor any float decoder.

Solution #13: In-band signalling of energy to the player. Energy reaches the Media Player through CMSD custom keys in HTTP response headers, and the TR notes it "could alternatively be achieved by embedding this information directly within the streaming presentation manifest" (§7.14.2). §9.2.3 says Solution #13's requirements "could be shared with the broader industry as formal requirements and serve as an invitation for collaboration", with metrics and in-band mechanisms from other organisations "for further study".

• What WAI offers: WAI's per-object MSF property is an in-band mechanism for a different transport (MoQ). This is the most direct point of contact in the TR, with a limit that has to be stated. The object's content_hash is committed under the group's signed Merkle root, and the property's group_receipt identifies that signed group. Its joules_micro, acquisition and acquisition_evidence fields are not signed: the group signature covers only the group's joule total (§7, L1). So the property is an in-band carrier for a per-object figure, not a signed one. In the tree at link 10 a player can check an object's figure and class only through an energy claim for that object (jwp-receipts §2.4.5), which the property neither carries nor references. An input could offer the property as a way for a player to check the figure only once it is signed or bound to such a claim.
• Where the contact ends: CMSD headers and 5GMS are not WAI's layer, and WAI would not bind them.

What the TR does not address. A term search of the V20.0.0 text finds no occurrence of signature, attest, integrity or tamper. The TR specifies who reports energy, at what granularity and over which reference points. It does not specify how a recipient checks a reported figure. That question is open, and WAI's energy-binding §3 answers part of it: which output a figure describes, not whether the figure is accurate. That answer needs the figure inside a signature, and energy-measurement §2 needs the class there too. In the tree at link 10 that holds for every wai-rs and wai-quantum receipt that carries its class and for an energy claim; it does not hold for a JWP group total or the MoQ property (§7, L1). On main only the C2PA energy binding and the video receipt meet both.

---

4. ISO/IEC 23001-11 4th edition: complementary, and the falsifier check

Landscape falsifier #1 is not triggered by the CD text. The CD (WG 3 N1864) was searched for measured or signed energy. The terms signature, hash, attest, certif, joule, watt, measured and measurement do not occur. The metadata remains predictive: complexity metrics, estimated decoding-operation ratios, attenuation maps and quality levels. Recheck at DIS.

Degradation is an explicit option in the standard. The CD introduction says the metadata works "without any degradation in the quality of experience", and also that "it is also possible to use this metadata to get larger energy savings, but at the expense of some QoE degradation". WAI's rules cover both routes by which that happens (determinism-tiers §2, What a tier covers, at link 02, PR #103). A sink that alters the decoded medium, as attenuation maps and display adaptation do, may not claim a tier for what it emits. A tier claim, decoded-medium hash or energy figure over a payload that an encoder altered to save energy, at a receiver's request or on its own account, covers that payload and not the one it stands in for.

A vocabulary note for reconciliation. 23001-11 itself defines a request/response pair for point-to-point sessions, decoding operation reduction request (DOR-Req) and response (DOR-Resp). In the tree at link 10, energy-binding §7.1–§7.2 (link 02) cite that pair as the 23001-11 case of the request/commitment pattern: the receiving device requests, and the remote encoder answers with how it decided to answer. Landscape §5.3 still attributes WAI's request/commit pattern to the RTCP TSRR/TSRN messages; DOR-Req/DOR-Resp is the earlier and closer precedent. op_delivered and the measured residual are what WAI's text adds. No receipt or binding carries any of the three fields yet (L10).

One editorial observation on the CD text, to raise only through a national body. The foreword says the 4th edition "cancels and replaces the third edition (ISO/IEC 23001-10:2025)", which appears to misstate the part number and year.

---

5. IETF GREEN

This is covered in landscape §3.5 and energy-measurement §2.1 and is not repeated here. Since the landscape was written:

• the YANG module has moved to -04 (2026-09-09);
• a power-state capability-discovery draft has appeared (draft-claise-green-capability-discovery-02, 2026-09-23).

The scope remains device and sub-component energy. It is the cheapest venue for the acquisition-identity derivation the landscape queues as item 8, because the IETF requires no membership. In the tree at link 10, energy-measurement §2.1 (link 08) fixes the rules such a derivation would follow (§8).

---

6. EU data-centre rating scheme, C(2026) 3472

Commission Delegated Regulation C(2026) 3472 final, dated 21 Sep 2026, amends Delegated Regulation (EU) 2024/1364. Read from the Commission text:

• An electronic label is generated by the European database "by 15 August 2027 and every year thereafter". Data centres below 500 kW installed IT power "may voluntarily participate".
• The amendments "simplify it by removing some indicators (such as the data traffic indicators)".
• Article 6 requires a review "by 31 December 2028 and every three years thereafter". The review includes the possibility to "(d) introduce indicators to measure the performance of the ICT equipment energy use" and "(e) introduce (partial) certification or auditing of the reported data".

Bearing: data-centre scope, not per object. The review asks, at facility scale, the question WAI's acquisition class asks at object scale: how can a reported figure be relied on? The recitals and articles read here (part 1) contain no per-stream, per-view or per-decode energy requirement. The annexes were not read for this note. The companion record read them (2026-09-global-sweep §5.2): Annex III adds a point (f), Certification of the reported data, to Annex I of Regulation 2024/1364, with self-certification and third-party certification kept distinct, and that record finds no per-stream, per-view or per-decode requirement in the act. ⚠ Whether the act has completed scrutiny and been published in the Official Journal was not checked. It enters into force twenty days after publication.

---

7. Where WAI fits, and what it still lacks

The fit, stated once. Session and network aggregates answer how much did this service, session or flow use? That is 3GPP's EIF and AF and DVB's framework. Predictive metadata answers how much should this cost? That is 23001-11. WAI's binding answers a third question: what did producing or decoding this object cost, measured how, over which reproducible bytes? The three are complementary. WAI's figure describes an output and a work unit that a third party can recompute. The joules, and how they were measured, rest on the reporter (L8).

What WAI lacks. Each item was checked against the extension text and the reference code in the tree at link 10; the state on main is given where it differs.

L1: Which receipt profiles meet energy-measurement §2. §2 requires a receipt it governs that carries a non-zero figure to carry an acquisition class, inside the signature, with the class's evidence, and a verifier to treat a receipt that breaks either coupling as invalid.

On main the profiles fall into three groups. They were sorted by reading every signing_payload in wai-rs/src and wai-quantum/src, and by searching both trees for a class field:

• Figure and class both signed: the video receipt (wai-rs/src/video_receipt.rs) and the C2PA energy binding.
• Figure signed, no class anywhere: in wai-rs, the linear-film, ternary-tt, provenance, spatial-audio, volumetric, interactive-worlds (reused by avatars and state-feeds), haptics and score receipts; in wai-quantum, the quantum-sim receipt, the quantum-ops receipts, the phasor-meter receipt and the QBOM manifest.
• Per-object figure not signed: the generic JWP receipt and the in-band WAI_RECEIPT MSF property.

In the tree at link 10 (link 08, PR #109; link 10, PR #112):

• Class always present and signed: the energy binding and its C2PA companion assertion, the wai.video.int_motion receipt, the wai.video.* OTT receipts of link 01, and an energy claim (jwp-receipts §2.4.5). For the two hardware classes, the declared uncertainty and the filtering state or calibration reference are signed with the class.
• Class as an optional signed label (energy-measurement §2.8): the world-session, film and reel, haptic, score, 4D-splat, audio-scene, ternary and provenance-step receipts in wai-rs, and every wai-quantum receipt (circuit, calibration, job, mitigation, decode, compile, rearrange, phasor, and the bill of materials per entry). A label changes the signing domain's version byte, so it can be neither added to nor stripped from a signed receipt. Without one, a receipt keeps its legacy bytes and its figure is unlabelled: accepted, and not read as any class. Labelling a new figure is a SHOULD that no verifier can check. The reference meters label every non-zero figure they seal; world_model::frame_receipt and the wai-web demos seal unlabelled figures, and no constructor in these families requires the class (§2.8 there).
• Per-object figure not signed: the generic JWP group receipt's signing payload covers total_joules_micro, the group sum (jwp-receipts §2.3), and the Merkle leaf is BLAKE3(domain ‖ content_hash) (§2.2), so an object receipt's joules_micro and origin sit outside the signature, and the object receipt has no member for the class. An energy claim restates the object's figure beside its class under the claim's own signature, and a verifier holding both rejects the pair if the figures differ. Nothing carries a class for a group total. The WAI_RECEIPT property carries content_hash, joules_micro, acquisition, acquisition_evidence and group_receipt (a BLAKE3 of the group receipt), and has no signature of its own (moq-streaming-format §5).

energy-measurement §1 records the JWP group and object receipts and the WAI_RECEIPT property as falling short of §2, and places OER/2 receipts outside its scope: an OER receipt's members are fixed and include no class (oer-receipts §2–§3). energy-measurement §2 says the reference implementation enforces its rules in verify(); at link 10 that holds for the always-present profiles and for any label that is present, and §2.8 says the optional-label families do not hold producers to labelling.

So "signed energy with its acquisition class" may be said, at link 10, of the always-present profiles, of an energy claim, and of a labelled receipt in an optional-label family. It may not be said of an unlabelled receipt, of a JWP group total, or of the MoQ property. On main it may be said only of the video receipt and the C2PA energy binding. What remains is a signed place for a group total's class, a member of the object receipt's own (or joules_micro and the class bound into the leaf), and a signature over the property.

L2: Calibrated instruments, on-chip counters, and who signs. On main, HwShunt covers "RAPL, NVML, SMC, IOReport, or an external shunt" (energy-measurement §2). On-die counters carry no accuracy certification; the TR 26.942 passage in §3 says the same of server power metrics. A reading from a calibrated instrument is a different claim. In the tree at link 10 (link 08), energy-measurement §2 makes them two classes: CalibratedInstrument, which requires a calibration reference that resolves to a certificate (§2.5), and OnChipCounter, which also covers any external meter whose uncertainty is not traceable to a current calibration (§2.2). HwShunt is legacy (§2.6). §2.1 forbids using a declared uncertainty to select a GREEN accuracy band, and declaring a band as an uncertainty.

A precedent for signing such readings is OCMF (Open Charge Metering Format), a data format for charging-station meter readings "that are relevant under calibration law". In OCMF the signature is made by "the signature-generating component, which is referred here as the gateway", and which the spec says could also be called the "measuring capsule" or "the signing component". That component may be attributable to the energy meter or be a separate gateway. The spec identifies it separately from the meter, and meter identification "is optional if the signature generating component has already been identified". So the signing key sits in a component of the metering installation, which need not be the meter itself. The spec does not say where the private key is stored. ⚠ How that component is type-approved or certified under calibration law is not in the spec and was not verified. energy-measurement §2.2 at link 10 says OCMF values are accepted because they come from "a conformity-assessed, legally verified measuring system — the meter together with the component that signs its values", and that legal verification is not the same statement as a calibration certificate's uncertainty. That agrees with the OCMF text read here on where the signature sits.

WAI's signing key is the publisher's, and a publisher's signature says who reported a number, not that an instrument produced it. The class now separates the two kinds of evidence, and the calibration reference makes the calibration claim checkable, not true (§2.5 there). Still open: a rule on which key signs — the publisher's, or one held by the metering component — and a mapping onto GREEN's accuracy identities.

Status after the v0.4.0 change "Key discovery, signing authority and module revocation": jwp-receipts §7.5 recommends (SHOULD) that a hardware-class figure be signed by a key held by the component that signs the reading and distinct from the delivery key, has a verifier report whether the key also holds delivery, and confirms a hardware-class energy authority only under a pinned anchor. The mapping onto GREEN's accuracy identities is still open.

L3: Declared tolerances. energy-measurement §2.1 requires an implementation to state how far its class lets the figure be leaned on. On main no tolerance figure appears in the extensions or in energy_binding.rs / video_receipt.rs. In the tree at link 10 (link 08), CalibratedInstrument and OnChipCounter must carry a declared standard uncertainty with its integration window (§2.3), and every verifier refuses one that is missing, zero, or smaller than the rounding of the whole-microjoule figure. ModelBased and Estimator still carry none, and §2.1 says so.

L4: No publishable absolute figure in WAI's own text. The worked example in energy-measurement §7 is a deliberately failing bracket at a ratio of 3.8, below the publication bar of 10, because a clean bracket was not reproducible on the authoring machine. Its receipt says HwShunt; §7 there says the reference meter now seals OnChipCounter for the same interface, and that the run's missing values cannot be reconstructed. An input that cites WAI's method has no example figure it may quote as absolute.

L5: Scope. The figure covers one component on one machine, in a lab bracket. The network, CDN, display, device idle and in-session measurement are all outside it (see §2 and §3).

L6: No API and no DASH, DVB-I or 5GMS binding. The only in-band carriage is the MoQ property.

L7: No key discovery (landscape §3.6). Every signature presumes the verifier already holds the key, and that includes the signer of an energy claim. The normative text says so too: transparency §6 says it does "not solve key discovery". It points to "jwp-receipts §7" for it, but jwp-receipts has no §7; its sections end at §6.8. OCMF leaves this out of band too: public keys reach the verifier "by means other than this protocol (out-of-band) … e.g. via a central register". WAI names no register or other mechanism.

Status after the v0.4.0 change "Key discovery, signing authority and module revocation": jwp-receipts §7 now exists, and transparency §6 points to it. A signer names its web origin in signer_id; the origin publishes a signed, chained key log at /.well-known/wai-keys; a verifier anchors the origin by pinning or by one recorded fetch and confirms offline. The anchor reaches the verifier out of band or on first use, and the hardware-class energy authorities are confirmed only under a pinned one.

L8: Not re-measurable, by construction. A third party reproduces the output and the work unit, never the joules (energy-measurement §5). The same holds for every field that describes the measurement: the acquisition class and its evidence, the idle and busy figures, sample counts, window, quality ratio and build profile. This is a stated limit, not a defect, and any input must repeat it in that form. energy-measurement §5 ("every field except the energy is independently checkable") and energy-binding §3 ("exactly one unverifiable term") read as if the joules were the only such term. That is true only if the measurement fields are counted as part of the joule figure. An input should use the wider wording, and those two sections should be reworded to match.

Status after the v0.4.0 change "Energy reports, labelled object leaves, and what the signatures cover": energy-measurement §5 and energy-binding §3 now use the wider wording: what stays unverifiable is the measurement — the joules and every field that describes how they were obtained — and a report's values can be checked for consistency with the figure, which is not truth. The code docs that called joules_micro the only attested field say the same.

L9: The reporting contract has no receipt fields. energy-measurement §6 requires a published figure to be accompanied by the idle mean and SD, busy mean and SD, sample counts, window, completion count, thread count, how the window opened, quality ratio and build profile. No receipt profile in wai-rs or wai-quantum has fields for them. At link 10 a hardware class's declared uncertainty and window are sealed, but not the values they were computed from. The energy binding carries a method that names the protocol, not the values, and an energy claim's method is a URI naming the protocol. The reference meters print the idle and busy figures, the marginal-to-idle ratio and the resolution term to their console. So the record DVB use case 1 would need (§2) is a requirement in the text, not yet a format any receipt carries.

Status after the v0.4.0 change "Energy reports, labelled object leaves, and what the signatures cover": closed for figures sealed with a class. A measurement claim (jwp-receipts §2.4.8) carries the bracket's values as integers, each bracket's liveness facts, the build (profile, toolchain, target) and the power reader, names the receipt that seals the figure by a figure profile (energy-measurement §6.1), and is signed by the figure's own key. Verifiers check that the figure and the declared uncertainty are what the integers give (energy-measurement §6.2); the reference meters write one by default. Figures sealed with no class, world_model::frame_receipt and the wai-web demos are recorded as falling short (energy-measurement §6), and the energy binding's report carriage is not specified.

L10: The operating-point fields exist only as text. energy-binding §7.2 and §7.3 specify op_requested, op_committed, op_delivered and the residual between a declared complexity descriptor and the measured energy. No receipt or binding in wai-rs or wai-quantum has these fields (grep). energy_binding.rs carries the reconstruction hash, the microjoules, the acquisition class and its evidence, coverage, work units and method. §2 use case 3 and §4 describe what the text adds, not what a receipt carries today.

Status after the v0.4.0 change "Energy reports, labelled object leaves, and what the signatures cover": an operating-point claim (jwp-receipts §2.4.9) carries op_requested, op_committed, op_delivered and a prediction for one figure, from a vocabulary named by URI. Whether the commitment was met and the residual are derived by every reader, never stated. No operating point is recorded against an unmetered or legacy HwShunt figure (energy-binding §7.2).

Unverified near-prior-art. Search snippets seen during this work pointed to public repositories describing signed receipts for AI inference with NVML-measured joules. Their bodies were not read, so they are neither named nor cited here. As the snippets described them, their scope is inference, not media. Read such material before writing any statement about what is new in signed energy receipts.

---

8. Candidate input text, per venue

Each item needs the membership named at the top, except the IETF item.

• DVB CM-EE (commercial requirements). A requirement derived from S100 §7.1.3 and §7.2.3: "It shall be possible to bind a reported energy figure to the media object or work unit it describes, to state how the figure was acquired, and to identify the party that reported it." This is the property a framework "used by all industry players" needs when figures come from third parties.
• 3GPP SA4 (TR 26.942 further study / Solution #13 follow-up). For KI #3, decode-energy evaluation against a work unit recomputable from the codestream. For the in-band path, the missing question of how a Media Player checks a figure it receives.
• ISO/IEC 23001-11 CD ballot. No technical comment is required on the predictive semantics, which WAI's measured binding accompanies. The editorial point in §4 could be raised through a national body.
• IETF GREEN (open participation). Derive WAI's acquisition class from data-source-accuracy, in one direction only, as energy-measurement §2.1 at link 10 sets it out: a derivation never improves the class, a measured identity yields OnChipCounter unless a calibration reference is held, and a graded band is never declared as a figure's uncertainty, nor selected by one. The per-figure uncertainty is stated separately (L2, L3). This is landscape queue item 8.

The open parts of L1 should be fixed, and any input should state L8 in its wider form, before any of these goes out.

---

9. What this document does not claim

• It does not claim that WAI measures delivery-chain, network or device energy. It measures an object's production or decode on one machine.
• It does not claim that a signature attests a figure's accuracy (energy-binding §3), or that an acquisition class is an instrument's attestation (energy-measurement §2.5).
• It does not claim that every WAI receipt profile meets energy-measurement §2. In the tree at link 10 the always-present profiles, an energy claim and a labelled receipt do; an unlabelled receipt, a JWP group total and the MoQ WAI_RECEIPT property do not (L1). On main only the video receipt and the C2PA energy binding do.
• It does not present anything attributed to a link of the landing chain as being in main. None of the chain is merged as of 2026-09-30.
• It does not claim that a third party can check anything beyond the output and the work unit. The joules, and every field describing how they were measured, rest on the reporter (L8).
• It does not claim that any receipt carries the quality ratio or the other bracket values (L9), or the operating-point fields of energy-binding §7 (L10). Both are requirements in the text only.
• It does not claim membership of DVB, 3GPP or SC 29, or that any input will be made.
• It does not describe any WAI mechanism as adopted or endorsed by any body named here.

---

Sources

Read on 2026-09-27 unless noted.

1. DVB BlueBook S100, Study Mission report on Energy Aware service Delivery and Consumption, Nov 2023. Read in full (§7 use cases, §8–9). https://dvb.org/wp-content/uploads/2023/11/S100_Study-Mission-on-Energy-Aware-Delivery-and-Consumption_Nov-2023.pdf
2. DVB, TV 2030: preparing for a future that's already in sight, 10 Sep 2025 (the energy-efficiency working group's status). https://dvb.org/news/tv-2030-preparing-for-a-future-thats-already-in-sight/
3. 3GPP TR 26.942 V20.0.0 (2026-06). Read from the archive: https://www.3gpp.org/ftp/Specs/archive/26_series/26.942/26942-k00.zip. Specification record: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=4305
4. 5G-MAG / 3GPP SA4 / Greening of Streaming workshop, 19 Mar 2026 (WI 1080050; workshop statements). https://www.5g-mag.com/workshops/media-energy-consumption/
5. ISO/IEC CD 23001-11 4th edition, WG 3 N1864 (w26533), cover dated 2026-08-28. Clean text read from https://www.mpeg.org/wp-content/uploads/mpeg_meetings/155_Geneva/w26533.zip. Part page: https://www.mpeg.org/standards/MPEG-B/11/
6. ISO/IEC 23001-19 part page. https://www.mpeg.org/standards/MPEG-B/19/
7. IETF datatracker: GREEN WG documents, https://datatracker.ietf.org/wg/green/documents/. Also draft-ietf-avtcore-rtcp-green-metadata, https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtcp-green-metadata/
8. European Commission, C(2026) 3472 final, 21 Sep 2026, part 1 (recitals and articles; the annexes were not read for this note). https://energy.ec.europa.eu/document/download/b073ba9b-82a8-45cb-b8ba-78dad149e941_en?filename=C_2026_3472_1_EN_ACT_part1_v9.pdf
9. OCMF, Open Charge Metering Format, OCMF-en.md at repository commit f6de139 (2025-12-04). Read: Goal, Transmission of Signed meter Readings, Signing and Verification Process, General Information (the signature-generating component), Meter Identification, and Relation of Serial Numbers, Charge Point and Public Key. The spec does not describe how the signing component is certified under calibration law, and that was not checked elsewhere. https://github.com/SAFE-eV/OCMF-Open-Charge-Metering-Format/blob/master/OCMF-en.md
10. In this tree, at link 10 of the landing chain (2026-09-30), and on main where a statement says so: extensions/energy-measurement.md §1–§8, energy-binding.md (§3, §4, §7), jwp-receipts.md §2.1–§3.1, moq-streaming-format.md §1 and §5, determinism-tiers.md §2, oer-receipts.md §2–§3, transparency.md §6, and the receipt sections of linear-film.md, ternary-tt.md, provenance.md, spatial-audio.md, volumetric.md, interactive-worlds.md, avatars.md, state-feeds.md, haptics.md, score.md, quantum-sim.md and quantum-ops.md. In code: wai-rs/src/energy_class.rs, energy_burst.rs, video_receipt.rs, energy_binding.rs, c2pa_emit.rs, claim_receipt.rs, the reference meters under wai-rs/src/bin/, and every signing_payload in wai-rs/src (film/, ternary_receipt.rs, provenance.rs, audio_scene/, splat4d/, world/, haptic/, score/, the wai_video_* modules) and wai-quantum/src (quantum_receipt.rs, quantum_ops.rs, quantum_phasor_meter.rs, quantum_qbom.rs, quantum_energy.rs). Also a search of both code trees for the energy-binding §7 fields (L10). The main groups of L1 were sorted at commit 1b3e390, and main's wai-rs and wai-quantum receipt code is unchanged since.
11. 2026-09-global-sweep, for the CM-EE announcement (§2.4), the ISO/IEC 23001-19 stage (§2.1) and the annexes of C(2026) 3472 (§5.2).

2026-10 addendum: delivery telemetry

CMSD headers and 5GMS remain outside WAI's receipt layer. Since this note was written, delivery-telemetry maps an unsigned, advisory observation about WAI delivery onto CMCD version 2 and CMSD keys. It carries content hashes and receipt link hashes as pointers, never a joule figure, an acquisition class or a quality figure, and it binds no receipt to CMCD or CMSD. The text above is unchanged.