open-standards/wai/SPEC.md
Transaction Science 5ee4c7e28b
Some checks failed
standards workspaces build + test / jouleclaw-rs (pull_request) Successful in 1m39s
standards workspaces build + test / aac-rs (pull_request) Successful in 32s
standards workspaces build + test / joule-code-rs (pull_request) Successful in 1m8s
standards workspaces build + test / joulecontract-rs (pull_request) Successful in 37s
standards workspaces build + test / map-rs (pull_request) Successful in 40s
standards workspaces build + test / mesh-rs (pull_request) Successful in 35s
standards workspaces build + test / openpay (pull_request) Successful in 2m53s
wai cross-architecture byte-equality / linux-aarch64 (pull_request) Successful in 24s
WAI conformance / cargo-class corpora · linux-arm64 (pull_request) Failing after 42s
WAI conformance / cross-arch byte-equality · linux-arm64 (pull_request) Successful in 26s
WAI energy receipts / energy receipts · linux-arm64 (pull_request) Successful in 50s
no-vanity-metrics / Scan committed Markdown for vanity metrics (pull_request) Successful in 3s
standards workspaces build + test / eoc-rs (pull_request) Successful in 1m48s
standards workspaces build + test / jcp-rs (pull_request) Successful in 1m17s
standards workspaces build + test / proof-rs (pull_request) Successful in 1m12s
standards workspaces build + test / sandbox-rs (pull_request) Successful in 2m6s
standards workspaces build + test / arl-rs (pull_request) Successful in 1m48s
standards workspaces build + test / smart-byte-rs (pull_request) Successful in 2m34s
wai cross-architecture byte-equality / linux-x86_64 (pull_request) Successful in 22s
standards workspaces build + test / joule-ui-rs (pull_request) Successful in 2m0s
WAI conformance / cargo-class corpora · linux (pull_request) Successful in 2m20s
WAI conformance / cross-arch byte-equality · linux (pull_request) Successful in 26s
standards workspaces build + test / jouledesk-rs (pull_request) Successful in 1m58s
WAI conformance / C2PA manifest emission · signed, read back, validated (pull_request) Successful in 44s
WAI energy receipts / energy receipts · linux (pull_request) Successful in 44s
standards workspaces build + test / joulehook-rs (pull_request) Successful in 2m5s
standards workspaces build + test / sense-rs (pull_request) Successful in 1m53s
wai formal verification (integer core) / kani (pull_request) Successful in 4m4s
standards workspaces build + test / macOS energy backend (jcp-energy) (pull_request) Successful in 1m50s
WAI JPEG-AI whole decode (pinned inputs, required) / fetch pinned JPEG-AI inputs → whole decode + pixel hash, required (pull_request) Successful in 54s
wai cross-architecture byte-equality / macos-arm64 (reference) (pull_request) Successful in 22s
WAI neural decoders end-to-end / synthetic fixtures → Rust decode → reference (±4) (pull_request) Failing after 1m11s
WAI neural sink gates / model-free refusals of the neural sink (pull_request) Successful in 26s
WAI conformance / cargo-class corpora · macos (pull_request) Successful in 2m29s
WAI conformance / cross-arch byte-equality · macos (pull_request) Successful in 22s
WAI energy receipts / energy receipts · macos (pull_request) Successful in 58s
WAI mbt2018_mean integer decode (regenerated vectors) / regenerate mbt2018_mean integer vectors → Rust decode, required (pull_request) Successful in 2m35s
wai cross-architecture byte-equality / windows-x86_64 (pull_request) Has been cancelled
WAI conformance / cargo-class corpora · windows (pull_request) Has been cancelled
WAI conformance / cross-arch byte-equality · windows (pull_request) Has been cancelled
wai: typed receipt classes and the soft binding class, reading OER through the OER module
A JWP receipt says what was delivered, by whom and at what energy cost, and
binds to its object one way. Other statements about the same objects had
nowhere to go, and energy-measurement §2 requires an acquisition class beside
every non-zero figure, which the object receipt has no member for.
jwp-receipts §2.4.3-§2.4.7 adds a `claim` kind with one envelope, one
canonical form (RFC 8785) and one signature rule for the classes energy,
lawful-basis and log-inclusion. §2.6 and §3.2 add a second, deliberately
weaker binding class: a publisher-signed soft binding with a resolution
endpoint, under the ancestor rule. §3.1 step 3 fixes a strict Ed25519 rule. A
declaration that a decision or a recovery record is checked against is
verified before anything is compared with it (`context_invalid`).

OER as settled on main is authoritative: this adds no second OER reader and
changes no OER rule, vector, verifier or document. An OER receipt an energy
claim names is read by oer::load under the document profile, verified by
oer::verify_receipt, and its figure read by the exact quantity reader the
composition checks use, through a new crate-private oer::rounds_to_micro.
claim_verify.py does the same with the OER reference's load, verify_receipt
and dec. The claim envelope keeps its own step-1 reader (claim_text.rs),
which reads claims only.

- Acquisition classes are the refined ones. The energy body carries the class
  as energy-measurement §2.7 writes it in JSON (energy_provenance,
  energy_uncertainty, energy_counter_filtering, energy_calibration_ref),
  present and null where a class has none, so a claim keeps one canonical
  form. Legacy HwShunt is refused, since no claim predates the refinement
  (energy_legacy_acquisition); missing, misplaced or sub-floor evidence is
  energy_acquisition_evidence. The grade correspondence is oer-receipts §2's,
  an exhaustive match over all five variants.
- §3.1 step 2's member tables give exactly the type step 2 checks, and step 2
  lists what the class rules add to a type as step 4's, never field_type. Both
  verifiers read a declaration in its table's order (they had read purposes
  before vocabulary and fragment, and every encoding after every member, so a
  declaration with two defects gave another reason than the text).
- oer::py_float_repr writes a double at a tie between two shortest decimals as
  CPython's repr does (round half to even at the shortest length). No content
  address or verdict depended on it: main's number profile keeps floats out of
  every receipt body. It changed the printed name of a vector named by such a
  number, which both OER verifiers print and the OER fuzzer compares. Fourteen
  doubles CPython 3.14.7 wrote are pinned.
- claim-conformance/: 154 vectors covering all 40 reasons, the canonical
  fixture recomputed by claim_verify.py and pinned, a second verifier
  (claim_verify.py) that shares no code with wai-rs, and differential.py,
  which runs both on inputs the corpus does not hold. receipt_claims joins the
  conformance library tests and both corpus loops.

Checked on this machine (macOS arm64) on the stream's tree:
- library tests with receipt_claims (dev; oer + receipt_claims also release);
- wai_claim_vectors and wai_oer_vectors verify their corpora;
- claim_verify.py reports every vector's declared outcome;
- differential.py: its default families and 20,000 random inputs (seed 7):
  no verdict differs and nothing crashes;
- oer2_verify.py passes every OER vector file and refuses every unreadable
  document, the C kernel's output equals firmware_vectors.json, and
  fuzz_differential.py (seed 1, 20,000 documents) finds no divergence.
And on this commit's tree, the per-link gate: build, library tests,
carriage, every corpus in the conformance loop, byte-exact, wasm32.

Not run here: the Linux and Windows legs (CI runs Linux; the Windows runner
is offline). The Python scripts are run by hand, not in CI.
Not done: key discovery (every claim signature presumes the verifier holds
the key), an authority class for who may sign which class, region- or
time-scoped soft bindings, and checking a log's receipt under its profile.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-09-30 01:42:45 -04:00

1289 lines
91 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# WAI v1.0 — Web AI Media Transport & Execution
Status: **Draft Standard**. Reference implementation: `wai-rs/` (Rust
lib + cdylib + staticlib, C FFI). Two paths open every conforming
file:
- the **neural condition** — the sink regenerates the media from a
compact conditioning payload against a *shared ambient prior* (a
model). The model is a **requirement of existence**, never
transported in the envelope that decodes against it, exactly as `.mp3`
does not ship its decoder. Its identity MAY be pinned by digest (a
`Prior`), and the pinned artifact's wire form MAY be declared
([prior-carriage](extensions/prior-carriage.md)).
- the **zeroth condition** — a *menu of registered SOTA standard
codecs*. Always satisfiable on any device that ships ffmpeg or
equivalent. WAI does **not** define new codecs; it dispatches to the
field's best-in-class lossy+lossless libraries (AVIF, JPEG-XL, PNG,
Opus, FLAC, AV1, zstd, XZ).
The capability a file requires is *named*, not supplied. Sinks that
have the named capability use it; sinks that don't fall back to a
declared `fallback` capability.
Keywords **MUST**, **MUST NOT**, **SHOULD**, **MAY** are RFC 2119.
---
## 1. Scope and model
WAI is a **container + capability dispatch standard**. It is media-
general (image, audio, video, text), royalty-free, and built around the
principle that the standard's value is the envelope and the dispatch
rules — not in re-implementing existing SOTA codecs.
A WAI file declares (in its manifest):
- what media it carries,
- what *capability* a sink must have to decode it,
- a fallback capability the sink can use if it lacks the primary,
- and the conditioning bytes for that capability.
Conforming sinks MUST implement the container envelope (§2), the
manifest schema (§3), the capability-dispatch algorithm (§4), and at
least the **mandatory floor** capabilities (§5). Other capabilities
(neural and additional zeroth) are OPTIONAL but RECOMMENDED.
---
## 2. Container
```
+--------+----------------+-------------------+----------------+-----------+
| "WAI1" | u32 man_len | manifest (JSON) | u32 payload_len| payload |
| 4 B | little-endian | man_len bytes | little-endian | bytes |
+--------+----------------+-------------------+----------------+-----------+
```
- Bytes 0..4 MUST be ASCII `WAI1`. A reader MUST reject any file whose
first 4 bytes differ.
- `man_len` and `payload_len` are unsigned 32-bit little-endian.
- The manifest is UTF-8 JSON, serialized with no insignificant
whitespace, preserving key insertion order. Readers MUST NOT depend
on key order for *semantics*; encoders SHOULD preserve order so files
round-trip byte-identically.
- The payload is opaque codec bytes whose interpretation is fully
determined by the manifest's `model_requirement.capability`.
All WAI multi-byte integers are little-endian unless stated otherwise.
---
## 3. Manifest schema
```json
{
"wai": "1.0",
"media": "image" | "audio" | "video" | "text",
"intent": "replicate" | "create" | "improve" | "...",
"model_requirement": { "capability": "<capability-string>",
"fallback": "<capability-string>" | null },
"conditioning": { "kind": "<codec-id>" },
"security": { "encryption": "<scheme>" | "none", "kid": <u64> },
"target": { ... }
}
```
- `wai` — spec version. This document defines `"1.0"`. Unknown major →
reject. Unknown minor → accept by ignoring unknown fields.
- `media` — media class; informational. The capability is authoritative.
- `intent` — generative intent. `replicate` (reconstruct the source) is
the only intent with normative reconstruction semantics in v1.0. What it
promises is set by the capability's registry class (§7, *Replicate-soundness*):
a byte-exact reconstruction — every conforming sink that decodes the payload
produces the same bytes (decode-equivalence) — where the capability's
reconstruction is specified exactly; and, for a standard codec whose named
standard holds decoders to a criterion around a reference rather than to
identical output (Opus's thresholds, RFC 6716 §6, are one), no more than that
standard's decoder conformance, so conforming sinks' reconstructions may differ
as far as that criterion allows; for a standard codec §7 has not yet classified,
what its standard's decoder conformance states, which the registry does not
assert is byte identity.
For a **neural** capability, `replicate` promises decode-equivalence and is sound
only under the integer-entropy contract (§7): a capability whose decode runs
float, or whose entropy decode alone is integer, MUST NOT claim it. That is
WAI's rule, and this revision applies it to `wai.image.jpegai` as well; it is
not a finding that JPEG AI's standard leaves the reconstruction unbounded (§7,
`NeuralEntropyExact`).
- `model_requirement.capability` — the capability string a sink MUST
resolve. See §5 for the registered set.
- `model_requirement.fallback` — a second capability the sink MAY use
if it lacks the primary. `null` means the file is inert without the
primary.
- `conditioning.kind` — short codec id matching the capability. Helps
multiplexers route bytes without parsing the full capability string.
- `security` — OPTIONAL. Absent, `null`, or `encryption: "none"` ⇒ the
payload is plaintext (the default). Otherwise the payload is encrypted
and MUST be recovered before dispatch; see §6. The capability, media,
and conditioning fields always describe the **plaintext** codec.
- `target` — codec-specific reconstruction parameters (dimensions,
sample rate, duration, frame count). Informational; the payload is
self-describing per the codec's own format.
---
## 4. Capability dispatch
A conforming sink MUST implement this algorithm:
1. Read the manifest. If `wai` major version is unknown → reject.
2. Let `cap = model_requirement.capability`.
3. If the sink advertises `cap`, decode `payload` via the codec
registered for `cap` (§5) and return.
4. Else, let `fb = model_requirement.fallback`.
5. If `fb != null` and the sink advertises `fb`, decode via `fb`'s
codec and return.
6. Else the file is **inert at this sink** — return a clear "missing
capability" error to the calling application.
A WAI **payload always corresponds to exactly one capability**. v1.0
does not support multi-codec multiplexed payloads.
If the manifest declares `security.encryption` other than `"none"`
(§6), the sink MUST recover the plaintext payload before step 3 and run
this algorithm on the plaintext; see §6.4.
---
## 5. Registered capabilities (the zeroth menu)
WAI v1.0 registers the following capabilities. Each names a standard
codec or a WAI-native class. The mandatory floor and the recommended
set are royalty-free; every registered capability carries a licence
class (see the end of this section), and one that is not royalty-free
is never a default. The "payload format" column is the
on-the-wire payload bytes; in every case it is the canonical bytes
that codec normally emits (a JXL file, an Opus stream, etc.) — WAI
does not wrap or re-frame them.
### Mandatory floor
Every conforming sink MUST implement:
| capability | payload | role |
|---|---|---|
| `wai.image.png` | PNG (RFC 2083) | universal lossless image |
| `wai.audio.flac` | FLAC (xiph.org/flac) | universal lossless audio |
| `wai.text.zstd` | zstd (RFC 8478) | universal compressed bytes |
These three guarantee that any sink with the standard system codec
libraries can open *some* file in every WAI-supported media class.
### Recommended modern set
Every conforming sink SHOULD implement:
| capability | payload | role |
|---|---|---|
| `wai.image.jxl` | JPEG-XL (ISO/IEC 18181) | lossless + lossy, modern SOTA |
| `wai.image.avif` | AVIF (ISO/IEC 23000-22) | lossy SOTA (AV1-based) |
| `wai.image.jpeg` | JPEG (ITU-T T.81) | legacy compatibility |
| `wai.audio.opus` | Opus (RFC 6716) | lossy SOTA |
| `wai.video.av1` | AV1 (AOMedia) | lossy SOTA |
| `wai.video.av1.lossless` | AV1 (AOMedia), `quantizer=0` | mathematically lossless YUV (lossy in RGB due to color conversion) |
| `wai.text.xz` | XZ/LZMA2 | maximum classical text ratio |
### Neural capabilities (OPTIONAL, sink advertises if its ML runtime supports them)
Each names a model the sink MAY have installed. Payload is a compact
conditioning representation specific to the capability (latent tokens,
prompt embeddings, etc.). The standard does NOT specify the byte
layout of these payloads — the capability owner does.
Neural capabilities are picked on the **best-quality-per-bit at each
bitrate band** principle — not on whatever model is famous or small.
2026 SOTA per medium, with the wire-byte win each one delivers. The
decode route for each is implemented in the reference sink (see the
`source` column / `neural/*.rs`); the model weights are sink-supplied.
*Audio:*
| capability | model | win vs zeroth | source |
|---|---|---|---|
| `wai.neural.encodec32` | EnCodec at 32 kHz, 4 codebooks | ~3 kbps acceptable music | `facebook/encodec_32khz` |
| `wai.neural.dac` | DAC at 44.1 kHz | 6 kbps near-transparent music | `descript/dac_44khz` |
| `wai.neural.mimi` | Mimi, 12.5 Hz frame rate | ~1.1 kbps real-time speech | `kyutai/mimi` |
| `wai.neural.wavtokenizer` | WavTokenizer single-codebook VQ | 0.9 kbps beats DAC @ 9 kbps on UTMOS | `novateur/WavTokenizer-large-*` |
| `wai.neural.snac` | SNAC multi-resolution RVQ (hierarchical code levels, own sample rate) | low-bitrate TTS standard | `neural/snac.rs` |
*Image:*
| capability | model | win vs zeroth | source |
|---|---|---|---|
| `wai.neural.bmshj2018` | bmshj2018-factorized + rANS (byte-exact CompressAI port) | ~80× vs raw RGB at q=3 (~0.26 bpp, 29 dB PSNR) | CompressAI |
| `wai.neural.mbt2018_mean` | mean-scale hyperprior (Gaussian-conditional entropy) | conditional-entropy family, stronger than factorized | `neural/hyperprior.rs` |
| `wai.neural.int_synth` | integer fixed-point synthesis (all-i64 transposed-conv, no float/ONNX) | bit-identical on every machine — soundly backs `intent = replicate` | `neural/int_synth.rs` (QAT weights sink-supplied) |
| `wai.neural.int_hyper` | integer fixed-point **conditional** codec — whole bitstream→image path integer (integer hyper-decoder σ → integer-σ entropy → integer synthesis) | the integer-entropy contract fully assembled; high quality (PTQ of mbt2018_mean) bit-identical on every machine | `int_hyper_synth.rs` (tables sink-supplied) |
| `wai.neural.int_mlicpp` | integer fixed-point **MLIC++ entropy topology** — `K` channel slices of the latent, each decoded as a checkerboard anchor pass then a non-anchor pass, with an entropy network over concat[latent decoded so far, hyper] re-run before every pass to give σ‖μ; hyper-decoder, entropy network and synthesis all integer | the channel-autoregressive × checkerboard entropy model at **decode-equivalence**: the encoder and every decoder compute the same σ, so the same distribution for every element, at any thread count; bit-identical on every machine. The committed conformance vector has synthetic weights, so it demonstrates decode-equivalence and states no quality figure | `int_mlicpp.rs` (one-file model bundle sink-supplied; `tools/wai_int_mlicpp_export.py`) |
| `wai.image.jpegai` | ISO/IEC 6048 JPEG-AI codestream → RGB — integer entropy front end (mANS, with an integer scale-index derivation) + 16-bit-PTQ integer hyper-decoder, context-model and synthesis networks + dequantisation, latent refinement, post-filters (the eICCI CNN among them) and colour conversion in IEEE-754 float with a fixed evaluation order. Scope: one configuration — 256×256 4:4:4, `model_id` 0 (tools_0), `beta_displacement_log` 0, the high-operation-point synthesis, the eICCI model pair the weight bundle carries, and the other header conditions in [determinism-tiers](extensions/determinism-tiers.md) §5; both decode paths refuse any other codestream. Within it, a sink without the integer weight bundle, or in a non-default floating-point environment, takes a float ONNX decode instead. Only checkpoint constants are sink-supplied | **entropy-consistency** (registry class `NeuralEntropyExact`): the entropy decode, including the scale-index derivation, is integer on both decode paths, so the decoded symbols reproduce on every machine. The exact decoder also pins one reconstruction to RGB, reproducible across machines under the build and floating-point conditions in [determinism-tiers](extensions/determinism-tiers.md) §5–§6 (it checks the floating-point environment before decoding) — a property of that decoder, not of the capability, so `wai.image.jpegai` does not back `replicate` (§7). On one reference codestream the exact decoder stays within max\|Δ\| ≤ 2 of the reference decoder (recorded max\|Δ\| = 1 on ~4.4% of samples); evidence in [determinism-tiers](extensions/determinism-tiers.md) §6. **Downgraded in v0.4.0:** this row previously claimed decode-equivalence, and the registry classed the capability `StandardDefined` | `jpegai_decode.rs` (+ `jpegai_{bitstream,mans,pipeline,synthesis,icci}.rs`) |
| `wai.generate.spectral` | deterministic integer GENERATIVE synthesis (`intent=create`) — prompt+seed → integer-LUT spectral composition, no float/ONNX | byte-identical on every machine, pinned to (model, prompt, seed, steps); the create-side of "conformance is a hash" (generation-equivalence) | `generate.rs` (small pinned model bundle) |
| `wai.neural.elic` | checkerboard context model (hyperprior + 2-pass spatial context) | the JPEG-AI / MLIC++ entropy class | `neural/context.rs` |
| `wai.neural.mlicpp` | MLIC++ multi-reference entropy (channel-AR slices + checkerboard + global attention) | learned image, low-bitrate high-fidelity | research code, `neural/mlicpp.rs` |
| `wai.neural.mlicv2` | MLICv2 / MLICv2+ (2025), MetaFormer transform | learned-image fidelity frontier; shares the mlicpp route | research code, `neural/mlicpp.rs` |
| `wai.neural.cmic` | Content-Adaptive Mamba (ICLR 2026), SSM transform + SCCTX entropy | learned-image frontier; shares the mlicpp route | arXiv 2508.02192, `neural/mlicpp.rs` |
| `wai.neural.glc` | Generative Latent Coding — categorical / VQ entropy | <0.05 bpp where JPEG-XL collapses | research code, `neural/glc.rs` |
*Video:*
| capability | model | win vs zeroth | source |
|---|---|---|---|
| `wai.neural.video_bmshj2018` | per-frame bmshj2018 | 1000×+ vs raw RGB, browser-decodable on WebGPU | CompressAI |
| `wai.neural.dcvc_rt` | DCVC-RT (2025), inter-frame with reference-feature propagation | real-time neural video at 1080p/4K | research code, `neural/video_dcvc.rs` |
| `wai.neural.dcvc_fm` | DCVC-FM (feature modulation), wide single-model quality range (RGB + YUV) | SOTA-RD neural video; shares the inter-frame route | research code, `neural/video_dcvc.rs` |
| `wai.video.int_motion` | DETERMINISTIC INTEGER inter-frame — I-frame + integer block motion-compensated P-frames + integer-quantized residual over rANS, no float/ONNX; motion is whole-pel or **half-pel** (`mv_precision`), the latter predicting at the half-grid by integer bilinear interpolation (`(a+b+1)>>1`, `(a+b+c+d+2)>>2`) so real footage — which pans a non-integer number of pixels per frame — costs fewer residual bits while staying byte-exact | byte-identical frame-by-frame on every machine (*frame-state-equivalence*, a per-frame portable hash); the temporal extension of the integer contract, where a float inter-frame decode desyncs down the GOP | `int_video.rs` (whole-pel `tools/wai_int_video_encode.py`; half-pel from real footage `tools/wai_int_video_real_encode.py`) |
| `wai.video.int_hyper` | NEURAL-KEYFRAME inter-frame — the I-frame is the LEARNED integer codec `int_hyper` decoded byte-exact, the P-frames are integer block-MC residuals on top | a learned keyframe you can put in a receipt + integer inter-frames; whole decode integer, byte-identical everywhere | `int_video::decode_pframes` ∘ `int_hyper_synth::decode_conditional` |
| `wai.video.manifest` | ATTESTED PER-SESSION MANIFEST — the OTT delivery layer, not a codec: a personalised HLS manifest (ads stitched at `EXT-X-DISCONTINUITY`, blackouts + geo enforced) rendered as a **pure function of the session *class*** `(content, entitlement, geo, blackout set, ad pod, window)` rather than the viewer, and sealed in an Ed25519 receipt that binds the JCP grant (capability, joule ceiling, `funds_ceiling` = ad budget), the composition, the stitched ads and the policy applied | **manifest-equivalence**: `manifest_hash == hash(render(segments))` and `session_class_hash` are recomputable by anyone holding the bytes, so the ads, blackouts and compose-work stop being dashboard claims; class-determinism means one generation serves every viewer of the class, and `uj_per_viewer` is the amortised energy that a 1:1-unique generator cannot report below its per-viewer cost. Only `joules_micro` is measured-attested | `wai_video_manifest.rs` |
| `wai.video.ssai` | ATTESTED SERVER-SIDE AD INSERTION — a **deterministic** ad decision (greedy by price within the avail duration and the funds remaining) plus a per-impression Ed25519 receipt binding the candidate pod, the manifest it belongs to, the served `creative_hash`es and the VAST quartile each reached | **spend-equivalence**: `budget_spent_micros` is recomputed from the *billable* impressions and rejected if it exceeds the grant's `funds_ceiling` — overspend cannot be signed; every creative and quartile is checkable, so a buyer and seller reconcile impressions from the same bytes instead of two logs that only a dashboard joins. Only `joules_micro` is measured-attested | `wai_video_ssai.rs` |
| `wai.video.keys` | ATTESTED CONTENT-KEY RELEASE — the DRM licensing decision as a record: every key release, and every refusal, is an Ed25519 receipt binding the KID, the DRM system, the entitlement demanded and the window enforced, with a BLAKE3 `key_commit` proving *which* key was released without carrying it | **decision-equivalence**: `verify()` re-runs the release policy over the receipt's own `(grant capability, entitlement, issued, expiry)` and rejects any misreported outcome, and enforces granted-iff-committed — so "keys went only to entitled, unexpired sessions" is checkable against the signed log, not asserted. Only `joules_micro` is measured-attested | `wai_video_keys.rs` |
| `wai.video.package` | DETERMINISTIC PACKAGING + ATTESTED SEGMENTMAP — a source sliced into content-hashed segments on GOP boundaries; the ordered `(index → content_hash)` map is a signed Merkle commitment, and identical content (ads, bumpers, replays, simulcast overlap) dedups to one stored/encoded copy | **map-equivalence + verifiable dedup**: `segment_map_root` lets a `wai.video.manifest` reference be checked against the package that produced it, and `verify()` recomputes `unique_segments`/`stored_bytes` from the segments so the storage/encode saving cannot be overstated; `uj_per_unique_segment` is the encode-once energy. Only `joules_micro` is measured-attested | `wai_video_package.rs` |
| `wai.video.channel` | VIRTUAL LINEAR / FAST ASSEMBLY — a continuous schedule of assets over wall-clock time, sliced into attested playback windows; windows chain via `parent_receipt_hash`, so a channel's history is a hash chain of program-as-run records | **schedule-continuity + recomputable program-as-run**: `verify()` rejects a schedule with a gap or overlap (no dead air, no double-booking) and recomputes `aired` from the schedule and the window, so what actually aired is checkable by a licensor, advertiser or regulator against the signed chain rather than an operator-held play-out log. Only `joules_micro` is measured-attested | `wai_video_channel.rs` |
**Sink-architecture note:** the inter-frame neural video codecs (DCVC-RT,
DCVC-FM) decode through `ort` and are **CPU-capable** for native sinks —
their real-time figures come from GPU execution, but the decode is not
CUDA-only. They are heavier than per-frame image codecs (a temporal net
plus reference-feature state), so a browser sink that cannot host the
temporal net should declare only `wai.neural.video_bmshj2018` (or another
browser-decodable neural video codec) for the `video` media class. The
choice is the deployer's, advertised per sink — the envelope is identical.
**TAESD is intentionally absent.** TAESD is a distilled SD VAE decoder
— it inverts a generative pipeline's encoder, not a general image
codec. Outside the SD pipeline it underperforms JPEG-XL at most
bitrates while costing ~5 MB of weights and ONNX compute. Don't ship
codecs for the brand; ship them for the bit budget.
**Image/video scope is honest:** zeroth codecs (JPEG-XL, AV1) are
already SOTA-adjacent in the bitrate bands where most media lives.
Neural image/video capabilities are registered for the bands where
zeroth codecs collapse (ultra-low bpp images, bandwidth-constrained
streaming) — not as defaults.
Each capability owns its payload format. Decoder implementations
(Python source-side, ONNX-export, browser onnxruntime-web) live in
`tools/wai_<capability>_*.py` and `wai-web/demo/`. New neural
capabilities are added by registration; the WAI envelope is unchanged.
See [`extensions/jwp-receipts.md`](extensions/jwp-receipts.md) for the
receipt-chain sub-spec covering per-object content hashes, per-group
Merkle roots, Ed25519 group signatures, and cross-hop preservation; the
typed receipt classes beside delivery (`energy`, `lawful-basis`,
`log-inclusion`) carried as `claim` receipts; and a second, weaker
binding class (a registry-named soft binding with a resolution endpoint)
whose recovered receipts attest the ancestor, never the object in hand.
See [`extensions/energy-measurement.md`](extensions/energy-measurement.md) for
how a receipt's `joules_micro` is acquired: the required acquisition class
(`CalibratedInstrument` / `OnChipCounter` / `ModelBased` / `Estimator`, with the
legacy `HwShunt` still accepted when read), the declared uncertainty — a
standard relative uncertainty and its integration window, never less than the
`0.5/√3` µJ (≈ 0.289 µJ) that rounding the figure to whole microjoules adds, so
`joules_micro × relative_ppm ≥ 288 676` — that both hardware classes must carry, the counter filtering state and calibration reference that
distinguish them, the bracketed marginal protocol (a burst whose window opens
from rest, divided by the work the window paid for), the attribution-quality
rule that decides whether a figure may be published at all, and how the receipt
families that sealed a figure before the class existed carry it as an optional
signed label that leaves every issued receipt's bytes unchanged.
See [`extensions/confidentiality.md`](extensions/confidentiality.md) for the
private-channel sub-spec: MLS (RFC 9420) group keys + SFrame (RFC 9605)
object encryption, the byte-level framing behind §6.
See [`extensions/reconstruction-binding.md`](extensions/reconstruction-binding.md)
for the reproducible-reconstruction binding: a C2PA / JPEG-Trust hard binding
over the *deterministically decoded pixels* of a neural-coded asset (SHA-256 over
the canonical RGB plus the descriptor that pins the reconstruction) — the
reconstruct-side companion to `provenance`, applicable to the byte-exact
`wai.neural.int_*` codecs and, over the exact decoder's pinned reconstruction
only, to `wai.image.jpegai`.
See [`extensions/energy-binding.md`](extensions/energy-binding.md) for the
companion energy assertion: the joules a reconstruction cost, bound to that
reconstruction, with the acquisition class and coverage C2PA 2.4's
`c2pa.environmental-sustainability` has no field for.
### Prior artifacts, general tensors and derivation operations
| capability | payload | status · extension |
|---|---|---|
| `wai.prior.nnc` | a trained network's parameters as an ISO/IEC 15938-17:2024 (NNC, 2nd edition) bitstream | the registered wire form a `Prior` MAY declare (`prior.form`); its digest then covers the coded bitstream. Optional, not recommended: royalty status is not established, and cross-decoder exactness of the reconstruction is not established, so a `replicate` over a neural capability cannot rest on a prior read out of it. As a payload it takes the replicate class of a standard whose decoder conformance the registry has not checked · [prior-carriage](extensions/prior-carriage.md) |
| `wai.tensor.nnc` | general tensorial data (split-inference feature maps, 3D/4D scene parameters) coded with NNC | **candidate**: general-tensor coding is in an unpublished amendment, so the payload format is not fixed and MUST NOT be emitted until pinned · [prior-carriage](extensions/prior-carriage.md) |
The ten derivation operations of ISO/IEC 23001-16:2021 (derived visual tracks)
are registered as `wai.derive.*` strings, each with a per-operation determinism
tier. They are **not payload capabilities**: an operation acts on samples another
capability decoded. WAI does not composite; the registration states what a
reproducibility claim over a derived sample needs. The geometric conditions a
tier lists for each operation are read from the operation's title: clause 8 of
ISO/IEC 23001-16, which defines each operation, was not read · [derived-tracks](extensions/derived-tracks.md).
### Interactive, temporal & computed content (extensions)
Media that consumes input, moves over time, or is *computed* from a
compact instruction set. Each registers its own payload format and a
deterministic `*-equivalence` conformance criterion over the
`wai.det.fixed64` fixed-point floor — the reconstruct half of the
standard. See the linked extension for each.
| capability | payload | conformance · extension |
|---|---|---|
| `wai.world.scene` / `.replay` / `.live` | WWLD container (op log) | replay-equivalence · [interactive-worlds](extensions/interactive-worlds.md) |
| `wai.world.model` | generative-world transport: a signed **action trace** (the world CausalOp log) + a declared `model_id` (`world_model.rs`) | the wire carries the *action trace*, not the pixels — it replays under canonical total order to one **session hash** on every machine (replay-equivalence), the generated frames vouched for by a signed, joules-accounted provenance receipt. The neural sibling of `.replay`; with an `int_*` renderer the frames hash-converge too (a generative interactive world you can put in a receipt) |
| `wai.mesh.glb` | glTF 2.0 Binary (Khronos) | asset, content-addressed (decoder sink-supplied) |
| `wai.splat.spz` | SPZ (Niantic) | asset, content-addressed; presentation only |
| `wai.audio.scene` | WSCN scene (objects + trajectories) | mixdown-equivalence · [spatial-audio](extensions/spatial-audio.md) |
| `wai.audio.score` | WSCR container (note events) | music as instructions; sink synthesizes, mixdown-equivalence · [score](extensions/score.md) |
| `wai.audio.int_codec` | LEARNED 1-D transform codec — integer transposed-conv synthesis + integer IGDN over a factorized-rANS latent (model + bitstream from `tools/wai_int_audio_export.py`) | **sample-equivalence**: int16 PCM byte-identical on every machine (a portable PCM hash); the audio analog of `wai.neural.int_hyper`, where a float learned-audio decode desyncs on ~1e-5 round-off. Pure i64, no float/ONNX (`int_audio.rs`) |
| `wai.haptic.signal` | WHAP envelope (intensity/sharpness keyframes) | sample-equivalence · [haptics](extensions/haptics.md) |
| `wai.feed.state` | WWLD, sim `wai.world.sim.feed0` | replay-equivalence · [state-feeds](extensions/state-feeds.md) |
| `wai.avatar.pose` | WWLD, sim `wai.world.sim.skeletal0` | pose-equivalence · [avatars](extensions/avatars.md) |
| `wai.splat.4d` | W4DS container (per-Gaussian keyframed tracks) | frame-state-equivalence · [volumetric](extensions/volumetric.md) |
| `wai.splat.int_codec` | LEARNED Gaussian-splat ATTRIBUTE codec — a learned transform over the `[14,S,S]` attribute image (pos/scale/rot/color/opacity), integer synthesis (int_hyper machinery, 14 channels) over a factorized-rANS latent (`int_splat.rs`; model + bitstream from `tools/wai_int_splat_export.py`) | **splat-equivalence**: the decoded attribute tensor is byte-identical on every machine (a portable cloud hash) — the int_hyper of 3D, where a float splat-attribute decode desyncs. The float rasterizer stays sink-supplied presentation; the *attributes* are the contract. Pure i64, no float/ONNX |
| `wai.film.linear` | WFLM container (sealed world + camera track + frame schedule) | film-equivalence · [linear-film](extensions/linear-film.md) |
| `wai.film.reel` | WREL container (sealed world + a sequence of shots = camera track + schedule each) | reel-equivalence (film-equivalence with cuts) · [linear-film](extensions/linear-film.md) |
| `wai.ternary.tt` | WQTT container (balanced-ternary MPS cores — packed trits + integer per-column scales) | a **quantum-inspired** (tensor-network) transform ported from the ternary/MPS fabric with ONE change: the per-column scale is an **integer**, so the whole decode is `i64`/`i128` and the reconstruction is byte-identical on every machine — **reconstruction-equivalence** (a portable recon hash), receiptable. Honest scope: a **provenance** transform, NOT a rate-competitive codec (measured RD is mediocre — `Lossy` tier; see the extension's §5 verdict). Encoder-side float SVD only · [ternary-tt](extensions/ternary-tt.md) |
| `wai.quantum.circuit` | WQC container (gate op-log — Clifford+T + dyadic phase) | the wire carries a **circuit** (kilobytes, linear in gate count), the sink CLASSICALLY simulates it in a fixed-point **complex** floor (`Amp` = i64 re/im), and the reconstructed `2^n`-amplitude statevector is byte-identical on every machine — **statevector-equivalence** (a portable statevector hash); measurement is sampled by the pinned `splitmix64` so a shot histogram at a pinned `(seed, shots)` converges too (**shot-histogram-equivalence**). The dyadic phase ladder gives the **QFT** ("quantum FFT"), transported as a circuit and reconstructed byte-exact. No quantum hardware — NISQ noise breaks the determinism the standard rests on; this makes a quantum *computation* transportable + receiptable, with **no** speedup claimed · [quantum-sim](extensions/quantum-sim.md) |
And the verify half — a signed, energy-accounted lineage for opaque
captured content WAI does **not** reconstruct (content-addressing +
receipts + measured joules): [`extensions/provenance.md`](extensions/provenance.md)
(`wai.asset.provenance`).
The same verify half, specialized to **quantum operations** — a signed,
content-addressed, joule-metered, grant-authorized receipt of a calibration run
(`wai.quantum.calibration`) or a dispatched QPU job (`wai.quantum.job`), where a
job binds the exact calibration state it ran under and `verify()` enforces the
grant's joule ceiling (gate ⊗ meter ⊗ receipt in one object). WAI owns the
receipt; the sink's control system runs the hardware:
[`extensions/quantum-ops.md`](extensions/quantum-ops.md).
### Immersive audio, cinema, volumetric, haptics, HDR (registered, sink-supplied)
The same "name the capability, the sink supplies the decoder" pattern extends
to the standard carriers of the immersive / theatrical / volumetric media a
full distributor needs. Each names an open reference where one exists; the
proprietary and SEP-pool entries are flagged, never defaults. Payload is the
named standard's canonical bytes.
| class | capabilities |
|---|---|
| immersive audio | `wai.audio.iamf` (IAMF/Eclipsa, royalty-free) · `wai.audio.ac4` (Dolby AC-4, proprietary) · `wai.audio.ivas` (3GPP IVAS, SEP-pool) · `wai.audio.mpegh` (MPEG-H 3D Audio, SEP-pool) · `wai.audio.avs3` (AVS3-P3 / Audio Vivid, SEP-pool) — the last two with the broadcast codecs below |
| cinema mastering | `wai.image.jp2` · `wai.video.j2k` (JPEG 2000 / DCP, OpenJPEG) |
| volumetric / 3D | `wai.mesh.draco` (royalty-free) · `wai.pc.gpcc` · `wai.pc.vpcc` (MPEG point clouds) · `wai.splat.sog` (Gaussian-splat compression, candidate) |
| haptics | `wai.haptic.mihs` (MPEG-I Haptics, ISO/IEC 23090-31; its 23090-33 ships bit-exact conformance vectors) |
| HDR dynamic metadata | `wai.meta.hdr10plus` (royalty-free) · `wai.meta.dovi` (Dolby Vision, proprietary) — **companion descriptors** to a video payload, not standalone media |
### Broadcast and streaming codecs (registered, sink-supplied)
The elementary video and audio bitstreams that terrestrial and satellite
broadcast, streaming and device playback carry. Registering them lets one
envelope name the bitstream a distribution chain already holds, and dispatch it
with a declared fallback or a sibling rendition. Every entry is
**sink-supplied** — the reference implementation bundles no decoder for any of
them — and **none is in the mandatory floor or the recommended set**:
registration never makes a capability a default. Payload is the named
standard's canonical elementary bitstream in the framing given; WAI does not
re-frame it.
| capability | standard | payload (canonical bytes) | licence |
|---|---|---|---|
| `wai.video.av2` | AV2 (AOMedia) — AV2 Bitstream & Decoding Process Specification v1.0.0, 28 May 2026 | the length-delimited bitstream of that specification's Annex B (each OBU preceded by its `leb128` byte length) | royalty-free |
| `wai.video.vvc` | VVC — ITU-T H.266 \| ISO/IEC 23090-3 | H.266 Annex B byte stream | SEP-pool |
| `wai.video.hevc` | HEVC — ITU-T H.265 \| ISO/IEC 23008-2 | H.265 Annex B byte stream | SEP-pool |
| `wai.video.avc` | AVC — ITU-T H.264 \| ISO/IEC 14496-10 | H.264 Annex B byte stream | SEP-pool |
| `wai.video.vp9` | VP9 Bitstream & Decoding Process Specification | VP9 frames in the IVF frame container (FourCC `VP90`) | royalty-free |
| `wai.video.evc` | EVC — MPEG-5 Part 1, ISO/IEC 23094-1, any profile | raw bitstream file storage format, ISO/IEC 23094-1 Annex B | SEP-pool (Main-profile tools) |
| `wai.video.evc.baseline` | EVC, Baseline profile only | as `wai.video.evc`, Baseline-conformant | royalty-free by design |
| `wai.video.avs3` | AVS3 video — AVS3-P2, T/AI 109.2-2021, IEEE 1857.10 | AVS3-P2 elementary bitstream | SEP-pool |
| `wai.video.lcevc` | LCEVC — MPEG-5 Part 2, ISO/IEC 23094-2 | LCEVC enhancement as the ISO/IEC 23094-2 Annex B byte stream (start-code-delimited NAL units) — **companion-only**, see below | SEP-pool |
| `wai.audio.mpegh` | MPEG-H 3D Audio — ISO/IEC 23008-3 | MHAS packet stream (MPEG-H 3D Audio Stream) | SEP-pool |
| `wai.audio.avs3` | AVS3 audio / Audio Vivid — AVS3-P3, T/AI 109.3-2023; GY/T 363-2023; GB/T 46271-2025 | AVS3-P3 elementary bitstream | SEP-pool |
| `wai.audio.aac` | AAC-LC, HE-AAC, HE-AAC v2 — ISO/IEC 14496-3 | ADTS stream (ISO/IEC 13818-7 / 14496-3); Extended HE-AAC is not this capability | SEP-pool |
*SEP-pool* means the standard's essential patents are licensed for royalties —
through patent pools, a single standard-essential-patent licensor, or FRAND
holders. Per-entry sources and caveats are in the research registry linked
below. Each is tiered `Lossy` (its distribution role; the lossless modes some
of them have are signalled in the bitstream, as for AVIF). No model WAI runs
is involved in any of them. For replication (§7) they fall in three classes:
- **`StandardDefined`** — AVC, HEVC, VVC and VP9. Each standard's decoder
conformance requires every sample a conforming decoder outputs to equal the
value its decoding process produces (H.264 §C.4; H.265 and H.266 §C.5.1; VP9
§8.1), so every conforming decoder outputs the same cropped decoded pictures.
The guarantee stops at those pictures: film-grain synthesis an SEI message
signals, colour conversion and other post-decoding processing are outside it.
- **`StandardTolerance`** — AV2. As for AV1, the output is identical unless the
payload signals film grain; then grain synthesis is held only to the absence
of "perceptually significant differences" from the reference (AV2 v1.0.0
§7.1).
- **`StandardUnclassified`** — EVC (both entries), AVS3 video, LCEVC, MPEG-H 3D
Audio, AVS3 audio and AAC. Their conformance documents were not read for this
revision, so the registry promises no byte identity for them. For AAC, three
decoders on one host gave three different PCM streams from one ADTS stream.
LCEVC's decoding process includes a signalled dither step (ISO/IEC 23094-2,
clause 8.11). Any of them moves to `StandardDefined` only with the conformance
clause that fixes its output.
The clauses behind each class, what was not read, and the cross-decoder
measurements are in the research registry.
**Dispatch.** These dispatch exactly as §4 describes. Because none is a floor or
recommended capability, no sink can be assumed to hold one: an encoder
addressing sinks it does not control SHOULD ship such a payload in a `WAI2`
envelope (§7.1) together with a recommended-set rendition of the same content,
and that rendition is what keeps the file from being inert at a conforming
sink. A v1.0 `fallback` alone does not: dispatch step 5 decodes the *same*
payload with the fallback's codec (§4), so a fallback helps only where that
codec's decoder accepts the primary's bitstream (`wai.video.evc.baseline` →
`wai.video.evc` is such a pair; an HEVC, VVC or AV2 bitstream is not an AV1
bitstream). A deployer that must not ship pool-licensed decode filters on the
licence class below, not on a hand-kept list.
**AV2 placement.** AV2 is royalty-free, with a published specification and a
reference decoder (AVM v1.0.0). It is registered here and **not** in the
recommended set, because that set states what every conforming sink SHOULD
implement, and in September 2026 that is not yet a reasonable ask: AVM is a
reference model, a production software decoder is still in development, and
hardware decode in shipping devices is not confirmed. Promotion to the
recommended set is a MINOR revision (§8) once deployable decode exists; the
capability string and its payload framing do not change. Until then an AV2
payload SHOULD travel in a `WAI2` envelope with a `wai.video.av1` rendition of
the same content.
**Enhancement layers (LCEVC).** An LCEVC enhancement is not a picture: it holds
residuals that an LCEVC decoder adds to the upscaled output of **one specific
base encode**. This registration names its **base codecs**: AVC, HEVC, VVC,
EVC, VP9 and AV1, as the capabilities that name those bitstreams —
`wai.video.avc`, `wai.video.hevc`, `wai.video.vvc`, `wai.video.evc`,
`wai.video.evc.baseline`, `wai.video.vp9`, `wai.video.av1` and
`wai.video.av1.lossless` — and not AV2, AVS3, JPEG 2000 or the WAI-native
integer codecs. The list is WAI's, not the LCEVC standard's: ISO/IEC
23094-2:2021 takes its decoded base picture from "a base decoder" (definition
3.17) and names no base codec among its normative references. A later revision
MAY add a base, which widens what the enhancement layer applies to (§8). WAI
carries it one of two ways.
- **Embedded.** The enhancement rides inside the base bitstream (SEI /
registered user data). The payload is the base codec's bytes, under the base
capability; a sink without LCEVC decodes the base and ignores the enhancement
under the base codec's own rules. No `wai.video.lcevc` component exists.
- **Separate.** The enhancement, in the byte-stream framing given below, is a
`WAI2` companion (§7.1): `role = "companion"`, `companion_of` naming the base
capability. This is the shape of LCEVC's dual-track storage in ISO/IEC
14496-15, where an enhancement track refers to exactly one base track, and the
companion mechanism fits it with one added rule that binds in both directions:
`companion_of` MUST name one of its base codecs and resolve to **exactly
one** selectable rendition of it in the envelope, and that rendition MUST NOT
be the base of any other enhancement layer. `companion_of` names a capability,
not a component, so with two renditions of the base capability it cannot say
which encode the residuals belong to; and a sink applies every companion bound
to the rendition it picks (§7.1), so two enhancement layers on one base would
add two sets of residuals to one picture. Either way the picture is
corrupted. Such an envelope does not conform; a sink MUST NOT apply its
enhancement layers, and MAY still present a base rendition.
The separate carriage's payload is the enhancement in the byte-stream form of
ISO/IEC 23094-2 Annex B, where a start code prefix (`0x000001`) precedes every
NAL unit. ISO/IEC 23094-2 defines an LCEVC bitstream as either a NAL unit
stream or a byte stream (definition 3.2); the byte stream is the form that
delimits its own NAL units, so it is the one `wai.video.lcevc` names. A NAL
unit stream without start code prefixes (for example with each NAL unit
preceded by its length) is not a `wai.video.lcevc` payload; carrying that form
would need its own capability string (§8).
**Companion-only capabilities.** `wai.video.lcevc` and the HDR dynamic-metadata
descriptors `wai.meta.hdr10plus` and `wai.meta.dovi` are **companion-only**:
their payload means nothing without the base it accompanies. An HDR descriptor
applies to a rendition whose payload is video (§7.1, rule 2), `wai.video.lcevc`
to one rendition of one of its base codecs (above). Every other registered
capability is **standalone media** and is never carried as a companion (§7.1).
A companion-only
capability MUST NOT be a v1.0 `capability` (a `WAI1` carries one payload, so
there is nothing for it to accompany) or a v1.0 `fallback` (dispatch step 5
would decode it on its own), nor a v1.1 selectable rendition; a sink never
dispatches it standalone. A `WAI1` naming one as its `capability` is inert: its
payload is companion data. A `WAI1` naming one only as its `fallback` does not
conform, and a sink MUST NOT take dispatch step 5 with it; step 3 is unaffected,
so a sink that advertises the envelope's `capability` still decodes it (§4).
The reference implementation checks these rules in
`Wai::check_component_roles` (v1.0) and `WaiMulti::check_component_roles`
(v1.1: the companion rules of §7.1, including both enhancement-layer rules
above), dispatches `WAI1`
envelopes through `Wai::dispatch_capability`, which applies both sentences
above, never returns a companion-only component from `pick` / `primary`, and
its `wai wrap` tool refuses to write an envelope that fails either check. Parsing stays
format-agnostic: a non-conforming envelope still parses, and the check is what
reports it.
The companion binding carries no per-picture timing. The framing above fixes
the bytes of a separately carried enhancement stream, not how its access units
align picture by picture with its base outside a timed container; this
revision does not pin that alignment, so the embedded form is the unambiguous
one until it does.
**Licence classes.** Every registered capability also carries an IP class —
`codecs::capability_license(cap)` ∈ {royalty-free, patent-pool, proprietary,
non-commercial}, with `is_royalty_free(cap)` as the predicate. It is a registry
property (not a per-file manifest claim — a codec's licence can't be honestly
asserted in an envelope's header), so a deployer can audit a title or a whole
catalogue in code: encode only to royalty-free capabilities, or flag every
pool/proprietary one. The per-title choice of which toll road to pay is a
property of the format, enforceable, not a policy on a slide. The
classification is exhaustive with no default class: a capability registered
without an explicit class is a registry defect the reference tests reject, so no
codec becomes royalty-free by omission. The same tests hold that every floor and
recommended-set capability is royalty-free.
See [`research/media-codec-registry.md`](research/media-codec-registry.md) for
the per-capability standard / spec number / verified royalty status / reference
library, what each named standard's decoder conformance fixes (§7), and the
remaining spec follow-ups.
---
## 6. Confidentiality (OPTIONAL — encrypted payloads / private channels)
By default a WAI payload is **plaintext**: any sink that advertises the
named capability (§4–§5) can decode it. This is correct for public
media — a shared world, a broadcast film. Some channels are instead
**private**: only an intended group may recover the content, and any
relay or multiplexer that carries it MUST be able to route, meter, and
attest the bytes **without** reading them.
Confidentiality is an OPTIONAL layer that is **orthogonal to the
capability**. It wraps the payload bytes; the capability still names how
to decode the *plaintext* once recovered. A sink decrypts first, then
runs capability dispatch (§4) on the plaintext.
### 6.1 Manifest field
A manifest MAY carry a `security` object:
```json
"security": { "encryption": "mls-sframe", "kid": 0 }
```
- `security.encryption` — encryption scheme id. Absent, `null`, or
`"none"` ⇒ the payload is plaintext (the default; §1–§5 unchanged).
`"mls-sframe"` ⇒ the payload is an SFrame (RFC 9605) ciphertext object
whose group key is agreed by MLS (RFC 9420) — the
`draft-jennings-moq-e2ee-mls` binding.
- `security.kid` — the SFrame key id selecting which sender/epoch key
opens the object. It is also carried in the SFrame header; the
manifest copy lets a multiplexer route without parsing the payload.
`media`, `intent`, `conditioning.kind`, and
`model_requirement.capability` continue to describe the **plaintext**
codec. They are NOT encrypted and remain visible for routing —
confidentiality protects the *content*, not the *shape*.
### 6.2 Keys are a requirement of existence
Exactly as the model behind a neural capability is never transported
(§1), the **group key is never transported in the WAI file**. Group
membership is established out of band via MLS; each member derives the
32-byte SFrame base key from the group's exporter secret under the label
`"moq-jwp sframe base key"`. A sink that is not a group member cannot
derive the key and the file is **inert at that sink** — the
confidentiality analog of a missing capability.
### 6.3 Relay transparency and attestation
A WAI relay or multiplexer that carries an encrypted payload MUST treat
it as opaque: it MUST NOT require the plaintext to route, meter, or
attest, and MUST NOT attempt capability dispatch on ciphertext. The JWP
receipt chain ([`extensions/jwp-receipts.md`](extensions/jwp-receipts.md))
commits over the **ciphertext** content hash, so per-object delivery,
energy, and integrity are attested end-to-end without any relay holding
the key. Content secrecy (SFrame/MLS) and delivery attestation (JWP) are
independent layers over the same bytes and compose: a relay proves it
forwarded the exact sealed bytes it was given while never learning what
they say.
### 6.4 Decrypt-then-dispatch
A confidentiality-aware sink MUST, before running §4:
1. If `security.encryption` is absent / `null` / `"none"`, proceed to §4
on the payload unchanged.
2. Else, if the sink does not implement the named scheme, or holds no
key for `security.kid`, the file is **inert at this sink** — return a
clear "no key / unsupported encryption" error. It MUST NOT feed
ciphertext to a codec.
3. Else recover the plaintext payload via the named scheme (for
`mls-sframe`: SFrame `open` under the member's base key), then run §4
on the recovered plaintext.
A sink that does not implement confidentiality at all MUST refuse an
envelope whose manifest carries a non-`none` `security.encryption`
cleanly, rather than mis-decode ciphertext.
Byte-level SFrame framing, the SFrame key schedule, and the MLS binding
(including per-sender keying for multi-sender channels) are specified in
[`extensions/confidentiality.md`](extensions/confidentiality.md). The
reference implementation is the `moq-sframe` (SFrame) and
`joule-comm-mls` (MLS exporter → base key) crates, with browser bindings
in `joule-comm-mls-wasm`; `Track::e2e_encrypted` is the switch that
selects this path. Live: https://wai.transaction.science/private-channel
---
## 7. Conformance
- A **conforming sink** MUST: implement the container (§2), capability
dispatch (§4), and the mandatory floor (§5).
- A **conforming encoder** MUST emit containers (§2) that any
conforming sink can read; the payload MUST be the canonical byte
stream for the registered capability.
- A decode is conformant by the criterion its capability's registry class
(below) sets. A `StandardDefined` or `NeuralIntegerExact` capability is
verified by **bit-exact decode-equivalence**: against the in-crate decoder or
wrapped reference library for the capabilities the reference implementation
decodes (`codecs::sink_capabilities()` and the in-crate neural and WAI-native
decoders), and against the named standard's own conformance bitstreams and
decoded outputs for a sink-supplied codec. A `GenerativeDeterministic`
capability is verified by bit-exact generation-equivalence at its pin. A
`StandardTolerance` capability conforms by its named standard's own
decoder-conformance criterion around a reference, not by bit-exact equality
with one library's output; a `StandardUnclassified` capability conforms by its
named standard's criterion, which this revision has not classified; WAI adds
no bit-exact requirement to either. A `NeuralEntropyExact` capability
conforms, as WAI registers it, at the entropy-decoder output (for
`wai.image.jpegai`, the criterion its named standard sets on the
reconstruction is not read in this revision).
`NeuralFloat` capabilities make no claim that their reconstruction is
bit-exact across sinks, and `Behavioral` ones conform by similarity. The WAI
Rust reference impl in `wai-rs/` ships a test suite that carries every
registered capability through the full WAI envelope (`cargo test --lib`,
`tests/carriage.rs`).
### Replicate-soundness — the integer-entropy contract (normative)
`intent = replicate` promises the reconstruction the capability's registry class
fixes (the classes are below). For every class that backs it except two, that is
a **byte-exact reconstruction**: every conforming sink that decodes the payload
produces the same bytes of the medium (*decode-equivalence*,
[determinism-tiers](extensions/determinism-tiers.md) §2). The two exceptions are
the standard codecs whose named standard fixes less than the bytes
(`StandardTolerance`) or has not been checked (`StandardUnclassified`); over those,
`replicate` promises that standard's decoder conformance and no more (*What
`replicate` promises over a standard codec*, below).
For a **neural** capability `replicate` promises decode-equivalence, and this
revision does not substitute a standard's decoder conformance for it. The one
registered neural capability with a named external standard is
`wai.image.jpegai` (ISO/IEC 6048). That standard's conformance part may set a
criterion on the reconstruction — an overview of the standard says the part
"considers the possibility that a decoder is conformant to the standard without
having bit-exact reconstruction" — but this revision has not read it, so holding
`wai.image.jpegai` to the neural rule is a conservative choice pending that
reading, not a finding that its standard leaves the reconstruction unbounded
(`NeuralEntropyExact`, below).
Decode-equivalence is only sound if the decode is byte-identical on
every machine — and that is **not** automatic. A learned
codec's entropy decode desyncs the instant the decoder's scale-bucket / σ
computation drifts from the encoder's by one float ULP: the bucket assignment
flips and the rest of the stream corrupts. So a neural decode that runs **float**
inference through a runtime — which chooses kernels, accumulation order, vector
width and fused multiply-adds per device — is reproducible only on the *same
build*, never guaranteed across hardware.
IEEE-754 basic operations are themselves correctly rounded. Float reproduces
across machines only when one implementation fixes everything a runtime leaves
free: the operations and their order, their precision, no contraction or
reassociation, no library function whose last-place error can reach the output —
and runs in the default floating-point environment (round-to-nearest-even, no
flush-to-zero, no denormals-are-zero), which a host process can change. These are
properties of one build and one process that neither the envelope nor the
registry can state, which is why the rule below requires integer arithmetic.
Therefore a neural capability MAY back `intent = replicate` **only** if its
entire decode path — entropy parameterization *and* synthesis — is
integer / fixed-point, with no float operation anywhere (the **integer-entropy
contract**). That is the only construction by which a neural capability is
registered at `decode-equivalence`. Two weaker properties MUST NOT back
`replicate`:
- **`entropy-consistency`** — the entropy decode (the decoded symbols, and the
parameters they are decoded with) reproduces on every machine, but later stages
run float, so the reconstruction may differ between conforming sinks. It is
necessary for a sound neural `replicate` — without it the decode desyncs — and
not sufficient, because `replicate` promises the reconstruction, not the
symbols.
- **A reconstruction pinned by one implementation** — float stages in a fixed
evaluation order, reproducible across machines only under that
implementation's build and the process's floating-point environment. Those
conditions are the ones the envelope and the registry cannot state, so a
`replicate` resting on them promises something no sink can check from what it
received.
The reference impl factors the halves of the contract into ORT-free, pure-i64
modules a codec composes: `int_entropy` (the deterministic scale→bucket step
that removes the float-σ desync), `int_synth` (integer synthesis), and the
integer rANS — assembled into a full conditional decode by `int_hyper_synth`
(`wai.neural.int_hyper`: factorized rANS-decode `z` → integer hyper-decoder
`h_s` → σ,μ → integer-σ bucket → rANS-decode residual → `y_hat = r + μ` →
integer synthesis — both bitstreams entropy-coded, no float anywhere). This is
a property of the capability, classified in the
registry as `codecs::capability_replicate_class(cap) -> ReplicateClass`:
- **`NeuralIntegerExact`** — integer by construction; byte-identical on every
machine; registered at `decode-equivalence`, and the only neural class that
backs `replicate`. (`wai.neural.int_synth` is synthesis only;
`wai.neural.int_hyper` is the full conditional codec — σ source, entropy, and
synthesis all integer; `wai.neural.int_mlicpp` is the channel-autoregressive ×
checkerboard entropy model on integer networks, so the σ it re-derives before
each of its `2·K` passes is integer too; `wai.video.int_hyper`,
`wai.audio.int_codec` and `wai.splat.int_codec` are integer throughout as well.)
- **`NeuralEntropyExact`** — the entropy decode is integer by construction, so
the decoded symbols are byte-identical on every machine; later stages run float.
Registered at `entropy-consistency`. An encoder MUST NOT emit `intent =
replicate` for one of these. (`wai.image.jpegai`: integer mANS entropy decode
and integer scale-index derivation on both reference decode paths; float
dequantisation, latent refinement, post-filters and colour conversion. What
its exact decoder pins, and under which conditions, is stated in
[determinism-tiers](extensions/determinism-tiers.md) §5. This class is the
neural rule applied to it, not a statement about its standard's conformance on
the reconstruction, which this revision has not read; see *`wai.image.jpegai`
and the standard classes*, below.)
- **`GenerativeDeterministic`** — the *create*-side of byte-exact conformance.
A generator (`intent = create`) whose entire pipeline is integer/fixed-point
and pinned to `(model, prompt, seed, steps)`, so the **generated** content is
byte-identical on every machine. There is no original to reconstruct, yet the
output hash is portable and receiptable — *generation-equivalence*. The
fixed-point sampler is mandatory: a float RNG or float sampling step desyncs
the stream exactly as a float σ does. (`wai.generate.spectral`: a pure-integer
spectral synthesis — prompt+seed draw integer-LUT sinusoid components by a
`splitmix64` PRNG; the float `sin()` that bakes the LUT runs once at
model-build, never at generation.) Distinct from `Behavioral`, which conforms
by similarity and never reproduces bytes. It generates rather than
reconstructs, so it does not back `replicate`.
- **`NeuralFloat`** — runs float inference; exact only on the same build. An
encoder MUST NOT emit `intent = replicate` for one of these; `perceptual` /
"exact on this build" is the honest claim. The registry claims no determinism
tier for these.
- **`StandardDefined`** — the reconstruction is specified exactly: by the named
standard, for the lossless formats whose decoded output it determines
(`wai.image.png`, `wai.audio.flac`, `wai.text.zstd`, `wai.text.xz`) and for the
video codecs whose decoder conformance requires every output sample to equal
the specified decoding process's (`wai.video.avc`, `wai.video.hevc`,
`wai.video.vvc`, `wai.video.vp9`; clauses in the table below), or by the
WAI extension that defines the capability's `*-equivalence` over integer /
fixed-point state (world, score, film, quantum, ternary, the haptic signal, the
integer inter-frame codec and the other WAI-native capabilities). `replicate`
promises the same bytes on every conforming sink. An extension's equivalence
holds given its inputs: where it composes other capabilities' decoded output (a
`wai.audio.scene` source decoded through `wai.audio.opus`, say), it is only as
exact as those capabilities' classes. `wai.audio.scene` is the one registered
capability whose output depends on envelopes it references rather than
carries, so the reference registry does not report it byte-exact from the
capability alone (below). No neural decode is in this class, and a
capability enters it only with a recorded basis — the conformance clause or
extension that fixes its output (the reference registry tests pin one per
member); without one, a standard codec is `StandardUnclassified`.
- **`StandardTolerance`** — a standard codec whose named standard, for at least
some conforming payloads, holds decoders to a criterion around a reference
rather than to identical output. For Opus and JPEG XL the clauses read state it
as numeric thresholds. For JPEG and JPEG 2000 the text read points to a
criterion without stating its bound (T.81 leaves the accuracy of dequantisation
and IDCT to its Part 2, which was not read; only the table of contents and terms
of ISO/IEC 15444-4 were read), so this revision states none. For IVAS, an
implementation based on its floating-point reference code whose output is not
bit-exact is tested by a non-bit-exact procedure instead: a per-frame
loudness-difference corridor for stereo and immersive operation, and for mono
operation the procedure of TS 26.444, which was not read (3GPP TS 26.252
§7.2.1). For AV1, AVIF and AV2 when film grain is signalled it is the absence
of "perceptually significant differences" from the reference grain synthesis,
which the AV1 specification leaves undefined (§7.2: its definition "is beyond
the scope of this specification") and the AV2 specification leaves to others
to define (§7.1). `replicate` promises what that conformance promises: every
conforming sink reconstructs within the standard's criterion — for film-grain
AV1 and AV2, a criterion no document WAI cites quantifies. It does not promise
byte identity across sinks.
- **`StandardUnclassified`** — a standard codec whose named standard's
decoder-conformance clauses this revision has not checked. `replicate` promises
what that conformance promises; the registry does not say whether that is byte
identity.
- **`Behavioral`** — a sink-generator path that conforms by similarity, not
bytes (`wai.semantic.*`).
#### What `replicate` promises over a standard codec
A standard codec's reconstruction is what its named standard's decoder
conformance fixes, in that standard's own output domain; `replicate` promises that
and no more. The registry classes each one by what the standard fixes (the clauses
cited are the ones read; the evidence, and what was not read, is in
[`research/media-codec-registry.md`](research/media-codec-registry.md)):
| class | capabilities | what the named standard fixes |
|---|---|---|
| `StandardDefined` | `wai.image.png`, `wai.audio.flac`, `wai.text.zstd`, `wai.text.xz` | the decoded output exactly: lossless formats (PNG, RFC 2083 — its filters are exact integer operations; FLAC, RFC 9639) and lossless byte formats |
| | `wai.video.avc`, `wai.video.hevc`, `wai.video.vvc` | every sample of every cropped decoded picture a conforming decoder outputs equals the value the specified decoding process produces (ITU-T H.264 (V16, 06/2026) §C.4; H.265 (V11, 01/2026) §C.5.1; H.266 (V4, 01/2026) §C.5.1); processing an SEI message only signals, such as film grain synthesis, is outside that decoding process |
| | `wai.video.vp9` | output frames "identical in all respects", in the same order, to those of the specified decoding process (VP9 Bitstream & Decoding Process Specification v0.6 §8.1) |
| `StandardTolerance` | `wai.audio.opus` | output within `opus_compare`'s thresholds of the reference decoder, with the same final range-decoder state (RFC 6716 §6) |
| | `wai.image.jpeg` | decoding "with appropriate accuracy", the accuracy of dequantisation and IDCT specified in Part 2 (ITU-T T.81 §7, A.3.3); Part 2 (ITU-T T.83) was not read, so the bound is not stated here |
| | `wai.image.jxl` | decoded samples within per-test peak-error and RMSE thresholds of reference images (ISO/IEC 18181-3 §4.1–§4.3) |
| | `wai.image.jp2`, `wai.video.j2k` | decoded components compared with reference components by error metrics, and a reversible path its definitions describe as lossless (ISO/IEC 15444-4); only the table of contents and terms of its public preview were read, so the metrics and thresholds are not stated here |
| | `wai.video.av1`, `wai.video.av1.lossless`, `wai.image.avif` | identical output frames, unless the payload signals film grain; then identical frames before grain synthesis, and output frames that "do not have perceptually significant differences" from the reference grain synthesis, a criterion whose definition the specification places outside its scope (AV1 §7.2) |
| | `wai.video.av2` | as AV1: identical output unless film grain is signalled, then one of the same two options (AV2 v1.0.0 §7.1) |
| | `wai.audio.ivas` | output bit-exact to the test sequences, or, for an implementation based on the floating-point reference code whose output is not, a non-bit-exact procedure: TS 26.444's for mono operation, a per-frame loudness-difference corridor for stereo and immersive operation (3GPP TS 26.252 V19.2.0 §7.1, §7.2.1) |
| | `wai.audio.iamf` | its substreams include Opus (above), and renderers are out of its scope |
| `StandardUnclassified` | `wai.video.evc`, `wai.video.evc.baseline`, `wai.video.avs3`, `wai.video.lcevc`, `wai.audio.mpegh`, `wai.audio.avs3`, `wai.audio.ac4`, `wai.mesh.draco`, `wai.pc.gpcc`, `wai.pc.vpcc`, `wai.splat.sog`, `wai.haptic.mihs`, `wai.meta.hdr10plus`, `wai.meta.dovi`, `wai.prior.nnc`, `wai.tensor.nnc` | not checked in this revision (all sink-supplied; `wai.splat.sog` names no frozen standard yet) |
| | `wai.audio.aac` | not checked in this revision; three decoders on one host gave three different PCM streams from one ADTS stream, so it is not placed where byte identity would be promised |
| | `wai.mesh.glb`, `wai.splat.spz` | the payload bytes pass through intact; what a sink decodes from them is not classified here (a glTF binary may carry JPEG images in its buffer and compressed geometry through extensions, and glTF 2.0 specifies an asset format, not a decoder conformance over what is rendered; SPZ stores quantised attributes) |
A conversion a sink applies after the standard's decode is not part of the
promise. A standard fixes its decoded samples at their own depth, layout and
colour representation, and none of those above fixes a conversion to another: PNG
sample-depth reduction (RFC 2083 §10.4 gives two methods), YUV→RGB for AV1 and
AVIF, JPEG's colour space (outside T.81's scope, §4.1), rendering an IAMF mix to a
loudspeaker layout. The reference sink returns `RGB8` images and f32 PCM, so its
output buffers include such conversions; they are the reference implementation's,
and this revision does not specify them.
#### `wai.image.jpegai` and the standard classes
`wai.image.jpegai` has a named standard, ISO/IEC 6048, but its registry class
(`NeuralEntropyExact`) comes from the neural rule above, not from what that
standard's decoder conformance fixes. What this revision has established, and what
it has not:
- JPEG AI sets its bit-exact conformance point at the entropy-decoder output, and
one codestream may be reconstructed through up to three synthesis transforms,
which a profile or the encoder can restrict (an overview of the standard, arXiv
2510.13867; [determinism-tiers](extensions/determinism-tiers.md) §1).
- The same overview says the conformance part, ISO/IEC 6048-4, "specifies the
requirements for generating a JPEG AI-compliant reconstruction" through a
testing suite for each profile and level pair, and "considers the possibility
that a decoder is conformant to the standard without having bit-exact
reconstruction", which it also calls "the possibility of standard compliance
with a certain leeway"; outputs of the processes after entropy decoding "may
diverge slightly from the reference". Read together, these passages point to a
criterion on the reconstruction around a reference, the kind
`StandardTolerance` records. The overview does not state such a criterion.
- ISO/IEC 6048-4 itself has not been read (the overview describes it as a draft
when it was written), so this revision does not state whether it sets such a
criterion, of what form, or how wide.
Classing `wai.image.jpegai` as `NeuralEntropyExact`, so that `replicate` over it
is refused, is therefore a conservative choice pending a reading of Part 4. It is
not a finding that the standard leaves the reconstruction unbounded. If Part 4
states a criterion on the reconstruction, `wai.image.jpegai` is a candidate for
`StandardTolerance`, over which `replicate` would promise that criterion; moving
it there would also take an exception to the neural rule above, which admits a
neural capability to `replicate` only by the integer construction.
This is not the choice made for the standard codecs. Over a `StandardUnclassified`
codec, whose conformance clauses are unread, and over AV1 or AVIF with film grain,
whose criterion the AV1 specification leaves undefined, `replicate` is honoured,
with its promise narrowed to the standard's conformance. Those capabilities keep
the behaviour they had before this revision. `wai.image.jpegai` had been
registered at `decode-equivalence`, which its float stages do not meet, and it was
moved to a class that does not back `replicate`. The two treatments differ because
of those choices, not because of anything the standards' texts were found to say.
**Registry change in v0.4.0 — a downgrade.** `wai.image.jpegai` was classed
`StandardDefined`, and §5 listed it at `decode-equivalence`. Its decode has float
stages, and a sink without the integer weight bundle decodes it through a float
ONNX Runtime path, so neither held as a property of the capability. It is now
`NeuralEntropyExact`, registered at `entropy-consistency`, and it no longer backs
`replicate`; before, the reference strict check passed a `replicate` envelope over
it whenever the prior declared an integer contract.
**Registry change in v0.4.0 — the standard codecs.** Every standard codec was
classed `StandardDefined`, and the first form of this revision's §3 promised the
same bytes on every conforming sink over all of them. The previously registered
capabilities in the `StandardTolerance` and `StandardUnclassified` rows above are
now in those classes. `replicate` over them is still honoured; what it promises is
narrower — the named standard's decoder conformance, not byte identity across
sinks. No other previously registered capability changes class. The broadcast and
streaming codecs this revision registers (§5) enter with the classes in the table.
A conforming sink that receives `intent = replicate` for a capability whose class
is `NeuralEntropyExact`, `NeuralFloat`, `GenerativeDeterministic` or
`Behavioral` MUST refuse the replicate claim (decode as perceptual or reject). The
capability is the one it decodes through: `model_requirement.capability`, or the
fallback when it decodes via §4 step 5. The
reference impl checks this per-envelope in `decode_envelope_strict`
(`codecs::replicate_refusal`) in two steps. First the capability's registry
class: only `NeuralIntegerExact` and the three standard classes pass, whatever the
envelope declares (`ReplicateClass::replicate_promise` states what each
promises). Then, for a `NeuralIntegerExact` capability, the pinned prior: it must
declare an integer-exact contract (`DeterminismClass`), and a prior that declares
the wire form of its artifact counts as integer-exact only if that form is
established to reconstruct identical tensors at every reader
([prior-carriage](extensions/prior-carriage.md) §5); no form is yet, so a
`replicate` whose prior declares one is refused. The prior check reads the
sender's declaration; the class check is what ties it to the capability, so an
envelope whose prior declares an integer contract over a float or entropy-only
capability is refused. `decode_envelope_strict` decodes only through
`model_requirement.capability`, so that is the one it checks. On the encoder
side, `wai wrap`, which pins no prior, writes `intent = replicate` only where that
check accepts it unpinned — over the three standard classes — for the capability
and for any fallback it declares, or, in the `WAI2` companion form (§7.1), for the
base payload's capability and each companion's, and otherwise refuses unless
given another intent (`codecs::unpinned_envelope_intent`). The registry class is
also the *static* audit of the same property: `wai capabilities` prints it per
row and reports the count of neural integer-exact capabilities, so a deployer can
require "dispatch `replicate` only to a cross-hardware-sound decode", or only to
a capability whose output is the same bytes on every conforming sink
(`codecs::is_cross_decoder_exact`), in code, exactly as it audits royalty
status. The class's promise
(`ReplicateClass::replicate_promise`) and `is_cross_decoder_exact` say the same
about byte identity for every registered capability but one. A capability whose
output is computed from other envelopes' decoded output
(`codecs::composes_decoded_sources`: `wai.audio.scene`) has the class
`StandardDefined` and the promise `ReplicatePromise::ByteExact`, because its mix
is exact given the PCM its sources decode to; `is_cross_decoder_exact` answers
from the capability alone and is false for it, because a source decoded through
`wai.audio.opus`, say, may decode differently on two conforming sinks. A deployer
auditing for the same bytes uses `is_cross_decoder_exact`, not the promise. Once
the capabilities of the envelopes a scene references are known,
`codecs::is_cross_decoder_exact_with_sources` is true when the scene's class and
every source's promise the same bytes; it answers false when it cannot tell — no
source given, or a source outside `wai.audio.*`, which a scene may not reference.
The `replicate` check above covers one envelope, so `replicate` over a scene is
honoured and promises the same mix only given the same source PCM; each source is
an envelope of its own, checked by its own class. That promise covers the output
the standard or extension specifies, before any conversion a sink applies
afterwards (above), so a hash over a converted output is portable only between
sinks that also agree on the conversion. The classification is exhaustive with no
default class: a capability registered without one has no class, and the registry
tests reject it.
This makes the cross-hardware property explicit per capability: a neural
capability whose decode is *integer all the way down* can put its reconstruction
in a receipt that verifies on another machine, and the registry records which
capabilities are.
Reproducibility is a **spectrum**, not a single point, and the `ReplicateClass`
values above span it. The neural classes map onto the two tiers
[`extensions/determinism-tiers.md`](extensions/determinism-tiers.md) names.
`NeuralIntegerExact` capabilities are registered at **`decode-equivalence`** —
the whole decode to the final medium reproduces on every conforming sink, so the
rendered result has a portable hash; this is the tier `replicate` over a neural
capability promises, and the precondition for a hard
[reconstruction binding](extensions/reconstruction-binding.md).
`NeuralEntropyExact` capabilities are registered at **`entropy-consistency`** —
the entropy decode reproduces across devices (integer entropy arithmetic or
explicit parameter transmission), the tier at which JPEG AI sets its bit-exact
conformance point; it does not back `replicate`. `NeuralFloat` capabilities claim
neither tier.
### Machine-checked totality (informative)
The cross-architecture matrix establishes byte-exactness by **sampling**: it
decodes fixed vectors on five real OS/arch combinations. `wai-verify/` supplies
the complementary half by **reasoning** — a model checker (Kani/CBMC) over the
same `#[path]`-included sources, for every input in a bounded window.
What it discharges is the property the byte-exactness claim rests on:
**arithmetic totality**. Rust integer overflow *panics in debug and wraps in
release*, so an overflowing decoder is not one implementation but two, and which
one a sink runs depends on how it was compiled. A decode proved free of
overflow, out-of-bounds access and non-termination is a decode whose bitstream
denotes exactly one symbol sequence.
`matmul`'s accumulation is total for fixed-point operands of realistic magnitude (±2^31 at Q16). This one is a *conditional* result and is stated as such: the product is formed in i128 then truncated to i64 and accumulated with a plain `+=`, which genuinely does overflow for large enough operands. Nothing in the signature constrains magnitude, so callers inherited that safe-operating range silently; the harness turns it into a written, checked precondition rather than reporting an unstated contract as a defect.
Currently proved for the integer transformer kernels (`int_transform`): `softmax` is total over the whole fixed-point path (ln2 reduction, i128 polynomial, shift, division) and its output **sums to exactly `2^PROB_FRAC`** with no negative probability — the normalisation the entropy stage depends on, since a denormalised distribution becomes a denormalised CDF. The checker also shows the degenerate uniform fallback to be *unreachable*; that branch would violate the same invariant if it ever fired, so the property currently holds by unreachability rather than by construction, and the code says so at the site.
Currently proved for the scale→bucket primitive (`int_entropy`): `det_build_index` always returns an index addressing a real scale-table entry, and is **monotone in σ** — a larger σ never selects a smaller bucket. The monotonicity is proved for an *arbitrary* edge table rather than only an ascending one, so it does not rest on a precondition a caller might not maintain; it is the property the bucketing exists to guarantee, and a non-monotone bucketing would mis-order the table without ever panicking.
Currently proved for the integer rANS coder: `RansDecoder::new` is total for
every input slice; `decode_categorical` is total and returns an in-alphabet
symbol for all admissible CDFs and all streams in the window; and `decode`'s
bypass escape is total. Each harness carries a `kani::cover` obligation, so a
proof cannot pass vacuously on assumptions that admit no state.
This is not redundant with the matrix. The matrix decodes *well-formed* vectors
and therefore cannot see defects only a malformed stream reaches; four such
defects in the bypass escape — a stream-controlled shift distance, two
saturating-arithmetic gaps, an unbounded read — were found this way and fixed,
with the conformance vectors confirming the fix changed nothing a conforming
encoder can produce.
The `wai.video.ssai` decision policy is **test-backed, not proof-backed**: the natural theorem — that `decide` never proposes a fill exceeding the funds, the avail duration or the slot count — did not close (three configurations, up to 900s each). The obstacle is that the decision sorts on a heap-allocated key, so the model carries `memcmp` and the allocator machinery rather than the budget arithmetic. Stubbing that away would prove a property of the stub. What *is* proved there is narrower: a fresh decision bills nothing until its beacons arrive, so a fill cannot be mistaken for delivery.
`layernorm` closes only at ±2^10 — *below* realistic Q16 activation magnitude (at ±2^20 it did not close in 25 minutes). Its guarded divide and surrounding arithmetic are therefore established for small operands only, not over the kernel's working range. The obstacle is `isqrt` over a symbolic u128, which is a limit of bounded model checking rather than a property of the code. `attention`, `linear`, `igdn` and the composed `TransformerBlock` are **not covered at all**. The technique does not reach everything, and this section records where it stops rather than listing only what it reached.
**Scope, stated plainly:** these are *bounded* proofs — small symbolic CDFs,
fixed-length symbolic streams, explicit unwind limits — not universal ones, and
they cover the stream-controlled paths rather than the whole crate. A CDF
supplied by internal tables is still assumed well-formed. The verification
claims what it checks and no more.
---
## 7.1. Multi-rendition envelope (v1.1 extension)
The v1.0 single-payload envelope is sufficient when one source produces
one rendition for one capability. v1.1 adds an OPTIONAL multi-payload
form for cases where the source emits the SAME content in multiple
renditions and lets the sink pick — typically because the sink's
compute budget, bandwidth budget, or runtime preference (browser-
native vs WebGPU vs WebNN vs native ML) differs at decode time.
The `model_requirement.fallback` field in v1.0 is **declarative** — it
names a capability the sink CAN look for. v1.1 makes fallback (and
multi-rendition selection generally) **executable** by carrying every
declared capability's payload in one envelope.
### Self-contained-ecosystem note
In a controlled-deployment ecosystem (every sink ships from one
authority and therefore has a known capability set) the multi-rendition
form is NOT a "graceful fallback for missing capability" — every sink
has every required capability. Renditions exist for **policy selection**:
high-quality on a desktop sink with WebGPU; low-quality on a phone sink;
quality-vs-latency by bandwidth headroom; native vs WebNN by which
runtime is initialized. The sink picks by deployer-defined policy, not
by which capability happens to be installed.
### v1.1 wire format
```
+--------+----------------+-------------------+----------------+----...---+
| "WAI2" | u32 man_len | manifest (JSON) | rendition table| payloads |
+--------+----------------+-------------------+----------------+----...---+
```
- Magic is `WAI2` (distinct from v1.0's `WAI1`; sinks dispatch by magic).
- Manifest is JSON with a single `renditions` array of self-contained
rendition entries, in deployer-preferred order:
```json
{
"wai": "1.1",
"media": "audio",
"intent": "replicate",
"renditions": [
{ "capability": "wai.neural.encodec32", "kind": "encodec_tokens" },
{ "capability": "wai.audio.opus", "kind": "opus" }
],
"target": { "sr": 48000, "dur": 5.0 }
}
```
Each entry has its own `capability` (the dispatch key) and `kind`
(the codec id matching the bytes in the corresponding payload).
- Rendition table: `u16 n_renditions | n × (u32 offset, u32 length)`,
offsets relative to the start of the payloads block. The table's
i-th entry corresponds to `renditions[i]` in the manifest.
- Payloads block: the rendition byte ranges, packed contiguously.
- `n_renditions` MUST equal the manifest's `renditions.length`.
### Selection algorithm
A v1.1-aware sink MUST:
1. Read the manifest, get the ordered list of `model_requirement`
entries.
2. Walk the list in order; pick the first entry whose capability the
sink either advertises OR whose declared backend the sink prefers
under its deployer policy.
3. Read the corresponding rendition's bytes from the payload block.
4. Dispatch as in v1.0 §4.
A v1.0 sink that encounters a `WAI2` envelope MUST refuse it cleanly
(unknown major). No silent fallback to the first payload — that would
hide a major-version mismatch.
### Companion components (descriptors bound to a payload)
A `WAI2` component carries an OPTIONAL `role`. Absent ⇒ `"rendition"` (a
selectable alternative of the same content — the default above).
`"companion"` marks a component **applied *with* the chosen rendition, not
instead of it**, naming the capability it binds to in `companion_of`. It
carries the payloads that are not standalone media — the capabilities §5
registers as **companion-only**: the HDR dynamic-metadata descriptors
`wai.meta.hdr10plus` / `wai.meta.dovi` (SMPTE ST 2094), which describe a video
payload, and the enhancement layer `wai.video.lcevc`, which adds residuals to
one. Carried as companions, the companion and its base ride in the **same
envelope**, so the binding is intrinsic — not a spoofable sidecar. This
revision registers no capability for immersive-audio mix metadata;
`wai.audio.iamf` carries its own audio substreams, so it is standalone media
and travels as a rendition.
Selection: a sink picks a rendition among the
`role != "companion"` entries, then applies every companion whose
`companion_of` names the chosen component (e.g. the HDR10+ block for the AV1
video the sink picked). `pick`/`primary` never return a companion, nor a
capability §5 registers as companion-only. Static HDR
characteristics (ST 2086 mastering display, HLG transfer) stay in-band in the
video bitstream / a manifest color field and need no companion.
A component with `role = "companion"` conforms only if:
1. its capability is companion-only, or is not registered in this revision. A
registered capability that is not companion-only is standalone media — its
payload decodes on its own — and MUST be carried as a rendition, not as a
companion;
2. `companion_of` is present and names a capability the companion applies to.
An HDR dynamic-metadata descriptor, registered as a companion to a video
payload, applies to a registered capability whose payload is video — the
`video` media class (§3), as the capability's registration places it: every
`wai.video.*` capability that is not companion-only, the neural video codecs
`wai.neural.video_bmshj2018`, `wai.neural.dcvc_rt` and `wai.neural.dcvc_fm`
(§5, *Video:*), and the films `wai.film.linear` and `wai.film.reel`
([linear-film](extensions/linear-film.md) gives a linear film's `media` the
value `"video"`, and a reel is a film with cuts). A capability registered as
video in a later revision joins that class.
`wai.video.lcevc` applies to one of the base codecs §5 lists for it. No
companion applies to a companion-only capability. This revision constrains
no base for a companion whose capability it does not register, nor an HDR
descriptor's base whose capability it does not register;
3. a selectable rendition of that capability is present in the envelope — for
an **enhancement layer**, exactly one, the base encode its residuals were
produced against, and that rendition is the base of no other enhancement
layer (§5). Several descriptor companions MAY bind to one base, and a
descriptor MAY bind to several renditions of one capability.
An envelope with a companion that breaks any of these does not conform (the
reference `WaiMulti::check_component_roles` reports the first break). A sink
MUST NOT apply a companion that breaks rule 1 or 2, nor one whose capability it
does not recognise; a companion that breaks rule 3 binds to nothing, or, for an
enhancement layer, is handled as §5 states. The sink MAY still present the
rendition it picked.
### v1.0 compatibility
v1.0 envelopes (`WAI1`) remain valid and their format is unchanged, except that
a `WAI1` naming a companion-only capability as its `capability` or `fallback`
does not conform (§5; below). Encoders
SHOULD emit `WAI1` when only one rendition is present (simpler form,
wider sink support). `WAI2` is for sources that genuinely benefit from
shipping multiple renditions per file.
### Envelopes the companion rules make non-conforming
The companion rules of §5 and this section change no capability's payload
format and no capability's role (§8). Each enforces something fixed before the
rules were stated:
- **a registration.** `wai.meta.hdr10plus` and `wai.meta.dovi` were registered
as companion descriptors to a video payload, not standalone media.
`wai.video.lcevc` was registered companion-only, with its base codecs, in the
same revision as these rules. Every other registered capability is standalone
media.
- **the definition of a companion.** When this section introduced
`role = "companion"`, it defined a companion as a component applied with the
chosen rendition and naming, in `companion_of`, the component it binds to.
Before these rules were stated, the text rejected none of the envelopes below,
and the reference implementation had no check that reported them (its `pick`
and `primary` could select an HDR descriptor). These do not conform:
- a `WAI1` that names an HDR descriptor as its `capability` or `fallback`,
carrying it as standalone media (§5);
- a `WAI2` that carries an HDR descriptor as a selectable rendition instead of
with `role = "companion"`. `pick` and `primary` no longer select it
(*Selection*, above);
- a `WAI2` that binds an HDR descriptor to a registered capability outside the
`video` media class (rule 2) — an audio, image or text payload, or any other
registered capability rule 2 does not list, a volumetric or world payload
among them;
- a `WAI2` that marks a registered standalone capability as a companion
(rule 1). This includes `wai.audio.iamf` carried as immersive-audio mix
metadata: the earlier text of this section named immersive-audio metadata
beside the HDR descriptors as a payload that accompanies another, and a
reference test carried `wai.audio.iamf` that way. That use did not follow
the registration — `wai.audio.iamf` was registered as an immersive-audio
carrier, standalone media, and no capability for mix metadata alone is
registered — and rule 1 follows the registration;
- a `WAI2` with a companion, of any capability — one this revision does not
register included — that has no `companion_of`, or whose `companion_of`
names no selectable rendition in the envelope (rules 2 and 3).
The first four enforce the registrations; the last enforces the definition of
a companion. Each still parses, and §5 and the rules above state what a sink
does with it. No earlier revision registered `wai.video.lcevc`; this one
registers it with these rules. An envelope that used that string while no
revision registered it is covered by §8's rule for a new registration, as is an
envelope that uses any string a later revision registers.
---
## 8. Versioning
- The `wai` manifest field is `MAJOR.MINOR`. A reader MUST reject an
unknown MAJOR. A reader MUST accept an unknown MINOR by ignoring
fields it does not understand, provided MAJOR matches.
- The container format (§2) and the manifest schema (§3) are frozen
for all of `1.x`.
- New capabilities (§5) MAY be added in any MINOR revision. Existing
capabilities MUST NOT be redefined — once a capability string is
registered for a codec, its payload format is fixed forever.
- A registration also fixes the capability's **role** (§5, §7.1): standalone
media, or companion-only — applied with a base rendition, never on its own.
Changing a capability's role, or narrowing the renditions a companion-only
capability applies to, redefines it. Widening them does not: no conforming
envelope stops conforming, and a reader of an earlier revision that reports
the new binding as not conforming does not apply that companion and can
still present its base.
- Removing or repurposing an existing capability — changing its payload format
or its role — requires a new MAJOR.
- A MINOR revision MAY add a conformance rule that enforces a registration,
or the definition of a manifest field, as it was made, changing no payload
format and no role. Such a rule makes non-conforming only envelopes that used
a capability against its registration or a field against its definition,
and the revision lists every kind of envelope it makes non-conforming; they
still parse. The companion rules of §5 and §7.1 are such rules, and §7.1
lists the envelopes they affect (*Envelopes the companion rules make
non-conforming*).
- Registering a capability gives a string a payload format and a role that no
earlier revision gave it, and the rules of §5 and §7.1 then apply to it. An
envelope that used the string before then used a capability no revision
defined, and no rule checked that use against a registration it did not yet
have: §7.1 constrains an HDR descriptor's base only when the base's
capability is registered, and holds a companion of an unregistered
capability only to naming a base that is present (rules 2 and 3). Leaving a
use unchecked does not make it conform to a registration made later, so the
registering revision MAY make such an envelope non-conforming where it uses
the string against the new registration. This narrows nothing a registration
fixed and is not a redefinition. The kinds of envelope are listed here, once,
for every registration, so a registering revision need not list them again:
registering a standalone capability makes non-conforming a `WAI2` that
carried it as a companion (rule 1) and, when it is outside the `video` media
class, one that bound an HDR descriptor to it (rule 2); registering a
companion-only capability makes non-conforming an envelope that carried it as
a `WAI1` `capability` or `fallback` or as a selectable rendition, that bound
it to a base or a number of bases its registration does not admit, or that
bound another companion to it (no companion applies to a companion-only
capability). Such envelopes still parse.
---
## Appendix A — Reference implementation
`wai-rs/` (Rust). Builds as `lib`, `cdylib`, `staticlib` so the C ABI
in `wai-rs/src/ffi.rs` drops in as `libwai.dylib` / `.so` / `.dll` and
can be called from any language. The crate wraps:
- **image**: `image` crate (PNG, JPEG, AVIF via `ravif`), `jpegxl-rs`
(libjxl 0.11.x).
- **audio**: `opus` (libopus 1.x), `claxon` + `flac-bound` (libFLAC).
- **video**: `rav1e` (AV1 encode) + `dav1d` (AV1 decode).
- **text**: `zstd` (libzstd), `xz2` (liblzma).
Run `cargo test --lib` (with `RUSTFLAGS="-L /opt/homebrew/opt/flac/lib"`
on macOS, or via the committed `.cargo/config.toml`).
Decode speed is an implementation property, not a conformance property: the
integer decoders run faster kernels (SIMD, threads) built to give the same
integer for every output element as the retained scalar reference kernels. That
equivalence is argued by construction and tested, not machine-proved (the
harnesses of §7 do not reach these kernels) — see
[`research/decode-throughput.md`](research/decode-throughput.md) for the
argument, its tests, its limits and measured throughput.
## Appendix B — Why a *capability menu*, not a custom codec
Earlier drafts of WAI defined custom transform + entropy stages for
each medium. That direction was dropped: re-implementing JPEG / MPEG /
Opus poorly is strictly worse than calling the field's mature
libraries. WAI's value is the envelope + capability dispatch + the
neural-shared-prior model, all of which are absent from existing
standards. The zeroth condition's purpose is **availability**, not
codec novelty.
## Appendix C — License
Apache-2.0. The standard and reference implementation are open;
royalty-free implementation is a precondition for adoption (avoiding
the H.264/H.265 royalty trap; following the VP9/AV1/AVIF/JPEG-XL open-
codec precedent).