open-standards/wai/research/2030-transport-landscape.md

# 2030 Media Transport, Encoding, Production and Delivery — landscape and ingest posture

> **Provenance note.** This is a landscape survey, not a normative extension. It
> was produced by a global sweep across standards bodies (ISO/IEC JTC 1/SC 29 WG
> 2/3/4/5, ITU-T SG21/JVET, IETF AVTCORE / MOQ / SCITT / COSE / GREEN, AMWA,
> C2PA, Fórum SBTVD/ABNT, Komdigi, WorldDAB), including non-English primary
> sources, then passed through two adversarial verification lenses: a **reality**
> lens (does the designation exist, at the stage and with the content claimed,
> from the body claimed) and a **bearing** lens (does it give WAI something to
> *register*, to *bind*, or to *specify against* — and is it already covered in
> the tree under another name).
>
> Seventy-one candidates reached verification. **Nineteen survived both lenses**
> and are recorded here. **Fifty-two were refuted** and are deliberately absent —
> see *What did not survive* below for the failure modes, so they are not
> re-litigated.
>
> **Confidence limits.** Stages move; several items below are drafts or
> committee documents that can change or die. Where a fact could not be
> independently confirmed it is marked **⚠ unverified** inline and must be
> checked against the issuing body's catalogue before any of this text is quoted
> outward.
>
> **Verification pass, September 2026.** Seven flagged designations were checked
> against primary catalogues after drafting. Five resolved as stated (ISO/IEC
> 23001-19 and its MPEG 153 milestone; ISO/IEC 23888-6 and the 13 January 2027
> CfP deadline; ITU-T H.274 V4 and the DSC triplet; ISO/IEC 23888-4 at CD; the
> 23888 series structure). One was **corrected** — there is no confirmable
> MPEG-AI *Part 7*; the conformance/reference-software companion has no visible
> number. One was **narrowed** — H.274's in-bitstream signatures survive remux
> but not transcode, since they are computed over NAL units. Two flags remain
> open by design and are listed in §9.5. Everything not marked ⚠ has been seen
> in a primary or issuing-body source. Two paywalled national standards (ABNT NBR 25608:2025, ARIB
> STD-B60) were read only through their public companions; clause-level claims
> about them are flagged. Nothing here is a conformance statement about WAI, and
> nothing here has been implemented.
>
> Posture throughout: **ingest, do not compete.** Where a body has already
> specified something, WAI names it, registers a capability string for it, or
> profiles it — and does not restate it. Where WAI's own text has a hole, the
> hole is stated plainly.
>
> **Later revision: ISO/IEC 23001-11.** This survey read 23001-11's
> decoding-operation reduction as a hint on which a decoder decodes worse. That
> reading is superseded wherever it appears: §1.2 (degradation under a power-saving
> hint), §2 (a hint that degrades decode), §3.2 Instance two, §5.3(d) and (e) (an
> operation reduction the sender requested, as a departure from byte-exact
> reconstruction), §8 row 1 and §9 item 2. In the 4th-edition CD text (WG 3
> N1864), a decoding operation reduction request goes from the receiving device
> to the remote encoder, which sends a less complex bitstream. Where that text
> allows "larger energy savings, but at the expense of some QoE degradation", the
> loss comes from what is sent (a payload altered before it is sent, or a
> lower-quality representation chosen) or from processing of the decoded
> pictures, not from a decoder decoding its payload worse. Its energy
> quantities are expected or potential savings, not energy that was spent.
> `determinism-tiers.md` §2 sorts that text's metadata sets by what they change
> and states the rules over them; the passages above are left as first written.
> The 2015 edition was not read, so §1.2's "since 2015" is unchecked.

---

## 1. What 2030 looks like — the thesis the evidence supports

Five movements, each with more than one independent instance.

**1.1 The wire carries a process, and this is now ordinary.** WAI's founding bet
— that a sink can be sent instructions and reconstruct the media itself — has
been standardised, ratified, and shipped by other bodies at three different
layers. Above the codec: ISO/IEC 23001-16:2021 defines a *track that carries a
derivation graph* the receiver evaluates. Inside the codec: ITU-T H.274's
neural-network post-filter SEI carries a filter — by URI or as an in-band
network payload — and, in the 01/2026 edition, an in-band **prompt** and seed fed
into that network's input tensor. Beside the pixels: MPEG-AI Part 2 codes video
*and descriptors* jointly, and Part 4 codes no pixels at all, shipping an
intermediate feature tensor from the middle of a network. Instruction-carriage
is specified at each of those layers. What WAI specifies is the *contract over
the instruction*.

**1.2 "Correct" is forking into several incompatible contracts.** Byte
comparability is becoming one fidelity target among four. Task accuracy is the
target in MPEG-AI Parts 2 and 4. Statistical indistinguishability with respect to
a downstream model's own variance is a target a vendor has already put in
market. Deliberate degradation under a power-saving hint is a target ISO/IEC
23001-11 has carried since 2015. Each is a fidelity claim no hash can express,
and each arrives at a sink through the same pipe as a byte-exact one.

**1.3 Energy is becoming a two-party protocol, not a measurement.** The field's
existing energy work is *predictive and prescriptive*: encoder-side complexity
metrics that tell a decoder what to spend (ISO/IEC 23001-11), a receiver request
and an encoder commitment (draft-ietf-avtcore-rtcp-green-metadata), and a
device-scoped power/energy data model with a graded accuracy taxonomy
(draft-ietf-green-power-and-energy-yang). None of it carries a measured
per-object figure bound to a reproducible output under a signature. That is
precisely WAI's lane — and it is now flanked on both sides, which changes the
work from invention to reconciliation.

**1.4 Provenance is moving below the container and after distribution.** ITU-T
H.274 (01/2026) signs the coded video inside the elementary stream, where the
signature survives a remux. C2PA's soft-binding path recovers a manifest from
the samples after the metadata has been stripped, via a registry of registered
algorithms and a resolution endpoint. IETF SCITT registers a signed statement in
a third-party append-only log so a receipt is checkable by someone who was never
on the delivery path. A hard, container-scoped, publisher-signed binding — WAI's
— is one binding class among several, and the others exist because normal
distribution destroys the first.

**1.5 The receipt is generalising into an envelope with typed classes.** A
national broadcast standard now defines a *privacy receipt* riding beside the
service signalling (ABNT NBR 25608:2025 §8.8). COSE defines a *transparency
receipt* as a registered structure (RFC 9942). WAI defines a delivery-plus-energy
receipt. Three bodies, three receipt classes, one shape. The design consequence
is that a receipt should be an envelope with a typed class and parent linkage,
not one hard-coded field set.

**The one-sentence consequence.** WAI's remaining defensible ground is not that
the wire carries instructions, and not that a receipt exists — both are now
common property. It is the *conjunction*: a pinned reconstruction with a declared
determinism tier, a measured energy figure with a declared acquisition class,
and a signature binding the two to the same reproducible output. Every item
below is judged by whether it strengthens, weakens, or contradicts that
conjunction.

---

## 2. Bets this evidence VALIDATES

**Transport-agnosticism was the right refusal.** ISO/IEC 23001-19 carries green
metadata in ISOBMFF and delivers it over MPEG-DASH — and the reason
draft-ietf-avtcore-rtcp-green-metadata exists at all is that Part 19 does *not*
cover RTP. The same semantics needed two carriage specifications from two bodies
and will need more. A standard that defined its own carriage would have had to
write the third. WAI rides one and registers the semantics; that scales, and the
evidence for it is a carriage fragmentation now visible in a single semantic
family.

**Registration is not a bundled decoder — and other bodies now run registries the
same way.** The C2PA soft-binding algorithm list is a public, schema-validated,
machine-readable registry of reverse-DNS algorithm identifiers carrying media
types and optional resolution endpoints, with no decoder attached. AMWA's
Capabilities Parameter Register is a public register of named parameters against
which constraint sets are expressed, rather than a bespoke schema per vendor.
Both are the pattern WAI's §5 registry already uses. This is corroboration, and
it is also an ingest surface: both registries are things WAI can point *at*
rather than re-author.

**Measured, provenance-classed, per-object energy is genuinely unoccupied — and
the field around it is not empty.** This must be stated carefully, because the
neighbourhood has incumbents (§5). ISO/IEC 23001-11 has carried in-band energy
metadata since 2015. C2PA 2.4 has an `c2pa.environmental-sustainability`
assertion, which WAI's `energy-binding` extension already companions. IETF GREEN
has an adopted WG draft with a *finer* accuracy taxonomy than WAI's three-class
enum. What none of them has is a figure that is (a) measured rather than
declared, (b) labelled with how it was acquired, (c) bound to a reproducible
output whose hash a third party can recompute, and (d) signed. The conjunction
is the position; each element separately is contested.

**Determinism tiers are the vocabulary the field is missing.** Three separate
items in this slice collide with WAI's tier vocabulary from three directions —
a post-decode filter that changes output pixels, a power-saving hint that
deliberately degrades decode, and a task-accuracy fidelity target that is not
byte-comparable at all. A body that had no tier vocabulary would have no way to
say what breaks. WAI has one, and its existence is what makes §3.2 and §3.3
statable as *bugs* rather than as vague unease.

**The instruction bet is directionally right.** MPEG-AI Part 4 ships a
half-finished computation. H.274 V4 ships a prompt inside a video elementary
stream. ISO/IEC 23001-16 ships an operation graph. Three bodies independently
concluded the wire should carry something other than samples.

---

## 3. Bets this evidence CHALLENGES

This section is the point of the document. Each entry names the WAI text that is
wrong, thin, or silent.

### 3.1 "The wire carries instructions" is not novel, and the claim must be narrowed

**ISO/IEC 23001-16:2021 — Derived Visual Tracks in the ISO Base Media File
Format** (MPEG-B Part 16; ISO/IEC JTC 1/SC 29, maintained by WG 3; 1st edition,
published 2021-11-19; **stage: Published**, no amendment, no 2nd edition — further
visual derivations remained Technologies-under-Consideration through MPEG 147,
July 2024).

A derived visual track (`dtrk` sample entry) carries derived samples, each an
ordered list of derivation operations over an ordered list of inputs — input
tracks, track groups, file-level image items, or the output of a preceding
operation, so operations chain and an input may itself be a derived track. The
first edition's normative base set is ten operations, each identified by a 32-bit
four-character code: Identity, sRGB Fill, Dissolve, Crop, Rotation, Mirror,
Scaling, ROI selection, Grid composition, Overlay composition.

**What this refutes:** any WAI claim that carrying a process rather than a
processed result is new. It was ratified in 2021, inside the container the whole
industry already ships.

**What it does not refute:** the compression bet. A derived visual track still
carries its input tracks' samples in the same file — it avoids re-encoding a
derived rendition; it does not replace pixels with instructions the way a sealed
op log does.

**The honest form of the claim, for use everywhere in the tree:** *a track that
carries a process the receiver evaluates is not novel — MPEG-B Part 16 ratified
it in 2021. The parts of Part 16 read here (clauses 1–4, 5.1 and 5.2, and the
table of contents) state neither a byte-exact determinism contract per operation
nor a signed receipt binding the executed graph to measured joules; clause 5.3,
clauses 6 and 7, clause 8, which defines each operation, and Annex A were not
read.* Note that the base set includes operations that
compute new sample values (Dissolve, Scaling), so the tier work is real, not
decorative.

> **Correction.** An earlier revision of this section said those operations carry
> "no bit-exactness requirement". That was not verified. Only the published
> sample of the standard was read (clauses 1–4, 5.1 and 5.2, and the table of
> contents; the sample ends at 5.2), and those parts say nothing about
> bit-exactness either way. Clause 5.3, clauses 6 and 7, clause 8, which defines
> each operation, and Annex A were not read, so whether they fix the operations'
> arithmetic — and so whether Part 16 leaves byte-exactness unspecified at all —
> is open.
> `extensions/derived-tracks.md` does not rely on either answer for its three
> universal conditions, which every tier needs and the executing sink checks. It
> does rely on the operations' titles, not on clause 8, for the geometric
> conditions it lists per operation and for which operations read a visual
> input, and reading clause 8 may show one of those lists to be incomplete.

*Caveat for any outward copy:* ISOBMFF is universally shipped, but derived visual
tracks have negligible deployed player support. The collision is
conceptual/standards-level, not installed-base.

*Scope note:* WAI currently declares presentation and compositing sink-supplied
(render is out of scope in `linear-film` and `interactive-worlds`; the float
rasterizer is presentation for splats). Ingesting the derivation operation set
means **tiering and receipting** the contract — not adopting compositing as
WAI's job.

### 3.2 `determinism-tiers.md` has a live conformance hole, twice over

This is the highest-value finding in the document, and it is a defect in WAI's
own text that exists whether or not anything external is ingested.

> **Later revision.** This section quotes `determinism-tiers.md` §3 as it stood
> when the survey was written. §3 and SPEC §7 have since been revised: `replicate`
> promises `decode-equivalence`, and `entropy-consistency` does not back it.

**Instance one — post-decode neural filters.** ITU-T H.274's `nnpfc` /
`nnpfa` SEI messages activate a neural post-filter *after* a conformant decode,
changing output pixels. `determinism-tiers.md` §3 says a capability's
registration states its tier, and that a `replicate` envelope must pin a prior
meeting at least `entropy-consistency` — but it says nothing about processing
activated after the decode. Consequently a capability over any payload that
permits VSEI messages cannot honestly claim `decode-equivalence`, and an envelope
with `intent = replicate` over such a payload is unsound. The fix: state that the
tier is a property of *decode plus any activated post-loop filter*, and that a
sink must either refuse or strip the activation, or drop the declared tier.

**Instance two — power-saving hints.** ISO/IEC 23001-11's decoding-operation
reduction metadata asks a decoder to spend fewer joules by decoding *worse*. An
object honouring a power-saving hint cannot simultaneously claim byte-exact
reconstruction. The extension must say so. This is the same hole from the other
side: a deliberate departure from the pinned reconstruction, with no tier
consequence written down.

> **Later revision.** Instance two misdescribes ISO/IEC 23001-11. In its
> 4th-edition CD text (WG 3 N1864), a decoding operation reduction request goes to
> the remote encoder, which sends a less complex bitstream; the request does not
> ask the decoder to decode worse. Of the metadata sets that text's Introduction
> names, those that change the decoded medium are attenuation-map
> post-processing, display adaptation and cross-segment decoding.
> `determinism-tiers.md` §2 now describes each mechanism and states its rules over
> them.

Both instances share a root cause: the tiers are defined over *the decode*, as if
the decode were the whole pipeline between bytes and output. It is not.

### 3.3 Byte-comparability is not the only fidelity contract, and WAI cannot state the others

Three independent arrivals.

**MPEG-AI Part 2 — Video coding for machines (VCM).** ISO/IEC JTC 1/SC 29/WG 4;
**stage: DIS**, promoted at MPEG 153 (online, 19–23 January 2026), FDIS planned
late 2026. Bitstream syntax, semantics and decoding that reconstruct video *and*
descriptors extracted from that video, jointly optimised for bitrate and for
machine-task performance after decoding. Companions: ISO/IEC TR 23888-3,
"Optimization of encoders and receiving systems for machine analysis of coded
video content" — a **Technical Report** (informative guidance covering both
encoder and receiving system; CDTR stage, no recent activity), and a
conformance-and-reference-software project that is registered but **early-stage,
with no published text and no released suite**.

*Verification (Sept 2026).* The ISO/IEC 23888 series resolves as: **Part 1**
TR 23888-1:2026 (AI for multimedia vision, published); **Part 2** Video coding
for machines — **DIS, enquiry phase**; **Part 3** *Optimization of encoders and
receiving systems for machine analysis of coded video content* — **CDTR**;
**Part 4** Feature coding for machines — **CD**; **Part 5** AI-based point cloud
coding; **Part 6** Media authenticity and provenance indication (PWI, §6.5).
Part 3 is therefore **confirmed** as the encoder/receiving-system companion.
**Part 7 is not confirmed** — no conformance-and-reference-software part appears
in the catalogue listing, so the number should not be cited; refer to it as an
unnumbered registered project until an identifier is seen. This does not change
the argument, which rests on Part 2's fidelity contract, not on its companions.

**MPEG-AI Part 4 — Feature coding for machines (FCM).** ISO/IEC JTC 1/SC 29/WG 4;
**stage: Edition 1 under development ("ongoing")**, with common test and training
conditions reissued every meeting from MPEG 144 (January 2024) through MPEG 155
(August 2026) and no published CD/DIS/FDIS milestone on mpeg.org — so any date is
an estimate, not a schedule.

*Verification (Sept 2026).* The number **23888-4** is **confirmed** against the
ISO catalogue — *ISO/IEC CD 23888-4, Artificial intelligence for multimedia —
Part 4: Feature coding for machines* — and the catalogue puts it at **CD**, which
is one milestone further than mpeg.org's silence implied. It codes intermediate feature tensors
taken from inside a machine-vision network: the origin runs the first N layers,
ships the tensor, the sink runs the remainder. No pixels are reconstructed at any
point.

**Vendor-defined "ML-Safe" compression.** Origin: [name removed 2026-09-30]; **stage:
vendor framing, no standards body, no designation** (blog post, 29 July 2026,
scoped in the source to autonomous-vehicle camera and synthetic footage).
Compression is called ML-Safe when the change it induces in a downstream model's
behaviour is statistically indistinguishable from the variance that model
already tolerates. What is *deployed* is the underlying content-adaptive rate
control; what is *proposed* is the fidelity framing — the source itself states
the industry "lacks a shared framework."

**What all three do to WAI.** `determinism-tiers.md` admits only
byte-comparable tiers, and `ReplicateClass::Behavioral` is a disclaimer rather
than a criterion. "Task-equivalent but not bit-equal" is unstateable in WAI
today. A whole ratified class of media (VCM) will arrive with a conformance
notion WAI cannot express, and a third object class (FCM's half-finished
computation) with a tier question WAI's vocabulary has never been put to.

**Placement matters.** Do **not** add a task-fidelity tier as a third peer
bullet inside `determinism-tiers.md`. The two existing tiers are
*reproducibility* tiers, checkable by the sink from the bytes alone; a task
contract is a *fidelity* tier that is not. Listing them together blurs a
distinction that file currently keeps clean. Land it as a sibling extension
(`task-fidelity.md`) referenced from `determinism-tiers.md` §4's spectrum
framing, and model the claim on `energy-measurement.md`'s provenance grading
rather than on the equivalence criteria. The claim shape is cheap: *ML-Safe with
respect to model-hash M, test T, tolerance τ, observed δ* — a
provenance-graded claim, no new receipt mechanism. WAI's receipt machinery
already signs arbitrary claims; the precise gap is that this claim is not
sink-checkable from the bytes, which WAI already handles elsewhere by grading
provenance.

**FCM's second, sharper bite: the split budget.** Sink-side joules are not new
to WAI — `energy-measurement.md` already meters decode energy, and every neural
capability burns sink joules today. What is new is that FCM makes the origin/sink
*work partition* a negotiated wire parameter through the cut point N.
`jwp-receipts.md` defines `joules_micro` as one `u64` for "producing this object"
by one producer, and §4 forbids conflating relay-scoped telemetry with
publisher-issued figures. A cut-point-aware receipt needs joules before the cut,
joules attributable after it, and a network-identity hash making the halves
provably compose — which pulls in Neural Network Coding (§6.4) as a dependency.

### 3.4 A receipt does not travel with its object, and WAI has one binding class

**C2PA Soft Binding Resolution API + the soft-binding algorithm list.** C2PA 2.4
Technical Specification (Decoupled profile) defines the web service:
`/matches/byBinding` (GET and POST), `/matches/byContent`, optional
`/matches/byReference`, plus store, fetch and service routes for depositing
manifests and bindings and listing supported algorithms. It is backed by a
CC-BY-4.0, schema-validated public JSON registry maintained by the C2PA
Technical Working Group, whose entries carry `alg`, `type`
(`watermark`|`fingerprint`), decoded/encoded media types, `entryMetadata.dateEntered`,
and optional `softBindingResolutionApis` endpoints, with reverse-DNS-style
identifiers. *Cite the registry by shape, not by entry count — it is actively
growing.*

**The premise, stated precisely.** The loose version ("a WAI receipt is silently
voided by the first CDN transcode") overstates it. Reconstruct-class objects have
no transcode hop by construction, `provenance.md`'s step chain already models a
transcode as a lineage step when the transcoder participates, and WAI does not
fail silently — it hard-rejects. The defensible claim is narrower and stronger:
**a WAI receipt is loudly voided by any non-participating re-encode, and there is
no recovery path.** WAI has exactly one binding class (BLAKE3 over the envelope)
and no notion of a receipt repository.

**The energy dimension, which is the part a generic provenance discussion
misses.** A soft-binding-recovered receipt attests the *ancestor's* measured
joules. If the object was transcoded en route, the transcode's energy is
unaccounted and the recovered receipt understates delivered energy. Any WAI
ingest **must** state that such a receipt attests the ancestor and not the object
in hand, or it breaks the "never probably fine" rule.

**Ingest scope.** The Decoupled profile is an HTTP service, and WAI defines no
transport and no service. The ingestible part is the **second binding class**
plus the algorithm-identifier and resolution-endpoint fields, referenced the way
MoQ is referenced — not the service.

### 3.5 The acquisition-class enum is private, and an adopted WG draft already has a finer one

**IETF GREEN WG** (Getting Ready for Energy-Efficient Networking, OPS area).
Adopted WG drafts as of mid-2026: `draft-ietf-green-framework-02`,
`draft-ietf-green-power-and-energy-yang-03` (a YANG data model for instantaneous
watts, nameplate power, power factor and cumulative watt-hours, hierarchical to
sub-components), `draft-ietf-green-terminology-02`,
`draft-ietf-green-use-cases-02`. Two individual drafts:
`draft-madpr-green-provenance-00` (2026-07-05), which augments the YANG module
with a COSE signature-verification outcome, signing-key identity and key
ownership; and `draft-petra-green-api-04` (2026-07-06), a **separate**
path-level Energy Traffic Ratio query API, not an augmentation of the module.

**The collision is not contingent on the provenance draft landing.** The
already-adopted `-03` WG draft defines an extensible `data-source-accuracy`
identity hierarchy: `accuracy-unknown`, `accuracy-unavailable`,
`accuracy-like-parent`, `accuracy-estimated` (`-static` = manufacturer datasheet,
`-historic` = prior measurements, `-learned` = ML prediction), and
`accuracy-measured` graded Bronze/Silver/Gold/Red/ones at ±30% / ±10% / ±5% /
±2% / exact. That is already a finer-grained superset of WAI's
`HwShunt`/`ModelBased`/`Estimator` enum, at WG-adopted stage, today, and it is
explicitly designed for extension by other modules.

**Two things this does not mean.** It does not mean WAI is superseded: GREEN is
Energy-Object/device-scoped (the power draw of network elements) while WAI's
`joules_micro` is per-object *work* energy — complementary, not substitutable.
And it does not expose a relay gap: `jwp-receipts.md` §4.2/§4.3 already disclaim
network-element energy, requiring relay telemetry to stay local and never be
conflated with publisher receipts, so the path-level API is an informative
citation for a relay's own figure, not a hole WAI must close.

**The uncomfortable part.** GREEN's identities are *tolerance bands*; WAI's are
*source-type labels*. Deriving WAI's three classes from `data-source-accuracy`
requires WAI to declare measurement tolerances it currently does not have. That
is real work, and it is the price of an external calibration referent for
`energy-measurement.md` §4's attribution-quality ratio.

### 3.6 No transparency log, no key discovery

**IETF SCITT / COSE.** RFC 9943, "An Architecture for Trustworthy and
Transparent Digital Supply Chains" (SCITT = Supply Chain Integrity, Transparency,
and Trust) and RFC 9942, "CBOR Object Signing and Encryption (COSE) Receipts"
(COSE WG; formerly `draft-ietf-cose-merkle-tree-proofs`), both **Standards
Track, published June 2026**; RFC 9995, "COSE Hash Envelope" (**July 2026**;
labels 258 `payload_hash_alg`, 259 `payload_preimage_content_type`, 260
`payload_location`). `draft-ietf-scitt-scrapi-11` (the HTTP registration and
resolution API) is **approved and in the RFC Editor queue**;
`draft-ietf-scitt-receipts-ccf-profile-04` (a concrete log profile) was **in WG
Last Call** and must not be presented as ratified. RFC 9943's term for the
checking party is *Relying Party*.

**What WAI actually lacks.** Not verifiability — an Ed25519 signature over a
group Merkle root is checkable by anyone holding the publisher key. The three
missing properties are **non-equivocation / split-view detection**, **independent
timestamping**, and **detectability of a suppressed receipt**.

**The gap is interop encoding, not capability.** The family already owns both
halves: an RFC-6962-style transparency log with consistency proofs exists, and
JCR-1 (deterministic CBOR + COSE_Sign1, RFC 9052) is already the canonical
receipt envelope across sibling standards. What nothing in the family has is a
**standardized external encoding** an outside auditor's off-the-shelf tooling can
verify with no bespoke verifier. The move is therefore: bring WAI's receipts onto
JCR-1 like its siblings, then add an RFC 9942 / RFC 9995 emission profile and
SCRAPI registration on top.

**Do not swap the delivery receipt for SCITT.** SCITT registers per-artifact
Signed Statements over an HTTP API; WAI emits per-object receipts at media-group
cadence. The correct profile registers the **group** receipt or periodic
checkpoints into a Transparency Service, leaving the per-object receipt where it
is.

**Prerequisite to check before asserting anything:** RFC 9995's
`payload_hash_alg` takes a COSE Algorithms registry identifier, and BLAKE3 does
not appear to be registered there. "BLAKE3 as the hash-envelope algorithm" is a
registration action or a dual-hash carry, not a free choice.

**Key discovery is worse than thin — it is absent.** ITU-T H.274's digitally
signed content SEI locates a public key either by a direct certificate URI or by
an ISO/IEC 21617-1 (JPEG Trust) trust-record URI. WAI cites 21617-1 in
`reconstruction-binding.md` §3, but has no key-discovery or trust-anchor
mechanism at all — no certificate, x509 or trust-record text anywhere in
SPEC.md. Every WAI signature today presumes the verifier already holds the key.

### 3.7 There is no authority class, and pre-emption is the highest-authority instruction

WAI signs objects (Ed25519, C2PA carriage) but defines no **authority class**: no
statement of which signing keys may assert which kinds of instruction. That is
tolerable while every instruction is "reconstruct this media." It stops being
tolerable the moment an object can seize the render surface — which is a
deployed, regulated instruction class today (§7.1). A standard whose core bet is
that the wire carries instructions has to answer who may sign the strongest one.

---

## 4. Transport — what WAI must bind to

WAI defines no transport by charter, and this survey validates that refusal
(§2). "Bind to" below means *name field semantics and specify a rule against
them* — never *adopt a carriage specification*.

### 4.1 Relay path as a claim, not a fact

**`draft-altanai-moq-relay-geocode-02` — "Geographic Location for Media over
QUIC Relays"** (Altanai Bisht, Cisco Meraki; Tim Evens, Cisco). **Stage:
individual Internet-Draft, "I-D Exists" — related to the MOQ WG but not adopted
by it**; v02 published 2026-08-04, expires 2027-02-05.

It proposes five options for conveying relay location and **recommends Option 1**:
per-object path tracing via MOQT extension headers (MoQTransport §10.2.1.2),
where each relay MAY append an entry carrying a `device` identifier and a
`direction` (ingress/egress), letting a client reconstruct the relay path from
received objects. Location is WGS84 decimal-degree latitude/longitude with
optional altitude, plus optional IATA three-letter codes and country codes. The
other four options (PUBLISH/SUBSCRIBE tracks, catalog metadata, metrics
attributes, well-known URIs) are out of scope for a WAI binding.

**Two limits that change the ingest.** First, the draft defines a **data model,
not a wire format** — it explicitly leaves the reserved namespace, extension
header type and encoding to a companion specification or a future MoQTransport
revision, and appending is `MAY`, so traces are advisory and may be incomplete.
Bind against field semantics, expect the encoding elsewhere. Second, WAI's
BLAKE3 content hash covers the `WAI1` envelope (magic + manifest + payload) and
**not** the MOQT extension headers this draft appends to. Path-trace entries are
therefore unsigned assertions sitting outside everything WAI signs, and a relay
can misstate its coordinates at zero cost.

**Correct ingest.** Bind the path-trace entries into the currently-unspecified
`jwp-receipts.md` §4.3 parallel relay-attestation receipt — signed under a
relay-owned key, chained per hop — and mark the geographic claim at an honest
tier. The sibling ruling is already on the books in the Sandbox standard: a
self-asserted locality is the weakest normative claim in the ladder, an
assertion by the party under audit, checked for presence and nothing else. RTT
and path consistency can **falsify** a coordinate; they can never verify one.

**Do not** take the grid-carbon lookup. It runs against explicit WAI doctrine,
not into a gap: `energy-binding.md` §4 carries a hard MUST NOT on populating a
carbon figure from an energy number times a grid-average factor while presenting
it as measured, and `jwp-receipts.md` §7 states that conversion of joules to
currency, carbon or grid mix is performed by downstream aggregators and is not
normative. A coordinate at most improves the provenance of a downstream
aggregator's input; it does not earn a carbon field in a WAI receipt.

Log this as a **near-term watch**, not a stable surface.

### 4.2 Bearers with no return path, and predicates evaluated at the sink

Generalised from the deployed regional early-warning systems in §7.1. Three
transport-independent seams, none of which requires WAI to define a bearer:

1. **A registered predicate capability** carried in the object and evaluated by
   the **sink** against locally-held state the source never learns, with a
   *predicate-equivalence* determinism contract in the shape of `state-feeds.md`
   §3. The specifiable property is determinism and auditability, **not
   enforcement** — every sink receives the bytes and can lie about its own
   state. The real privacy claim is only that the source learns nothing, which is
   genuinely the dual of source-side session-class targeting in the OTT manifest
   work.
2. **A priority / pre-emption field plus a sink-held trust anchor** naming which
   signing keys may assert it (§3.7).
3. **A detached / store-and-forward receipt profile** for unidirectional bearers,
   reconciled out of band. `jwp-receipts.md` assumes relay-chain linkage
   throughout; no receipt can prove *rendering* over a bearer with no return
   path, so the deliverable is the honest profile, not a proof.

### 4.3 Pre-dispatch capability constraints

**AMWA NMOS BCP-004-01 (Receiver Capabilities) and BCP-004-02 (Sender
Capabilities), both v1.0.0**, with the public **Capabilities Parameter Register**.
Machine-readable constraint sets — ORed sets of enum/min/max constraints over
named parameters (media type, frame rate, colour sampling, bit depth, codec
profile), published in a register rather than a bespoke schema.

**Ingest the constraint-set grammar and the register pattern only**, adopted as a
sink-side precondition on §4 dispatch: *the sink advertises `cap` **and** the
object's declared parameters satisfy the registered constraint set for `cap`*.
This needs no transport — it evaluates the `target` values WAI already carries —
and it makes §7.1 rendition selection evaluable instead of deferring to an
unexpressed deployer policy. Today WAI's dispatch treats support as binary: a
sink either claims a capability or does not, and cannot say "this capability, but
only to 4K60, 10-bit, this profile," so partial support — the normal case — fails
at decode time rather than at selection time.

**Drop the pre-flight negotiation framing (IS-11).** WAI deliberately defines no
transport, registry or controller for it to attach to, and pre-flight
capability-plus-energy-budget binding is already owned by JCP.

**Two honest limits.** NMOS's registers are ST 2110 / broadcast-essence-shaped
and cover only WAI's conventional media capabilities — nothing for the neural,
quantum, world or haptic families, whose register entries WAI must author itself.
And the grammar is thin, close to a JSON-Schema subset; the value is the ratified
precedent and the register discipline, not novel machinery.

### 4.4 The streaming-format slot, and how CMSF proves it is open

MoQ separates **transport** (`draft-ietf-moq-transport`, rev 18, approaching WG
Last Call) *(2026-09-30: the current revision is draft-ietf-moq-transport-21,
published 2026-09-08, a WG Document; the working group's milestone for sending it
to the IESG is 2026-12-31)* from **streaming format** (`draft-ietf-moq-msf`). MOQT moves objects;
MSF says what the objects *mean* — it fragments a bitstream into objects, uses a
**catalog** to declare what a publisher emits, and sets prioritisation.

The catalog's `packaging` field names the format, and MSF's own text fixes its
value set: `loc`, `mediatimeline`, `eventtimeline`, `moqlog`, `moqmetrics`,
`catalog`. There is no central streaming-format registry.

**CMSF shows the set is not closed in practice.** `draft-ietf-moq-cmsf` is a
sibling Internet-Draft that:

- declares `packaging` value **`cmaf`**, stating in §3.5.1 that it *"extends the
  allowed packaging values defined in [MSF]"*;
- inherits MSF wholesale — *"All of the specifications, requirements, and
  terminology defined in [MSF] apply to implementations of this extension"*;
- adds two **track-level** catalog fields (`maxGrpSapStartingType`,
  `maxObjSapStartingType`);
- and registers nothing: **"This document has no IANA actions."**

A sibling draft, no registry action, no permission sought. That is the cheapest
standards path anywhere in this survey, and it is already walked — LOCMAF is a
second instance of the same move.

**What CMSF did not take is the per-object slot.** MSF §12 defines MSF Properties
at **Track** *and* **Object** scope, with an IANA *MSF Property Type values*
registry that today holds essentially one entry (`MSF_COMPRESSION`). CMSF adds
track-level fields only and defines no per-object property.

A per-object property carrying a content commitment and a measured-energy figure
is the shape `jwp-receipts.md` already has. This is the one place in this survey
where WAI's existing artifact fits an existing extension point **without
redesign** — the receipt is already per-object, and the slot is already per-object
and empty.

Two constraints, both per §4.4. First, what would be bound is the **field
semantics and the rule over them**, never MOQT's extension-header byte encoding —
that stays MOQT's. Second, MOQT is pre-Last-Call: a binding written now is
written against a moving target, so the honest form is a draft that tracks the
transport rather than a normative extension that pins it.

*Provenance of this subsection:* added after the sweep, from direct reads of
`draft-ietf-moq-msf` and `draft-ietf-moq-cmsf-00`. The automated survey did not
surface the streaming-format layer at all — it found MoQ only through the
confidentiality binding WAI already has — which is itself worth noting about the
method: a sweep keyed to *what is new* can miss a slot that is old and open.

### 4.5 What must NOT be bound

Stated explicitly so it is not re-argued: ISOBMFF/DASH carriage of green
metadata; the RTCP feedback messages themselves; the C2PA Decoupled HTTP
service; DVB-T2 bearer signalling; the MOQT extension-header byte encoding. Each
is somebody else's layer, and WAI riding a transport rather than defining one is
the property that makes the rest of the ingest cheap.

---

## 5. Delivery telemetry and energy — a contested field, not an empty one

### 5.1 The incumbents

| Designation | Body | Stage | What it carries |
|---|---|---|---|
| ISO/IEC 23001-11 (MPEG-B Part 11, "Green metadata") | SC 29/WG 3 | **3rd ed. 2023 in force**; AMD 1:2024 (EVC), AMD 2:2025 (new display power reduction metadata); **4th ed. at CD** (WG 3 doc N01742) | complexity metrics for decoder DVFS, decoding-operation-reduction metadata, quality metrics parameterising the trade-off, display power-reduction metadata |
| ISO/IEC 23001-19 ("Carriage of green metadata") | SC 29/WG 3 | advanced to publication as an **IS at MPEG 153**; ISO publication pending as of Sept 2026 | storage in ISOBMFF (14496-12), delivery over MPEG-DASH (23009-1) — **DASH, not CMAF**, and **not RTP** |
| `draft-ietf-avtcore-rtcp-green-metadata-16` | IETF AVTCORE | **IESG Evaluation** (AD Followup, one open DISCUSS), intended Proposed Standard, normatively aligned to 23001-11:2023 | TSRR (PT=PSFB, FMT=12): receiver requests a frame rate and picture width/height in luma samples; TSRN (FMT=13): sender notifies what it will actually use, explicitly permitted to differ |
| `draft-ietf-green-power-and-energy-yang-03` | IETF GREEN | **adopted WG draft** | device/sub-component power and energy, with the graded `data-source-accuracy` identity hierarchy (§3.5) |
| `c2pa.environmental-sustainability` | C2PA | **published, 2.4** | `energy_kwh` (per ISO/IEC TR 20226:2025) with optional `measurementMethod` — already companioned by `energy-binding.md` |

*Verification (Sept 2026).* The identifier **23001-19** and the MPEG 153 IS
milestone are **confirmed** against MPEG's own 153rd-meeting record: WG 3
advanced *Carriage of green metadata* to publication as an International
Standard, defining storage in ISOBMFF (14496-12) and delivery with MPEG-DASH
(23009-1). It exists as a dedicated carriage part precisely because carriage had
outgrown the 23001-11 amendment route (cf. 23001-11:2015/Amd 1:2016, *Carriage of
green metadata in an HEVC SEI message*). The ISO catalogue entry was not
reachable directly (iso.org returns 403 to automated fetch), so confirm the
published number at first outward citation. The 4th edition of 23001-11 remains
at WD/CD, **not ratified**; do not present it alongside the carriage part as
though both were in force.

### 5.2 What is actually unoccupied

Green metadata is **predictive and prescriptive** — what the decoder *should*
spend. It carries no measured joules, no acquisition provenance, no signature and
no per-object binding to a reproducible output. It is therefore **not prior art
against `energy-binding.md`**, and any text claiming otherwise should be
corrected: the relationship is complementary — a prospective steering signal
beside a retrospective measured receipt. The same holds for GREEN (device-scoped
power draw, not per-object work energy) and for the RTCP pair (a request and a
commitment, not a result).

The unoccupied square is the conjunction from §1: measured, acquisition-classed,
per-object, bound to a reproducible output, signed.

### 5.3 Four concrete ingests

**(a) A registered companion descriptor for green-metadata semantics.** Same
pattern as `wai.meta.hdr10plus` and `wai.meta.dovi`: name the capability
(complexity metrics, quality recovery, display adaptation), the sink supplies the
decoder, no carriage adopted.

**(b) A request/commit/deliver triple in the receipt.** Take from TSRR/TSRN the
receipt shape WAI lacks: seal *(requested profile, notified profile, delivered
profile)* alongside the measured joules. That converts a recorded figure into a
figure scored against a promise — a commitment/conformance pair neither standard
provides. Do **not** register the RTCP messages; WAI rides MoQ, not RTP.

**(c) A residual binding that makes the predictive claim falsifiable.** When a
declared complexity/operating-point descriptor and a measured energy binding both
cover the same reconstruction, the receipt carries the **residual**. That closes
a loop nobody has closed: the prescription becomes checkable against the
measurement. It is the efficiency/1 pattern — a per-unit signed figure anchored
to a reproducible outcome — applied to decode.

**(d) Degradation-blindness is the reason (b) and (c) are not optional.** A
receipt that records joules spent *without* recording the operation reduction the
sender requested is degradation-blind: a sink can always cut joules by decoding
worse. `energy-measurement.md` §5's recomputable-work-unit rule blocks this at the
byte-exact tier, but not at the weaker tier `determinism-tiers.md` admits
(`entropy-consistency`), and not for the conventional codecs WAI already carries.
This applies the joule-ceiling × fidelity-floor pattern already shipped in the
Mesh standard to media, which makes it a cheap ingest rather than a research bet.

**(e) Derive the acquisition classes from GREEN's identities** and declare the
tolerances that derivation requires (§3.5). And specify the interaction with
`determinism-tiers.md`, since operation reduction is a deliberate departure from
byte-exact reconstruction and must state its tier (§3.2).

---

## 6. Production chain — the gap WAI has barely addressed

WAI's provenance model is a step chain among *participating* parties, with the
identity fixed as a hash over the complete envelope. The production and
distribution world is standardising provenance in three places WAI does not
reach: below the container, after the container is destroyed, and in a
third-party log.

### 6.1 Below the container — signatures in the elementary stream

**ITU-T H.274 (V4, 01/2026), in force 2026-01-13 | ISO/IEC 23002-7 (VSEI)** —
digitally signed content SEI messages **DSCI / DSCS / DSCV**. Issued by ITU-T
SG21 / JVET jointly with ISO/IEC JTC 1/SC 29 WG 5. DSCI declares the hash method
(SHA-1 … SHA-512/256, FIPS 180-4) and locates the public key by certificate URI
or by an ISO/IEC 21617-1 (JPEG Trust) trust-record URI; DSCS/DSCV carry the
signature and verification scope over picture units, with verification substreams
covering non-VCL NAL units under a `dsci_sei_signing_flag`. Carried into the AVC
12th edition (FDIS at MPEG 154). On the ISO side, pair with **23002-7:2024 (3rd
ed.; 4th ed. in preparation)** rather than implying a published twin of V4.

*Verification (Sept 2026).* **ITU-T H.274 (V4) (01/2026) is confirmed to exist
and to carry the DSC triplet**, with DSCV holding the signature plus verification
system and substream IDs, DSCS carrying the matching `dsci_id`, and the design
explicitly resisting removal, insertion and shuffling of chunks in the protected
stream. A GStreamer implementation exists. Two refinements: the mechanism traces
to JVET contribution **JVET-AN1019**, and independent write-ups still describe
DSC as *being incorporated* into VSEI — so treat V4 as the edition that carries
it, not necessarily the edition that invented it. **Critically, survivability is
remux-scoped, not transcode-scoped:** signatures are computed over NAL units, and
a transcode rewrites those. That is not a weakness of the comparison — it is the
boundary between this finding and §3.4: H.274 covers repackaging, soft binding
covers re-encoding, and WAI today has neither.

**Why this matters:** the standards world is drawing the provenance boundary one
layer *below* WAI, where a signature survives repackaging and is verifiable by a
decoder that has never heard of WAI.

**Honest scope.** WAI registers **no** VSEI-family codec — H.265 appears in
SPEC.md only in the royalty-trap rationale favouring royalty-free codecs — so the
ingest is **prospective**, not a live interop problem. It would require first
registering a VSEI-family capability, honestly pool-flagged as WAI already does
for IVAS, G-PCC and V-PCC.

**Correct ingest:** a provenance/determinism extension that verifies DSC SEI at
the elementary-stream level and chains the verdict into the WAI receipt as an
**attested input with a stated precedence rule** (not a replacement), plus the
key-discovery mechanism WAI lacks entirely, borrowed from DSCI's key-location
design.

### 6.2 Below the container — executable payloads in the elementary stream

**Neural-network post-filter SEI (`nnpfc` / `nnpfa`)**, ITU-T H.274 | ISO/IEC
23002-7. **Stage: ratified — entered in version 3 (H.274 (09/2023) | ISO/IEC
23002-7:2024), extended in V4 (01/2026).** H.265 support is by normative
reference and dates to H.265 (07/2024), refined in H.265 (01/2026) — a
reference-in, not a native definition.

`nnpfc` declares a sink-side neural post-filter either by URI or by carrying the
network payload in-band as an ISO/IEC 15938-17 (NNC) bitstream, with declared
input/output formats and a `purpose` field — a small fixed enum (resolution and
chroma upsampling, frame-rate interpolation, quality enhancement/denoising,
colourization), **not** a capability registry. `nnpfa` activates it for a picture
range. V4 adds `nnpfc_inband_prompt_flag` / `nnpfc_prompt` — an in-band text
prompt fed into the network's input tensor, e.g. to generate
spatial-extrapolation content — and `nnpfc_seed`. That is a literal in-band
generative prompt inside a video elementary stream, and it is the strongest
external evidence for §1.1.

**Three corrections to the obvious reading.** (1) In-band weights are **not**
unbound: WAI's per-object BLAKE3 covers the whole opaque payload, so an NNC blob
inside the stream is hash-pinned by construction. The real hole is the
**URI-referenced form** — the payload then carries only a pointer, and the
fetched network is code executed at the sink that no WAI hash covers. (2) The
sharpest hole is determinism-tier soundness, not signing — see §3.2. (3) The
energy angle is the weakest leg: a sink-side meter over the decode already
captures post-filter inference joules; what is missing is *attribution* between
decode and filter, a provenance refinement rather than an absence.

**Correct ingest:** a container policy plus a companion descriptor —
`wai.meta.nnpf` alongside `wai.meta.hdr10plus` / `wai.meta.dovi` — that states the
tier consequence and requires the URI form to be pinned or refused. Not a mandate
to ship a post-filter dispatcher.

### 6.3 After the container — recovery when the binding is destroyed

Covered in §3.4. The deliverables are a second binding class, an
algorithm-identifier field, a resolution-endpoint field, and the
ancestor-attestation rule for energy.

### 6.4 The artifact a `Prior` names has no normative wire form

**MPEG Neural Network Coding — ISO/IEC 15938-17 (MPEG-7 Part 17).** Edition 2
published 2024 (neural-network parameters and their incremental updates; note
incremental/federated update coding landed in **Ed. 2**, so it is not new).
**Stage: Committee Draft of Amendment (CDAM) issued at MPEG 154** (Santa Eulària,
27 April – 1 May 2026); MPEG separately lists an ongoing Edition 3 project with
the same tensor-coding objective, into which the work is expected to be
integrated — so cite it as *"the NNC amendment (CDAM, MPEG 154)"*, not "Ed. 3".
Reference software: specified by a separate part, ISO/IEC 15938-18 (*Conformance
and reference software for compression of neural networks*; 1st ed. 2023, 2nd
ed. 2025), which also carries the conformance bitstreams and the decoder and
bitstream test procedures. NNCodec ([name removed 2026-09-30]) is a separate open
implementation: its README calls it "an efficient implementation of NNC" and
states that 2.0-beta is compliant with 15938-17:2024, and its licence file states
that no patent rights are granted. Describe NNC as the **first** international
standard on neural network compression, not the only one. *(Corrected: an
earlier revision of this note called NNCodec the reference implementation.)*

**NNC is not quantisation-only.** The 2022 edition's public sample defines an NNR
unit as carrying "compressed or uncompressed" network data. Its table of contents
lists decoding methods for payload types `NNR_PT_INT`, `NNR_PT_FLOAT`,
`NNR_PT_RAW_FLOAT` and `NNR_PT_BLOCK` (§7.3.2–7.3.5), and a decoding process for
an integer weight tensor (§7.3.6). NNCodec's source (HEAD, read September 2026)
reads an `NNR_PT_RAW_FLOAT` payload as raw 32-bit floats
(`nnc_core/hls/__init__.py`). Its approximator gives int32 tensors a `skip`
method with `dq_flag` 0, so they are not quantised
(`nnc_core/approximator/integer.py`). Its payload-type enum marks `NNR_PT_INT`
"not yet implemented". So integer and raw-float carriage without quantisation is
already in the published text. On that evidence, the amendment's "lossless
compression" adds compression for values the published text can already carry
exactly, rather than introducing exact carriage. The decoding clauses themselves
(§7.3) and the 2024 edition were not read.

The amendment adds: lossless and mixed lossy+lossless compression in one
bitstream; source-data-type indication for limited-bit-depth models; finer-grained
quantisation configuration; configurable extensions for initialising, ordering
and packing data; extension beyond trained parameters to **general tensorial
data** (split-inference feature maps, federated-learning updates, 3D/4D scene
parameters including Gaussian splats); and **signing and verification of
individual coded data units**.

*Verified (Sept 2026) against a primary source.* MPEG's press release for its
154th meeting (mpeg.org, 4 June 2026), in the section headed "MPEG publishes
Committee Draft of Amendment of Neural Network Coding (NNC)", states the stage and
the features listed above, including: "it adds support for signing and
verification of data units, which allows verifying the authenticity of a set of
neural network parameters, as well as parts of a neural network or its updates."
MPEG's meeting list gives MPEG 154 as Santa Eularia, 2026-04-27 to 2026-05-01.
*(Corrected: an earlier revision of this note said the signing feature could not
be corroborated from public sources. The press release corroborates it.)* The
amendment's text and its WG document number were not seen. So what a data-unit
signature covers, which scheme it uses and how its key is identified are unknown.
The **base standard is confirmed**: ISO/IEC 15938-17 (1st ed. 2022, 2nd ed.
2024), *Compression of neural networks for multimedia content description and
analysis* — DeepCABAC entropy coding, pruning/sparsification/low-rank
preprocessing, incremental-update support, with reference software in
ISO/IEC 15938-18 and a separate open implementation (NNCodec) [name removed 2026-09-30].
The claim that needs no amendment at all is the carriage one: NNC is a ratified
wire format for the artifact a `Prior` names; for a set of several files, WAI pins
its listing (`wai.prior.set`, SPEC §3.1). The signing feature is a second surface. It concerns how
NNC's in-band signatures relate to WAI's digest, which
`extensions/prior-carriage.md` §6 fixes without depending on the amendment's
details.

**What WAI already has, stated correctly.** WAI pins model identity
normatively: SPEC §3.1 defines the pin, carried as `conditioning.prior` in a
single-payload manifest and on each rendition of a multi-rendition one, and
requires a sink to verify it before decoding and to refuse with a named reason.
What WAI does not specify is model carriage: the set a pin names travels outside
the envelope, in a form the pin MAY declare.

**Three concrete surfaces.** (1) Name NNC as the standards-track normative form
for the artifact a `Prior` identifies, so `Prior.sha256` covers a portable
bitstream rather than an ad-hoc directory. Whether a bitstream reconstructs its
network identically at every decoder, and so could carry `decode-equivalence`
rather than only `entropy-consistency`, is decided by the decoding process
(clause 7) and its conformance requirement, not by the amendment. Integer and
raw-float payload types already carry values unquantised in the published text.
*(Corrected: an earlier revision said the amendment's lossless mode would make the
bitstream byte-exact. Exact values are already carriable. Byte-exact
reconstruction at every decoder is the open question, and clause 7 is where it is
settled.)* (2) Register a
capability for the general-tensor payload: split-inference feature maps and 3D/4D
scene tensors are a payload class WAI lacks and which fits the instruction/latent
thesis — and it directly abuts the existing `wai.splat.int_codec`. (3) Reconcile
NNC's data-unit signing with WAI's Ed25519/Merkle receipt chain the way
`reconstruction-binding.md` reconciles C2PA, before the two diverge.

### 6.5 The one square with a deadline

**MPEG-AI Part 6 — "Media authenticity and provenance indication."** Call for
Proposals issued by ISO/IEC JTC 1/SC 29/WG 2 (Technical Requirements) on
technologies owned by WG 3 (MPEG Systems), at **MPEG 155, Geneva, 13–17 July
2026**; CfP document w26712, dated 18 July 2026. **Responses due 13 January
2027**, evaluated at MPEG 157 (January 2027). Scope: system-level media
authentication across the entire lifecycle — authoring, creation, production,
editing, storage, delivery and playback — built on MPEG Systems technologies.
Preceded by five Exploration reports (MPEG 151–155) and a WG 2 requirements
document. **Stage: exploration/requirements; no working draft exists.**

*Verification (Sept 2026).* The part number is **confirmed**: ISO/IEC 23888-6,
*Information technology — Artificial intelligence for multimedia — Part 6: Media
authenticity and provenance indication*, carried as an ISO **PWI** (preliminary
work item) project record. The CfP was approved by **WG 2** at MPEG 155;
responses are input contributions to the **157th meeting, Brisbane, due 13
January 2027**. The published development plan then targets CD/CDAM at MPEG 158,
DIS/DAM at MPEG 159 and **FDIS/FDAM in early 2028** — so a contribution accepted
in January 2027 has roughly a year of drafting influence before the text sets.

**Bearing.** Real and uncovered: WAI's existing C2PA / JPEG Trust ingest is
authoring-side manifest provenance, a different layer from a systems-layer
delivery-and-playback authenticity specification. Two WAI positions absent from
every provenance standard in this survey — a per-object **measured**-energy
binding with a declared acquisition class, and explicit determinism tiers
separating byte-exact reconstruction from approximate re-rendering — belong
exactly there.

**Correct near-term action.** Requirement-mapping and alignment, plus a
membership path. This is a published CfP and requirements package to specify
WAI's extensions *against* — there is no bitstream, no format and no capability
string to register — and submitting an input contribution requires SC 29
national-body membership. Do not plan around an assumed proposal submission. The
downside of silence is symmetric and worse than the cost of alignment: if this
lands as the systems-layer provenance format, WAI becomes an alternative to it
rather than a profile of it.

---

## 7. Regional standards a Western review misses

Both items below are ratified national instruments, both were surfaced only by
non-English search, and both contain a mechanism WAI has no vocabulary for.

### 7.1 Indonesia — sink-evaluated scope predicates and pre-emptive priority objects

**Peraturan Menteri Kominfo No. 3 Tahun 2014**, *"Persyaratan Teknis Sistem
Peringatan Dini Bencana Alam pada Alat dan Perangkat Penerima Televisi Siaran
Digital Berbasis Standar DVB-T2"* — ditetapkan 15 January 2014, diundangkan 21
January 2014. Issuing body: Kementerian Komunikasi dan Informatika (Kominfo;
since October 2024 Kementerian Komunikasi dan Digital, Komdigi). Primary text:
`jdih.komdigi.go.id/produk_hukum/view/id/193`.

**Mechanism.** Alert objects are injected into the DVB-T2 stream at the
multiplexer (agency server → mux → set-top box), fed by the national hazard
agencies (BMKG, BNPB, PVMBG, KLHK, BPBD). The viewer enters a postal code at
channel scan; the **receiver** filters incoming alerts against that
locally-held code, so only sinks inside the affected area render. Rendering
authority is **tiered**: *Waspada* (blue) and *Siaga* (yellow) render as a ~30%
overlay for ~30 s over continuing programming; *Awas* (red) seizes the full
screen with audio. Pre-emption is an attribute of the highest priority class, not
of every alert.

**The pattern is not unique to Indonesia.** The same sink-evaluated-predicate
shape recurs in ISDB-T EWBS and in WorldDAB's Automatic Safety Alert (**ETSI TS
104 090 v1.1.2, September 2024** — location codes plus wake-up and switch).
*Do not* list the Israeli Home Front Command TV alert as an instance: its region
code is composited centrally into the broadcast and the receiver performs no
filtering.

**What WAI has no vocabulary for.** (1) A scope **predicate** evaluated at the
sink against state the source never learns — targeting with no upstream identity,
no profile and no telemetry, which is the privacy-preserving dual of every
addressable-delivery scheme and needs a determinism contract of its own, because
a predicate that evaluates differently on two conformant sinks means the same
object reached different audiences. (2) A **pre-emption** instruction class,
whose authority question WAI has never asked (§3.7). (3) A bearer with **no
return path**, over which no receipt can prove rendering. The three seams and
their honest limits are specified in §4.2.

### 7.2 Brazil — a lawful-basis declaration and a viewer-decision receipt

**ABNT NBR 25608:2025, "TV 3.0 — Codificação de aplicações" (Application
Coding)**, ABNT/CEE-085, published 2025-11-18. §8.8 *Privacy Manager*: §8.8.2
**PRRD** (Privacy Record Request Description), §8.8.3 **privacy record**, §8.8.4
**privacy receipt**. Companion (explicitly **non-normative**, stamped "NO
NORMATIVE VALUE" on every page, and in English): the Fórum SBTVD *TV 3.0
Operational Guidelines — Application Coding*, July 2026. ⚠ Clause-level detail
below is read through the companion; the normative text is paywalled.

**Mechanism.** PRRD is an XML fragment carried in Service Layer Signaling (see
ABNT NBR 25602), following the ATSC A/331 fragment-based signalling model. Per
service it declares one or more `piiProcessing` elements (one per language)
containing `purpose` elements typed with W3C DPV terms and a `purpose@lawfulBasis`
per purpose, with personal-data categories from W3C PD v2.0. Structured records
and receipts follow the ISO/IEC TS 27560:2023 model (a Technical Specification,
"Privacy technologies — Consent record information structure"; the standard
cites it undated). The PRRD schema is namespaced
`tag:sbtvd.org.br,2025:XMLSchemas/TV30/AppSignaling/PRRD/1.0/…` and versioned per
instance by the root `PRRD@schemaVersion` attribute.

**Two precision points that change the reading.** Do **not** call PRRD a
*consent* mechanism: it is deliberately agnostic across lawful bases
(`dpv:Consent`, `dpv:LegitimateInterest`, `dpv:Contract`, `dpv:LegalObligation`,
`dpv:PublicInterest`, `dpv:VitalInterest`,
`dpv:OfficialAuthorityOfController`), each purpose carries its own basis, and
PRRD itself records no viewer choice — it declares the processing context the
later record and receipt are expressed against. And do **not** describe the
receipt as cryptographically signed: no signature, hash or integrity mechanism is
described in the public text, which weakens but does not eliminate the analogy to
WAI's signed delivery receipts.

**Bearing.** This is a ratified national broadcast standard defining a
receipt class WAI does not have — the afferent dual of a delivery receipt,
answering *what may be done with what the sink observed, on what lawful basis,
and here is the record that the viewer decided* — expressed as a signalling
fragment riding beside the manifest, exactly where WAI's own per-object metadata
sits. It is the strongest evidence in this survey for §1.5.

**Correct ingest.** A **typed receipt class** in the `jwp-receipts.md` envelope
(which already has kinds and parent linkage), plus a **companion-rendition
descriptor** for the declaration fragment — the slot HDR10+ metadata already
uses. A companion's capability is companion-only (SPEC §7.1, rule 1), and a
sink applies only one it recognises, so the fragment would need a companion-only
capability registered for it; IAMF is standalone media and rides as a
rendition. Not a new receipt format.

### 7.3 Regional items examined and rejected

Two further regionally-originated candidates were verified and did **not**
survive, and are recorded here only so they are not re-opened: a Chinese
intelligent-media transport standard (no ingestible surface — WAI's registry is a
capability registry with no transport or container class, and an opaque WAI
envelope rides such a bearer today with zero adaptation), and a Japanese
MMT-over-TLV broadcast standard whose load-bearing clause claim proved to be a
committee **proposal** rather than adopted text. Neither is a finding.

---

## 8. Ingest queue, ranked

Ranked by *decision-forcing-ness ÷ cost*, not by importance of the external body.
Items 1–2 are internal defects that need no external dependency at all.

| # | Ingest | Shape of work | External dependency | Why now |
|---|---|---|---|---|
| 1 | **Determinism-tier rule for post-decode processing and power-saving hints** (§3.2) | normative text in `determinism-tiers.md`: the tier is a property of decode **plus** any activated post-loop filter; a sink must refuse/strip or drop the tier; an object honouring an operation-reduction hint MUST NOT claim byte-exact reconstruction | none | a live soundness hole in shipped text; ratified externally on both sides |
| 2 | **`task-fidelity.md` as a sibling extension** + a consumer-type axis in `content-taxonomy.md` (§3.3) | tier name + provenance-graded claim shape *(model-hash M, test T, tolerance τ, observed δ)*; referenced from `determinism-tiers.md` §4; **not** a third peer tier inside it | none | VCM reaches FDIS; the vendor framing exists and admits no shared framework |
| 3 | **Green-metadata companion descriptor + request/commit/deliver + residual binding** (§5.3) | one registered companion capability; three receipt fields; a residual rule | ISO/IEC 23001-11 semantics (published) | closes degradation-blindness; applies joule-ceiling × fidelity-floor to media |
| 4 | **Receipt envelope with typed classes** — delivery, energy, lawful-basis, log-inclusion (§1.5, §7.2) | generalise `jwp-receipts.md` kinds; PRRD, SCITT and soft binding all land in this slot | none (shape only) | three bodies converging on the same artifact |
| 5 | **Second binding class + resolution-endpoint field + ancestor-attestation rule** (§3.4) | fields + a MUST stating a recovered receipt attests the ancestor, not the object in hand | C2PA soft-binding algorithm list (published registry) | today a non-participating re-encode leaves no recovery path |
| 6 | **Key discovery**, plus DSC SEI verdict chaining with a precedence rule (§3.6, §6.1) | a trust-anchor mechanism WAI has none of; borrow DSCI's key-location design (certificate URI or ISO/IEC 21617-1 trust record) | ITU-T H.274 V4 (in force) | every WAI signature presumes the verifier already holds the key |
| 7 | **JCR-1 alignment, then an RFC 9942 / RFC 9995 emission profile + SCRAPI registration** (§3.6) | move receipts onto the family's canonical envelope; emit the group receipt or checkpoints; decide BLAKE3 registration vs dual-hash | RFCs published; SCRAPI in RFC Editor queue; CCF profile in Last Call | non-equivocation, timestamping and suppression-detection are missing today |
| 8 | **Derive acquisition classes from GREEN `data-source-accuracy`**, and declare tolerances (§3.5) | register `HwShunt`/`ModelBased`/`Estimator` as identities derived from the hierarchy; state measurement tolerances | adopted WG draft | the enum is private and coarser than an adopted draft, now |
| 9 | **NNC as the normative artifact form for a `Prior`**; register the general-tensor payload (§6.4) | reference the bitstream; one new capability; reconcile data-unit signing | CDAM stage — track, do not pin | a pin covers a set of files through its listing; NNC would give its networks a coded form |
| 10 | **Sink-evaluated predicate capability + authority class + detached receipt profile** (§4.2, §7.1) | predicate-equivalence contract; priority field + sink-held trust anchor; store-and-forward receipt profile | deployed regional precedent (no dependency) | pre-emption is the highest-authority instruction and WAI names no signer class |
| 11 | **NMOS constraint-set grammar over the capability registry** (§4.3) | a sink-side precondition on §4 dispatch; author register entries for the non-broadcast families | BCP-004-01/-02 v1.0.0 (ratified) | makes §7.1 rendition selection evaluable rather than policy-deferred |
| 12 | **Register the Part 16 derivation operations with a per-operation determinism tier** (§3.1) | capability strings + tiers; do not adopt compositing | ISO/IEC 23001-16:2021 (published) | prevents restating a 2021 ratification as a WAI invention |
| 13 | **MPEG-AI Part 6 requirement mapping + SC 29 membership path** (§6.5) | map WAI's measured-energy binding and determinism tiers onto the CfP requirements | CfP responses due **13 January 2027** | the only square in this survey with a deadline |
| 13b | **MoQ streaming-format binding** — a sibling I-D declaring `packaging: "wai"`, plus a per-object MSF Property carrying the JWP content commitment and measured joules (§4.4) | one draft; inherit MSF; **no IANA action** (CMSF precedent) | `draft-ietf-moq-msf` / `-cmsf`; MOQT pre-Last-Call, so track rather than pin | the per-object property slot is empty, the receipt is already per-object, and the transport is the one [name removed 2026-09-30]-class delivery is converging on |
| 14 | **Watch list** | relay geocode (unadopted I-D, data model only); FCM cut-point receipt; the VCM conformance suite when it issues; ISO/IEC 23001-11 4th ed. and 23001-19 catalogue confirmation | — | none is a stable surface yet |

---

## 9. What would falsify this

Each of these is an observation that would invalidate a specific conclusion
above. They are listed so the document can be checked rather than believed.

1. **The energy square turns out to be occupied.** 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 and the position collapses to a profile of someone else's field. Check
   at each MPEG meeting and at each GREEN WG revision.

2. **The determinism-tier hole is not a hole.** If a reading of
   `determinism-tiers.md` §3 plus SPEC.md §7 already excludes post-decode
   processing by construction — for instance because no registered capability's
   payload can carry VSEI messages — then §3.2's first instance is a
   documentation clarification rather than a soundness defect. The second
   instance (power-saving hints) would survive regardless.

3. **The carriage-fragmentation argument reverses.** If ISO/IEC 23001-19 or a
   successor grows an RTP binding, or the AVTCORE draft is abandoned, the
   evidence for §2's transport-agnosticism claim weakens to a single data point.
   It does not become wrong; it becomes unsupported.

4. **Soft binding turns out to be unusable for energy.** If the recovered-receipt
   ancestor rule cannot be stated without either overstating what the receipt
   covers or making the receipt useless, then item 5 in the queue is not
   ingestible and WAI should say plainly that it has one binding class and no
   recovery path, rather than shipping a weak second one.

5. **A designation in this document does not exist as described.** Five of the
   original flags were checked in September 2026 and **resolved**: ISO/IEC
   23001-19 and its MPEG 153 IS milestone (confirmed); ISO/IEC 23888-6 and the
   13 January 2027 CfP deadline (confirmed, with the full CD→DIS→FDIS ladder to
   early 2028); ITU-T H.274 V4 (01/2026) carrying the DSC triplet (confirmed,
   with survivability narrowed to remux, not transcode); ISO/IEC 23888-4 at CD
   (confirmed); and the 23888 series structure (Part 3 confirmed, **Part 7
   corrected — no such part appears in the catalogue**).

   A sixth was **resolved** later in September 2026. The NNC
   signed-data-unit feature (§6.4) is stated in MPEG's own press release for
   MPEG 154, as part of the Committee Draft of Amendment. Its text was not
   read, so the feature's details remain unknown.

   **One remains open and it is consequential.** ABNT NBR 25608's clause-level
   detail (§7.2) was read only through public companions because the standard
   is paywalled; buy it before quoting a clause number outward. If it fails
   catalogue confirmation, that row leaves the queue without disturbing the
   others.

6. **The regional mechanisms are already expressible.** If a predicate capability
   turns out to be a straightforward instance of existing WAI state-feed
   machinery with no new determinism contract required, item 10 shrinks to a
   registry entry. The authority-class gap (§3.7) would still stand on its own,
   because no amount of state machinery says which key may sign a pre-emption.

7. **Two adversarial lenses were not enough.** Fifty-two of seventy-one
   candidates were refuted, and the dominant failure modes were *already covered
   under another name*, *no ingestible surface*, and *mis-staged or
   misattributed* — a draft presented as ratified, a guideline presented as a
   normative annex, a proposal presented as adopted text. That distribution is
   itself a warning: the surviving nineteen were checked against the same
   failure modes, but the base rate suggests at least one of them is wrong in a
   way this pass did not catch. Re-verify stage and issuing body before any of
   this text is quoted outside the tree.