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

91 KiB
Raw Permalink Blame History

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).
  • 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

{
  "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.

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 §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 §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 §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_hashes 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 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 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 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 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 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
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

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.

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
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
wai.audio.score WSCR container (note events) music as instructions; sink synthesizes, mixdown-equivalence · score
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
wai.feed.state WWLD, sim wai.world.sim.feed0 replay-equivalence · state-feeds
wai.avatar.pose WWLD, sim wai.world.sim.skeletal0 pose-equivalence · avatars
wai.splat.4d W4DS container (per-Gaussian keyframed tracks) frame-state-equivalence · volumetric
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
wai.film.reel WREL container (sealed world + a sequence of shots = camera track + schedule each) reel-equivalence (film-equivalence with cuts) · linear-film
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
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

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 (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.

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 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:

"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) 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. 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 §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 §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):

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 §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 §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 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. 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:
    {
      "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 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 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).