### Determinism tiers — naming the reproducibility spectrum for neural decode

- New [`extensions/determinism-tiers.md`]: names the two guarantees a neural
  capability can make, so a manifest can declare which it satisfies and a verifier
  knows what it may check. `entropy-consistency` — the entropy decode reproduces
  across devices (integer entropy arithmetic or explicit parameter transmission);
  JPEG AI sets its bit-exact conformance point at this tier (the entropy-decoder
  output). `decode-equivalence` — the whole decode to the final medium reproduces
  on every conforming sink, so the rendered result has a portable hash; WAI's
  integer capabilities are registered at this tier, and it is the precondition for
  a hard reconstruction binding. Referenced from SPEC §7 (Replicate-soundness);
  framed self-referentially.
- Normative: over a neural capability, `intent = replicate` promises
  `decode-equivalence` (SPEC §3, §7; standard codecs, below). The
  first version of the extension called `entropy-consistency` the floor for a
  sound neural `replicate`, and SPEC §7 said the same in its closing paragraph
  while requiring an integer decode path in its rule. Resolved: a neural
  capability backs `replicate` only if it is registered at `decode-equivalence`,
  which §7 admits only by the integer construction; `entropy-consistency` MUST NOT
  back it, and neither may a reconstruction that one implementation pins through
  fixed-order float stages. A tier is a property of the capability as registered,
  not of one implementation.
- **Downgrade: `wai.image.jpegai` is registered at `entropy-consistency`, not
  `decode-equivalence`, and no longer backs `replicate`.** Its registry class
  moves from `StandardDefined` to the new `NeuralEntropyExact` (integer entropy
  decode, float later stages). Its decode has float stages and a float ONNX
  fallback, so decode-equivalence never held as a property of the capability, and
  `StandardDefined` ("the neural float hazard does not apply") did not describe it.
  What the exact decoder does is unchanged — one pinned reconstruction, reproducible
  across machines under the conditions in the extension's §5 — and is now stated as
  a property of that decoder. A reconstruction binding over `wai.image.jpegai` is
  checkable only with that decoder (reconstruction-binding §2). Earlier entries
  below that call the JPEG AI decode decode-equivalent, or byte-identical on every
  machine, are superseded by this one.
- **`replicate` over a standard codec promises the named standard's decoder
  conformance, not byte identity across sinks.** The first form of this change
  stated in SPEC §3 that `replicate` promises the same bytes on every conforming
  sink, while every standard codec stayed `StandardDefined` and passed the rule —
  including codecs whose standard conforms decoders to a bound around a reference
  (RFC 6716 §6 holds an Opus decoder to `opus_compare` thresholds, not to
  identical output). SPEC §3 and §7 now state the promise per registry class, and
  two classes are added:
  - `StandardTolerance` — the named standard holds decoders to a criterion around
    a reference: `wai.audio.opus`, `wai.image.jpeg`, `wai.image.jxl`,
    `wai.image.jp2`, `wai.video.j2k`, `wai.video.av1`, `wai.video.av1.lossless`,
    `wai.image.avif` (AV1 §7.2: identical output unless film grain is signalled,
    and then no "perceptually significant differences", a criterion the AV1
    specification leaves undefined), `wai.audio.iamf`.
  - `StandardUnclassified` — the named standard's conformance clauses have not
    been checked: `wai.audio.ac4`, `wai.audio.ivas`, `wai.mesh.draco`,
    `wai.pc.gpcc`, `wai.pc.vpcc`, `wai.splat.sog`, `wai.haptic.mihs`,
    `wai.meta.hdr10plus`, `wai.meta.dovi`, and the pass-through asset formats
    `wai.mesh.glb` and `wai.splat.spz`.

  `StandardDefined` keeps the capabilities whose reconstruction is specified
  exactly (PNG, FLAC, zstd, XZ and the WAI-native capabilities). `replicate` over
  the reclassified capabilities is still honoured; what it promises is narrower.
  SPEC §7 also states that a conversion a sink applies after the standard's decode
  (PNG depth reduction, YUV→RGB, JPEG colour space, rendering an IAMF mix) is not
  part of the promise, and that an extension composing other capabilities' output
  is only as exact as their classes (spatial-audio §4 now says so for sources
  decoded through Opus). The clauses read for each classification, and what was not
  read, are in `research/media-codec-registry.md`. API: new
  `ReplicateClass::{StandardTolerance, StandardUnclassified}` variants,
  `ReplicatePromise` and `ReplicateClass::replicate_promise`; `wai capabilities`
  prints `standard-tolerance` / `standard-unclassified` for them.
- `wai.image.jpegai` stays `NeuralEntropyExact` as a conservative choice pending a
  reading of its conformance part, ISO/IEC 6048-4. An earlier form of this change
  said in SPEC §7 and the extension that its standard does not bound the
  reconstruction, so no weaker promise than `decode-equivalence` was available.
  Part 4 had not been read, and the overview of the standard that was read (arXiv
  2510.13867) says the conformance part "specifies the requirements for generating
  a JPEG AI-compliant reconstruction" and "considers the possibility that a decoder
  is conformant to the standard without having bit-exact reconstruction", with "a
  certain leeway" — which points to a criterion around a reference, though the
  overview does not state one. SPEC §7 (*`wai.image.jpegai` and the standard
  classes*) now states what was and was not read, that the capability is a
  candidate for `StandardTolerance` if Part 4 sets such a criterion, and that its
  treatment differs from the `StandardUnclassified` codecs' and film-grain AV1's
  by this revision's choice, not by anything found in the standards. No class or
  runtime behaviour changes.
- `decode_envelope_strict` and `Wai::replicate_is_sound` now apply SPEC §7 in two
  steps (`codecs::replicate_refusal`): the capability's registry class first, then
  the pinned prior. Before, they read only the prior's *declared* contract string,
  so a `replicate` envelope over `wai.image.jpegai` or a float codec passed when its
  prior declared an integer contract; it is now refused. API: new
  `ReplicateClass::NeuralEntropyExact` variant (an exhaustive `match` must add it),
  `DeterminismTier`, `ReplicateClass::{neural_tier, label}`,
  `codecs::{replicate_refusal, ReplicateRefusal}` and `Wai::replicate_refusal`;
  `Wai::replicate_is_sound` now consults the registry (a floor capability with no
  prior now passes it; the free function `container::replicate_is_sound` is
  unchanged and checks only the prior).
- Fix: `wai wrap` wrote `intent = replicate` over every capability, including
  `wai.image.jpegai` and the float neural codecs, which SPEC §7 says an encoder MUST
  NOT do, and it pins no prior, so its envelopes over an integer-exact neural codec
  were refused by the strict decode as well. It now takes `--intent <intent>`
  (default `replicate`) and writes `replicate` only where a sink accepts it with no
  prior — over the three standard classes; otherwise it refuses, says why, and
  writes nothing. The same holds for a `--fallback` capability, since a sink that
  lacks the primary decodes through it (SPEC §4 step 5): `wai wrap wai.image.jp2 …
  --fallback wai.image.jpegai` is refused unless given another intent. SPEC §7 now
  says the class a sink checks is that of the capability it decodes through. API:
  `codecs::unpinned_envelope_intent`. The library test checks every registered
  capability against the sink's own check; `tests/cli_wrap_intent.rs` runs the
  binary, which needs the `codecs` feature, which no CI job builds.
- CI: new `wai-neural-gates.yml` runs the two model-free neural-sink tests,
  `strict_decode_gates_unsound_replicate` (the `decode_envelope_strict` gate) and
  `resolve_checked_verifies_prior_hash`, on the Linux runner, and fails unless both
  ran. No workflow ran them before: they need the `neural` feature, which
  `wai-conformance.yml` does not build, and `wai-neural-e2e.yml` selects only the
  reference-match tests. The job runs in an Ubuntu 24.04 image: the ONNX Runtime
  binary the `ort` crate downloads needs glibc 2.38 and a GCC 13 libstdc++, and
  in the runner's default 22.04 image the test binary fails to link.
- Wording corrections, each checked against its source:
  - The claim that byte identity holds between sinks running the same decoder
    build (the `StandardTolerance` and `ReplicatePromise` docs, SPEC §7) had
    nothing behind it and is removed; `replicate` over those classes does not
    promise byte identity across sinks.
  - JPEG and JPEG 2000 were listed with Opus and JPEG XL as having a stated bound.
    The clauses that would state them were not read (T.81 leaves the IDCT's
    accuracy to its Part 2; only the table of contents and terms of ISO/IEC
    15444-4 were read), so SPEC §7, the extension and the registry docs now say so
    and give no bound.
  - The JPEG AI overview is quoted instead of paraphrased: it says Part 4
    "considers the possibility" of conformance without bit-exact reconstruction,
    and does not itself state a criterion on the reconstruction.
  - "Before v0.4.0" in the registry comments and "until v0.4.0" in the extension
    were wrong: the replicate classes and `wai.image.jpegai` were both added within
    v0.4.0. They now say "earlier in v0.4.0".
  - determinism-tiers §2 described ISO/IEC 23001-11's decoding-operation reduction
    as in-band metadata with which a decoder degrades its output after a conformant
    decode. The 4th-edition CD text (WG 3 N1864) says otherwise: a decoding
    operation reduction request goes from the receiving device to the remote
    encoder, which sends a less complex bitstream, and complexity metrics let a
    decoder vary its operating frequency; neither changes the output of a decode.
    §2 now sorts every metadata set that text's Introduction names by what it
    changes. Attenuation-map post-processing, display adaptation (the RGB
    components of reconstructed frames rescaled, saturated or, for contrast
    enhancement, set to zero or the peak signal before display) and cross-segment
    decoding (an enhanced picture used as a reference) change the decoded medium,
    and the post-decode rule applies to them. Decoding-operation-reduction and
    attenuated-video requests, and low-power encoding, change the payload before
    it arrives; the rule about "honouring a hint" is replaced by one about such a
    payload: a tier, hash or receipt over it covers that payload, not the one it
    stands in for. Media selection and complexity metrics change neither. §2 also
    says what the metadata is: power-saving metadata stated in advance, whose
    energy quantities are expected or potential savings (clauses 7.4 and 8), not
    energy that was spent. energy-binding §7.1–§7.2 and task-fidelity §4 follow;
    §7.2 now names the parties to `op_requested` and `op_committed` as the
    requesting and the acting party, where "sender" and "receiver" had them
    reversed for a DOR request. The transport landscape research note marks its
    earlier reading as superseded in a note under its provenance header that
    names every passage repeating it.
  - `int_entropy.rs` cited SPEC §6 for replicate-soundness; it is §7.
- Correction to the JPEG AI entries (SPEC §5 row and the decoder entry below): the
  dequantisation, latent refinement, post-filters (including the eICCI network) and
  colour conversion run in IEEE-754 float with a fixed evaluation order, not in
  integer; and the end-to-end test bar is max|Δ| ≤ 2 (recorded max|Δ| = 1), not
  1 LSB.
- Fix: `wai.image.jpegai` decoded codestreams it does not implement. The exact
  decoder checked only the picture size and latent channel counts, so a 256×256
  codestream with β ≠ 0, another `model_id`, another synthesis transform or another
  eICCI model selection passed that check and was decoded as if it had the
  implemented configuration; the float ONNX path was no better (it applied β to the
  entropy parameters but not to dequantisation). The earlier statement that every
  per-image quantity is derived from the bitstream did not hold while β is not
  implemented; β ≠ 0 is now refused. `jpegai_decode::check_codestream` now
  checks every header field either path hard-codes, and both paths refuse a
  codestream that fails it. The exact decoder also refuses to run in a non-default
  floating-point environment (`fp_env_is_default`). The committed reference
  codestream (`wai-rs/tests/vectors/jpegai/`) lets the library tests exercise the
  check without fixtures.
- Fix: the JPEG AI picture-header parser mislabelled a flag. The bit after each
  component's GRFS channel flags is `synthesis_tile_enable`; the LSBS flags are the
  first two bits of the tool header (`parse_lsbs_flags`). It also read `c_ver` /
  `c_hor` when `s_ver` / `s_hor` is 2, where the reference codes neither; the float
  path's parser shared that defect and dropped the separate chroma β.
- Float reproducibility stated precisely (SPEC §7, the extension, `DeterminismClass`):
  IEEE-754 basic operations are correctly rounded, and float decodes diverge across
  hardware through what a runtime chooses per device and through the floating-point
  environment. `replicate` still requires integer arithmetic, because those
  conditions belong to one build and one process.
- The extension now also states what a receipt can hash under each tier, why
  transmitting entropy parameters stops at `entropy-consistency`, which capabilities
  are offered at `decode-equivalence` and at what cost, and the evidence behind each
  claim — which tests skip, which CI does not run, and which matrix legs actually
  ran (the Windows x86_64 leg has not run since 2026-08-27).

