2d3a18f368
extensions/delivery-telemetry.md: the observation, its CMCD version 2 mapping and header shards, custom keys carrying Strings, switch reasons, CMSD, session metrics, privacy and conformance. Cohort assignment and capable share stay out of this revision. moq-streaming-format §5 states that telemetry never restates the per-object property's figure; energy-exposure-mapping gains a dated addendum, its text otherwise unchanged. Co-Authored-By: Claude Opus 5.5 <[email protected]>
659 lines
42 KiB
Markdown
659 lines
42 KiB
Markdown
# 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](2030-transport-landscape.md)
|
||
> §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](../extensions/energy-measurement.md),
|
||
> [energy-binding](../extensions/energy-binding.md),
|
||
> [jwp-receipts](../extensions/jwp-receipts.md) and
|
||
> [moq-streaming-format](../extensions/moq-streaming-format.md) §5. The companion
|
||
> record [2026-09-global-sweep](2026-09-global-sweep.md) 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](2026-09-global-sweep.md) §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](2026-09-global-sweep.md) §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](syfai-input.md) §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](2026-09-global-sweep.md) §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](2026-09-global-sweep.md), 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](../extensions/delivery-telemetry.md) 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.
|