### The WAISM profile: a checked subset of WebAssembly for the decoder modules a sink runs

- **A new extension, [extensions/waism.md](extensions/waism.md).** A sink checks a
  WebAssembly decoder module before it instantiates it, against numbered rules (§4), each naming the clause of
  WebAssembly 3.0 or of WAI it rests on. The profile has two levels (§2). The integer level refuses floating point,
  relaxed vector instructions, imports, a start function and a table that can change, and requires one memory with a
  declared maximum; its output is the same on every engine that implements WebAssembly 3.0, with no engine setting.
  The float level admits floating point; its output holds a tier only on an engine set to the NaN rule of the
  deterministic profile (DET) of WebAssembly 3.0, shown by a probe in the sink's process, and never above
  `entropy-consistency`. A module exports a fixed interface of `i32` functions (§5). Checks 9 to 13 follow
  jwp-receipts §7.9's checks 1 to 8 (§6): the rules; a `conform-result/1` record over the module's digest that
  attests its capability's vectors and its refusal of every failed `memory.grow`, signed by a key that the head the
  grant was confirmed under lists with `module/decoder`; the engine; an instantiation with
  an empty import object; a run under a guard, where a trap or a limit is a refusal and nothing is output; and the
  output's hash. The refusal codes are in §8, and the corpora a checker, a module and an engine are held to in §9,
  with a planted module for every rule, each given by its construction from one minimal module.
- **jwp-receipts.** §7.9 gains checks 9 and 10 for every decoder module a sink would run on a WebAssembly engine,
  whatever its bytes, and their four codes; `key_log::module_check` implements checks 1 to 8, and the key-log corpus
  (§5.8) is of checks 1 to 8. §7.5's *Modules* lets a key that holds `module/decoder` sign the record of check 9c,
  which a sink finds in the head the grant was confirmed under, since the record carries no `signer_id`. §2.4.12's
  decoder entry gains five module members (`module_profile`, `engine`, `engine_settings`, `module_probe`,
  `conform_result`), which a `module:` entry that ran under the profile carries and every other entry, and every
  entry sealed under an earlier text, does not; and rules 15 to 17, with the codes `session_module_profile_missing`
  and `session_module_engine_not_deterministic`. A verifier that implements the profile reads the members and applies
  the three rules; one that does not refuses the members as `unknown_member`, as `wai-rs` and `claim_verify.py` do,
  and §5.11's claim corpus covers rules 1 to 14. A `module:` entry at `decode-equivalence` sealed under an earlier
  text was valid, and a verifier that implements the profile now refuses it (rule 16): that text let a sink state the
  tier for a module's output with nothing of the module checked.
- **browser-sink §4.3 step 6.** A wasm decoder's output holds the registered tier only where the decoder is a module
  the page holds at the integer level; §7.2 binds the frames of any other wasm decoder at `none`. The routing, the
  route's tier and §11's reasons are unchanged. `frame_tier`, the second implementation and the corpus take a `wasm`
  frame's decoder to be such a module (§12), and the page the text names loads no wasm decoder for a room's tracks.
- **determinism-tiers §5, integer-operators §6 and SPEC §7.** WebAssembly as a fabric of `decode-equivalence` is a
  module a sink holds at the integer level. determinism-tiers §5 states that CI checks wai-web's packages for relaxed
  SIMD and threads only, and that the package of record holds floating-point instructions and imports, which the
  integer level refuses.
- This change is text. It changes no code, vector or workflow.
