72e3300752
jwp-receipts §7: a did:web signer_id names a web origin, which publishes a key log at /.well-known/wai-keys: revisions signed by a root key that pre-commits to its successor, listing the origin's keys, the authorities each holds, and whether each is active, retired or revoked. A verifier that has anchored the origin, pinned or fetched, confirms an accepted receipt, claim or module grant against the log offline, and reports the outcome beside the item's own verdict, never in it. Hardware-class energy, lawful-basis and pre-emption authorities are confirmed only under a pinned anchor. Revocation refuses every item under a revoked key. §7.9 authorises decoder and reconstruct modules, and pinned parameter sets, by SHA-256 digest through signed module grants from the sink's module origins, revokes them by digest in the key log, and bounds how long a revoked module keeps running by grant_max_s + status_max_age_s, under ceilings of 86400 s and 3600 s. Every failure, offline included, leaves the module not held and dispatch falls back. wai-rs gains signer_id (ungated) and key_log (feature key_discovery), the wai_signer_vectors and wai-keys binaries, and the signer-conformance corpus with an independent Python verifier. The reference meters and the world demo sign under labels. A section-reference guard checks that every section SPEC.md or an extension cites in another of them exists. This commit is the stream as merged onto link 14. The commits after it reconcile it with the parameter-set pin and the energy reports. Co-Authored-By: Claude Opus 5.5 <[email protected]>
112 KiB
2026-09 global sweep — record of a multi-language landscape scan
Provenance note. This is a record, not a normative extension and not a conformance statement. It captures what a multi-language sweep of media standards, deployments, energy measurement and regulation found on 2026-09-26, what the WAI tree holds and in what form, and which gaps the findings expose. Nothing in it has been implemented by writing it down.
It is a companion to
2030-transport-landscape.md(cited below as the 2030 landscape), which remains the analysis and the ranked ingest queue. This record does not restate that document. Where an item is already there it is cited by section, and §8 lists the places where this sweep updates or corrects it. Two notes committed with this record take up standards inputs it found untracked:syfai-input.mdandenergy-exposure-mapping.md.How much to trust each line. The sweep gathered the external claims on 2026-09-26. Every P row but one was then read again against its source on 2026-09-27; §1.1 says how. The record was re-checked against its sources and against the tree before publication. Every row carries a grade:
grade meaning P✓ the cited issuing-body page, datatracker entry or paper was read or re-read on 2026-09-27, or on the later date the row gives, and contains the fact as stated P an issuing-body source is recorded by link or identifier but was not re-read after the sweep tree the fact comes from another document in this tree, cited by section, and carries that document's own sourcing R ⚠ reported by the sweep from its gathered sources, but no link was kept. Re-verify before quoting outward S ⚠ secondary source only (blog, trade press, vendor material, a co-organiser's page) N ⚠ seen only in search-result snippets, body not read C ⚠ sources conflict Anything graded R, S, N or C is unverified.
Which tree. The repo-side claims (§5.3, §6, §7) describe two states.
mainis the published tree. Every file underwai/that those sections cite by line is unchanged onmainsinceafc7ece(2026-09-27), so a line number given formainholds at that commit. The WAI work that answers most of the gaps below lands as a linear chain of pull requests on the forge. Each targetsmain, and they merge in order. As of 2026-09-30 none is merged intomain.
link branch PR 01 feat/wai-video-workflow#82 02 wai/land-02-determinism-tiers#103 03 wai/land-03-jpegai-no-libm#104 04 wai/land-04-codec-registry#105 05 wai/land-05-prior-nnc#106 06 wai/land-06-ci-headline-tests#107 07 wai/land-07-int-decode-kernels#108 08 wai/land-08-energy-classes#109 09 wai/land-09-int-mlicpp#111 10 wai/land-10-receipt-classes#112 Each link contains the links before it, so the tree at link 10 holds all ten. What a row says a link does was read from the files of that tree. Everything attributed to a link is proposed in that link's pull request and is not in
main. The forge's CI runs for the chain's pull requests were read on 2026-09-30. The workflows the chain adds or changes have run on the forge's runners since 2026-09-28;wai-sota-vectors.yml,wai-jpegai-e2e.ymlandwai-neural-gates.ymlhave passed on every run.wai-neural-e2e.ymlfails on every link and passes on the head of PR #101, the MLIC++ fixture fix, which is independent of the chain. Link 11, which carries this record, also corrects determinism-tiers §5–§6 and energy-measurement §2.4 where this record found them out of date.Naming. Standards bodies, public institutions, research institutes, papers and standards are named where a source names them. Companies are not named in this record's prose. Where a row rests on a company's own page that was read, the page's URL or document identifier is given as the citation, because the row cannot be checked without it. A company whose material was not read is neither named nor cited. Interface and platform names (RAPL, NVML, IOReport, [name removed 2026-09-30], ONNX Runtime) are used as identifiers, the way the tree's own texts use them, and so are file paths in the tree. Quotations from the tree and from sources are verbatim, except that a company name inside one is elided with "…".
Posture throughout: record facts about the field; say what they mean for WAI's own text. Nothing here is framed as a contest with any other effort.
1. Method and coverage limits
Scans. Seven scans ran on 2026-09-26. Three were organised by language and four by topic:
- Chinese-language sources.
- Japanese and Korean sources.
- European languages and Brazil.
- Standards bodies and the state of the art in neural codecs.
- Media energy measurement.
- Rest of world and industry deployment.
- Regulation.
The search budget ran out. The shared web-search budget was exhausted partway through the scans. Reports were written from sources already gathered, so coverage is uneven. "None found" in this record means none found in what was searched. It does not mean none exists. The areas the sweep did not reach:
- energy figures for codecs (joules per decode, per encode, per stream);
- 2026 hardware media engines and NPU decode support, including for AV2 and learned codecs;
- the current C2PA specification version and how manifests behave across re-encode;
- the literature on deterministic neural decoding, beyond the papers the sweep read;
- ISO catalogue stage codes (iso.org returned HTTP 403 to automated fetch, as it did for the 2030 landscape);
- Nordic and Dutch sources;
- Korean ATSC 3.0 developments in 2025–26;
- which institutions are behind the Chinese integer learned-codec work.
Verification. No adversarial verification pass ran during the sweep. The 2030 landscape used two lenses; this record grades by source quality instead. The repo-side claims were checked against the tree by reading the named files and by the greps each row states.
1.1 How the sources were read
- Fetched as raw text and searched: the IETF drafts (ietf.org archive), their revisions, states and dates (datatracker API), RFC 9943 (rfc-editor.org), the arXiv abstracts (arXiv API), and DVB BlueBook S100 (PDF converted to text).
- Read through a web-fetch tool that returns a model's extraction of the page, with verbatim quotes requested: the mpeg.org pages (meetings; the 153rd, 154th and 155th meeting pages; Exploration 52; MPEG-B Part 11), the JPEG 111th-meeting press release, the AOMedia AV2 landing page and press release, two dvb.org news items, the 5G-MAG workshop page, the UWA project page, and one CDN operator's MoQ documentation. Each was read once. The quoted phrases below are what the tool returned, not a verbatim archive.
The pages read later on 2026-09-27 (Exploration 45, the MPEG-B Part 19 and MPEG-AI Part 5 pages, and EU C(2026) 3472 with its annexes) say so in their rows. The one P row not re-read on 2026-09-27 is the FAMIUM citation (§3.3).
2. Standards status
Stages as observed on the dates given. Stages move, so treat every row as a dated observation.
2.1 ISO/IEC JTC 1/SC 29 (MPEG) and ITU-T/JVET
| item | stage | date | source | grade |
|---|---|---|---|---|
| MPEG 155, Geneva | held | 13–17 Jul 2026 | https://www.mpeg.org/meetings/ | P✓ |
| MPEG 156, Hangzhou | scheduled | 19–23 Oct 2026 | same | P✓ |
| MPEG 157, Brisbane | scheduled | 18–22 Jan 2027 | same | P✓ |
| MPEG 158, Geneva | scheduled | 19–23 Apr 2027 | same | P✓ |
| SyfAI — Exploration 52, Systems technology for AI-based media standards, an MPEG Systems exploration (MPEG Systems is SC 29/WG 3, as 2030 §6.5 records) | exploration. The page lists documents at MPEG 151 (MPEG Systems support for Coding for Machine technologies), MPEG 153 (Systems technologies for coding for machine standards, dated 2026-02-12), MPEG 154 (first under the SyfAI title, dated 2026-07-14) and MPEG 155 (SyfAI title, listed without a date) | MPEG 151 onward | https://www.mpeg.org/standards/Explorations/52/ | P✓ |
| — when "SyfAI" began | the secondary report says SyfAI "started at the 153rd MPEG meeting"; the part page shows the SyfAI title first at MPEG 154, on a line of documents going back to MPEG 151 | — | the part page, and https://multimediacommunication.blogspot.com/2026/07/mpeg-news-report-from-155th-meeting.html | C ⚠ |
| — its AI update-framework thread, opened jointly with WG 7. Five topics: a format for AI parameter data, a manifest for updating parameters, a repository to serve them, integrity checking, and "bit exactness together with conformance" | opened | MPEG 155 | the secondary report above. The MPEG 155 Exploration 52 document and any joint WG 3 / WG 7 output were not read | S ⚠ |
| ISO/IEC 23001-11 Green Metadata, 4th edition | WD dated 2026-03-02 (MPEG 153); CD text listed under MPEG 155 with the date 2026-09-21. The text is WG 3 N1864, and its cover is dated 2026-08-28 (energy-exposure-mapping.md §1) |
— | https://www.mpeg.org/standards/MPEG-B/11/ | P✓ / tree (document number, cover date) |
| — earlier editions | 3rd ed. 2023; Amd 1:2024 (EVC); Amd 2:2025 (display power reduction). The part page shows no publication years | — | 2030 landscape §5.1 | tree |
| — its content | the part page describes it as metadata "enabling a decoder to consume less energy while providing a usable video". Tool list (decoder complexity metrics, operation-reduction metadata, quality metrics, display power reduction) from 2030 §5.1. The CD text was not read for this record. energy-exposure-mapping.md §4 searched it for signature, hash, attest, certif, joule, watt, measured and measurement, found none, and describes its metadata as predictive |
— | part page; 2030 §5.1; energy-exposure-mapping §4 | P✓ (description) / tree (tools; no measured or signed energy in the CD) |
| ISO/IEC 23001-19 Carriage of Green Metadata | advanced to publication (IS) at MPEG 153 by WG 3. The part page is consistent with this: edition status "ongoing", newest document at MPEG 152 (2025-10-24), titled Potential improvement of ISO/IEC DIS 23001-19 — the DIS stage before the MPEG 153 promotion | MPEG 153 | https://www.mpeg.org/153rd-meeting-of-mpeg/ ; https://www.mpeg.org/standards/MPEG-B/19/ (both read 2026-09-27) | P✓ |
| MPEG-2 Systems 10th ed. WD: adds MPEG-Green data transport | WD | MPEG 155 | — | R ⚠ |
| ISO/IEC 23888-2 VCM | promoted to DIS at MPEG 153; FDIS expected late 2026 | — | https://www.mpeg.org/153rd-meeting-of-mpeg/ | P✓ |
| ISO/IEC 23888-4 FCM | CD issued at MPEG 154 | — | https://www.mpeg.org/154th-meeting-of-mpeg/ | P✓ |
| ISO/IEC 23888-5 (MPEG-AI Part 5), AI-based point cloud coding | edition 1, status "ongoing". The part page lists one document, CTC on AI-based point cloud coding, at MPEG 155, dated 2026-09-06. The sweep's "common test conditions finalised" is not established by the page, and the item is not on the MPEG 153, 154 or 155 meeting pages | MPEG 155 | https://www.mpeg.org/standards/MPEG-AI/5/ (read 2026-09-27) | P✓ (CTC listed) / R ⚠ ("finalised") |
| Call for Proposals on media authenticity and provenance indication with MPEG Systems technologies | CfP issued at MPEG 155. Proposals due 13 Jan 2027, evaluated at MPEG 157 | — | https://www.mpeg.org/155th-meeting-of-mpeg/ | P✓ |
| — its part number, ISO/IEC 23888-6 (MPEG-AI Part 6), and later stages | the meeting page names the CfP but not the part number. CD at MPEG 158; FDIS early 2028 | — | mpeg-ai-part6-mapping.md; 2030 §6.5 |
tree |
| Beyond-VVC Joint Call for Proposals (JVET, SC 29/WG 5 with ITU-T) | issued at JVET's 43rd meeting. Registration by early September 2026; main package due end of October 2026, a supplemental package mid-December; evaluation at the JVET meeting in Brisbane, January 2027; first test model in the second half of 2027; first version targeted end of 2029. Welcomes technology based on neural networks and AI alongside conventional tools | — | https://www.mpeg.org/155th-meeting-of-mpeg/ | P✓ |
| Gaussian splat coding — Exploration 45 | exploration. The page lists documents from MPEG 150 (draft use cases and requirements, 2025-04-26) through MPEG 152 and 154 (common test conditions) to MPEG 155 (use cases, 2026-07-18; a call for content, 2026-07-31). It names no working group | MPEG 150 onward | https://www.mpeg.org/standards/Explorations/45/ (read 2026-09-27) | P✓ |
| — its tracks and timeline | intra (I-3DGS) and inter (A-3DGS) tracks (2026-09-30: WG 4 N 837 and WG 2 N 531 define I-3DGS and A-3DGS as representations — I-3DGS "point clouds represented in the “INRIA” format", A-3DGS "alternative Gaussian splat representations" — not intra and inter tracks); 83 inputs at MPEG 155; codec selection 2027; standard targeted Oct 2029. None of this is on the part page | MPEG 155 | — | R ⚠ |
| V-PCC (ISO/IEC 23090-5) Gaussian-splat amendment | CDAM (2026-09-30: Draft Amendment since MPEG 154, per WG 4 N 837) | MPEG 153 | https://www.mpeg.org/153rd-meeting-of-mpeg/ | P✓ |
| G-PCC (ISO/IEC 23090-9) Gaussian-splat Amd 1 | CDAM | MPEG 154 | https://www.mpeg.org/154th-meeting-of-mpeg/ | P✓ |
| Enhanced G-PCC, ISO/IEC 23090-38 | FDIS | MPEG 155 | https://www.mpeg.org/155th-meeting-of-mpeg/ | P✓ |
Bearing on the registry. The last five rows bear directly on three registered
capabilities. wai.pc.vpcc is ISO/IEC 23090-5 and wai.pc.gpcc is 23090-9,
both with a patent-pool licence class. wai.splat.sog is a candidate registered
"ahead of an MPEG freeze". None of the three has a decoder inside wai-rs;
their decoders are sink-supplied.
media-codec-registry.md records a demonstrated
end-to-end decode of wai.pc.gpcc through the MPEG reference tool built from
source, and an encode plus structural decode of wai.pc.vpcc, both through
tools/wai_carriage_demo.sh (not re-run for this record). §6 maps the rows, and
G11 lists the questions they raise.
2.2 JPEG (ISO/IEC JTC 1/SC 29/WG 1)
| item | stage | date | source | grade |
|---|---|---|---|---|
| JPEG AI, ISO/IEC 6048 | Part 1 published 2025; Parts 2 and 5 published 2026; Part 3 (reference software) and Part 4 (conformance) at stage 60.00, under publication | — | — | R ⚠ |
| — its determinism design, as published | integer entropy pipeline (8-bit multipliers, 32-bit registers, overflow-free) is bit-exact; the normative conformance point is the entropy-decoder output, and reconstruction may diverge | — | overview paper arXiv 2510.13867 (its abstract does not state this; body not re-read for this record; syfai-input.md §5 quotes the passages from its body) |
S (consistent with determinism-tiers.md §1) |
| JPEG AI core experiments on energy-consumption analysis and on bit-exact reconstruction | reviewed at the 111th meeting (virtual, 13–17 Apr 2026). The release reports results across CPU, GPU and FPGA, with FPGA the most energy-efficient and GPU the lowest-latency. New core experiments on energy consumption, bit-exact reconstruction and evaluation are to continue | press release published 8 Jun 2026 | https://jpeg.org/items/20260608_press.html | P✓ |
| JPEG Trust | Part 1 (Core Foundation) 2nd edition published. Part 2 (Trust profiles and reports) "has now entered the DIS stage"; Part 3 (Media asset watermarking) "released for DIS balloting"; the Part 4 (Reference Software) DIS "also released for balloting". "A first JPEG Trust Summit is planned on 12-13 November 2026 in London." The standard number the sweep gave, ISO/IEC 21617, is not on the release | press release published 8 Jun 2026 | https://jpeg.org/items/20260608_press.html (read 2026-09-27) | P✓ (stages, summit) / R ⚠ (number) |
Bearing. The bit-exact reconstruction work is in the base standard's own core experiments. If it produces a reconstruction conformance point, the published Part 1 design in the row above stops describing later editions (§6, F11).
On main, WAI's texts do not agree on the capability. SPEC §5 registers
wai.image.jpegai at decode-equivalence, "reproducible on every machine";
the code classes it StandardDefined, which SPEC §7 defines as reconstruction
fixed by the standard; and SPEC §7 admits no float operation into replicate
(G9). In the tree at link 10 (link 02, PR #103), SPEC §5 registers the
capability at entropy-consistency, its registry class is NeuralEntropyExact,
and it does not back replicate. SPEC §7 (wai.image.jpegai and the standard
classes) records that its conformance part, ISO/IEC 6048-4, has not been read,
and that the capability is a candidate for StandardTolerance if Part 4 sets a
criterion on the reconstruction.
2.3 IETF (datatracker, read 2026-09-26; revisions, states and dates re-read 2026-09-27)
| item | stage | date | grade |
|---|---|---|---|
draft-ietf-moq-transport-21 |
WG Document. Milestones: transport and C4M (Common Access Tokens) to IESG Dec 2026. LOC, the streaming format (the milestone names it the WARP Streaming Format; draft-ietf-moq-warp is in state Replaced, by draft-ietf-moq-msf) and Privacy Pass authentication to IESG Mar 2027 |
2026-09-08 | P✓ |
draft-ietf-moq-loc-04, -msf-01, -cmsf-01, -c4m-01, -secure-objects-01, -privacy-pass-auth-03 |
WG drafts. None of these, nor -transport-21, contains the terms energy, joule, watt or power consumption (text search) |
— | P✓ |
WebTransport over HTTP/3, draft-ietf-webtrans-http3-16 |
In WG Last Call | 2026-07-06 | P✓ |
RTP over QUIC, draft-ietf-avtcore-rtp-over-quic-14 |
expired. Revision -14 is dated 20 March 2025 in its header (datatracker: published 2025-03-21) and expired in September 2025 (header: 21 September; datatracker: 2025-09-22). No later revision | 2025-03-20 | P✓ |
SCONE protocol, draft-ietf-scone-protocol-09 |
submitted to the IESG; IESG state IESG Evaluation. Bearing on WAI not assessed | 2026-09-25 | P✓ |
GREEN WG: framework-02 (2026-07-06, per its header), power-and-energy-yang-04 (2026-09-09), terminology-02 (2026-06-30), use-cases-02 (2026-08-07) |
WG drafts. Device and sub-component power telemetry. -04 keeps the graded data-source-accuracy hierarchy (measured bronze/silver/gold/red/ones; estimated static/historic/learned). No signature over energy values in any of the four. framework-02 does carry certification and calibrated-sensor material and asks for origin authentication of monitored data used for accounting (§6.1) |
as listed | P✓ |
draft-ietf-avtcore-rtcp-green-metadata-17 |
TSRR/TSRN hint messages; IESG state RFC Ed Queue | 2026-09-09 | P✓ |
2.4 Other bodies
| item | stage | date | source | grade |
|---|---|---|---|---|
AOMedia AV2: specification and libavm reference software |
specification and reference code v1.0.0 dated 28 May 2026 (landing page). Release announced 9 Jun 2026, "developed under AOMedia's royalty-free patent policy"; libavm remains the reference software; commercial conformance-stream packages from two vendors "are already available" (press release) |
2026-05-28 / 2026-06-09 | https://av2.aomedia.org/ ; http://aomedia.org/press%20releases/Alliance-for-Open-Media-Releases-AV2-Codec/ | P✓ |
| — its content | neither page mentions neural tools, energy or determinism. The specification text was not read for this record, so absence from the specification is not established | — | both pages | ⚠ |
| — shipping hardware decode | unknown: the hardware area was not reached | — | — | ⚠ |
| 3GPP SA4 WI 1080050, Study on Media Energy Consumption Exposure and Evaluation Framework phase 2 | study; outcomes documented in TR 26.942 | — | named on the workshop page below; the 3GPP portal was not read for this record (energy-exposure-mapping.md §3 reads TR 26.942 V20.0.0) |
S ⚠ |
| — joint workshop of 3GPP SA4, Greening of Streaming and 5G-MAG | quoted findings: "the lack of granular, shareable energy data across devices, networks and services"; "there is no standard that will give you the measurement… in an end-to-end use case". The page mentions no signing or attestation layer | 19 Mar 2026 | https://www.5g-mag.com/workshops/media-energy-consumption/ | P✓ |
| DVB BlueBook S100, Study Mission on Energy-Aware service Delivery and Consumption | study-mission report | Nov 2023 | https://dvb.org/wp-content/uploads/2023/11/S100_Study-Mission-on-Energy-Aware-Delivery-and-Consumption_Nov-2023.pdf | P✓ |
| — its content | four use cases: common measurement (§7.1), exposure (§7.2), energy as a source- or quality-selection criterion (§7.3), modernisation (§7.4). Existing coverage stated as "None in DVB" for §7.1 and §7.3. For §7.2, existing DVB APIs are said to be not designed to report energy. Draft requirements include a common reporting framework, open APIs per component, energy efficiency of a media instance in DVB-I, and DASH representation selection by energy efficiency | — | same | P✓ |
| DVB CM-EE subgroup | announced as a new Commercial Module subgroup on 17 Nov 2023 | 2023-11-17 | https://dvb.org/news/dvb-to-consider-energy-efficiency-when-creating-commercial-requirements-for-specs/ | P✓ |
| — the DVB chair's TV 2030 article | says "in 2024 we launched a working group on energy efficiency" and "so far we have struggled to bring this group and topic to life", and invites participation. The article does not name CM-EE. That this working group is CM-EE is the record's inference | 2025-09-10 | https://dvb.org/news/tv-2030-preparing-for-a-future-thats-already-in-sight/ (re-read 2026-09-27) | P✓ (quotes; a year old) / ⚠ (identification with CM-EE) |
| DVB-I package | approved, adds a security framework (TS 103 770); no energy items | 30 Jun 2026 | — | R ⚠ |
| IEEE 1857.11-2024, neural-network-based image coding (AVS_1857_WG) | published | 2024-12-20 | — | R ⚠ |
| — its call for proposals | required reproducibility cross-checks, not bit-exact decode | — | — | R ⚠ |
| IEEE P1857.11.1 (large generative models) | PAR approved | 2025-06-13 | — | R ⚠ |
syfai-input.md §5 and its sources read the IEEE 1857.11 call
for proposals and the standard's record page; this record's two IEEE 1857.11
rows keep the sweep's own grade.
3. Regional findings
3.1 China
| item | status | grade |
|---|---|---|
| AVS4 | announced Mar 2026; combines conventional and AI coding tools; no public draft | R ⚠ |
| AVS3 video | group standard since 2020; national standard still awaiting issuance | R ⚠ |
| Audio Vivid, GB/T 46271-2025 | in force 2026-03-01; includes a neural component; also ITU-R BS.2493 | R ⚠ |
| HDR Vivid, GB/T 46269.1/.2-2025 | national standard | R ⚠ |
| AVS point cloud, T/AI 128.2-2024 | group standard | R ⚠ |
| Perceptually lossless coding, T/AI 129.1-2024 | group standard | R ⚠ |
| Smart Media Transport, GB/T 33475.6-2024 | national standard | R ⚠ |
| UWA〔2026〕042, AI Ultra High Definition Media Encapsulation and Transmission Protocol (《AI超高清媒体封装与传输协议》) | project approved 2026-06-18; recruiting drafting participants, so pre-draft; the proposer the project page names is an operator's media subsidiary. https://theuwa.com/new-detail/899 | P✓ (project page) |
| Low-latency live delivery | converged on WebRTC. No MoQ work found at a Chinese standards body | R ⚠ |
| Media energy | no media-energy standard found. Device-level only: GB 24850-2020, GB 21520-2023 | R ⚠ |
Relation to the 2030 landscape. §7.3 of that document rejected an unnamed
Chinese intelligent-media transport standard: no ingestible surface, and an
opaque WAI envelope rides such a bearer unchanged. ⚠ Whether that item was
GB/T 33475.6 was not checked. If it was, the same reasoning applies here.
UWA 042 is a different item, an AI-specific encapsulation still at pre-draft,
and is a watch item (syfai-input.md §7).
Unreached: which institutions are behind the Chinese integer learned-codec work.
3.2 Japan and Korea
Japan.
| item | status | grade |
|---|---|---|
| ARIB STD-B80 (ISDB-T3) | v1.1 (2026-04-16) | R ⚠ |
| ARIB STD-B60 (MMT) | v2.0 (2025-03-25), the main deployed MMT profile | R ⚠ |
| NHK STRL Open House 2026 | C2PA provenance across capture, edit and distribution, with hardened in-browser verification. Cloud-unified broadcast/online production on ST 2110 + CMAF low-latency (no MoQ or QUIC). Live 8K 360-degree coding on VVC | R ⚠ |
| a learned image coding line with quantised arithmetic since 2020 | arXiv 2007.04684 (fixed point weight quantization), 2111.09348 (quantized weights and activations). arXiv metadata carries no affiliation, so the institution the sweep attached to this line is not verified | P✓ (titles) / ⚠ (affiliation) |
| arXiv 2608.00483 (2026-08; GLOBECOM 2026), by authors overlapping the line above | mixed-precision cross-platform neural video coding. P-frames run in FP16. I-frames and periodic feature-adapter resets run in IEEE-754 FP32, keeping the arithmetic entropy coder synchronised across GPUs. Evaluated across 12 GPUs of four architecture generations. Claims "deterministic synchronization at critical boundaries" and cross-generation decodability "for recent architectures". The abstract makes no bit-exactness or identical-reconstruction claim | P✓ (abstract) |
| METI Top Runner, TV target FY2026 | per-device annual kWh | S ⚠ |
The 2030 landscape (§7.3) rejected a clause-level claim about a Japanese MMT-over-TLV standard as a committee proposal rather than adopted text. Nothing in this sweep reopens it.
Korea.
| item | status | grade |
|---|---|---|
| Low-complexity feature transform adopted into MPEG FCM (ISO/IEC 23888-4) | MPEG 155. No secondary source was kept, and the MPEG 155 report cited in §2.1 does not mention it | R ⚠ |
| ISO/IEC 23003-8 biomedical and general waveform signal coding | FDIS at MPEG 155 (https://www.mpeg.org/155th-meeting-of-mpeg/). Described by the sweep as ETRI technology | P✓ (stage) / R ⚠ (attribution) |
| TV energy efficiency | per-device grades | R ⚠ |
Unreached: Korean ATSC 3.0 developments in 2025–26.
3.3 Europe and Brazil
Brazil — TV 3.0 / DTV+. Established by Decree 12.595/2025 (27 Aug 2025). The system uses:
- the ATSC 3.0 physical layer;
- ROUTE/DASH transport, with HLS optional for internet-delivered alternative content;
- VVC as the main video codec with LCEVC enhancement;
- MPEG-H Audio;
- the ABNT NBR 25601–25609 series.
Anatel Ato 2705 (24 Feb 2026) sets provisional conformity requirements.
Broadcasts have been on air since June 2026 in Rio de Janeiro, São Paulo and
Brasília, with 15 capitals targeted by 2030. R ⚠ for all of these. The 2030
landscape (§7.2) analyses the part of this system with a direct WAI bearing, the
lawful-basis declaration and privacy receipt in ABNT NBR 25608:2025 (§8.8 there).
⚠ That clause number comes from public companions: the 2030 landscape (§9
item 5) records that the paywalled standard itself was not read, and asks that
it be bought before the clause number is quoted outward. On main no extension
or code carries that declaration. In the tree at link 10 (PR #112), a
lawful-basis claim class (jwp-receipts.md
§2.4.6) records a declaration of purposes, each with its own basis, and decisions
taken against it, in the shape that section attributes to the standard's public
operational guidelines (§6). The bearing on the registry: on main all three
mandated media codecs are unregistered in WAI; at link 04 (PR #105), SPEC §5
registers wai.video.vvc, wai.video.lcevc (companion-only) and
wai.audio.mpegh (G5).
Europe.
| item | status | grade |
|---|---|---|
| Germany DVB-I launch | planned for 2026; sources give conflicting dates | C ⚠ |
| Spain national multiplex RGE2 | moves to DVB-T2 + HEVC UHD from 5 Nov 2026 | R ⚠ |
| [name removed 2026-09-30], Green Streaming whitepaper (Oct 2024) | kWh/GB is an inadequate metric; end devices account for 70–80% of chain energy | R ⚠ |
| FAMIUM Green hardware-in-the-loop energy rig | Computers 15(10):653, 25 Sep 2026. Body not read | P (citation; not re-read) / ⚠ content |
| France RGESN | 17 May 2024; 78 criteria; mandatory for public bodies | R ⚠ |
| France ARCEP decision 2025-2428 | declarative; excludes streaming platforms | R ⚠ |
| Blue Angel DE-UZ 215 (resource- and energy-efficient software) | ecolabel with a measure-and-publish requirement | R ⚠ |
Bearing. If end devices account for most of the chain's energy (a single
whitepaper, unverified), the sink-side decode is where a per-object figure
carries the most weight. That is the scope
energy-measurement.md already meters.
The claim is only as strong as that one source.
Unreached: Nordic and Dutch sources.
3.4 Rest of world
| item | status | grade |
|---|---|---|
| India, Direct-to-Mobile (D2M) on ATSC 3.0 in 470–582 MHz | Phase I authorised 2026 | S ⚠ |
| India, BIS IS 18112:2025 receiver standard | mandatory from 26 Jan 2026 | R ⚠ |
| Russia | no domestic codec programme found. The largest platform defaults to H.264, uses AV1 only for popular creators, and delivers over HTTP/3 | R ⚠ |
| Turkey, Indonesia | on DVB-T2 (Indonesia's DVB-T2 early-warning mechanism: 2030 landscape §7.1) | R ⚠ |
4. Industry deployment reality (2026)
- Codec mix. An encoder vendor's survey (March 2026; vendor-run; not read directly, and not named under this record's naming rule) reports production use of H.264, HEVC, AV1, VP9 and VVC [figures removed 2026-09-30: a vendor-run survey's numbers are not cited by this record]. S ⚠. The sweep's reading is that VVC ships at scale only where a national mandate requires it (Brazil, §3.3). R ⚠. That is an inference from the sources found, not a census.
- Media over QUIC. The CDN relay service found by the sweep publishes
developer documentation (last updated 31 Jul 2026; read, so cited by URL
under the naming rule). It lists relays for
draft-14 and draft-16 of MoQ Transport and a draft-18 test relay,
and describes the service as a beta ("free to use during the beta
period"). P✓ ([URL removed 2026-09-30]). The current transport
draft is -21 (§2.3). There are niche production deployments and many
trade-show demonstrations (R ⚠). No top consumer platform was found
delivering to viewers over MoQ (R ⚠). WebTransport is reportedly
baseline across the major browsers (S ⚠) (2026-09-30: confirmed from a
primary source — the W3C WebTransport Candidate Recommendation Snapshot of
2026-07-30, and Baseline status since 2026-03-24 in the web-platform status
data). Bearing: any interop claim for
moq-streaming-format.mdmust name the transport draft it was tested against. The relay found serves -14 and -16 and is testing -18, while the WG text is at -21. - Neural codecs. No neural codec was found in production at large platforms. R ⚠. The hardware and NPU area, where such a deployment would most likely show up, was not reached (§1).
- Cross-platform learned video without bit-exact arithmetic. arXiv
2606.28027 (MLVC, ECCV 2026) explicitly transmits scale parameters through
the hyperprior. Its abstract says this "guarantees entropy coding consistency
across devices without requiring bit-exact arithmetic", at a bitrate cost
(magnitude not recorded). It reports real-time encode and decode on
commodity NPUs from three vendors. P✓ (abstract). The abstract claims
entropy-coding consistency, not identical reconstructions. That the
reconstructions differ across platforms is inferred, not read ⚠. This is a
published instance of the explicit-parameter-transmission approach. On
main,determinism-tiers.md§1–§2 names that approach only generically. In the tree at link 10 (link 02, PR #103), §1 names arXiv 2606.28027 as its instance and says the side information costs bitrate, and §2 says why the route stops atentropy-consistency(G7). - Energy disclosure. No platform was found publishing per-stream or per-view energy. R ⚠.
5. Energy verifiability and regulation
5.1 Who can check an energy figure today
The question asked here is narrower than "who measures energy". It is whether a party that was not present can check a measured figure, and whether that figure is bound to a specific media outcome.
No standard or product was found that binds measured energy to a specific media outcome in a way a third party can verify. The closest precedents each provide part of that:
| precedent | what is signed or checked | what is not | grade |
|---|---|---|---|
| OCMF signed meter values (EV charging, under German calibration law) | a component of the metering installation signs session start and stop readings, and a third party can check them independently. energy-exposure-mapping.md L2 reads the OCMF text: the signing component need not be the meter itself |
not media; no binding to a reproducible output | R ⚠ / tree (which component signs: energy-exposure-mapping L2) |
| An ML-benchmark power methodology | wall-plug instrument plus peer review of the method | unsigned | R ⚠ |
| RAPL under confidential computing | — | the counter is deliberately filtered where an enclave may be running. The technical guidance published with advisory INTEL-SA-00389 (CVE-2020-8694, CVE-2020-8695; https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/running-average-power-limit-energy-reporting.html) gives the added noise as typically under 2 % standard deviation in readings at 1 s intervals and 5–15 % at 100 ms, with larger variance at thermal design power; filtered energy is reported when SGX is enabled or system software has enabled filtering, and TDX uses the filtered energy information. The advisory bulletin itself carries none of this, which is why the first reading found neither. energy-measurement §2.4 cites the guidance from link 11 | P✓ (the guidance, read 2026-09-30) |
| Confidential-computing GPU attestation; SPDM / Caliptra | firmware and configuration | not energy | R ⚠ |
| Cloud per-customer carbon reporting | — | explicitly not assured (one hyperscaler's methodology page, updated 2026-09-24) | R ⚠ |
| SCITT, RFC 9943 (Standards Track, June 2026) | signed statements plus transparency receipts | defines no energy claims (the RFC text contains neither "energy" nor "joule") | P✓; profiled in transparency.md |
| Emission Impossible, arXiv 2506.16347 | zero-knowledge proofs over carbon-emissions claims across a supply chain | a proposed methodology ("This paper proposes…"), not a deployed system | P✓ (abstract); already cited in jcp/jcp-rs/crates/jcp-efficiency/MAPPING.md §4 |
| 3GPP TR 26.942 / SA4 WI 1080050 | an exposure and evaluation framework | the workshop page mentions no signing or attestation layer; energy-exposure-mapping.md §3 finds no signature, attest, integrity or tamper in the V20.0.0 text |
S ⚠ (§2.4) / tree |
| DVB S100 draft requirements (2023) | a common reporting framework; per-component APIs; per-media-instance efficiency; energy-based DASH representation selection | S100 stated existing DVB coverage as "None in DVB" for two of its four use cases. No CM-EE output was found by the sweep, and the DVB chair wrote in Sep 2025 that a working group on energy efficiency launched in 2024 had "struggled to bring this group and topic to life" (the article does not name CM-EE) | P✓ (§2.4) |
In-tree precedent, outside WAI. The Sandbox standard's sandbox-tee energy
module (sandbox/sandbox-rs/crates/sandbox-tee/src/energy.rs) binds an energy
statement into a TEE attestation report and derives a trust level from the
evidence:
Unattested: a signed figure over a counter of unproven provenance.IntegrityAttested: a verified report over a counter the platform reports about itself.PhysicallyRooted: a dedicated sensor signed at the source.
Its CounterClass keeps HwShunt for a dedicated shunt and gives RAPL, NVML,
IOReport and Redfish classes of their own. Only HwShunt is
is_independently_rooted().
JCP's efficiency/1 carries an optional energy_attestation, a commitment to
that report (jcp/jcp-rs/crates/jcp-efficiency/src/training.rs). The rationale
is in that crate's MAPPING.md §4, which already cites PLATYPUS and arXiv
2506.16347. For TEE-attested readings this is the family's own answer to who
can check the figure. WAI's receipts do not reference it, on main or at
link 10 (§7, G4, G6).
The family's receipt ladder draws no such line. JCR-1 is the signed-receipt
format the family shares. JCP's SPEC says its receipts share the JCR-1 envelope,
and Sandbox §6.4 calls JCR-1 "the signed-receipt format shared across the …
family". Its normative §2.3
(jouleclaw/jouleclaw-rs/crates/jouleclaw-jcr1/docs/JCR-1-spec.md:69–72) puts a
RAPL MSR, the NVML cumulative-energy counter and a board shunt in
HwShunt alike. The other standards that list interfaces under HwShunt do
the same with RAPL, NVML, ROCm SMI, Level Zero, SMC or a shunt: JCP §5.1,
Sandbox §6.3, Proof, Mesh. So at the receipt level, on-die counters and
dedicated shunts share one class across the family. Only sandbox-tee's
counter classes separate them, and, in the tree at link 10, WAI's own classes
(below).
Where the family puts IOReport is not uniform. §5.3 records each standard's actual class for an IOReport reading, with file references.
In WAI. oer-receipts.md gives every
figure an evidential grade: projected, simulated, derived or
measured. It also makes receipts canonical, content-addressed, hash-chained
and signed. Its header says "a third party can check every figure without
trusting the producer". The checks in its §5–§6 cover the following:
- canonical form and identity;
- the chain and the signature under the key the vector file publishes;
- that each breakdown sums;
- the Landauer-floor arithmetic;
- the bundle roots and record hashes;
- that the receipts sum to a ledger's
meter_joules.
These establish the figures' internal consistency and who signed them. They do not establish that a figure matches a physical measurement:
- The ledger value.
meter_joulesis a plain value in the vector file, and the extension does not say who attests it. - The
measuredgrade. It covers "an instrument, a datasheet, or a published measurement" alike. - No acquisition-class member. §3's member list is closed and has no member
for the class. §2 says which grade each class supports and forbids a producer
to grade
measureda figure whose class isEstimator, and says that no reason code checks the rule, because a receipt carries no class. Theprovenance.deviceandenergy.methodmembers are free text; the corpus values arehardware,emulationandsimulation, andhardware_meterandmodel_estimated.
In the tree at link 10, oer-receipts §2 (link 08, PR #109) extends that
correspondence to the refined hardware classes and says that neither
hardware nor hardware_meter names a class, and
energy-measurement.md §1 places OER/2
receipts outside that extension's rules. An energy claim
(jwp-receipts.md §2.4.5; link 10, PR #112)
carries both axes for one object's figure — the class with its evidence, and a
grade it refuses when the grade ranks above what the class supports — and may
name the OER receipt that records the figure. A verifier holding both checks
that they agree on grade and figure, which makes the producer rule checkable
against the class the claim's signer states. The OER receipt itself still
carries no class.
So an OER receipt does not say whether a measured figure came from a counter
the platform relays or from an independently rooted instrument. It also does not
say who, other than the signer, stands behind the magnitude (§7, G6). OER is
WAI's own extension. It does not bear on this section's conclusion about the
field outside WAI (F1).
Bearing on WAI. energy-measurement.md
§5 states that a figure "is not verifiable by re-execution" and that, where
reconstruction is byte-exact, energy is "the single attested variable". The
OCMF precedent (R ⚠) shows a property that would make that variable
checkable by a third party: a signature made inside the metering installation,
not by the producer. The filtered-RAPL row (P✓) shows the
opposite case, an on-chip counter that may carry deliberate noise. On main,
WAI's HwShunt puts both in one class, as the family's receipt-level HwShunt
does, and takes in IOReport. In the tree at link 10 (link 08, PR #109),
energy-measurement §2 splits WAI's hardware class into CalibratedInstrument
and OnChipCounter. Each carries a declared uncertainty (§2.3); the counter
records its filtering state (§2.4) and the instrument a calibration reference
(§2.5). HwShunt becomes a legacy class, accepted and never emitted (§2.6), and
IOReport is OnChipCounter (§2.9). The class is the producer's signed
declaration: a calibration reference makes the calibration claim checkable, not
true (§2.5).
5.2 Regulation
No jurisdiction was found to mandate per-stream, per-view or per-decode energy figures. The rules found are device-scoped, facility-scoped, declarative, or allow estimates:
| jurisdiction / instrument | what it requires | grade |
|---|---|---|
| EU, Commission Delegated Regulation C(2026) 3472 (dated Brussels, 21 Sep 2026; transmitted to the Council the same day as ST 13444/26) | a common Union rating scheme and label for data centres. From 15 Aug 2027 the European database generates an electronic label for data centres that have reported (Art. 3). The amendments to Regulation 2024/1364 remove "some indicators (such as the data traffic indicators)". Its Annex III adds to point 1 of Annex I of Regulation 2024/1364 a point (f), Certification of the reported data: a scheme "in the framework of which a qualified or accredited third party validates the monitoring, data validation and reporting procedures", with "a distinction between self-certification and third-party certification". It defines an item; the text read does not require certification. Annex I of 2024/1364 itself was not read. A review by 31 Dec 2028 (Art. 6) is to consider "indicators to measure the performance of the ICT equipment energy use" and "(partial) certification or auditing of the reported data" | P✓ (read 2026-09-27: the act, https://energy.ec.europa.eu/document/download/b073ba9b-82a8-45cb-b8ba-78dad149e941_en?filename=C_2026_3472_1_EN_ACT_part1_v9.pdf ; its annexes, https://data.consilium.europa.eu/doc/document/ST-13444-2026-ADD-1/en/pdf) |
| EU ESPR working plan 2025–2030 | ecodesign/label revision for displays, indicatively 2027; no ICT-specific act | R ⚠ |
| EU CSRD | scope narrowed by the Omnibus I package | R ⚠ |
| EU AI Act Art. 53 | general-purpose AI model providers must document known or estimated training energy (estimation allowed) | R ⚠ |
| France, RGESN / ARCEP 2025-2428 | §3.3: mandatory for public bodies / declarative, excluding streaming platforms | R ⚠ |
| Germany, Blue Angel DE-UZ 215 | voluntary ecolabel: measure and publish | R ⚠ |
| US | DOE withdrew set-top box coverage. The voluntary set-top box agreement (Tier 4 from 2026) uses third-party lab testing and audits | R ⚠ |
| Japan (METI Top Runner), Korea (TV grades), China (GB 24850-2020, GB 21520-2023) | per-device annual figures or grades | S / R ⚠ |
Two EU texts touch who checks reported data, both for data centres, not streams. C(2026) 3472's Annex III defines Certification of the reported data and requires self-certification to be distinguished from third-party certification; its 2028 review is chartered to consider (partial) certification or auditing. The only regime found that relies on third-party testing is the US voluntary set-top box agreement (R ⚠), and it tests devices, not streams.
5.3 How the monorepo's standards class an IOReport reading
IOReport is the SoC energy interface the reference meters read on arm64 macOS
[name removed 2026-09-30]. This table records, per standard, the class an IOReport reading
actually gets, from the normative text and from the reference code. It was made
by reading every tracked line that mentions IOReport (git grep -n -i ioreport,
outside this record), with its surrounding lines wherever a class name was near,
together with each standard's HwShunt definition and the code that assigns the
tag. None of the files cited in the rows other than WAI's differs between
afc7ece and the tree at link 10, so their line numbers hold on main and in
that tree. The WAI row gives both states. Nothing was run: where a class comes
from code, it is the tag the code assigns, not an observed receipt.
| standard | normative text | reference code | class of an IOReport reading |
|---|---|---|---|
| JCR-1 (the shared receipt envelope) | jouleclaw/jouleclaw-rs/crates/jouleclaw-jcr1/docs/JCR-1-spec.md:69–72 (§2.3): ModelBased — "vendor model estimate from freq/voltage/utilization (… IOReport, NVML power.draw)" |
conformance vector 6 (conformance/vectors.json:148, conformance/README.md:31): ModelBased |
ModelBased |
| JouleClaw | jouleclaw/SPEC.md:73–74 (provenance table), :88 ("Model-based, not measured"): ModelBased. The same table puts ROCm SMI under ModelBased |
jouleclaw-energy: src/apple_ioreport.rs:1, :11 and test provenance_is_model_based (:431–433); conformance/vendors/apple-silicon-ioreport.json:12; MEASURED_ENERGY.md:23 — ModelBased. Its load-average fallback, src/apple.rs:1, :89–91, is Estimator. jouleclaw-compliance src/passport.rs:132–133 (and test :701–704) maps MeasurementMethod::IoReport to Estimator, "until the FFI is wired". jouleclaw-energy/conformance/README.md:26 lists the ROCm SMI counter as HwShunt, against the SPEC |
ModelBased; Estimator in jouleclaw-compliance |
| JCP | jcp/SPEC.md §5.1 (:395–402): RAPL and NVML → HwShunt, time × power → ModelBased. No IOReport rung |
jcp-energy src/lib.rs:15–17, :435–438, :481 (Meter::IoReport => Provenance::ModelBased): ModelBased. jcp-gateway src/lib.rs:429–436 seals its metered evaluation as HwShunt whenever the Sandbox PowerMeter reads hardware, which on arm64 macOS [name removed 2026-09-30] is IOReport (jcp/README.md:49) |
split: ModelBased (jcp-energy), HwShunt (jcp-gateway) |
| Joule Code | joule-code/spec/receipt.md:32 (normative sub-spec): HwShunt — "read from a hardware energy interface (RAPL, … SMC/IOReport, an external shunt)". Its signed form is a JCR-1 envelope (:38–40) |
joule-code-remediate src/lib.rs:635–657 seals an attributed share of a Sandbox-meter reading as ModelBased (its source string: "attributed(ModelBased over IOReport HwShunt)"). examples/l3-jouleclaw/src/bin/run.rs:29–33 uses JouleClaw's ModelBased counter; that example's README.md:44–45 still says Estimator "until IOReport is wired" |
split: HwShunt (normative text); ModelBased in both code paths |
| Sandbox | sandbox/SPEC.md:217 (§6.3) lists RAPL/powercap, NVML, ROCm SMI, Level Zero and "an SMC/shunt otherwise" under HwShunt; IOReport is not named. sandbox/README.md:9: the reference meter reads IOReport, RAPL and NVML, "each tagged HwShunt" |
sandbox-meter src/probe/mod.rs:8–10, :247 and src/probe/ioreport.rs:3: HwShunt; sandbox-proof src/lib.rs:1153 likewise. sandbox-tee src/energy.rs gives IOReport a CounterClass of its own (IoReport), not independently rooted |
HwShunt (receipt); own class in sandbox-tee |
| Proof | proof/SPEC.md:89 and proof-schema src/lib.rs:104: HwShunt = RAPL/NVML/SMC/shunt; IOReport not named |
proof-cascade src/meter.rs:1–2, :23 calls itself "the HwShunt backend" and reads IOReport on arm64 macOS [name removed 2026-09-30]; proof-cli src/main.rs:90–93, :117 seals the reading with Energy::measured, which sets HwShunt (proof-schema src/lib.rs:153–158). The same module doc, meter.rs:9–10, says "a macOS reading is ModelBased" |
split: HwShunt (code); ModelBased (its own module doc) |
| Sense | sense/SPEC.md:166–170: the reference meter is Sandbox's PowerMeter ("real RAPL/IOReport") |
sense-schema src/lib.rs:214–215: HwShunt — "A hardware energy reading (RAPL, IOReport, NVML)" |
HwShunt |
| Joule UI | joule-ui/SPEC.md:73: the reference meter is Sandbox's PowerMeter ("real RAPL/IOReport") |
joule-ui-serve Cargo.toml:21–23 and src/bin/joule_ui_serve.rs:29–31: an arm64 macOS [name removed 2026-09-30] IOReport reading makes "the receipt's HwShunt" true |
HwShunt |
| Mesh | mesh-schema src/lib.rs:41–44: HwShunt = RAPL/NVML/SMC/shunt; IOReport not named |
mesh-meter Cargo.toml:22 (hw-meter-apple enables JouleClaw's IOReport counter); src/lib.rs:222–233 passes JouleClaw's provenance through unchanged |
ModelBased (inherited from JouleClaw) |
| JouleDesk | — | jouledesk-github Cargo.toml:20–21, src/lib.rs:34–44: JouleClaw's detect_meter with the IOReport feature; records the meter's own provenance |
ModelBased (inherited from JouleClaw) |
| EOC | eoc/vocab/v1.ttl:34–35 carries the three names; IOReport is not mapped |
eoc-core src/joule_cost.rs:7–12 has two classes, Measured and Estimated; eoc-meter src/lib.rs:56–61, :145 reads IOReport as Measured ("Measured-grade") |
Measured (a two-class vocabulary) |
| WAI | main: extensions/energy-measurement.md:34, :42–43: HwShunt = "RAPL, NVML, SMC, IOReport, or an external shunt"; "RAPL, NVML and IOReport are sensor values". Link 10 (link 08, PR #109): §2's table puts RAPL, NVML, SMC and IOReport under OnChipCounter, §2.9 classes IOReport OnChipCounter, and §2 requires a producer that carries a WAI figure into a three-name vocabulary to map both refined hardware classes to HwShunt |
main: bin/wai_video_meter.rs:184–190 stamps an IOReport reading HwShunt, and the other receipt families that seal a joules_micro figure (quantum, ternary, world, film, haptic, score, splat4d, spatial audio, provenance) carry no class. Link 10: the reference meters (wai_video_meter, wai_meter, wai_world_meter, wai_quantum_meter, wai_prov) read IOReport through a non-privileged reader (energy_burst) and seal OnChipCounter, with filtering state Unknown and a declared uncertainty, or seal unmetered; every wai-rs and wai-quantum receipt family that seals a figure can carry the class (§6) |
main: HwShunt, or unlabelled. Link 10: OnChipCounter (HwShunt at the three-name level), or unlabelled in a receipt of the legacy form |
Map, Access (aac), JouleContract, JouleHook and Smart Byte either carry the
three names or none, and mention IOReport nowhere.
What this shows.
- The monorepo is split on IOReport, not uniform with WAI departing. The
normative JCR-1 text and JouleClaw class it
ModelBased, and Mesh and JouleDesk inherit that. Joule Code's normative receipt text, the Sandbox reference meter, Sense, Joule UI,jcp-gateway, Proof's code and WAI onmainclass itHwShunt. WAI at link 10 classes itOnChipCounter, a refinement that maps toHwShuntat the three-name level.jouleclaw-complianceclasses itEstimator, EOCMeasured, andsandbox-teegives it a class of its own. - Four standards are split internally: JCP (
jcp-energyagainstjcp-gateway), JouleClaw (jouleclaw-energyagainstjouleclaw-compliance, and ROCm SMI between its SPEC and its conformance table), Joule Code (its normative text against its code) and Proof (its code against its own module doc). - JCR-1 envelopes can carry both. Several of the
HwShuntemitters seal JCR-1 envelopes (Sandbox SPEC §6,sandbox/SPEC.md:225; Proof'sproof-receipt;sense-receipt/src/jcr1.rs; Joule Codereceipt.md§3), so a JCR-1 envelope in this tree can carry an IOReport reading asHwShuntwhile JCR-1 §2.3 classes itModelBased. This follows from the code paths; no such envelope was produced for this record. - ROCm SMI is split the same way:
ModelBasedinjouleclaw/SPEC.md:74,HwShuntinsandbox/SPEC.md:217 and injouleclaw-energy's conformance table.
energy-measurement §2.9 at link 10 lists where other documents class
IOReport differently: jouleclaw/SPEC.md, jouleclaw-energy, the JCR-1
conformance files, jouleclaw-compliance, jcp-energy and the Joule Code
example. It names sandbox/README.md, proof/README.md,
joule-code/spec/receipt.md and eoc-meter as agreeing with it at the
three-name level. It does not list the JCR-1 §2.3 text itself, jcp-gateway,
Sense, Joule UI, the Sandbox meter code, Proof's code and module doc,
joule-code-remediate, Mesh or JouleDesk. It changes none of those documents.
6. What the tree holds, and in what form
Checked by reading the named files and grepping wai/ for code, in the tree at
link 10 and on main. The state column says how far each item goes:
- implemented: code in
wai-rs(orwai-quantum) carries it, in the file named; - specified: extension or SPEC text only, and no code carries it (grep stated);
- analysed: a research document only, and the ingest is open.
Where the two trees differ, a row gives main first and then link 10, naming
the link and pull request. Only implemented rows are carried by code.
Specified and analysed rows are still work, and much of it is in the 2030
ingest queue (2030 §8, item cited per row). This section maps where each finding
lands. It is not a statement that the finding needs nothing further.
| finding | where in the tree | state | what the tree holds |
|---|---|---|---|
| JPEG AI's published conformance point is the entropy-decoder output; reconstruction may diverge | SPEC.md §5 (the wai.image.jpegai row) and §7; determinism-tiers.md §1–§6; reconstruction-binding.md §1–§2; wai-rs/src/codecs/mod.rs; wai-rs/src/container.rs; wai-rs/src/jpegai_decode.rs; wai-rs/src/reconstruction_binding.rs |
main: tier names specified; a coarser classification and the reconstruction hash implemented; SPEC §5 registers wai.image.jpegai at decode-equivalence while the code classes it StandardDefined (G9). Link 10: specified and implemented, with the tiers as a type in code |
main: capability_replicate_class puts the integer neural capabilities in NeuralIntegerExact (wai.neural.int_synth, wai.neural.int_hyper, wai.video.int_hyper, wai.audio.int_codec, wai.splat.int_codec); wai.image.jpegai falls through a default arm to StandardDefined; the two tier names appear in no type. Link 10: determinism-tiers §1 states the base standard's conformance point and quotes an overview's account of its conformance part; §2 defines the tiers; §5 lists the capabilities at each (link 02, PR #103). NeuralIntegerExact also holds wai.neural.int_mlicpp (link 09, PR #111). wai.image.jpegai is the one NeuralEntropyExact capability, registered at entropy-consistency (link 02). codecs::DeterminismTier and ReplicateClass::neural_tier carry the tiers in code (link 02). Every registered capability is listed under one class with no default class: an unlisted one returns None, which the tests reject, and StandardDefined needs a recorded basis pinned in the tests (link 04, PR #105). Per Prior, a substring heuristic over the free-text determinism string still gives IntegerExact, FloatReproducible or Unknown; since link 02 the registry class is checked before it (codecs::replicate_refusal). ⚠ JPEG AI's own core experiments on bit-exact reconstruction are continuing (§2.2), so this row describes the published Part 1, not necessarily later editions (F11) |
the floor a neural decode must meet to back intent = replicate |
SPEC.md §3, §7 (Replicate-soundness); determinism-tiers.md §2–§3; reconstruction-binding.md §1–§2; wai-rs/src/codecs/mod.rs (replicate_refusal); wai-rs/src/container.rs (replicate_is_sound, determinism_class); wai-rs/src/neural/mod.rs (decode_envelope_strict) |
main: specified three ways (G10); the code follows SPEC §7's all-integer rule, applied to the prior's declared string. Link 10: specified once and implemented (link 02, PR #103) |
Link 10: over a neural capability replicate promises decode-equivalence, which SPEC §7 admits only by an integer / fixed-point decode path with no float operation. entropy-consistency MUST NOT back replicate ("necessary … and not sufficient"), and neither may a reconstruction that one implementation pins through fixed-order float stages. determinism-tiers §2 defines decode-equivalence over "integer / fixed-point arithmetic end to end". decode_envelope_strict and Wai::replicate_is_sound check the capability's registry class first, then the pinned prior. The free function container::replicate_is_sound still checks only the prior |
| explicit parameter transmission as a route to a reproducible entropy stage | determinism-tiers.md §1–§2 |
specified | main: named with no instance or cost (G7). Link 10: §1 names arXiv 2606.28027 as the instance and says the side information costs bitrate, and §2 says why transmitting parameters stops at entropy-consistency (link 02, PR #103) |
| decode followed by processing that changes the output (post-filters, operation-reduction hints) | determinism-tiers.md §2, What a tier covers |
specified | a tier covers the whole path to the medium the sink emits; 2030 §8 item 1 landed as this text. At link 02 the section also accounts for every metadata set the Introduction of the 23001-11 4th-edition CD text names, read from that text. No code enforces the rule (grep over codecs/, container.rs and neural/); the post-filter matches in wai-rs/src/jpegai_*.rs are JPEG AI's own decoder stages |
| Green Metadata (23001-11 / -19), the RTCP green-metadata draft, IETF GREEN | 2030-transport-landscape.md §3.5, §5; energy-exposure-mapping.md §1, §4–§5; at link 10 also determinism-tiers.md §2 and energy-binding.md §7.1–§7.2 |
analysed; the tier rule above is specified | complementary predictive or device-scoped work. At link 02, energy-binding §7.1–§7.2 cite 23001-11's decoding operation reduction request and response (DOR-Req / DOR-Resp) as the request/commitment case |
| a per-figure acquisition class | energy-measurement.md §1–§2.9; wai-rs/src/energy_class.rs; wai-quantum/src/quantum_energy.rs; wai-rs/src/claim_receipt.rs |
main: implemented in the energy binding and the video receipt only. Link 10: implemented in every wai-rs and wai-quantum receipt family that seals a figure (link 08, PR #109), and in an energy claim (link 10, PR #112); absent from the JWP group and object receipts and from OER |
main: HwShunt / ModelBased / Estimator. jwp-receipts.md §2.3–§2.4 and its implementation (joule-code/joule-code-rs/crates/joule-moq/src/receipt.rs) have no class field; the other receipt families carry none. Link 10: CalibratedInstrument, OnChipCounter, ModelBased, Estimator and legacy HwShunt (§2), one definition in energy_class, mirrored by quantum_energy. The class is always present in the energy binding, its C2PA companion assertion, the wai.video.int_motion receipt and the wai.video.* OTT receipts, and an optional signed label in the world-session, film and reel, haptic, score, 4D-splat, audio-scene, ternary and provenance-step receipts and in every wai-quantum receipt (Labelled, and LabelledQbom per entry). Every wai-quantum type with a joules_micro field is labellable (grep). Every wai-quantum receipt type with a joules_micro field implements the label, and the bill of materials is labelled per entry (grep). An energy claim (jwp-receipts §2.4.5) gives a JWP object's figure a signed place for its class. The JWP object and group receipts still have no member for it, the WAI_RECEIPT property carries it unsigned, and an OER/2 receipt has none (energy-measurement §1; G6) |
| acquisition class derived from network-layer identities, never improved, with a declared tolerance | energy-measurement.md §2.1, §2.3 |
main: specified, not implemented. Link 10: the declared uncertainty implemented for the hardware classes; the derivation specified, not implemented |
main: §2.1 makes the tolerance a MUST, and no receipt has a field for one. Link 10 (link 08, PR #109): §2.3 requires CalibratedInstrument and OnChipCounter to carry a standard relative uncertainty with its integration window, and energy_class refuses a hardware class without one or below the figure's own resolution. §2.1 says a derivation from a network-layer identity SHOULD be made and MUST NOT improve the class, that a graded band MUST NOT be declared as an uncertainty, and that a declared uncertainty MUST NOT select a band. ModelBased and Estimator still carry no uncertainty (§2.1). No code maps data-source-accuracy identities (grep). 2030 §8 item 8 |
| an evidential grade per figure; content-addressed, chained, signed receipts; a ledger identity tying the chain to a meter | oer-receipts.md; wai-rs/src/oer.rs (feature oer); oer-conformance/ |
implemented (on main; CI runs wai_oer_vectors) |
Four grades, weakest first: projected, simulated, derived, measured. The grade is a separate axis from the acquisition class, and §2 states which grade each class supports, extended at link 08 to the refined hardware classes. Its kinds include reconstruction and decode, but the conformance corpus holds only decision, bundle and anchor receipts, plus a teleport negative for unknown_kind. What its checks establish, and what they do not, is in §5.1 (G4, G6) |
| request / commitment / delivery and the residual | energy-binding.md §7 |
specified, not implemented | op_requested / op_committed / op_delivered appear only in the extension text (grep over wai-rs and wai-quantum). 2030 §8 item 3 |
| SCITT / COSE Receipts | transparency.md (Status: Draft); at link 10 also jwp-receipts.md §2.4.7 |
main: specified, not implemented. Link 10: a log-inclusion claim implemented; emission and inclusion checking specified only |
main: an emission profile; no scitt or cose_sign1 in any *.rs under wai/. Link 10 (PR #112): a registration MAY be recorded as a log-inclusion claim that carries the log's receipt verbatim with its registration profile; accepting that claim is not verifying the inclusion, and checking the log's receipt under its profile is not specified. Still no scitt or cose_sign1 in code (grep). 2030 §8 item 7 |
| MoQ MSF / LOC / CMSF | moq-streaming-format.md (Status: Draft) |
specified, not implemented | a packaging value "wai" plus a per-object property; at link 08 the property gains acquisition_evidence. No MSF packaging code under wai/ (grep for msf; the packaging hits are wai.video.package, a different layer). 2030 §8 item 13b |
| Brazil lawful-basis declaration (ABNT NBR 25608 §8.8) | 2030 landscape §7.2; at link 10 also jwp-receipts.md §2.4.6, wai-rs/src/claim_receipt.rs (feature receipt_claims), claim-conformance/ |
main: analysed, open ingest. Link 10: specified and implemented as a claim class (PR #112) |
main: no extension or code carries it (grep for lawful, PRRD, privacy receipt and 25608 outside the landscapes). Link 10: a lawful-basis claim is a declaration of purposes, each with its own basis and data categories from a declared vocabulary, or a decision recorded against one; its shape is the one jwp-receipts §2.4.6 attributes to the standard's public operational guidelines. It is not a consent mechanism, and nothing supplies an operator's key (jwp-receipts §2.4.6). The clause-number caveat of §3.3 stands. 2030 §8 item 4 |
| MPEG-AI Part 6 CfP | mpeg-ai-part6-mapping.md |
analysed | requirement mapping; membership blocker stated |
| the C2PA environmental-sustainability assertion | energy-binding.md; wai-rs/src/energy_binding.rs (C2PA_STANDARD_LABEL); wai-rs/src/c2pa_emit.rs |
implemented | emitted as a companion alongside WAI's own assertion |
| MPEG's splat and point-cloud work: Exploration 45; the V-PCC and G-PCC Gaussian-splat amendments; Enhanced G-PCC, ISO/IEC 23090-38 (§2.1) | media-codec-registry.md, Volumetric / 3D geometry compression; wai-rs/src/codecs/mod.rs (CAP_PC_GPCC, CAP_PC_VPCC, CAP_SPLAT_SOG, CAP_SPLAT_INT_CODEC); wai-rs/src/int_splat.rs; volumetric.md (wai.splat.4d); 3d-neural-coding-landscape.md; 2030 §6.4 |
wai.splat.int_codec implemented. wai.pc.gpcc, wai.pc.vpcc and wai.splat.sog are registered: a capability string, a licence class and a tier, and no decoder inside wai-rs (grep). Their decoders are sink-supplied. media-codec-registry.md records a demonstrated end-to-end decode of wai.pc.gpcc through the MPEG reference tool built from source, and a real encode plus structural decode of wai.pc.vpcc, both via tools/wai_carriage_demo.sh (not re-run here). CI's tests/carriage.rs covers byte-identical carriage and known-capability dispatch for the registry, not these decodes |
Registry: wai.pc.gpcc (23090-9) and wai.pc.vpcc (23090-5) are POOL. wai.splat.sog is "MPEG WG4 WIP", "RF (open work)", a candidate "registered so a capability exists ahead of an MPEG freeze". main: capability_license gives PatentPool for the two PCC capabilities and, through its default arm, RoyaltyFree for wai.splat.sog; capability_replicate_class gives all three StandardDefined through its default arm. Link 10: all three are StandardUnclassified (link 02, PR #103; SPEC §7's table), and capability_license lists every capability with no default class, wai.splat.sog as royalty-free "SOG open work" (link 04, PR #105). 3d-neural-coding-landscape.md says splat coding applies NNC to the splat parameters; 2030 §6.4 records an NNC amendment covering Gaussian splats, unverified there (G11) (2026-09-30: 2030 §6.4 verifies it against MPEG's MPEG 154 press release; see its "Verified (Sept 2026)" paragraph) |
| a royalty class per capability | media-codec-registry.md, License classification; codecs::capability_license() / LicenseClass |
implemented | the mechanism any new pool-licensed registration uses. At link 04 the function is exhaustive with no default class, so a registered capability cannot become royalty-free by omission (G5) |
6.1 The 2030 energy-square falsifier, leg by leg
2030 §9 item 1 reads: "If any of ISO/IEC 23001-11's 4th edition, MPEG-AI Part 6's eventual working draft, or a GREEN WG document adds a measured per-object figure with an acquisition class bound to a reproducible output under a signature, then §2's 'unoccupied conjunction' is false … Check at each MPEG meeting and at each GREEN WG revision."
| leg | what was checked | result |
|---|---|---|
| ISO/IEC 23001-11 4th edition | the part page's one-line description and the 2030 §5.1 tool list, read for this record. The CD text (WG 3 N1864) was not read for this record; energy-exposure-mapping.md §4 searched it for signature, hash, attest, certif, joule, watt, measured and measurement and found none |
not triggered at CD (tree: energy-exposure-mapping §4). Recheck at DIS |
| MPEG-AI Part 6 working draft | none exists: the CfP closes 13 Jan 2027 (§2.1) | not applicable yet |
| GREEN WG documents | the four WG drafts at their current revisions (§2.3), fetched as text. Searched for signing, provenance, attestation, certification and per-object or per-stream terms; the security sections, framework-02 §4.1.4–§4.1.6 (read 2026-09-27) and the video-streaming use case (use-cases-02 §2.8) were read |
not triggered. Energy is scoped per hardware component (the Energy Object). -04 carries a measured/estimated accuracy hierarchy, already recorded at -03 in 2030 §3.5. No draft signs energy values. framework-02 §8 asks for authentication, authorisation and integrity protection of control actions, and protection of monitored data; it adds that monitored data "may be used as input to control, accounting, and other actions, so integrity of transmitted information and authentication of the origin may be needed". Its §4.1.4 requires every reported metric to carry an accuracy indication; §4.1.5 supports reporting industry-standard efficiency certifications per Energy Object, as a device-level reference; §4.1.6 gives an example accuracy identity, "Vendor-specific calibrated sensor with certificate ID XYZ". These are the GREEN material closest to F1 and to §5.1's calibrated-instrument point: a certificate identity attached to a sensor class, and origin authentication for accounting. None of them signs a per-object figure or binds one to a reproducible output. The video use case concerns traffic volume, multicast and caching. The individual draft draft-madpr-green-provenance-00 (2030 §3.5) is not a WG document and had no newer revision on 2026-09-27 |
2030 falsifier #1 is not shown to be triggered. That holds on the GREEN leg (checked here), on the 23001-11 leg at CD stage (by the term search in energy-exposure-mapping §4), and is moot for now on the Part 6 leg. The 23001-11 leg must be re-checked at DIS.
7. Gaps, and their status in the landing chain
G1–G11 were found on main, by the method in the evidence column; every file
that column cites by line is unchanged on main since afc7ece. The status at
link 10 column says what the tree at link 10 holds, and which link and pull
request carries it. A closed gap names where it closed. An open gap stays open.
None of the chain is in main until it merges, and each pull request has its own
review.
| # | gap (on main) |
evidence on main |
status at link 10 |
|---|---|---|---|
| G1 | The integer decoders are scalar and single-threaded, and no throughput figure is published. A determinism tier with no speed figure cannot be weighed against an approach that pays in bitrate rather than arithmetic (G7). | no rayon, std::thread, core::arch, std::simd or target_feature in wai-rs/src/int_*.rs, rans.rs or jpegai_*.rs; no throughput figure in README.md, SPEC.md or determinism-tiers.md (grep) |
Closed at link 07 (PR #108). wai-rs/src/int_kernels.rs adds register-blocked convolution, transposed-convolution and IGDN kernels (SIMD widening multiply-accumulate on aarch64, portable Rust elsewhere) and scoped worker threads (none on wasm), selected by a run-time Policy whose default is the fast kernels on all cores. The scalar reference kernels are kept and selectable. The claim is that every policy gives the same integer for every output element; it is argued by construction and tested, not machine-proved (SPEC Appendix A). decode-throughput.md §4 publishes whole-decoder and kernel figures from wai_decode_bench, measured on one macOS arm64 machine, best of four runs under a stated load (§3). Its limits (§5): one machine and one architecture; x86_64 compiled but not executed; the largest rows use synthetic weights. determinism-tiers §5 (What decode-equivalence costs) described the decoders as single-threaded with no explicit SIMD and no throughput figure until link 11, which describes the fast kernels and points to the note |
| G2 | The SOTA-quality and JPEG-AI whole-decode tests skip-as-pass when their inputs are absent, and no CI job runs them. A skipped test reports as passed. | wai-rs/tests/int_hyper_synth.rs and int_video_sota_keyframe.rs (return when the artifacts are not in WAI_SOTA_INT_DIR, default /tmp/sota_int); jpegai_e2e_full.rs (return without WAI_JPEGAI_CODESTREAM / _WEIGHTS_DIR / _NORM). The WAI workflows run cargo test --lib, --test carriage, --test neural_native_decode, the byte-exact-conformance stage goldens, the corpus verifiers and wai_oer_vectors; none runs the three test targets above |
Addressed at link 06 (PR #107); both workflows pass on the forge. With WAI_REQUIRE_SOTA_VECTORS=1 a missing or incomplete input fails the test and names the tool that produces it; without the switch the skip is written to the process's real stderr (tests/support/require_vectors.rs; tests/require_vectors_rule.rs checks the rule in child processes). wai-sota-vectors.yml regenerates the int_hyper vectors from pinned inputs and runs int_hyper_synth, int_video_sota_keyframe and require_vectors_rule. wai-jpegai-e2e.yml fetches the pinned JPEG AI inputs, checks them against tools/jpegai-e2e-v1.sha256, and runs jpegai_e2e_full, jpegai_reconstruction_binding and jpegai_cross_platform. Both set the switch, require each test by name, fail on a skip banner, and also run weekly. Both have run on the forge's Linux x86_64 runner and passed on every run since 2026-09-28 (runs read 2026-09-30); determinism-tiers §6 says so from link 11. Still in no workflow: jpegai_live and the dispatch test jpegai_exact_bundle_decodes, which need the neural feature and local assets |
| G3 | SyfAI's AI update-framework thread, opened at MPEG 155 jointly with WG 7 (S ⚠), covers parameter formats, manifests, repositories, integrity checking and bit exactness for NN decoders. The artifact a WAI Prior names has no normative wire form. Prior { id, sha256, determinism } pins identity: sha256 hashes the decoder artifact the sink runs. No wire format for that artifact is specified (2030 §6.4). |
wai-rs/src/container.rs struct Prior; 2030 landscape §6.4; no SyfAI or Exploration 52 mention in the tree (grep) |
Addressed at link 05 (PR #106), with limits. prior-carriage.md §2: a Prior MAY declare form; when it does, the digest covers the coded bitstream, and a sink that cannot read the form MUST refuse the prior. §3 registers wai.prior.nnc (ISO/IEC 15938-17:2024) as the one form, optional and not recommended, because its royalty status and cross-decoder exactness are not established. Prior::is_cross_hardware_exact requires a declared form to be established exact, none is, so a replicate resting on a declared form is refused (§5). The reference sink reads no form (READABLE_PRIOR_FORMS is empty), and wai-rs has no NNC reader or writer. SPEC's opening section now says a model's identity MAY be pinned by digest (a Prior). syfai-input.md, committed with this record, maps WAI onto the update framework; its G1 records what SPEC still does not define |
| G4 | WAI's HwShunt takes in IOReport, a reading the monorepo classes five ways; and neither WAI nor the family's receipt ladder separates platform-relayed counters from independently rooted instruments. Only sandbox-tee does. Three layers. (a) The family's receipt ladder. Every standard that lists interfaces under HwShunt puts on-die counters and dedicated shunts in it together (JCR-1 §2.3, JCP §5.1, Sandbox §6.3, mesh-schema, proof-schema), and IOReport is classed inconsistently (§5.3). (b) sandbox-tee's CounterClass reserves HwShunt for a dedicated shunt and gives RAPL, NVML, IOReport and Redfish classes of their own; its AttestTrust ladder is derived from evidence, and efficiency/1 commits to the attestation (§5.1). (c) WAI has HwShunt cover "RAPL, NVML, SMC, IOReport, or an external shunt", and wai_video_meter stamps IOReport readings HwShunt. That places WAI with Joule Code's text and the Sandbox meter, and against JCR-1 §2.3. WAI's texts present the ladder as the family's own without noting the split: video_receipt.rs says it is "reused verbatim from mesh-schema / proof-schema", which list no IOReport; energy_binding.rs calls it "the family's ladder"; energy-measurement.md §2 says WAI reuses "the same three names the receipt families elsewhere in the ecosystem already use". At every layer but (b), a verifier cannot tell a platform-relayed counter, which may be deliberately filtered (§5.1), from an independently rooted instrument. |
§5.3 (the per-standard survey); wai/extensions/energy-measurement.md §2; wai-rs/src/energy_binding.rs:30, :47–51 (Acquisition); wai-rs/src/video_receipt.rs Provenance doc comment; wai-rs/src/bin/wai_video_meter.rs:184–190; jouleclaw/jouleclaw-rs/crates/jouleclaw-jcr1/docs/JCR-1-spec.md §2.3; jcp/SPEC.md §5.1; sandbox/SPEC.md §6.3–§6.4; mesh/mesh-rs/crates/mesh-schema/src/lib.rs and proof/proof-rs/crates/proof-schema/src/lib.rs (Provenance); sandbox/sandbox-rs/crates/sandbox-tee/src/energy.rs (AttestTrust, CounterClass, is_independently_rooted); jcp/jcp-rs/crates/jcp-efficiency/MAPPING.md §4 and src/training.rs (energy_attestation). No mention of sandbox-tee, CounterClass, AttestTrust, energy_attestation, PhysicallyRooted or IntegrityAttested under wai/ (grep) |
WAI's side closed at link 08 (PR #109); the family's side open. energy-measurement §2 separates CalibratedInstrument (an external instrument with a current calibration) from OnChipCounter (a counter the measured silicon keeps, or any instrument whose uncertainty is not traceable). Each carries a declared uncertainty (§2.3); the counter carries its filtering state (§2.4), the instrument a calibration reference (§2.5). HwShunt is legacy, accepted and never emitted (§2.6), and IOReport is OnChipCounter (§2.9). energy_class.rs is the one definition, and the reference meters seal OnChipCounter. The "reused verbatim" sentence is gone; video_receipt.rs and energy_binding.rs still call the ladder the family's, and §2 says the three-name vocabulary is extended, not replaced, with both refinements mapping to HwShunt. §2.9's list of differing documents is partial (§5.3). No WAI text references sandbox-tee's ladder (grep). The family's IOReport split and whether its receipt-level ladder should separate the two kinds of hardware evidence are unassigned (below) |
| G5 | The codec registry has no AV2, VVC, HEVC, LCEVC, MPEG-H Audio, AVS3 or Audio Vivid capability. Brazil mandates three of these (§3.3). Two are Chinese standards: AVS3 (a group standard, with its national standard pending) and Audio Vivid (GB/T 46271-2025). 2030 §6.1 (Honest scope) records that WAI registers no VSEI-family codec. The tree's codec survey is a second surface to reconcile. wai/glossary/codecs.json, which wai/README.md describes as the "Reference catalog of media codecs surveyed for capability registration", has entries for HEVC / H.265 and VVC / H.266 (both niche), LCEVC (niche) and ECM (academic, JVET's exploration model beyond VVC), and none for AV2, MPEG-H Audio, AVS3 or Audio Vivid. glossary/SCHEMA.md defines success as "carries non-trivial production traffic today" and niche as "alive in specific contexts". §4 reports HEVC in production use at 65% in a vendor survey (S ⚠), §3.3 reports VVC as a national broadcast system's main codec (R ⚠), and the HEVC entry's own description calls it universal in broadcast UHD. The grades are descriptive and the contrary evidence is unverified, so this is a reconciliation item, not a correction. |
capability strings in wai-rs/src/codecs/*.rs: none for these codecs. Other mentions, from a grep over *.rs, *.md, *.json, *.toml, *.yml, *.yaml, *.html, *.ts and *.js under wai/: the glossary/codecs.json entries above; the H.264/H.265 royalty sentence in SPEC.md and CHANGELOG.md; the BD-rate note that names VVC in wai-rs/src/codecs/mod.rs and wai-rs/src/neural/mlicpp.rs; HEVC as an example name in glossary/SCHEMA.md; the 2030 landscape. Royalty class per codec not established by this sweep: only AV2's royalty-free patent policy was seen at the issuing body (the AOMedia press release, §2.4) |
Closed in the registry at link 04 (PR #105); the glossary is not reconciled. SPEC §5 Broadcast and streaming codecs registers wai.video.{av2,vvc,hevc,avc,vp9,evc,evc.baseline,avs3,lcevc} and wai.audio.{mpegh,avs3,aac}, each with one payload framing and a licence class whose basis is recorded in media-codec-registry.md. wai.audio.avs3 names AVS3 audio / Audio Vivid (GB/T 46271-2025). All are sink-supplied, none is a default, and wai.video.lcevc is companion-only. SPEC §7 classes AVC, HEVC, VVC and VP9 StandardDefined on the conformance clauses read, AV2 StandardTolerance, and EVC, AVS3, LCEVC, MPEG-H 3D Audio and AAC StandardUnclassified. The licence classes rest on the registry's recorded bases, not on this sweep. glossary/codecs.json is unchanged, so its grades still stand against §3.3 and §4 |
| G6 | No WAI receipt says who can check the energy figure, and the base JWP receipt does not carry even the acquisition class that energy-measurement.md requires. The precedents in §5.1 differ exactly on who can check: instrument-signed (OCMF), peer-reviewed but unsigned, log-registered (SCITT), TEE-attested with a derived trust level (the family's sandbox-tee AttestTrust), or producer-asserted. The base JWP receipt has no acquisition-class field; its group signature covers total_joules_micro and no class, and the per-object joules_micro is in neither the Merkle leaf nor the signature. energy-measurement.md §2 requires a class inside the signature for any non-zero figure, while its header says it adds "no new wire format". The video receipt signs its class. The energy binding carries its class in a C2PA companion assertion signed as part of whatever manifest carries it. The OER receipt carries an evidential grade and a ledger identity, and no class. 2030 §8 item 4 queues typed receipt classes. |
extensions/energy-measurement.md header, §1, §2 and §5; extensions/jwp-receipts.md §2.1–§2.4; joule-code/joule-code-rs/crates/joule-moq/src/receipt.rs (ObjectReceipt, GroupReceipt::signing_payload: no class); wai-rs/src/energy_binding.rs, wai-rs/src/video_receipt.rs; extensions/oer-receipts.md §2–§3, wai-rs/src/oer.rs; no reference to the family ladder under wai/ (grep, as in G4) |
Partly closed at link 10 (PR #112); the rest open. Every receipt within energy-measurement's scope that wai-rs and wai-quantum seal can carry the class (link 08, PR #109). jwp-receipts §2.4.3–§2.4.7 add a claim kind with typed classes. An energy claim (§2.4.5) restates a JWP object's figure beside its class, the class's evidence, a coverage statement and a grade; a verifier holding the object receipt rejects the pair if the figures differ, and one holding the OER receipt the claim names checks that grade and figure agree. claim_receipt.rs (feature receipt_claims) implements it, with vectors in claim-conformance/. Open, as energy-measurement §1 records: the JWP object receipt has no member of its own for the class; the group total has none, and nothing carries one for it; the WAI_RECEIPT property's class and evidence sit outside any signature; an OER/2 receipt has no member for the class. On who can check: a claim carries its signer's authority and no more (§2.4.4); key discovery and an authority class for who may sign which class are not done (CHANGELOG, v0.4.0 entry for typed receipt classes); no WAI receipt references sandbox-tee's ladder or efficiency/1's attestation (grep). Status after the v0.4.0 change "Energy reports, labelled object leaves, and what the signatures cover": the object's class rides in its labelled leaf, a group total can carry a signed class of its own, and a WAI_RECEIPT property's class counts only where a signed statement restates it; joule-moq verifies both labelled forms. Status after the v0.4.0 change "Key discovery, signing authority and module revocation": key discovery and an authority class for who may sign which class are jwp-receipts §7 (wai-rs key_log, feature key_discovery; signer-conformance/); a hardware-class energy authority is confirmed only under a pinned anchor, and a verifier reports whether the key also holds delivery |
| G7 | Explicit parameter transmission appears in determinism-tiers.md only as a generic route. Its first published cross-NPU instance (arXiv 2606.28027) and its cost are not recorded. Also unrecorded: the mixed-precision entropy-synchronisation line (arXiv 2608.00483: FP16/FP32 across GPUs, no bit-exactness claim); the quantised learned-coding line (arXiv 2007.04684, 2111.09348); and IEEE 1857.11's use of reproducibility cross-checks rather than bit-exact decode (R ⚠), a reproducibility notion the tier vocabulary does not name. Both 2606.28027 and 2608.00483 target a synchronised entropy stage, so at most entropy-consistency, and 2608.00483 only over the GPUs it tested. On main, whether such a decode may back replicate depends on which of G10's conditions is read. |
extensions/determinism-tiers.md §1–§3; SPEC.md §7 (read) |
Partly closed at link 02 (PR #103). determinism-tiers §1 names arXiv 2606.28027 as the explicit-parameter instance and says the side information costs bitrate (no magnitude), and names a quantised decoder, arXiv 2312.11209, as the route to a reproducible reconstruction. Such a decode reaches entropy-consistency and does not back replicate (G10). Not in the tree at link 10 (grep): arXiv 2608.00483, the quantised line 2007.04684 / 2111.09348, and IEEE 1857.11's reproducibility cross-checks; the last is described in syfai-input.md §5, committed with this record |
| G8 | Standards inputs not tracked in the tree: SyfAI; 3GPP TR 26.942; DVB S100 and CM-EE; the beyond-VVC CfP; Gaussian Splat Coding Exploration 45; IEEE 1857.11 / P1857.11.1; UWA 042; India D2M; the JPEG AI core experiments on energy consumption and bit-exact reconstruction. | a case-insensitive, word-bounded git grep -P over tracked *.md, *.rs, *.json, *.toml, *.yml, *.yaml, *.html, *.ts and *.js files finds none of these designations outside this record. The one other hit for uwa is the Hausa word in aac/aac-rs/crates/aac-core/src/translations_data.json ("ha":"uwa"), which is not the organisation. MPEG's splat work is tracked, though not Exploration 45 by name: media-codec-registry.md and codecs/mod.rs register wai.splat.sog against "MPEG WG4" work in progress, 3d-neural-coding-landscape.md records splat coding under standardisation, and 2030 §6.4 records an NNC amendment covering Gaussian splats (G11) |
Partly closed by the two notes committed with this record. syfai-input.md tracks SyfAI, IEEE 1857.11 and UWA 042; energy-exposure-mapping.md tracks TR 26.942, DVB S100 and CM-EE. The same grep over the tree at link 10 finds the beyond-VVC CfP, Exploration 45, India D2M and the JPEG AI core experiments in no document but this record. Those four stay open |
| G9 | WAI's texts and code class wai.image.jpegai in ways that contradict one another, and SPEC contradicts itself on it. SPEC §5, the capability's registration (SPEC.md:197), describes the decode as "integer entropy front end (mANS) + integer dequant/value path + fixed-order synthesis and post-filters" and declares "decode-equivalence: one pinned reconstruction … reproducible on every machine (a portable decoded-pixel hash)". reconstruction-binding.md §1 (:30–31) says the decode to RGB is "byte-identical on every machine", and §2 (:72) sets the binding's criterion at decode-equivalence; determinism-tiers.md §2–§3 list the capability there. SPEC §7 lets a neural capability back replicate only "with no float operation anywhere" (:445–448). capability_replicate_class returns StandardDefined for it through the default arm, and SPEC §7 defines that class as "reconstruction is fixed by the named codec/standard … the neural float hazard does not apply"; neither half holds for JPEG AI (§2.2; its decode runs the model). The strict replicate check reads only the envelope's prior (neural/mod.rs:282–292). Loose ends: (i) jpegai_synthesis.rs and jpegai_mans.rs say they back wai.neural.jpeg_ai, a string registered nowhere; (ii) the decode has f32 steps between its integer stages — its dequantisation among them, although SPEC §5 calls it integer; (iii) the byte-for-byte claim is made normatively, in SPEC §5 and reconstruction-binding.md §1, and rests on an exp() from the platform maths library and on no measurement on a second platform; (iv) the reference sink's dispatch (neural/mod.rs:205–216) uses the exact decoder only when the integer weight bundle is present, and otherwise falls back to a float ONNX Runtime decode. |
SPEC.md §5 (:197) and §7 (:445–448, the StandardDefined bullet at :476–478, :492–495); extensions/reconstruction-binding.md §1 (:21–35) and §2 (:72); extensions/determinism-tiers.md §2–§3; wai-rs/src/codecs/mod.rs (the default arm and the test asserting StandardDefined); wai-rs/src/jpegai_decode.rs, jpegai_synthesis.rs, jpegai_mans.rs, jpegai_pipeline.rs; wai-rs/src/neural/mod.rs:205–216, :282–292; git grep -n decode-equivalence over wai/ |
Closed at link 02 (PR #103), with the maths library removed at link 03 (PR #104). SPEC §5's row registers entropy-consistency (registry class NeuralEntropyExact), describes dequantisation, latent refinement, post-filters and colour conversion as IEEE-754 float with a fixed evaluation order, and says "Downgraded in v0.4.0: this row previously claimed decode-equivalence". reconstruction-binding.md §1–§2 make the pinned reconstruction a property of the exact decoder, reproducible under that decoder's build and floating-point conditions. SPEC §7 states the new class and the reason. Loose ends: (i) fixed — the module docs name wai.image.jpegai, and wai.neural.jpeg_ai appears nowhere else in the tree (grep); (ii) the float steps remain and are now stated as float; (iii) link 03 builds exp and rounding from IEEE-754 basic operations (float_repro), guards the decode path with clippy's disallowed_methods and a linked-symbol check (tests/jpegai_decode_symbols.rs), and pins nine hashes for one codestream; determinism-tiers §6 records them identical on macOS arm64, wasm32-wasip2, Linux arm64 and Linux x86_64 under user-mode emulation, and not measured on Windows, macOS x86_64 or x86_64 hardware; (iv) the float fallback remains, and SPEC §5, determinism-tiers §5 and reconstruction-binding §1 now state it, and that the result does not record which path ran. Still true: a norm.json with a missing or mistyped key panics in the loaders instead of falling back, as the try_jpegai_exact doc comment says |
| G10 | WAI's texts give three conditions for a neural decode to back replicate or a portable reconstruction hash, and SPEC states all three. (1) All-integer: SPEC §7 (SPEC.md:445–448, :492–495), enforced in code on the envelope's declared prior (replicate_is_sound requires DeterminismClass::IntegerExact, a substring heuristic over Prior.determinism). (2) decode-equivalence with fixed-order float admitted: determinism-tiers.md §2 defines the tier over "integer / fixed-order arithmetic end to end" (:57–58), and SPEC §5 registers wai.image.jpegai, whose float stages run in a fixed order, at that tier. (3) entropy-consistency as the floor: SPEC §7's closing paragraph (:497–505) calls it "the floor for a sound neural replicate", and determinism-tiers.md §2–§3 repeat it; §3 also says "a float neural decode meets neither tier", which does not square with the explicit-parameter route. A decode with integer entropy and fixed-order float synthesis meets (2) and (3) but not (1). |
SPEC.md §5 (:197) and §7 (:445–448, :492–495, :497–505); extensions/determinism-tiers.md §1–§3; extensions/reconstruction-binding.md §1–§2; wai-rs/src/container.rs (Prior::determinism_class at :108–117, is_cross_hardware_exact, replicate_is_sound) |
Closed at link 02 (PR #103), on condition (1). SPEC §7: a neural capability backs replicate only if its entire decode path is integer / fixed-point with no float operation, "the only construction by which a neural capability is registered at decode-equivalence"; entropy-consistency ("necessary for a sound neural replicate … and not sufficient") and a reconstruction pinned by one implementation's fixed-order float stages MUST NOT back it. determinism-tiers §2 defines decode-equivalence over "integer / fixed-point arithmetic end to end", and §3 says a decode that derives its entropy parameters in float meets neither tier while one that reads them from the codestream, or derives them in integer arithmetic, and runs later stages in float meets entropy-consistency only. The strict check reads the registry class before the prior. Remaining: the prior check still reads a sender-declared string by substring, which determinism-tiers §3 states |
| G11 | Three volumetric registrations sit against MPEG's 2026 splat and point-cloud work, and none of the sweep's rows was mapped to them. wai.splat.sog is a candidate "registered so a capability exists ahead of an MPEG freeze" (registry: "MPEG WG4 WIP", "RF (open work)"). wai.pc.gpcc (23090-9) and wai.pc.vpcc (23090-5) are registered POOL. None has a decoder inside wai-rs; the registry records demonstrated sink-side decodes via tools/wai_carriage_demo.sh (not re-run here, and not in CI). The sweep found a V-PCC Gaussian-splat CDAM (MPEG 153) (2026-09-30: at Draft Amendment since MPEG 154, WG 4 N 837), a G-PCC Gaussian-splat Amd 1 at CDAM (MPEG 154), Enhanced G-PCC ISO/IEC 23090-38 at FDIS (MPEG 155), and Exploration 45's document series up to a call for content at MPEG 155, all P✓; its tracks and dates are R. Questions: (a) whether what MPEG standardises is what wai.splat.sog names, which cites Self-Organizing Gaussians / SOGS while the part page names no candidate technology; (b) whether its royalty class holds (capability_license returns RoyaltyFree through the default arm; nothing the sweep read establishes the licensing of a codec MPEG selects); (c) whether 23090-38 is a payload wai.pc.gpcc admits or needs its own capability, and whether the splat amendments change what the two PCC capabilities admit; (d) the replicate class: all three fall through to StandardDefined, although wai.splat.sog has no frozen standard. The tree's "WG4" attribution was not checked (the Exploration 45 page names no working group), and 3d-neural-coding-landscape.md describes a "future wai.pointcloud.*" without mentioning the registered wai.pc.* strings. |
research/media-codec-registry.md; wai-rs/src/codecs/mod.rs (CAP_PC_GPCC, CAP_PC_VPCC, CAP_SPLAT_SOG and their arms); tools/wai_carriage_demo.sh; wai-rs/tests/carriage.rs; research/3d-neural-coding-landscape.md; 2030 §6.4 |
(d) closed at link 02 (PR #103); (b) made explicit at link 04 (PR #105); (a), (c), the "WG4" attribution and the wai.pointcloud.* sentence open. All three are StandardUnclassified, the class for a standard whose decoder-conformance clauses have not been checked (SPEC §7 notes that wai.splat.sog names no frozen standard yet). capability_license lists wai.splat.sog explicitly as royalty-free ("SOG open work"), which makes the class explicit and does not establish it. (2026-09-30: capability_license now classifies wai.splat.sog patent-pool, conservatively and provisionally while it is a candidate; SPEC §5, Licence classes) codecs/mod.rs and media-codec-registry.md still say "MPEG WG4", and 3d-neural-coding-landscape.md still describes a "future wai.pointcloud.*". Exploration 45 is untracked (G8) |
Found but assigned to no link. These are recorded so they are not lost:
- The 23001-11 4th edition at DIS. The CD text was searched for
energy-exposure-mapping.md§4; the DIS text needs the same search (§6.1, F1). - JPEG AI's core experiments on bit-exact reconstruction (§2.2). If JPEG AI
adopts a bit-exact reconstruction conformance point, the tier split between
what the base standard fixes and what WAI adds moves for JPEG AI (F11). In the
tree at link 10, determinism-tiers §4 calls
entropy-consistency"the tier at which JPEG AI sets its bit-exact conformance point", and SPEC §7 records that the conformance part has not been read. Neither text tracks the core experiments. - The family's IOReport and
HwShuntvocabulary (G4, §5.3) raises two questions beyond WAI.- Which class IOReport gets. The monorepo classes an IOReport reading five
ways, and JCP, JouleClaw, Joule Code and Proof are each split internally.
JCR-1 envelopes can therefore carry the same reading as
ModelBasedorHwShuntdepending on which standard sealed them. Settling it spans JCR-1 §2.3 and every standard in §5.3; ROCm SMI needs the same decision. energy-measurement §2.9 states WAI's own choice (OnChipCounter) and lists some of the differences; it does not, and cannot, settle the others. - Whether the receipt-level ladder should separate platform-relayed counters
from independently rooted instruments, as
sandbox-tee's counter classes and WAI'sOnChipCounter/CalibratedInstrumentsplit do. A family question, unassigned. - Stale texts found on the way:
joule-code/examples/l3-jouleclaw/README.md:44–45 (saysEstimator"until IOReport is wired", while itsrun.rsuses theModelBasedcounter);jouleclaw-compliancepassport.rs:117, :133 (Estimator, "or estimator until FFI ships", whilejouleclaw-energyhas an IOReport reader);proof-cascademeter.rs:9–10 against the same file's :1–2.
- Which class IOReport gets. The monorepo classes an IOReport reading five
ways, and JCP, JouleClaw, Joule Code and Proof are each split internally.
JCR-1 envelopes can therefore carry the same reading as
- The open parts of G6. A signed place for a JWP group total's class, a
member of its own for the JWP object receipt, a signature over
WAI_RECEIPT, and key discovery for claim signers. Status after the v0.4.0 change "Energy reports, labelled object leaves, and what the signatures cover": the JWP object receipt carries its class in its Merkle leaf with its figure and origin (jwp-receipts §2.2, §2.4.2); a group total can carry its own class under a labelled group payload that also signs the parent link (§2.3, §2.4.1); aWAI_RECEIPTproperty's class reads as signed only where it equals the leaf's label or anenergyclaim (moq-streaming-format §5). Status after the v0.4.0 change "Key discovery, signing authority and module revocation": key discovery for claim signers is jwp-receipts §7. Open: an OER/2 receipt's class, and who, other than the signer, stands behind a figure. - G7's other lines (arXiv 2608.00483, the quantised learned-coding line, IEEE 1857.11's reproducibility cross-checks) and G8's other inputs (the beyond-VVC CfP, Exploration 45, India D2M, the JPEG AI core experiments) are not in the tree at link 10.
- MoQ secure objects.
confidentiality.mdis built on thedraft-jennings-moq-e2ee-mlsbinding (MLS + SFrame), and the WG draftdraft-ietf-moq-secure-objects-01exists. The relationship between the two was not examined. draft-ietf-avtcore-rtcp-green-metadatais in the RFC Editor queue (§2.3). When it publishes, 2030 §5.1's reference becomes an RFC number.- JPEG Trust Part 3 (media asset watermarking), released for DIS balloting
(§2.2), bears on the second binding class (2030 §3.4), which link 10 adds as
a
soft-bindingclaim with an ancestor rule (jwp-receipts §2.6.2, §3.2; PR #112). It is a watch item. - MPEG-Green data transport in the MPEG-2 Systems 10th edition WD is carriage, which 2030 §4.5 says WAI does not bind. It is a watch item only.
- EU C(2026) 3472 (§5.2): its Annex III item on certification of reported data, with self- and third-party certification kept distinct, and its 2028 review of (partial) certification or auditing. Both concern data centres. A watch item for F2 and for G6's who-can-check question.
8. Updates and corrections to the 2030 landscape
These are recorded here and are not applied to that file. The 2030 landscape in the tree at link 10 still carries each reading in the second column. Apply them when that document is next revised.
| 2030 section | it says | this sweep observed | grade |
|---|---|---|---|
| §3.3 (FCM paragraph) | "MPEG 155 (August 2026)" | MPEG 155 met 13–17 Jul 2026 (mpeg.org/meetings; the 2030 landscape's own §6.5 agrees). The mpeg.org 155th-meeting press page is posted 12 Aug 2026, a likely origin of "August" | P✓ |
| §3.3 (FCM paragraph and its verification note) | "no published CD/DIS/FDIS milestone on mpeg.org"; the catalogue's CD is "one milestone further than mpeg.org's silence implied" | mpeg.org is not silent: the MPEG 154 page says "a CD of ISO/IEC 23888-4 was issued at the 23rd ISO/IEC JTC 1/SC 29/WG 4 MPEG Video coding meeting" (re-read 2026-09-27). The catalogue's CD agrees with it | P✓ |
| §3.5, §5.1 | draft-ietf-green-power-and-energy-yang-03 |
now -04 (2026-09-09): same accuracy hierarchy; still per-component and unsigned |
P✓ |
| §4.4 | draft-ietf-moq-transport rev 18, approaching WG Last Call |
now -21 (2026-09-08), state WG Document; transport and C4M to IESG targeted Dec 2026 |
P✓ |
| §5.1 | draft-ietf-avtcore-rtcp-green-metadata-16, IESG Evaluation |
now -17 (2026-09-09); IESG state RFC Ed Queue |
P✓ |
| §5.1 | 23001-11 4th ed. at CD (N01742) | dated on the part page: WD 2026-03-02 (MPEG 153), CD text 2026-09-21 (MPEG 155). The CD text is WG 3 N1864 (energy-exposure-mapping.md §1) |
P✓ / tree |
| §4.1 (grid-carbon paragraph) | "jwp-receipts.md §7 states that conversion of joules to currency, carbon or grid mix is performed by downstream aggregators" |
That statement is jwp-receipts §6.6, Out of scope ("Pricing semantics for joules"). When the landscape was written jwp-receipts had no §7 in the tree; its §7 is now Key discovery and signing authority, so the reference names the wrong section | tree |
| §9 item 1 | three legs (23001-11 4th ed., Part 6 WD, a GREEN WG document); "check at each MPEG meeting and at each GREEN WG revision" | GREEN leg checked and not triggered; Part 6 leg not applicable yet; 23001-11 leg not triggered at CD on energy-exposure-mapping §4's search (§6.1) | P✓ / tree |
9. Dated windows
| when | what | note |
|---|---|---|
| 19–23 Oct 2026 | MPEG 156, Hangzhou (dates P✓). That SyfAI (Exploration 52) and its AI update-framework thread continue there is the record's expectation from their document series (§2.1), not a published agenda ⚠ | input contributions need ISO/IEC JTC 1/SC 29 national-body membership (the blocker already stated in 2030 §6.5). syfai-input.md is WAI's draft input toward this window; it is not submitted |
| end of Oct 2026 | beyond-VVC CfP: main response package due; a supplemental package due mid-Dec 2026 | P✓ for the dates and for "technology based on neural networks and artificial intelligence will be considered". That the next video codec will then face the reproducibility question is the record's inference ⚠ |
| 5 Nov 2026 | Spain RGE2 → DVB-T2 + HEVC UHD | R ⚠ |
| 12–13 Nov 2026 | JPEG Trust Summit, London | P✓ (JPEG 111 release, §2.2) |
| Dec 2026 | MOQT and C4M to IESG (WG milestone) | P✓ |
| 13 Jan 2027 | MPEG-AI Part 6 CfP responses due, evaluated at MPEG 157 | mpeg-ai-part6-mapping.md; SC 29 membership. P✓ |
| 18–22 Jan 2027 | MPEG 157, Brisbane; beyond-VVC evaluation at the JVET meeting there | P✓ |
| Mar 2027 | LOC, the streaming format and Privacy Pass authentication to IESG (WG milestone) | P✓ |
| 19–23 Apr 2027 | MPEG 158, Geneva | Part 6 CD target per mpeg-ai-part6-mapping.md (tree). Dates P✓ |
| 15 Aug 2027 | EU data-centre label generated from this date (C(2026) 3472 Art. 3) | P✓ (§5.2) |
| before 15 Oct 2026 | Gaussian splat coding call for content: test material wanted for MPEG 156 (2026-09-30 addition, WG 5 N 422) | P✓ |
| 2027 | Gaussian Splat Coding codec selection | R ⚠ |
| 31 Dec 2028 | EU review: ICT-equipment energy indicators; (partial) certification or auditing of reported data (C(2026) 3472 Art. 6) | P✓ (§5.2) |
| end of 2029 | beyond-VVC first version targeted | P✓ |
| Oct 2029 | Gaussian Splat Coding standard targeted | R ⚠ |
| 2030 | Brazil TV 3.0 in 15 capitals | R ⚠ |
10. What would falsify this
Each item names an observation that would invalidate a specific conclusion above, so the record can be checked rather than believed. Every "none found" conclusion is also exposed to the unreached areas in §1.
-
F1. "No standard or product binds measured energy to a media outcome in a way a third party can verify" (§5.1). Falsified if any of the following signs a measured figure bound to a reproducible output that a party who was not present can check:
- the 23001-11 4th edition at DIS or later (the CD text was searched and does not, §6.1);
- an MPEG-AI Part 6 working draft;
- a GREEN WG document. The current revisions of the four WG drafts were checked and do not (§6.1); re-check at each revision;
- a revision of 3GPP TR 26.942;
- a DVB CM-EE output.
If F1 fires through 23001-11, Part 6 or a GREEN WG document, the 2030 falsifier #1 fires with it.
-
F2. "No jurisdiction mandates per-stream, per-view or per-decode energy" (§5.2). Falsified by such a rule in any jurisdiction, and Nordic and Dutch sources were not reached. It is also falsified if the ESPR displays revision or the EU 2028 review adds per-stream reporting.
-
F3. "No WAI receipt lets a verifier tell a platform-relayed counter from an independently rooted instrument" (G4, G6). This holds on
main, for all four WAI receipt forms: the energy binding and the video receipt put both kinds of source underHwShunt, the JWP receipt carries no class, and the OER receipt'smeasuredgrade covers "an instrument, a datasheet, or a published measurement" while itsprovenance.deviceandenergy.methodmembers are free text. In the tree at link 10 (link 08, PR #109),OnChipCounterandCalibratedInstrumentare signed classes that make exactly this distinction, so F3 no longer describes that tree for any receipt that carries one of them, including anenergyclaim for a JWP object (link 10, PR #112). It still describes a JWP group total, an OER/2 receipt, and any figure in an optional-label family sealed without its label. The distinction is the producer's signed declaration: a verifier gates on the class and its evidence, and can check a calibration reference against its certificate, but the class is not an attestation by the instrument (energy-measurement §2.5). Across the monorepo the distinction also exists insandbox-tee'sCounterClass::is_independently_rooted()andAttestTrust, withefficiency/1'senergy_attestation. The family's receipt-level ladder in JCR-1 §2.3 does not make it (§5.1), and the family does not agree on where IOReport sits in it (§5.3). -
F4. "The codec registry lacks AV2, VVC, HEVC, LCEVC, MPEG-H, AVS3 and Audio Vivid" (G5). This holds on
main: no capability string inwai-rs/src/codecs/*.rsadmits these payloads, and the glossary survey entries register none. At link 04 (PR #105) the registry registers all of them, so F4 does not describe the tree at link 10. -
F5. "Parameter transmission reaches a reproducible entropy stage but not a reproducible reconstruction" (§4, G7). Falsified if arXiv 2606.28027's reconstructions turn out bit-identical across the tested NPUs. The boundary
determinism-tiers.md§2 draws betweenentropy-consistencyanddecode-equivalencewould then be misplaced for that approach. arXiv 2608.00483 does not bear on this: it synchronises the entropy stage by mixed precision and claims no identical reconstruction. At link 10 (link 02, PR #103) the consequence forreplicateis settled either way: a decode that is not integer / fixed-point end to end does not back it, whatever its reconstructions do on the devices tested. -
F6. "SyfAI's AI update-framework thread covers the properties WAI's
Priorand determinism tiers specify" (§2.1, G3). This rests on a secondary report. It is falsified or narrowed if either of the following scopes bit exactness out, or defines it as reference-software reproducibility only: the MPEG 155 Exploration 52 document, or the joint WG 3 / WG 7 output on the update framework. The part page lists the MPEG 155 document without a date, and it was not read. This is the most load-bearing unverified item in this record, and the one to read first before MPEG 156. -
F7. "No neural codec in production at large platforms" and "no top consumer platform delivers over MoQ" (§4). Falsified by a disclosed deployment. The hardware and NPU area, where the first would most likely appear, was not reached.
-
F8. "VVC ships at scale only under national mandate" (§4). Falsified by a disclosed large non-mandated VVC deployment. The supporting survey is vendor-run with no stated sample size, so this conclusion is weak to begin with.
-
F9. "DVB has written energy requirements and no CM-EE output was found" (§2.4, §5.1). Falsified if CM-EE has published output since the DVB chair's September 2025 article, which is a year old and describes "a working group on energy efficiency" without naming CM-EE. That would also change the DVB item of
energy-exposure-mapping.md§8. -
F10. Mis-staging. The 2030 landscape named mis-staging and misattribution among the dominant failure modes of its refuted candidates (its §9, item 7). For that reason every P row but one was re-read before publication (§1.1). Many R-graded stage claims (§2) remain unverified. Re-verify stage and issuing body before quoting any row outside the tree, and re-check the tree before quoting a §5.3, §6 or §7 row: the chain's pull requests may change before they merge.
-
F11. "JPEG AI's normative conformance point is the entropy-decoder output; reconstruction may diverge" (§2.2, §6). JPEG AI's core experiments on bit-exact reconstruction are continuing (P✓). If a JPEG AI edition or amendment adds a bit-exact reconstruction conformance point, this finding is false for that edition onward. In the tree at link 10, determinism-tiers §4 and SPEC §7 would then no longer describe JPEG AI's own guarantee as
entropy-consistency, and theNeuralEntropyExactclass ofwai.image.jpegai, which SPEC §7 calls a conservative choice pending a reading of Part 4, would need revisiting. Check at each JPEG meeting.