### The record made true: training, paths, protected content, reader limits, security

- **`int_synth`'s weights are quantised after float training.** SPEC §5 and
  [determinism-tiers](extensions/determinism-tiers.md) §5 said the capability decodes
  "QAT weights". No committed model was trained that way: the trained corpus vector,
  `photo`, was made by `tools/wai_int_synth_real.py`, float training then post-training
  quantisation with each layer's shift derived from its measured activation range, and
  the weights of the synthetic vectors and of the cross-architecture golden come from a
  seed. Both texts now say so, and so do the tools:
  `tools/wai_int_synth_qat.py` is marked experimental (it trains against one fixed shift
  and made no committed model), and `tools/wai_int_synth_export.py` names the working
  path.
- **Stale paths.** The int_synth decoder is `int_synth.rs` at the crate root, not
  `neural/int_synth.rs`. The quantum-ops engine and the quantum-sim receipt live in
  `wai-quantum`, whose features `wai-rs` forwards. README and SPEC Appendix A no longer
  send macOS builders to a `.cargo/config.toml` that no longer exists: `wai-rs/build.rs`
  finds libFLAC.
- **Protected content: two lanes** (SPEC §6.5). Lane A, hardware-protected content,
  decodes inside the platform's protected media path; WAI's records about it (among
  them the served manifest, the segment map, the key-release decisions, the ad
  decisions and impressions of `wai.video.ssai`, the program-as-run windows of
  `wai.video.channel`, and the content hashes of WAI objects) cover no decoded frame.
  This revision registers no `security.encryption` value for it. Lane B, end-to-end
  encryption at the application layer (`mls-sframe`), decrypts in the application, so
  the tier and the output digests of the sink that holds the key hold as they do for
  plaintext; staged-measurement counts no encrypted object, and a verifier without the
  key checks none of a `reconstruct-session` claim's rules that need a payload. Lane B
  is not a protected-path robustness level. `wai.video.keys` and the confidentiality
  extension say which lane they belong to.
- **Where the exact tier holds** (determinism-tiers §5). `decode-equivalence` is shown
  on native CPU and on wasm32, on no GPU or NPU; a WebAssembly decoder at the tier uses
  no relaxed-SIMD instruction and depends on no NaN's bits; and the tier never covers
  output a sink cannot read.
- **Reader limits** (SPEC §2). A reader need accept no manifest longer than 2²⁷ bytes
  (128 MiB) or nested deeper than 127, and refuses a longer one from `man_len` alone
  (`manifest_too_large`). The length limit is sized to the largest manifest a
  conforming staged layer has: a `prev` (staged-delivery §3) naming a different
  producer for each of the 2²⁰ units a `WIR1` layer may cover (staged-delivery
  Appendix A.3) is about 94 MB. It bounds what a reader reads, not the memory a parse
  takes, which in the reference readers is up to nearly 40 times the manifest's length
  (`SECURITY.md`). `wai-rs`'s readers, its HTTP head parser (`head_malformed`) and the
  Python verifiers apply the length limit, and the HTTP corpus holds it at its edge;
  the writers, `wai-web`'s included, refuse to write past it, and refuse a payload whose
  length does not fit its `u32` field.
  *Envelopes this makes non-conforming:* none of the layout's; an envelope whose manifest
  is longer than 128 MiB, or nested deeper than 127, is one a conforming sink may refuse,
  so a conforming encoder no longer writes it (SPEC §7).
- **`SECURITY.md`.** How to report a vulnerability, and where the reference
  implementation reads untrusted input: the manifest limits and the memory a manifest's
  parse takes, the native codec libraries and their gaps (unbounded decompression output
  for `wai.text.zstd` and `wai.text.xz`; no fuzzing in CI), module authorisation, and the
  fingerprinting risk of `held_sets`. CI checks its section references.

