open-standards/wai/extensions/determinism-tiers.md

WAI Extension: Determinism Tiers for Neural Decode

Status: Draft. Names the spectrum of reproducibility guarantees a neural capability can make, so a manifest can declare which one it satisfies and a verifier knows what it may check. Defines two tiers — entropy-consistency (the entropy decode reproduces) and decode-equivalence (the whole decode to the final medium reproduces) — and states which one intent = replicate over a neural capability promises, what a receipt can hash under each, which WAI capabilities are registered at each and at what cost, and what the repository demonstrates today. One optional manifest member carries a tier name: a pin's tier (SPEC.md §3.1). Otherwise a vocabulary and conformance framing over §7. Keywords MUST, MUST NOT, SHOULD, MAY are RFC 2119/8174.

1. Why tiers

Neural decode reproducibility is not binary. A neural decode evaluated in float through an inference runtime does not, in general, reproduce its reconstruction across hardware. Each IEEE-754 basic operation (add, subtract, multiply, divide, square root) is correctly rounded, so it gives the same result for the same operands everywhere; the differences come from what a runtime may choose per device — kernels and accumulation order, vector width, fused multiply-add, reduced precision, math-library functions — and from the process's floating-point environment. A decoder that also derives its entropy parameters in float can, from one diverging bit, select a different distribution from the encoder's and corrupt the entropy decode. A float stage whose operations, order, precision and environment are all fixed does reproduce, within the implementation that fixes them; §5 describes one, and §2–§3 say why that is not a tier and does not back replicate. Three published routes to reproducibility are below. Two make the entropy stage reproducible while leaving the reconstruction to pixels to the implementation, within whatever criterion a conformance specification sets on it:

• The base standard. JPEG AI (ISO/IEC 6048) defines its bit-exact conformance point at the output of the entropy decoder, not at reconstruction to pixels; its entropy pipeline is integer so that stage replicates across devices, while the outputs of later processes "may diverge slightly from the reference". One codestream may legally reconstruct through up to three synthesis transforms, which a profile or the encoder can restrict. Bit-exact picture reconstruction was left out of the first version on purpose. An overview of the standard (arXiv 2510.13867) states all of this. It also says that the conformance part, ISO/IEC 6048-4, "specifies the requirements for generating a JPEG AI-compliant reconstruction", with 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" — "the possibility of standard compliance with a certain leeway". These passages point to a criterion around a reference on the reconstruction; the overview does not state one. Part 4 was a draft when the overview was written; this document has not read it, so it does not say whether Part 4 sets such a criterion, of what form, or how wide.
• Explicit parameter transmission. A published cross-platform learned video codec (arXiv 2606.28027) transmits its entropy model's scale parameters explicitly, through the hyperprior, so the decoder reads them instead of deriving them and the entropy decode is consistent across devices without bit-exact arithmetic. The side information costs bitrate. Same target: a reproducible entropy stage, a reconstruction that may vary.

The third makes the reconstruction itself reproducible:

• A quantised decoder. A published learned image codec (arXiv 2312.11209) quantises the weights and activations of all its decoder subnetworks, without accumulator overflow, so that the reconstructed image is deterministic across devices, and reports its output as bit-exact.

WAI names the two outcomes as tiers, so a capability states which one it makes, an envelope's intent can demand the one it needs (replicate over a neural capability demands decode-equivalence, §3), and a receipt or a provenance binding (reconstruction-binding) can do the same.

2. The tiers

entropy-consistency

The entropy decode reproduces byte-for-byte across devices — the decoded symbols (the entropy-decoder output) have a portable hash — but the reconstruction to the final medium (pixels, samples) MAY differ between conforming sinks. A sink achieves this either by integer entropy arithmetic (deriving the coding parameters with fixed-point ops, as WAI's integer decoders and JPEG AI's entropy pipeline do) or by explicit parameter transmission (the codestream carries the parameters, so no bit-exact derivation is required).

• Conformance criterion: entropy-equivalence — a verifier decodes the entropy stage and compares the decoded symbols, NOT the pixels.
• What a receipt can hash: the codestream and the decoded symbols. The latent formed from the symbols is hashable only where every step that forms it (adding a predicted mean, say) is itself integer or transmitted. The reconstruction has no portable hash, so an energy figure at this tier binds to the codestream and symbols, never to an output every conforming sink reproduces (energy-binding §3); a reconstruction that one implementation pins is that implementation's (§3).
• JPEG AI sets its bit-exact conformance point at this tier, and explicit parameter transmission reaches it (§1). The overview also says JPEG AI's conformance part "considers the possibility that a decoder is conformant to the standard without having bit-exact reconstruction" (§1); whether that part sets a criterion on the reconstruction is not read here, and any such criterion is not one of this document's tiers. WAI registers wai.image.jpegai here (§5). The tier is necessary for a sound neural replicate under SPEC §7 — without it the decode desyncs — but not sufficient, and it MUST NOT back replicate: replicate promises the reconstruction, and this tier leaves the reconstruction free.

Why transmitting parameters stops at this tier. A learned entropy decode desyncs when the decoder derives an entropy parameter (a scale, and from it the distribution the next symbol is decoded with) that selects a different distribution from the one the encoder used. Transmitting the parameter removes that derivation from the decoder: every decoder reads the same value and decodes the same symbols, whatever arithmetic its networks run in. Nothing after the entropy decoder is constrained. The steps that turn symbols into a latent and the synthesis transform still run in the arithmetic the device provides — float, reduced precision, fused or reordered accumulation — and, unless the implementation fixes that arithmetic, their results differ by device. A codestream can pin values; it cannot pin the arithmetic a network is evaluated in, and the reconstruction depends on that arithmetic. So a portable hash of the reconstruction needs every stage after the entropy decode fixed as well, which is the next tier. The two routes compose: a capability MAY transmit parameters and pin its arithmetic.

decode-equivalence

The whole decode to the final medium reproduces byte-for-byte on every conforming sink — the reconstructed pixels (or samples, or attributes) have a portable hash. The capability's registration pins one reconstruction and specifies it in integer / fixed-point arithmetic end to end, entropy and synthesis, so the output depends on nothing a build, a device or a process chooses. Where the base codec admits several conformant reconstructions, this tier fixes one. This is what intent = replicate over a neural capability promises (§3).

A tier is a property of the capability as registered, not of one implementation. An implementation that pins a reconstruction by evaluating float stages in a fixed order (§5 describes one) reproduces it only under conditions of its own build and process (§3). That is a property of the implementation, stated as such; it does not place the capability at this tier.

• Conformance criterion: the medium's *-equivalence (e.g. decode-equivalence for wai.neural.int_hyper, sample-equivalence for wai.audio.int_codec, splat-equivalence for wai.splat.int_codec).
• What a receipt can hash: everything the lower tier can, plus the reconstructed medium itself as the capability's canonical buffer (canonical RGB8 for images, per reconstruction-binding; int16 PCM; the attribute tensor; a per-frame hash for video), under the descriptor that pins the reconstruction. This is the tier at which an energy figure binds to an output a verifier can reproduce (energy-binding §3).
• Where a base standard sets its conformance point at the entropy decoder (JPEG AI, §1), a capability over it reaches this tier only by registering one reconstruction in integer arithmetic; wai.image.jpegai has not (§5). For any capability this tier is the precondition for a hard provenance binding over the rendered content that every conforming sink can check — a decoded-pixel hash is only portable when the reconstruction is pinned.

A capability satisfying decode-equivalence satisfies entropy-consistency by construction; the reverse does not hold.

What a tier covers

A tier is a property of the whole path from codestream to the medium that is hashed, bound, or presented — not of the decode stage in isolation. A sink that decodes conformantly and then alters the result has not satisfied the tier, however faithful the decode itself was.

This is not hypothetical. Published and draft standards define mechanisms that change the medium after, or alongside, a conformant decode, and they arrive through the same pipe as the codestream:

• Post-decode neural filters. ITU-T H.274 (V4, 01/2026) nnpfc / nnpfa SEI messages activate a neural post-filter after decoding, changing output pixels. The filter may be named by URI or carried in-band.

• Energy-saving presentation and quality-recovery metadata. ISO/IEC 23001-11 (green metadata) defines metadata with which a receiver changes the decoded pictures, before display or inside the decode:

  • Attenuation-map information, carried in an SEI message with the attenuation map as an auxiliary picture, describes post-processing to apply to the decoded pictures so the display emits less light. A receiver can also ask the transmitter for such maps with a display attenuation map power reduction request (DAMPR-Req); the maps it receives are applied to the decoded content in the same way.
  • RGB-component statistics and quality levels drive display adaptation. The receiver chooses a quality level, scales the RGB components of the reconstructed frames by the peak signal over that level's max_rgb_component, and lowers the backlight or voltage in proportion (Annex B.2). At any level other than the no-quality-loss operating point, components above that level's max_rgb_component are saturated; for contrast enhancement, components at or below lower_bound are set to zero and those at or above upper_bound to the peak signal (clause 7.4).
  • Quality metrics for cross-segment decoding: a decoder uses them to decide whether to enhance the first picture of a low-quality segment from the last picture of the previous segment, and the enhanced picture becomes the reference for the pictures that follow.

  The standard notes that its metadata can also be used "to get larger energy savings, but at the expense of some QoE degradation".

Other 23001-11 mechanisms leave the decode as it is. Three of them change the payload before it arrives:

• A decoding operation reduction request (DOR-Req) goes from the receiving device to the remote encoder in a point-to-point session. The encoder produces a less complex bitstream and can answer with a response (DOR-Resp) saying how it decided to answer.
• A display power reduction attenuated video request (DPRAV-Req) asks the remote encoder to apply an attenuation map to the video before encoding it. The receiver then gets an attenuated video, and the response (DPRAV-Resp) states the energy reduction rate and quality it can expect.
• Low-power encoding, which produces the low-quality segments that cross-segment decoding repairs, alternates high-quality and low-quality segments to reduce the encoder's power.

In each case the sink decodes what it receives like any other bitstream, but the payload is not the one that would have been sent otherwise. The remaining two alter neither a payload nor a decode's output. Media-selection metadata lets an adaptive-streaming client choose among the available representations by their decoder- and display-power characteristics; what it receives is one of those representations as published. Complexity metrics let a decoder vary its operating frequency, which changes what a decode costs, not what it outputs.

All of this is metadata for saving power, stated in advance; none of it reports energy that was spent. Its energy quantities are expectations: an attenuation map's expected energy saving rate, and the rates a receiver asks for and a transmitter says the receiver can expect, each a percentage (clause 7.4); a representation's decoder-operation reduction ratios and its maximum potential display power saving (clause 8). Complexity metrics are proportions of decoding operations over a period (clause 6.2), and a DOR-Resp acknowledges what the encoder changed. So a sink that acts on this metadata has a prescription, not a measurement, and a tier claim or receipt over its output is bound by the rules below like any other.

This section accounts for every metadata set that the Introduction of the 4th-edition CD text (WG 3 N1864, dated 2026-08-28) names. Read in that text: the Introduction, and in part clauses 6, 7, 8 and 9 and Annex B.2, B.4, B.5 and B.6. The published edition was not read.

The rules:

• A sink claiming a tier MUST evaluate it over the medium it emits. If it applies processing to the decoded medium that alters it — after decode, as attenuation maps and display adaptation do, or fed back into the decode as cross-segment decoding does — it MUST either not apply the processing, or MUST NOT claim the tier for the emitted result.
• A tier claim, a decoded-medium hash or an energy figure over a payload that an encoder altered to save energy — at a receiver's request, such as a decoding-operation-reduction or attenuated-video request, or on its own account, as low-power encoding does — covers that payload, not the one it stands in for, and a receipt over it MUST NOT be presented as covering the payload it stands in for. Spending fewer joules by computing or emitting less is a fidelity choice; a receipt that reports the joules while concealing the degradation states a cost without its consideration.
• A capability's registration SHOULD state whether its payload can carry post-decode processing directives at all. A capability whose payload cannot is unaffected by this section, and saying so is cheaper than leaving it open.

The general rule, which is why this section exists: a determinism claim covers what the sink emits. A hash over a decode that something later modified describes an artifact nobody saw — the hash verifies, and it attests the wrong thing.

A pinned integer derivation run over the decoded medium is processing that alters it, and is the one kind that keeps the tier: wai-synthesis:upscale2 and wai-synthesis:denoise3 (synthesis §4), and the super-resolution derivations of exact-upscale §3 under a prior the sink holds by its SHA-256. Each is a pure integer function of the decoded samples and its pinned parameters, so a sink that emits its output holds the tier of the decode it ran on, and states the derivation, and its prior, with the output (synthesis §9.2, exact-upscale §6).

HDR display adaptation is such processing: a sink makes, from the decoded picture, a gain map or dynamic metadata and its display's headroom, the rendition it presents, and the standards that define it state the computation in real numbers, so the presented pixels differ from sink to sink. The derivations of exact-tonemap §4 and §5 pin it in integer arithmetic: a rendition is a pure function of the decoded samples, the companion's bytes and the headroom, so a sink that presents one holds the tier of the decode it ran on, and states the headroom and the rendition's digest in its rendition record (exact-tonemap §7).

3. Declaring and using a tier

• Declaring. A capability's registration (SPEC §5) states its tier via its *-equivalence criterion, and its registry class carries it (SPEC §7): NeuralIntegerExact capabilities are registered at decode-equivalence, NeuralEntropyExact capabilities at entropy-consistency, and NeuralFloat capabilities claim neither. §5 lists WAI's capabilities at each tier. A capability MAY declare entropy-consistency when it only guarantees the entropy stage. A pin MAY also state a tier in the manifest, as tier (SPEC §3.1), from the closed vocabulary decode-equivalence, entropy-consistency, or none for neither; an encoder writes only those tokens, and a sink reads any other token as none. A stated tier above the capability's registered tier does not conform (tier_exceeds_class): the replicate verdict does not rest on it.
• Over a neural capability, replicate promises decode-equivalence (SPEC §7). An envelope with intent = replicate over a neural capability MUST be over a capability registered at decode-equivalence, which SPEC §7 admits only by the integer construction: an integer / fixed-point decode path with no float operation. Such an envelope MUST pin the parameter set of that capability with a pin that declares decode-equivalence (SPEC §3.1, §7). entropy-consistency MUST NOT back replicate. A neural decode that derives its entropy parameters in float meets neither tier; one that reads them from the codestream, or derives them in integer arithmetic, and runs its later stages in float meets entropy-consistency only. A reconstruction that one implementation pins through fixed-order float stages does not back replicate either: what makes such a stage reproducible — a build that emits no fused or reassociated operations, the default floating-point environment in the running process, library functions whose last-place error cannot reach the output — belongs to one implementation and one process, and neither the envelope nor the registry can state it. That is why wai.image.jpegai is registered at entropy-consistency and does not back replicate (§5).
• Over a standard codec, replicate promises the named standard's decoder conformance (SPEC §7, What replicate promises over a standard codec). For some standards that is the same bytes on every sink; others hold decoders to a criterion around a reference — numeric thresholds in the clauses read for Opus and JPEG XL; for JPEG and JPEG 2000 a criterion whose bound the text read does not state (SPEC §7); and, for AV1 when film grain is signalled, a perceptual criterion the AV1 specification leaves undefined — and over those replicate promises that criterion, not byte identity. The tiers in this document describe neural capabilities. wai.image.jpegai has a named standard too, and the overview's account of its conformance part (§1) points to a criterion around a reference on the reconstruction; if Part 4 states one, that would put it among the standards whose conformance replicate could promise. That part has not been read here. Holding wai.image.jpegai to decode-equivalence, and so refusing replicate over it, is a conservative choice pending that reading, not a finding about the standard; SPEC §7 (wai.image.jpegai and the standard classes) states the choice and how it differs from the choice made for the standard codecs.
• What the reference impl checks. decode_envelope_strict applies SPEC §7 in two steps (codecs::replicate_refusal). First the capability's registry class: only NeuralIntegerExact passes among the neural classes (the three standard classes, which are not neural, are not refused by this rule). The class does not depend on anything the sender declares, so a replicate envelope over wai.image.jpegai or a float codec is refused even when its prior declares an integer contract. Then, for an integer-exact capability, the pin: it must declare decode-equivalence — by tier, or, for a pin without tier, by the reading of its determinism string that SPEC §7 fixes, a substring match (a contract containing int, fixed or integer and none of f32, f64, float). Either way it verifies a declaration, not the arithmetic. Neither step inspects the decode path a sink actually runs; for wai.neural.int_synth and wai.neural.int_mlicpp, the NeuralIntegerExact capabilities the reference neural dispatch decodes, there is only the integer path.
• Receipts. A receipt that carries a decoded-medium hash as reproducible by any conforming sink MUST come from a decode-equivalence capability. A hash over a reconstruction that one implementation pins (§5) is that implementation's, and a receipt MUST NOT present it as the capability's.
• Post-decode processing. A tier claim is void if the sink alters the medium after decode (§2, What a tier covers). This applies to the emitted result, not to the decoder's internal conformance.
• Provenance. The reproducible-reconstruction binding — a C2PA / JPEG-Trust hard binding over decoded pixels — is checkable by every conforming sink only over a decode-equivalence capability; over an entropy-consistency capability only the entropy-stage output is bindable that way. reconstruction-binding §1–§2 also define a binding over wai.image.jpegai as a binding over its exact decoder's pinned reconstruction; that binding is checkable only by that decoder under the conditions in §5–§6.
• Staged delivery. A unit refined in stages holds the weakest tier of its base and every layer applied to it, and entropy-consistency does not pass through a layer (staged-delivery §5).

4. Framing

Both tiers here are reproducibility guarantees: a sink can check them from the bytes it received. A separate axis exists for media whose correctness is a downstream model's behaviour rather than a byte comparison — see task-fidelity, which is a sibling rather than a third tier precisely because such a claim is not sink-checkable from the bytes.

The two tiers are named so that each capability states which one it makes. entropy-consistency is the tier at which JPEG AI sets its bit-exact conformance point, and the tier WAI registers wai.image.jpegai at. decode-equivalence pins one full reconstruction, so the rendered result, not only the entropy stream, is reproducible and hashable; it is what replicate over a neural capability promises. §5 lists the WAI capabilities at each tier, with what the tier costs them.

5. Where WAI offers each tier, and what it costs

decode-equivalence

capability	hashable medium	how the reconstruction is pinned
wai.neural.int_synth	RGB	integer synthesis (post-training quantisation of a float model, with per-layer shifts calibrated on measured activations; of the committed vectors only photo is such a model, and gradient, bloom, facade and the cross-architecture golden of §6 use seeded integer weights)
wai.neural.int_hyper	RGB	integer hyper-decoder, integer scale → distribution step, integer synthesis (post-training quantisation of a float model)
wai.video.int_hyper	per-frame	an int_hyper keyframe, then integer motion-compensated P-frames
wai.audio.int_codec	int16 PCM	integer synthesis over a factorized rANS latent
wai.splat.int_codec	attribute tensor	integer synthesis over a factorized rANS latent
wai.neural.int_mlicpp	RGB	integer hyper-decoder; an integer entropy network re-run before each of the 2·K channel-slice × checkerboard passes, integer scale → distribution step; integer synthesis. Stream values an exact decode cannot hold are refused, not wrapped

| wai.audio.opus.dred.int | the feature sequence (i32 at 2^16) | the draft's DRED feature decoder as the wai-ops/1 graphs of dred-int/1, over the draft's own weights file pinned by SHA-256: weights quantized from their float32 bits, integer activations, tanh and the sigmoid as integer tables (opus-dred §4). The vocoder that renders the features is the sink's and outside the claim |

These seven are integer throughout, are the capabilities the registry classifies as NeuralIntegerExact, and are the neural capabilities that back replicate.

entropy-consistency: wai.image.jpegai, and its exact decoder's pinned reconstruction

The registry classifies wai.image.jpegai as NeuralEntropyExact and registers it at entropy-consistency. This is a downgrade: earlier in v0.4.0 the capability was listed in the table above and classified StandardDefined, and the reference strict check passed a replicate envelope over it whenever the prior declared an integer contract. It moved because its reconstruction runs float stages and the reference sink can decode it through a float ONNX Runtime path, so decode-equivalence never held as a property of the capability (SPEC §7).

stage	arithmetic
entropy decode (mANS) and the scale-index derivation (an integer hyper-scale network)	integer on both reference decode paths — what the capability guarantees
hyper-decoder, context-model and synthesis networks	16-bit-PTQ integer in the exact decoder; float through ONNX Runtime in the fallback
dequantisation, latent refinement, the post-filter chain (the eICCI post-filter is a float CNN), colour conversion	IEEE-754 float in a fixed evaluation order in the exact decoder; float in the fallback

The exact decoder's pinned reconstruction. WAI's exact decoder (jpegai_decode::decode) pins one reconstruction to canonical RGB8: the high-operation-point synthesis, then the post-filters, in the arithmetic above. It reproduces across machines when the conditions in §6 hold: its float stages use only IEEE-754 basic operations in the fixed order of the source, with the gain scaler's exp and every rounding built from those operations (float_repro), so no platform math library is on the path; the target evaluates at the operands' own precision; and the floating-point environment is the default. The decoder checks the last two before decoding (jpegai_decode::check_scope). Those conditions belong to this implementation. That is why the pinned reconstruction is not a tier, does not back replicate, and is bindable only as reconstruction-binding defines. On one codestream, the decoded bytes, and the float values the decoder reports after each stage, have been measured identical on four platforms (§6); values inside a stage are not compared directly.

The exact decoder implements one configuration, which its tests exercise. jpegai_decode::check_codestream accepts a codestream only when its headers select exactly that configuration:

• a 256×256, 8-bit, 4:4:4 picture with no display cropping and the built-in YUV→RGB colour transform;
• the high-operation-point synthesis (synthesis_transform_id 2);
• model_id 0, whose gain, LSBS and LEF tables and residual-scaling constants are tools_0's;
• beta_displacement_log 0 for luma and chroma. The exact decoder does not implement the quantiser's β displacement, so a codestream with any other β is refused, not decoded;
• 160 luma and 96 chroma latent channels, one entropy substream per plane, and no region partitioning, cube flags, 3-D gain or synthesis tiling; LSBS, residual variance scaling and GRFS enabled;
• post-filters only in the forms implemented: one single-tap linear enhancement filter per chroma plane; eICCI untiled on all three planes with the model pair the weight bundle carries (short-list indices 0 and 1 — the bundle format does not record its pair, and the exporter emits only that one); the nonlinear enhancement filter untiled and unmasked, with eight weights; LEF on a luma channel;
• both headers parse to the end of their segments, and the SOZ, SORP and SORS substreams are present with no SOQ segment.

That is narrow. Of the reference encoder's five default rate points (cfg/BRM/default.json), only the first selects model_id 0 with β = 0; the others select model_id 1–3 or a non-zero β and are refused, as is any codestream to which the encoder's bitrate matcher assigns a non-zero β.

The float ONNX path hard-codes the same models, tables and filter selection, and refuses the same codestreams, so the reference sink refuses a codestream outside this configuration rather than decoding it to the wrong image. Within it, the exact decoder runs when the sink supplies its integer weight bundle and the thread's floating-point environment is the IEEE-754 default. Otherwise the reference sink decodes the same capability ID through the float ONNX Runtime path, whose reconstruction is not pinned. Both paths return the same result type, and the reference dispatch does not report which one ran.

On both paths the stages the capability's claim covers, the scale path and the two entropy decodes, run through the integer operator set, by the lowering jpegai-int/1 (integer-operators §13.6.1) at the profile acc32. Their refusals have codes: model_mismatch for a bundle that fails a load check of §13.6.1 or whose scale graphs do not meet acc32, and stream_exhausted for a latent or hyper-latent substream that ends before the decode it carries. The exact decoder runs its hyper decoders, context stages and synthesis through the same operator set too, by jpegai-int/1 (§13.6.2) at the profile acc64: those graphs' outputs lie outside the claim, and their refusals are model_mismatch for a weight file that fails §13.6.2's load checks or networks that do not meet acc64, and field_range for a dequantised residual, a latent or an activation that leaves i32. A sink that holds the integer weight bundle and refuses the exact decode reports that refusal, with its code; it does not then decode the codestream through the float path. Only a sink without the bundle, or a thread or target that cannot run the exact decoder's float stages, takes the float path. A decoded-pixel hash or a reconstruction binding over wai.image.jpegai holds only for output of the exact decoder.

What decode-equivalence costs

The tier adds nothing to the wire: nothing is transmitted beyond the capability's own codestream. The costs fall elsewhere, and the JPEG AI exact decoder pays the same ones for its integer networks:

• Fidelity to the float model. The quantised networks do not reproduce the float model's output, so the pinned reconstruction differs from it. For wai.neural.int_hyper, over one pretrained model (mbt2018_mean, quality 6) and one pinned test photograph, the integer decode of the full conditional bitstream measured 35.985 dB PSNR against 36.175 dB for the same model's float decode, a cost of 0.19 dB (macOS arm64; wai-rs/src/int_hyper_synth.rs). Quality is image-dependent, and this compares the model only with its own float decode. For the JPEG AI exact decoder, wai-rs/tests/jpegai_e2e_full.rs compares against the reference decoder's output on one 256×256 reference codestream and asserts max|Δ| ≤ 2 with at most 5% of samples differing; the recorded result is max|Δ| = 1 on 4.446% of samples (macOS arm64, release build, 2026-09-27). CI jobs re-check both bars: wai-sota-vectors.yml requires the int_hyper cost to stay within 1 dB on that photograph, and wai-jpegai-e2e.yml runs the JPEG AI comparison and requires the decoded pixels to hash to a pinned value. Both have run on the forge's Linux runner and passed on every run since 2026-09-28 (§6).
• Compute. The decoders are CPU code in integer arithmetic (i64, with i128 intermediates in places; plus fixed-order float for the JPEG AI exact decoder's float stages, which stay single-threaded). Their convolutions, IGDN and the JPEG AI synthesis's attention and element-wise steps run through int_kernels: register-blocked tiles, NEON widening multiply-accumulate on aarch64 (portable Rust elsewhere), and worker threads on native targets (one worker on wasm). Each fast kernel gives the same integer for every output as the scalar reference kernel kept beside it, which stays selectable at run time (Policy::reference()). They cannot use the float GPU / NPU paths a float learned decoder runs on. Measured throughput, on one machine and with its limits, is in research/decode-throughput.md §4–§5; no claim in this document depends on those figures.
• Model preparation. A model is offered at this tier only once exported into the decoder's pinned form, sink-supplied: quantised weights and requantisation constants for the integer networks (and, for the JPEG AI exact decoder's eICCI post-filter, float weights with BatchNorm folded in). A float-only model is not offered at this tier as it stands.

Parameter transmission pays in bitrate and leaves the decoder's arithmetic free; the integer decode pays in quantisation, compute and model preparation and adds no bits. A capability's tier states which trade it made.

Where decode-equivalence holds: fabrics, and output a sink cannot read

The tier is a property of the integer arithmetic a capability's registration fixes, so a fabric meets it when it executes that arithmetic exactly. What this revision shows, by fabric:

• CPU, native. The reference decoders, whose fast kernels give the same integer for every output as the scalar reference kernels (Compute, above). The golden-byte suite passes on Linux x86_64, Linux arm64 and macOS arm64 (§6).

• WebAssembly. The same Rust compiled to wasm32. wai-web-wasm.yml builds the browser crate for wasm32-unknown-unknown and, under Node, requires the int_synth corpus and the committed WIV1, WIH1, WIA1 and WIS1 vectors to decode to the hashes the native decode gives; it passed on the forge for main at 412a08c5 (2026-10-09). The int_mlicpp vector decodes to its pinned bytes on wasm32-wasip2 under wasmtime (§6). The browser crate's release build contains no SIMD instruction: on the source of the change that added this subsection it validated with WebAssembly's SIMD and relaxed-SIMD features disabled (wasm-tools validate), which CI does not check. A WebAssembly decoder at this tier MUST NOT use relaxed-SIMD instructions, whose results the WebAssembly specification lets engines choose among, and MUST NOT depend on the bits of a NaN.

• GPU. A decoder's wai-ops/1-i32 graphs (integer-operators §9.1) run on a GPU through wai/wai-ops-gpu: WGSL compute kernels in 32-bit words, at the acc32 widths for a graph whose certificate meets that profile, and otherwise in 64-bit and 128-bit arithmetic built from 32-bit words, an acc64 implementation (integer-operators §7.3). The host makes the interpreter's run-time checks before the device runs anything, and a check tensor that leaves its range refuses the decode at its operator. The driver's stage operators stay on the CPU, and so does a graph with an operator outside wai-ops/1-i32. The tier is claimed for those graphs only under the conditions of Claiming the tier on a GPU (below), which the crate meets, and only on an adapter where a run, on the kernel text of this revision, gave WGSL's result for every guarded case of the integer semantics suite, the host's result for every word of the arithmetic probe, and the interpreter's outputs, at both widths, for every graph vector of integer-operators §14.1 and §14.2 that wai-ops/1-i32 covers (§6), with the run's report committed (wai/research/ops-gpu-runs.txt). That is each adapter and backend below:

  • Metal, on the integrated GPU of an arm64 desktop (macOS 27.0.1), in the forge's run 10236 (job 46928) of wai-ops-gpu.yml;
  • a browser's WebGPU on that same GPU, the kernels compiled by the browser's own WGSL compiler (Chromium 148, headless), in the same job;
  • Vulkan, on an integrated GPU of PCI vendor 0x1002, device 0x1586 (Mesa 26.0.8), Linux x86_64, and a software Vulkan driver (llvmpipe, Mesa 26.0.8) on that host, which runs on the CPU.

  On Metal, the capability corpora (integer-operators §14.4) also decoded with their graphs on the device, as §6 records: every committed vector and refusal fixture of wai.neural.int_hyper, wai.video.int_hyper, wai.audio.int_codec, wai.splat.int_codec, wai.neural.int_synth and wai.neural.int_mlicpp gave the bytes, or the refusal code, of the decode on the CPU, and every graph the device ran gave the interpreter's outputs. wai.image.jpegai's scale graphs (hs_y, hs_uv, at acc32) and hyper decoders and context stages (rec_y, rec_uv, at acc64) ran there with the interpreter's outputs, so its entropy-consistency claim (§5) holds with its scale path there. Its synthesis graphs use operators outside wai-ops/1-i32 and ran on the CPU. On the Vulkan adapters the capability corpora have not run on this revision's kernels. The adapters G1 showed on the kernel text before this revision (Vulkan on Linux x86_64 with PCI vendors 0x10de and 0x8086), and those a hand run showed on this revision's kernels with no record committed (Vulkan and DX12 on a Windows x86_64 host, and its software DX12 adapter), are not claimed until a run of this revision's kernels is recorded there. The kernel text differs from G1's only in the shift masks and the two clamps that Claiming the tier on a GPU requires. Nothing is claimed for an adapter, a backend or a driver version that is not listed.

• NPU. No decoder of these capabilities runs on one in this revision, and the tier is not claimed there. A network evaluated in floating point on a GPU or NPU does not meet it (§1).

The tier covers the medium a sink emits and can hash (§2, What a tier covers). A sink that hands a payload to a protected media path whose output the application cannot read, as Lane A of SPEC §6.5 does, holds no output to hash, and the tier never covers that output: the sink MUST NOT claim the tier for it, or bind a digest, a reconstruction or an energy figure to it. Content that the application decrypts itself, as in Lane B of SPEC §6.5, is decoded like any plaintext, and the tier holds for it as it does for plaintext.

Claiming the tier on a GPU, and on another accelerator

decode-equivalence holds on an accelerator (a GPU, a neural processor, any device other than the CPU that runs a decoder's graphs) only where three things keep the integer arithmetic the capability's registration fixes: the program the device runs, the toolchain's translation of that program into the device's own code, and the device. In general form, a decoder claims the tier for output an accelerator computed only when, for every program that ran it: the program computes in integers only, so no reassociation or fusion can change a result; it uses no operation whose result depends on a grouping the device chooses; no result depends on scheduling (item 3 below, as written); the translation gives the program language's result for every operation it uses, and the program does not reach an operation on operands where the translation does not; the device passes a conformance suite of the operations' edge cases, and the implementation's probe of the wider arithmetic it builds, before it runs a graph; and the claim names the device and the toolchain that ran. The items below are those conditions for a GPU, whose programs are WGSL modules; another accelerator's text states its own program language, translator, suite and probe in their place.

The texts read for a GPU are WGSL, W3C Candidate Recommendation Draft, 21 October 2026, and naga 30.0.1, the translator wgpu 30.0.1 compiles WGSL with.

WGSL defines each integer operation at run time, the cases that are errors when the operands are known before the shader runs included (WGSL §8.8, §8.10, §17.5): addition, subtraction, multiplication and negation of a concrete integer type are modulo 2^32; e1 / 0 is e1, and e1 % 0 is 0; the most negative i32 divided by −1 is itself, and its remainder 0; a shift amount is taken modulo 32; an integer clamp(e, low, high) is min(max(e, low), high); a bit field's offset and count are clamped to the word. The languages a WGSL module is translated into leave some of these open: MSL and HLSL leave signed overflow undefined; MSL leaves a left shift of a negative or overflowing signed value undefined, and a right shift of a negative value to the implementation; and MSL, HLSL and SPIR-V leave a zero divisor, the most negative value divided by −1, a shift by the width or more, and a clamp whose bounds are out of order undefined or to the implementation. Floating point is open even in WGSL: an implementation may reassociate operations, and may fuse them where the result is at least as accurate (WGSL §15.7.5). A subgroup operation's result depends on its subgroup, whose size is a power of two from 4 to 128 that the device compiler chooses, whose invocations have no defined relationship to local_invocation_index, and of whose invocations only the active ones take part (WGSL §15.5, §15.6.3). An out-of-bounds access has several permitted outcomes (WGSL §6.5.7).

So a decoder MAY claim decode-equivalence for output whose graphs ran on a GPU only when every condition below holds for every shader module that ran them, on that adapter, in that process. Otherwise the output is the GPU's, and no tier is claimed for it.

1. Integer only. Every scalar type in the module, of every declaration and of every expression, is bool, i32 or u32; every literal is of one of them; every conversion is between them. No floating-point type appears for any purpose, an index or a loop bound included. With no floating-point operation, no reassociation or fusion an implementation may make changes a result: integer addition and multiplication modulo 2^32 give the same value in any order.
2. No subgroup or quad operation, and no extension. The module enables nothing (enable) and calls no subgroup or quad built-in.
3. No result depends on scheduling. Each output word is written by one invocation and read by no other invocation of the same dispatch. Every atomic operation on a given memory word is of one kind: atomicOr, atomicAnd, atomicMin or atomicMax, or atomicAdd and atomicSub together; no atomicLoad, atomicStore, atomicExchange or atomicCompareExchangeWeak reaches it in the dispatch; and the value an atomic returns is not used. Each of those kinds alone is order-free; two on one word are not (an atomicOr then an atomicAnd differs from the reverse). No access is out of bounds.
4. The translation gives WGSL's results. A translation into a language that leaves an integer result open produces WGSL's result for each operation the module uses: signed addition, subtraction, multiplication and negation evaluated in unsigned arithmetic and reinterpreted; division and remainder through a guard that substitutes the divisor 1 where WGSL's result is the dividend, and remainder 0; the absolute value of the most negative value, itself. naga 30.0.1 does all of these in MSL and HLSL (its naga_div, naga_mod, naga_neg and naga_abs, and signed arithmetic through unsigned); in SPIR-V, whose integer addition, subtraction, multiplication and negation wrap, it guards division and remainder. In MSL the division and remainder guards, and in SPIR-V the division and unsigned-remainder guards, are written only while its integer-division checks are on; SPIR-V's signed remainder is guarded even with them off, and HLSL's guards are always written (DX12's translation goes through FXC, shader model 5.1). A host MUST NOT turn a translator's guards off: in wgpu, a module created unchecked, or ShaderRuntimeChecks::int_div_checks false. Where a translator does not produce WGSL's result for an operation, the module MUST NOT reach that operation on the operands concerned. naga 30.0.1 passes a shift amount to MSL, HLSL and SPIR-V without reducing it modulo 32, writes a signed left shift as it is, and writes an integer clamp as MSL's and HLSL's clamp; so every shift amount in the module is a literal below 32 or masked below 32 (e & 31u), no left shift has a signed left operand (the module shifts the u32 and bitcasts), and every clamp has literal bounds in order, another bound being written min(max(e, low), high). A right shift of a negative value, which MSL leaves to the implementation, is held by item 5: the suite runs it on the adapter.
5. The adapter passes the conformance suite first. Before an adapter runs any graph of the decode, in the same process, it gives WGSL's result for every case of the integer semantics vectors (wai/wgsl-conformance/integer.jsonl) that the file marks guarded, and for further cases of each operation that the implementation draws, and the host's result for every word of the implementation's probe of the wider arithmetic it builds from 32-bit words. And the implementation has reproduced, on that adapter, backend and driver, every graph vector of integer-operators §14.1 and §14.2 its subset covers, at each width it runs (integer-operators §12, Evidence for a fabric). An adapter that differs on any guarded case or probe word runs no graph.
6. The claim names what ran. A receipt or report of a GPU decode at this tier names the adapter (backend, PCI vendor and device, driver) and the translator and its release. Where the backend reports no PCI identity and no driver (Metal and a browser's WebGPU give vendor and device 0x0 and an empty driver), it names in their place the adapter name the backend gives and the operating system's build, or the browser and its version.

The semantics vectors cover every integer operation a kernel may use (rule 7 of tests/wgsl_rules.rs keeps the kernels inside them), on i32, u32 and two-component vectors of them where a kernel uses those, with the edge cases above: every pair of a set of values at and near the edges of both types for the arithmetic, division and remainder, every shift amount from 0 to 40 and the extremes past it, and bit fields at and past the word. They mark as unguarded the cases item 4 keeps a module from, a shift amount of 32 or more and clamp bounds out of order, whose result is the hardware's through naga 30.0.1. A run reports what each adapter gives on them; a difference there does not refuse the adapter, since no module at this tier reaches one. The file is written from WGSL's definitions by wai_ops_gpu::semantics::reference and checked against it natively, and against the same reference compiled to wasm32, under Node and in a browser page.

wai/wai-ops-gpu meets these conditions. tests/wgsl_rules.rs holds every shipped module, on naga's IR, to items 1, 2 and 4 and to item 3's atomic and barrier parts: the types and literals; a closed list of expressions and built-in functions; the one atomic operation, atomicOr, its result unused, and no atomic load or store; the bindings, with no workgroup or private memory and no barrier; the shift masks, no signed left shift, and clamp bounds; that every integer operation a kernel uses is one the semantics suite runs; and naga's wrapping of signed arithmetic and its guard helpers in each module's MSL and HLSL translations, which disappear from the MSL with its division checks turned off. Item 3's other parts, each output word written by one invocation and read by no other, and no access out of bounds, rest on the host's indexing of the dispatch and on wgpu's bounds checks, which the checked module-creation call keeps on; the rules check does not decide them. It also holds the crate to the checked module-creation call, and shows each planted violation (a floating-point value, f16, a subgroup reduction, an atomicAdd, an atomic's result read, an atomic load, an atomic store, workgroup memory and a barrier, a storage barrier alone, an unmasked shift, a signed left shift, a clamp with run-time bounds) refused by the rule it breaks. Discovery runs item 5's suite and probe on each adapter before it runs a graph; tests/semantics.rs shows every adapter refused when the suite's remainder is written by hand, a - (a / b) * b, which gives a where WGSL gives 0. In a browser, wai-ops-gpu/browser runs the same suite through the browser's own WGSL compiler.

6. Evidence status

What the repository demonstrates, claim by claim, as of 2026-09-27 (main at afc7ece), except where a row names a later run: the rows that cite run 745 read the forge's runs of the landing chain's head 7cfcecfa on 2026-09-30. A test that skips reports as passing, and a matrix leg whose runner did not run reports nothing; neither is evidence.

The CI rows below come from the forge's commit statuses (/api/v1/repos/Transaction-Science/open-standards/commits/<sha>/statuses), read for every commit on main since 2026-08-10 and for the pre-merge commits named, not from the workflow definitions. Two workflows run the same golden-byte suite (wai/byte-exact-conformance, cargo test --release): the cross-arch byte-equality job of wai-conformance.yml, and wai-byte-equality.yml. Both declared Linux x86_64, Linux arm64, macOS arm64 and Windows x86_64 legs until 2026-09-30, when the Windows x86_64 legs were taken out of both workflows because its runner is offline; there is no Windows leg now, and no macOS x86_64 or Windows arm64 leg. No Windows x86_64 job ran for this repository after 2026-08-27: every later Windows status on main is "Waiting to run" or "Has been cancelled", and the forge's task list has no Windows task after that day. The Windows results below are history.

claim	evidence	where
Cross-architecture identity of the rANS coder, int_synth, and the JPEG AI symbol decode (a reference-encoder codestream, given its distribution indices)	golden-byte assertions passed on Linux x86_64, Linux arm64 and macOS arm64 on main at afc7ece (2026-09-27, wai-conformance.yml; wai-byte-equality.yml last ran on main at 3f50097, 2026-08-29, all three legs passing), and on Windows x86_64 last on main at 3e7811f (2026-08-27). Between 3e7811f and afc7ece the suite only gained the video and keyframe goldens; these goldens, the sources they decode and the suite's lockfile are unchanged	byte-exact-conformance/; .github/workflows/wai-conformance.yml, wai-byte-equality.yml
Cross-architecture identity of integer inter-frame video, and of int_hyper on a small learned keyframe	the same suite, passing on Linux x86_64, Linux arm64 and macOS arm64 on main at afc7ece (2026-09-27). Windows x86_64 never decoded the keyframe clip: it was added in d4c922b (2026-08-28), whose Windows legs were cancelled. Windows decoded the integer video goldens only on the pre-merge commits c9be2ad, 256e5dd, 7dfca26 and 3d34860 (2026-08-25/26), whose video sources, vectors and golden file match main but whose byte-exact-conformance/Cargo.lock differs; the change reached main at 3f50097, after the last Windows run on main	as above
wai.image.jpegai exact decoder: the integer derivation of the distribution indices matches the reference decoder exactly	a test on one machine that skips unless its fixtures (sink-supplied weights, normative tables, codestream) are provided; CI does not provide them	wai-rs/tests/jpegai_hyperscale_calibration.rs
wai.image.jpegai exact decoder, whole decode through the one public decode() call: it stays within a stated bound of the reference decoder's output (max|Δ| ≤ 2, ≤ 5% of samples); two decodes in one process are byte-identical, and a reconstruction binding taken over one verifies the other	wai-jpegai-e2e.yml fetches the pinned jpegai/v1 inputs (an extraction of the reference-software assets, published under WAI's models root), checks each file against the SHA-256 manifest tools/jpegai-e2e-v1.sha256, and runs both tests with WAI_REQUIRE_SOTA_VECTORS=1, under which a missing input fails instead of skipping. The job also fails on any skip banner in the test log, and requires the decoded pixels to hash to a pinned SHA-256. One 256×256 codestream. The workflow has run on the forge's Linux runner (x86_64 hardware) and passed on every run since 2026-09-28. Before that, its job passed under forgejo-runner exec on the same host (2026-09-27) with the exact decoder as it stood on main at afc7ece, which calls the platform exp; there too the decoded pixels matched the pinned hash, the value measured on macOS arm64	wai-rs/tests/jpegai_e2e_full.rs, jpegai_reconstruction_binding.rs; .github/workflows/wai-jpegai-e2e.yml
wai.image.jpegai exact decoder across platforms: the jpegai/v1 codestream decodes to the same RGB8 bytes, and to the same bits in the float values the decoder reports after each stage (values inside a stage are not hashed), on each platform measured	measured 2026-09-28 with rustc 1.98.0, release builds, inputs checked against their SHA-256, all four on the source of the change that added this row: macOS arm64 (native, on the development machine); wasm32-wasip2 (wasmtime 49, on the same machine); Linux arm64 (glibc 2.36, a container in an arm64 Linux VM on that machine); Linux x86_64 (glibc 2.36, the x86_64 build run in that container under user-mode emulation, QEMU 7.0, not on x86_64 hardware). All nine pinned hashes matched on each platform. On all four they also matched on an earlier state of that change, before the decode's exp and rounding moved to float_repro. Before the move the decode called the platform exp on every target, and its roundings compiled to calls to the symbols round, roundf and rint on x86_64 and round and roundf on wasm32, which the link resolves: an x86_64 Linux test executable inspected after the move, whose other code still rounds this way, took them from Rust's compiler builtins, not the C library (for wasm32 this was not checked). Not measured: macOS x86_64 (no x86_64 translation layer is installed on the development machine), Windows, x86_64 hardware, 32-bit targets. The test skips unless the inputs are supplied. wai-jpegai-e2e.yml supplies them and requires this test to run and pass on its Linux runner; that workflow has run on the forge's Linux x86_64 runner and passed on every run since 2026-09-28	wai-rs/tests/jpegai_cross_platform.rs
float_repro, the decode's exp and rounding: the same bits over a fixed grid of inputs; exp within 2 ULPs of the host math library (1 ULP measured); rounding equal to the standard library's	library unit tests under the library-test step of the conformance workflow (neural_int), which has run them on its macOS, Linux x86_64 and Linux arm64 runners since 2026-09-28. The pinned-bits and rounding tests never skip. The host comparison asserts the host library's accuracy as much as this module's. Its gate selects by target, not by host: it runs on macOS arm64, on Linux x86_64 and arm64 with glibc, and on WASI, and is reported as ignored, with the reason, elsewhere, Windows included. On the source of the change that added this row it was run against these hosts' exp, with a worst case of 1 ULP on each: the platform math library on macOS arm64; the WASI C library under wasmtime; glibc 2.36 on Linux arm64, and glibc 2.35 in the Ubuntu 22.04 image the workflow's Linux arm64 runner used on 2026-09-28; glibc 2.36 on Linux x86_64 under user-mode emulation, against three of the four exp variants glibc chooses among by processor feature (the variant each run used follows from the features glibc's loader reported active): SSE2 (QEMU 7.0, whose emulated processor reports none of AVX, FMA, AVX2 and FMA4), AVX (QEMU 7.2, -cpu max with FMA and AVX2 masked by glibc's hwcaps tunable, which leaves AVX active) and FMA (QEMU 7.2, -cpu max). On a separate probe of 20 million inputs, the SSE2 and AVX variants returned the same bits, and the FMA variant different bits for some of them. Not compared: the FMA4 variant, which glibc chooses on a processor that has FMA4 but not both FMA and AVX2, and which neither emulator offers. Not run on x86_64 hardware or on other glibc versions, where the gate still runs it; a failure there would say that the host's exp and this one are more than 2 ULPs apart, not that float_repro's bits changed	wai-rs/src/float_repro.rs tests
The exact decode path calls no platform math library	two checks. Clippy's disallowed_methods (wai-rs/clippy.toml), denied in each module on the decode path, rejects any use of a listed float method, including f64::exp(x) and .map(f64::exp). tests/jpegai_decode_symbols.rs lists the symbols of an executable that links only the decoder's entry points and weight loaders. It rejects any C math-library function the executable imports, and any it defines other than the round-to-integral functions (floor, round, rint and the like), whose results IEEE 754 fixes. It allows those definitions because a definition shows what the linker kept, not what the decode calls: linked with GNU ld 2.40 for x86_64 Linux, the debug executable defined the compiler builtins' floor, though nothing in it referred to floor. On the source of the change that added this row, both checks pass on macOS arm64, the symbol check in debug and release builds. The symbol check also passes, in debug builds, on Linux arm64 (the container above) and on Linux x86_64 under user-mode emulation, linked with GNU ld (reporting that floor as allowed) and with LLD. With a platform exp put back as f64::exp(…), both fail on macOS arm64 while the decoder's unit tests still pass, and the symbol check fails on Linux x86_64 with GNU ld. With a float % put into the decode, the symbol check fails on macOS arm64 and clippy, which does not see operators, passes. The conformance workflow runs both on its unix legs, on the forge's runners since 2026-09-28	wai-rs/clippy.toml, wai-rs/tests/jpegai_decode_symbols.rs, .github/workflows/wai-conformance.yml
wai.image.jpegai scope: the reference codestream is accepted; copies with β, model_id, the colour transform or an LSBS flag changed are refused; a flush-to-zero or round-toward-zero environment is detected. The float ONNX path calls the same check	library unit tests over a committed copy of the reference codestream, which never skip and fall under the library-test step of the conformance workflow (neural_int); the environment test runs on arm64 only. Run on the four platforms above, on the source of the change that added the cross-platform row (the environment test on macOS arm64 and Linux arm64). The float path's refusal (β and model_id edits) is tested only with its ONNX bundle supplied (jpegai_scope_ort.rs, skips otherwise)	wai-rs/src/jpegai_decode.rs tests, wai-rs/tests/vectors/jpegai/
SPEC §7's replicate rule: the registry class decides first, so an integer-declared prior over wai.image.jpegai or a float codec is refused; wai.image.jpegai is the only NeuralEntropyExact capability; the standard codecs sit in the classes SPEC §7 lists, and the tolerance and unclassified ones are not refused; an encoder that pins no prior (wai wrap) writes replicate only over the standard classes, for the capability and for any declared fallback, or, in the WAI2 companion form, for the base payload's capability and each companion's	library unit tests (codecs, container) that never skip and fall under the same library-test step. The strict-decode test in tests/neural_native_decode.rs needs the neural feature; wai-neural-gates.yml runs it on the Linux runner, in an Ubuntu 24.04 image because the neural test binary does not link in that runner's default 22.04 image. Its strict-decode job ran on the forge and passed on every run from 2026-09-28; before that the job passed under forgejo-runner exec on the Linux runner's host (Linux x86_64, 2026-09-27). The pin-aware tests since added to that workflow (its longer exact list of neural_native_decode tests, the step of model-free neural library tests, and the neural C ABI step, tests/ffi_neural_pin.rs) have no recorded forge run yet. The wai binary no longer needs the codecs feature, so the tests that run wai wrap (cli_wrap_intent.rs, and cli_registry.rs for the candidate refusal and the registry export) run in the conformance workflow's carriage step on every leg; this row records no forge run of them yet. The C envelope packers emit through Wai::to_emit_bytes and WaiMulti::to_emit_bytes, whose candidate refusal a library test checks with no feature (the_emit_path_refuses_a_candidate, in the library-test step); the C wrappers themselves build under the codec-free ffi feature, and tests/ffi_envelope.rs (envelope_pack_refuses_a_candidate, envelope_select_never_picks_a_candidate) runs in the conformance workflow's C ABI envelope step on every leg; this row records no forge run of that step yet. The browser writers' refusal runs in wai-web-wasm.yml (verify_pack.mjs)	wai-rs/src/codecs/mod.rs, container.rs tests; wai-rs/tests/neural_native_decode.rs, cli_wrap_intent.rs, cli_registry.rs; wai-web/demo/verify_pack.mjs
wai.neural.int_hyper and wai.video.int_hyper at full model scale (the pretrained mbt2018_mean, exported to integers): the Rust decode reproduces the export tool's integer reference byte for byte (synthesis, hyper-decoder, the whole conditional bitstream, an eight-frame clip), and costs at most 1 dB against the same model's float decode on one pinned photograph	wai-sota-vectors.yml regenerates the vectors on the runner from pinned inputs (the photograph's pixels and the checkpoint's bytes by SHA-256, the Python stack by version) and runs both tests with WAI_REQUIRE_SOTA_VECTORS=1, under which a missing vector fails instead of skipping. The job also fails on any skip banner in the test log, and runs require_vectors_rule.rs, which checks that without the switch a variable naming absent or incomplete inputs fails as well. Rust is checked against the export of the same run on the same machine: the vectors come from float computation, and some of them differed between machines and between runs, so none of their hashes is pinned and none is compared across machines. The workflow has run on the forge's Linux runner (x86_64 hardware) and passed on every run since 2026-09-28	wai-rs/tests/int_hyper_synth.rs, int_video_sota_keyframe.rs, require_vectors_rule.rs; .github/workflows/wai-sota-vectors.yml
wai.audio.opus.dred.int: the profile's features are an exact integer function of the payload and the pinned weights, the same on the CPU and on a GPU, and within the draft's tolerance of its reference features	the corpus live-conformance/dred/ regenerates byte for byte, and its second implementation (dred_verify.py, standard-library Python written from the extension) recomputes every digest and row; the two graphs on the GPU at acc64 give the interpreter's integers graph by graph and the CPU decode's bytes; on the draft's eight test vectors the features pass the draft's feature test and lie at total 0.0021 from the network in floating point (opus-dred §6)	measured 2026-10-22 with rustc 1.98.0 on macOS arm64 (the build host: the wai-rs tests in release, the GPU test on its Metal adapter gpu-metal-0) and the Python verifier on a second macOS arm64 host. Not measured: x86_64, Linux, Windows, wasm. CI runs the corpus, the measurement and the verifier on the forge's Linux arm64 runner (wai-conformance.yml) and the GPU test on the macos runner (wai-ops-gpu.yml), with no forge run recorded yet. The weights are fetched by digest, not committed
wai.audio.int_codec, wai.splat.int_codec	committed vectors that never skip. Their frozen hashes are the output of an independent Python integer reference, computed when the vectors were exported (tools/wai_int_audio_export.py, tools/wai_int_splat_export.py); no Python runs in CI. The conformance workflow's fast-kernel steps enable audio_int and splat_int and, in debug and release builds, decode both vectors against those hashes under the reference kernels and every fast-kernel policy (tests/int_kernels_vectors.rs); that passed on the forge's Linux x86_64, Linux arm64 and macOS arm64 runners for the landing chain's head 7cfcecfa (run 745, 2026-09-30). The same steps also name tests/int_audio.rs and tests/int_splat.rs, which check each vector against the same hash and against its own metadata (sample count; attribute count, tensor size and grid side); Cargo declares each with its feature as a required feature, so a step that names it without that feature fails instead of running nothing. This row records no forge run of those two	wai-rs/tests/int_audio.rs, int_splat.rs, int_kernels_vectors.rs; .github/workflows/wai-conformance.yml
wai.neural.int_mlicpp on its committed vector (synthetic seeded weights; a 64×64 image, 8 latent channels in 4 slices): the decode reproduces the export tool's independent integer reference byte for byte — the RGB, and every scale bucket and symbol of the latent stream in coding order (512 symbols over all 16 buckets of the scale table, 47 of the symbols coded by the rANS escape) — under the reference kernels and under the fast kernels on 1, 2, 3, 5 and all available threads; one integer unit changed in each of four chosen parameters, one on each path that feeds a value (a hyper-decoder weight, an entropy-network weight, a mean-head bias, a synthesis weight), changes the image; a header whose shapes the model cannot produce, or on which a network would form a buffer over the cap, is refused before anything is allocated (tests/int_mlicpp_preflight.rs, which counts allocations); damaged payloads are refused or decode, and never panic in an overflow-checked build	measured 2026-09-29 with rustc 1.98.0 on the source of the change that added this row: macOS arm64 native (the wai-rs tests, with overflow checks on and off; the byte-exact-conformance golden, release) and wasm32-wasip2 under wasmtime 49.0.1 (the same tests and golden, release; on wasm the fast kernels run single-threaded as portable scalar code, and usize is 32-bit). All pinned hashes matched on both. Not measured: x86_64 — the development machine has no x86_64 translation layer installed, and an x86_64-apple-darwin build of the golden compiles but cannot execute there — nor Linux or Windows. The golden runs on every leg of the byte-exact matrix (wai-conformance.yml, wai-byte-equality.yml) and tests/int_mlicpp.rs on every leg of wai-conformance.yml in both profiles. Both passed on the forge's Linux x86_64, Linux arm64 and macOS arm64 runners for the landing chain's head 7cfcecfa (run 745, 2026-09-30); there is no Windows leg. The dispatch through decode_envelope_strict (the prior pinning the one-file model bundle, the strict gate) runs in wai-neural-gates.yml. The weights are synthetic, so nothing here measures compression quality	wai-rs/tests/int_mlicpp.rs, wai-rs/tests/int_mlicpp_preflight.rs, byte-exact-conformance/src/int_mlicpp_golden.rs, wai-rs/tests/neural_native_decode.rs; tools/wai_int_mlicpp_export.py
wai-ops/1-i32 graphs on GPUs (wai/wai-ops-gpu, §5, Claiming the tier on a GPU): every shipped module meets items 1, 2 and 4 and item 3's atomic and barrier parts on naga's IR; each device gives WGSL's result for every guarded case of the integer semantics suite and agrees with 128-bit host arithmetic on every probe case; every graph vector of ops-conformance/ that the subset covers gives the interpreter's outputs or refusal code, at acc32 and at acc64; the integer decoders, with their graphs on the device, give the CPU decode's bytes or refusal codes on every committed vector and refusal fixture, and every graph the device runs gives the interpreter's outputs	the forge's run 10236 (job 46928) of wai-ops-gpu.yml, 2026-10-22, rustc 1.98.0 and wgpu 30.0.1 (naga 30.0.1), release builds, on the kernel text of the change that added Claiming the tier on a GPU, on the adapters §5 lists: Metal on macOS 27.0.1 (arm64), and headless Chromium 148 on that GPU; and, on 2026-10-24 at the commit that added wai/research/ops-gpu-runs.txt (which holds both runs' report lines), Vulkan on Linux x86_64 with the 0x1002 adapter (Mesa 26.0.8) and llvmpipe, where every test of the crate ran and passed with WAI_OPS_GPU_REQUIRE=1 and the semantics suite, the probe, the corpus and the mutants gave the figures below with none differing. tests/wgsl_rules.rs passed, each planted violation refused by the rule named. On Metal the semantics suite (tests/semantics.rs) gave WGSL's result for every one of 254,464 cases, the 25,088 committed and 4,096 SplitMix64 cases of each operation: 231,690 guarded, and the 22,774 unguarded too (a shift amount of 32 or more, clamp bounds out of order); the browser leg ran 82,432 cases with none differing, and the committed file reproduced under the reference compiled to wasm32, in the page and under Node 26. The probe (tests/arith.rs) agreed on every word of 1,051,757 cases; the corpus (tests/corpus.rs) ran 813 vectors (1,104 decodes) on the 32-bit kernels and 1,426 (1,921 decodes) on the 64-bit ones, 212 of the decodes refusals, with no difference; 209 graphs use an operator outside the subset and ran on the CPU, and 95 vectors are refused at load. Eighteen edits of one kernel expression each (tests/mutants.rs) were each caught by the corpus, an edited product by the probe, and a remainder written by hand by the semantics suite at discovery. wai-rs/tests/ops_gpu.rs decoded the committed vectors and refusal fixtures of the six capabilities §5 names, the world renderer's two vectors and wai.image.jpegai's jpegai/v1 codestream on Metal, in the forge run, comparing every graph the device ran with the interpreter as well as each decode's bytes; none differed. The browser leg ran the corpus and the semantics suite, not the decoders. Hand runs of this kernel text on Vulkan on Linux x86_64 (PCI vendors 0x10de and 0x8086, and llvmpipe) and on Windows x86_64 (Vulkan and DX12, PCI vendors 0x10de and 0x8086, and the software DX12 adapter) committed no record, and G1's runs of the 0x10de and 0x8086 adapters were of the kernel text before it; none of those is claimed. wai-rs/tests/ops_gpu.rs has not run on the Vulkan adapters on this kernel text. wai-ops-gpu.yml runs the Metal and browser legs on the macos runner, where an absent adapter fails. No other workflow runs a GPU leg of these tests	wai-ops-gpu/tests/, wai-ops-gpu/browser/, wai-rs/tests/ops_gpu.rs, wgsl-conformance/; .github/workflows/wai-ops-gpu.yml

So at entropy-consistency, WAI's JPEG AI symbol decode is demonstrated across architectures (x86_64 against arm64) once the distribution indices are given; the integer derivation of those indices is demonstrated against the reference on one machine, by a test CI does not run. At decode-equivalence, cross-architecture identity (x86_64 against arm64) is demonstrated for int_synth, integer video and int_hyper on committed small-scale vectors; of these, only int_synth has also been decoded on Windows on main. wai.audio.int_codec and wai.splat.int_codec decode their committed vectors to the hashes a separate implementation computed, on Linux x86_64, Linux arm64 and macOS arm64 (run 745): cross-architecture identity (x86_64 against arm64) against one pinned hash per vector, on small vectors; neither has been decoded on Windows. For full-scale int_hyper, identity rests on construction, not on a cross-machine comparison of decoded output: CI checks its decode against the export's integer reference on one machine per run. wai.neural.int_mlicpp's committed vector decodes to the same pinned bytes on macOS arm64 and on wasm32-wasip2 (a 32-bit target), measured on the development machine; it also passed on the byte-exact matrix's Linux x86_64, Linux arm64 and macOS arm64 legs in run 745. On GPUs, the committed vectors of int_hyper (and its video keyframe), int_codec audio and splat, int_synth and int_mlicpp decode with their graphs on the device to the CPU decode's bytes on Metal, the adapter §5 lists that runs them, after it gave WGSL's integer semantics on every guarded case, in the wai-ops-gpu workflow's forge run 10236 (job 46928).

For the JPEG AI exact decoder's pinned reconstruction (§5), identity across machines rests on construction, and on one comparison: a single codestream on the four platforms in the table. The construction is integer arithmetic for the integer stages and, for the float stages, only IEEE-754 basic operations, which are correctly rounded:

• evaluated single-threaded in the fixed order of the source, each at its own precision (true of x86_64, AArch64 and wasm32 targets; not of x87, which the exact decoder refuses);
• with no fused or reassociated operations, which Rust does not emit unless the source asks for them;
• in the default floating-point environment, which the exact decoder probes before decoding (§5): round to nearest even, subnormals neither flushed nor read as zero;
• with no platform math library on the path. The gain scaler needs exp, which math libraries are not required to round correctly. Rounding to an integer is exactly specified, but on some targets it compiles to a call: with rustc 1.98, f64::round, f32::round and f64::round_ties_even become calls to the symbols round, roundf and rint on x86_64, and the first two do on wasm32, and the link decides what answers them (in the x86_64 Linux executable inspected, Rust's compiler builtins did, not the C library). The decoder takes both from wai-rs/src/float_repro.rs, built from basic operations, so their bits are fixed by the source. Clippy's disallowed_methods, denied in each module on the decode path, and a check of the linked decoder's symbols (tests/jpegai_decode_symbols.rs) keep math-library calls off the path (see the table above).

That the exact decoder's gain scaler equals the reference decoder's rests on margin, because the two compute it in different arithmetic. The scaler is exp((g + β) · log_k / 2⁷) rounded to 2⁻¹⁰. The exact decoder evaluates it in f64 with float_repro::exp, which was measured within 1 ULP of the host math library on the four platforms. The reference software evaluates it in float32: the log-domain gain as float32, times log_k rounded to float32, then the float32 exp of its tensor library, then rounding half to even. Neither exp is guaranteed to be correctly rounded. The inputs are exactly the normative gain tables, because the exact decoder refuses β ≠ 0.

tools/wai_jpegai_gain_exp_margin.py computes the exact value of both evaluations with 60-digit decimal arithmetic, over the gain tables exported from the reference software, and gates on the result at β = 0. It found the following for every entry of all eight tables:

• the exact value of the decoder's f64 evaluation lies at least 4 × 10¹⁰ f64 ULPs from a rounding boundary;
• the exact value of the reference's evaluation, from its float32 argument, lies at least 77 float32 ULPs from one;
• both round to the same integer.

So any float32 exp within 77 ULPs gives the reference the exact decoder's scaler. The tool also fails unless the decoder's log_k is the value the reference computes.

This does not extend to every β. The tool's --beta-sweep option reports, without gating, all 5118 values of g + β that the tables and the 12-bit header field can produce. At four of them (1115, 1922, 2285 and 2289), the exact value of the reference's evaluation lies within one float32 ULP of a boundary. There the reference's own scaler depends on the last bit of its exp, so it can differ between the platforms the reference runs on. At 2285 and 2289 the exact value lies just above the boundary, a correctly rounded float32 exp lands exactly on it, and rounding half to even then gives the integer below it. At every g + β, the exact decoder's formula gives the scaler that a correctly rounded float32 exp gives. The reference's own expression, evaluated on the development machine (macOS arm64), also gave the exact decoder's scaler at all 5118; its float32 exp there was at most 0.85 ULP from exact on those inputs. A decoder that implements β would still have to settle what the reference's scaler is at those four inputs. This one does not implement β.