WAI Extension: Determinism Tiers for Neural Decode

Mirrored from the canonical text at commit 117bad22 (2026-10-01).

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.

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.

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

These six 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).

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

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.

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.

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