# WAI decisions Each choice here is decided, and its reason is written beside it: what was read, and why the choice follows. A choice that is the owner's (money, contracts, licences, going live) is not made here. - **D1. The video floor is AV1's Main profile, at the Main tier, at level 4.1 and below.** Decided 2026-11-10. SPEC §5, *Video floor*; packaging §7.1; `floor-conformance/`. - **What was read.** The AV1 Bitstream & Decoding Process Specification, version 1.0.0 with Errata 1, Annex A. A.2: a Main-profile decoder decodes `seq_profile` 0, 4:2:0 or monochrome at 8 or 10 bits; High adds 4:4:4, and Professional adds 12 bits and 4:2:2. A.3: each operating point carries a `seq_level_idx`; level 4.0 is 2 359 296 samples a picture, at most 6144 wide and 3456 high, and 70 778 880 samples a second (its example 1920 × 1080 at 30 frames); level 4.1 is the same picture at 141 557 760 samples a second (1920 × 1080 at 60), with a Main-tier rate of 20 Mbit/s (High tier, 50); level 5.0 raises the picture to 8 912 896 samples (3840 × 2160); `seq_level_idx` 31 is *maximum parameters*, which carries no limits. A.4: a level X.Y decoder decodes every stream that conforms to that level. And a major mobile platform's compatibility definition (read 2026-11-10): every handheld decodes AV1 and offers it to applications; an AV1 decoder decodes the Main profile at 8 and 10 bits; a hardware AV1 decoder decodes 1920 × 1080 at 30 frames and 16 Mbit/s where the display is that tall; its media performance class requires a hardware AV1 decoder of Main 10 at level 4.1, and requires AV1 only to 1080p where it asks other codecs for 2160p. - **What the packager's floor renditions need.** The floor rendition is the one rendition of a packaged video that every sink that presents video plays (packaging §7). It is the HD rendition of content made at 24 to 60 frames a second. Level 4.1 holds 1920 × 1080 at 60 (124 416 000 samples a second) and 2048 × 1152 at 60 exactly; level 4.0 holds 1080-line pictures at 30 only, so content at 50 or 60 frames would have to fall to a 720-line floor. A level of 5.0 or above would hold 2160-line pictures, which a floor rendition does not need, and would raise the picture every video sink must decode nearly fourfold. - **What platform decoders broadly hold.** The platform requirements read ask AV1 at 1080p, Main profile, 8 and 10 bits, and name level 4.1 where they name a level; a 1080p30 decode at 16 Mbit/s is past level 4.0's Main-tier 12 Mbit/s and within level 4.1's 20. None asks AV1 above 1080p. So level 4.1 is the highest level those requirements reach and the lowest that holds the floor's renditions. - **The tier.** Main. The High tier raises the bit rate a decoder of the level must take (to 50 Mbit/s at 4.1), which no requirement read asks of a floor. - **What stays outside the floor.** The High and Professional profiles, the High tier and the levels above 4.1 stay in the recommended set: a sink SHOULD decode them (SPEC §5). - **What follows.** A sink that presents video MUST decode a `wai.video.av1` payload in the video-floor profile: every sequence header at `seq_profile` 0, every operating point at `seq_tier` 0 and `seq_level_idx` ≤ 9, and the framing's largest frame and frame rate within level 4.1's limits. A packager's first floor rung of a video component is the floor rendition and is refused outside it (`floor-av1-profile`, `floor-av1-level`). The decoder suite's video-floor case signals level 4.1, the top of the bound, and the suite holds a High-profile stream and a level-5.0 stream that are refused as a floor. - **D2. A core candidate is re-pinned, not given a new version.** Decided 2026-11-10. CORE.md, *The freeze rule*; `scripts/check-wai-core-freeze.py`. - The freeze rule let a change of meaning pass only with the core version raised. The core is a 1.0 candidate that its maintainers have not declared; raising its version for the edits that must precede 1.0 would make it a 1.1 candidate, and 1.0 could never be declared. A release candidate is numbered within its version. - So, while the lock's status is `candidate`, a change of meaning raises the lock's `candidate` by exactly one, rewrites the digests, and adds a dated note naming each item whose pin changed and why. A changed pin without both fails; so do a note that leaves out a changed item or names an unchanged one, a candidate raised with no changed pin, and a re-pin of a core that is not a candidate. A declared core changes by a version bump alone; an erratum stays the way to change wording without meaning. - Candidate 2 is one re-pin for the whole of its change: the six splits CORE.md listed and the video floor's bound (D1). - **D3. `claim-conformance/` and `signer-conformance/` stay unpinned.** Decided 2026-11-10. CORE.md, *What is not pinned*. - Every vector of both carries profile content: a claim's class, a key log's authorities (which name classes), an authority case's item. Both are written byte for byte by generators that build even their envelope, signature and chain cases from profile classes, so pinning them would freeze those classes, and a class is a profile's to change under its version. The rules every class keeps are pinned as text instead (`receipts.2.4.4`, `receipts.3.1`, `receipts.7.5`, `receipts.7.9` and the rest of jwp-receipts §7). - **D4. OER/2's exception to the signature rule stays in the core's text.** Decided 2026-11-10. SPEC §7, *Signatures*; CORE.md, *What is held although it names a profile*. - The rule fixes which signatures every conforming verifier accepts, so an exception to it is part of the rule. Stated over a profile's list, it would let a profile change what a core verifier accepts. It stays held, naming the one record family whose chain signature was settled before the rule. - **D5. An invalid-traffic rule is one that signed records decide; the rest stays out of scope.** Decided 2026-11-10. ad-presentation §14.1; stitched-presentation §12. - Read: *Invalid Traffic Detection and Filtration Standards Addendum*, June 2020 update (final), §1 to §2.4.1 and §4.2 to §4.2.2. Its general invalid traffic is found by "lists or with other standardized parameter checks", its sophisticated invalid traffic by analysis. A WAI verifier's verdict must be the same in every implementation, so a rule here is a comparison of signed bytes or integers and never a score, a rate or a model. - So six rules are in: two claims of one impression, a span past the creative or a media time in two claims, an absent attestation where the terms require one, sessions past a signed cap under one device key, a signed address in a list pinned by digest, and a signed user agent holding a token of a list pinned by digest. Traffic judged by browser type, speed, interval, repetition or outliers, and all sophisticated invalid traffic, are not approximated; the texts name them as the measurer's. - A list rule decides membership in the pinned bytes. Whether a range's traffic is invalid is the list's publisher's judgment and the pinning authority's: the addendum requires data-center traffic to be "known to be invalid in order to be filtered", and a verifier cannot know that. - An impression a turned-on rule has no record for is undecided and its spend withheld, apart from both the valid and the excluded, as the addendum keeps impressions "without sufficient information to make an IVT decision" out of the invalid counts. An excluded impression is counted as excluded, never dropped. - The texts set no rule for how an operator identifies a person: a device key is a key the device holds, and an address is what a named edge signed that it saw. - **D6. An identity assertion's holder signs the core deterministic encoding of the signer payload, and WAI keeps those bytes where a C2PA SDK's validator verifies others.** Decided 2026-11-10. c2pa-binding §4.10, §4.11 and §9.3. - Read: *Identity Assertion*, version 1.3 (DIF Ratified Specification, 17 August 2026), §5.2 and §8.2.1 to §8.2.2. §8.2.1: the `signer_payload` "MUST be serialized as described in Section 4.2.1, 'Core Deterministic Encoding,' of RFC 8949", and "the resulting byte string is presented to the credential holder for signature". RFC 8949 §4.2.1 sorts a map's keys bytewise by their encodings, so the members are signed as `role`, `sig_type`, `referenced_assertions`. The text names one serialization and admits no other. - The SDK `c2pa_emit` signs through (the `c2pa` crate, 0.91.7) verifies an identity assertion's signature over the members in the schema's order (`referenced_assertions`, `sig_type`, `role`), and so reports `cawg.x509.signature.mismatch` of every assertion signed as §8.2.1 says, and none of one signed over that order. - So WAI writes and verifies §8.2.1's bytes, on its own stores and through the SDK alike, and does not read the other order: an assertion signed over it is refused (`identity_signature_mismatch`). Accepting both would have a verifier accept a signature over bytes the specification does not name. The difference is stated in c2pa-binding §9.3 and pinned by a test that fails when the SDK's validator changes which bytes it verifies. - **D7. Over HTTP a room's part is served when its group's receipts are held, and low latency is a measurement.** Decided 2026-11-10. live-http-egress §3.2, §6.2, §9. - Read: `draft-pantos-hls-rfc8216bis-22` §4.4.3.7 to §4.4.5.3 and §6.2.2 to §6.2.6; `draft-ietf-moq-cmsf-01`, whole; the DASH Industry Forum's change request *Low-latency Modes for DASH* of 27 March 2020, clauses 9.X.4 and 9.X.5. ISO/IEC 23009-1 and ISO/IEC 23000-19 were not read. - A group's receipts are signed over all its objects (jwp-receipts §2.2), and an egress serves no byte it has not verified. So a part is served as it arrives only where the publisher published the group's receipts before the group; a publisher that signs at a group's end has the group's parts served then. No receipt over part of a group is defined: it would be a second signature format, and is left until a publisher needs it. - A latency figure states its host, its path, what was timed and the parameters. The HLS part hold-back and the DASH `ServiceDescription` target are what an egress asks of a player, and are never written as what a viewer gets. - The MPD addresses segments by number at one duration, as the change request's `SegmentTemplate@duration` with `$Number$` does, so it is served only for tracks whose groups are on a grid; tracks off a grid are served over HLS alone. A `SegmentTimeline` would lift that at the cost of an MPD that changes with every segment. - A room's CMAF track carries receipts as any media track of the room does, and its catalog entry names its receipts track. The packaging draft's text (`ietf/`, §5.3.3) states that link for `wai` and `wai-link` tracks and has not yet been revised to name `cmaf`; `ietf/catalog_check.py` holds a `cmaf` track's link to the same rules meanwhile. - **D8. A MoQ extension draft is implemented with what the transport draft spoken has; its unmerged or unassigned parts are not sent.** Decided 2026-11-10. moq-streaming-format §4.6; co-watch §15. - Track switching is stated as a SUBSCRIBE and a REQUEST_UPDATE of `draft-ietf-moq-transport-23`. `SWITCH_FROM` (two pull requests against MOQT, unmerged) and `draft-gurel-moq-track-switching-01`'s `altTrackGroup` and Switch Track Alias are in no MOQT revision, so no implementation would read them, and they are not sent. - Where a draft's code points are unassigned (`draft-nandakumar-moq-tempo-00`'s TBD1, TBD2, TBD3 and TBD6), the reference uses placeholders in the range MOQT leaves to an application, held in one module and stated as placeholders wherever they appear. A message parameter among them is sent only on a session whose peer declared a Setup Option for it: an unknown message parameter cannot be skipped (-23 §9.19), and an unknown Setup Option is ignored (§9.1). - A relay's measurement is a record of one host on one day, signed, and compared only with that host's own earlier record. No public text states a figure of one as a property of the relay, and none compares it with another implementation's. - **D9. Coding for machines is registered as two candidates with no probe, and its split of work is receipted by two claims, never one figure.** Decided 2026-11-10. SPEC §5, *Candidate capabilities*; format-probes §19; task-fidelity §5; machine-descriptors. - **What was read.** The committee's public project pages for MPEG-AI Part 2 (video coding for machines, ISO/IEC 23888-2) and Part 4 (feature coding for machines, ISO/IEC 23888-4), as served on 2026-11-10. Each states its objectives, gives its first edition a publication year of 0 and the status `ongoing`, and lists as documents only the common test conditions of each meeting (for Part 4, the common test and training conditions). - **What was not readable.** The text of either part, at any stage: neither project page links a draft, and the ISO catalogue's search page answered the fetch with 403, so its entries for the standard were not read. No stage (committee draft, draft international standard) is stated on the pages read, so the specification states none. - **What follows for the registry.** Both are candidates: a registered string with no pinned payload format, never emitted and never dispatched. Neither has a probe. A probe is written from a text that says how a payload begins and where its parameters lie, and none read says either; a probe from a draft's software would pin a bitstream the next meeting may change. Their licence class is `patent-pool`, provisional, as for every candidate whose royalty terms no text states, and that is a registry class, not a reading of any patent. - **What follows for claims.** A candidate is registered for what its bitstream and records are. No benchmark was run and no task accuracy is claimed for either format: a claim about a task's result is a task-fidelity claim, with its model, test, tolerance and observation, made by whoever ran the test. - **The split of work.** Feature coding puts part of a network on each side of the wire, so one figure for "producing the object" would name a producer that does not exist. Each side signs its own half, with its own meter's class or none. A verifier adds two figures only when they are of one acquisition class, gives no total across classes, and lists an unmetered side as unmetered. The halves are shown to belong together by a digest over the cut and both parameter sets that each half must restate, not by either party's word about the other. - **Descriptors.** A machine's labels, regions and embeddings are a signed statement by the machine that a named model gave them for a named object. They are carried on the existing `meta` event rather than a new kind, so no event reader, relay or policy record changes; an embedding is named by digest and its vector is not carried in the event. - **D10. SCTE 224 is imported from its schema and a public practice; what its clauses alone define is refused, never guessed.** Decided 2026-11-10. audience-decision §10. - Read: the XML schema `scte_224_20211011.xsd` of ANSI/SCTE 224 2021, as the schema documentation of the EPG Linear Schedule Data specification reproduces it, and *Blackouts and Airing Substitution, Encoding Best Practice* (BP-EPG-BLK v1.0 draft, 1 October 2026), CC BY 4.0. The standard's own text was requested from its publisher's site on 10 November 2026 and refused to an unattended client, so its clauses were not read. - So the import binds what those two fix: the elements and their order, `match`'s three values, time-matched media points, `Apply`'s duration, `Remove` by reference, the audience and action namespaces, `audience:Zip`, and the blackout value of `action:Content`. Anything else a document uses (`MatchSignal`, the eligibility window, `priority`, `matchOffset`, `order`, `reusable`, `source`, an audience of `ALL` over several members, re-application) is refused `scte224_not_carried`, with no meaning given to it. - No audience property the public texts fix maps exactly onto a region code: a postal code is not one and lies in none. A blackout's regions are therefore carried in a property of WAI's own namespace, in the place the schema gives to properties of another namespace, and `audience:Zip` and an excluded audience (`NONE`) are refused `scte224_audience_unmappable`. A postal code is never mapped to the region that holds it. - Open: whether the standard's clauses define a country or subdivision property. If they do, it is imported once the text is read, beside WAI's own. - **D11. An ad creative record is checked against a receipt, never in its place; a stitched track is recomputed.** Decided 2026-11-10. live-ads §13, §14. - Read: `draft-riedl-moq-ad-creative-signaling-01` and `draft-englishm-moq-content-stitching-00`, whole, with the first's schema and vectors. SVTA 2053-1 was not read; the payload is read only as far as the draft states it. - A record's signer must be the decider and its pod the fill a receipt signs. A record that names tracking or verification resources is read, and a WAI sink requests none of them: presentation is stated by a signed claim. - The content stitching draft defines no format. The composed track is fixed here as a function of the programme's listing, the schedule and the receipts, changing ingredient at Group boundaries alone, so that a verifier recomputes it. Nothing is asked of a relay. - **D12. An edge cache's rules are written as CDNI metadata with one object of WAI's own, and the open-caching objects follow the IETF drafts.** Decided 2026-11-10. cache-metadata §4, §6. - Read: RFC 8006 §3.3, §4.1, §4.2.1, §4.2.2.2, §4.2.6, §4.3.1 to §4.3.3, §4.3.8, §6.5 to §6.7 and §7.3; RFC 8008 §5.1 to §5.4, §5.7 and Appendix B; RFC 9388 §1 and §2; `draft-ietf-cdni-cache-control-metadata-06` §3; `draft-ietf-cdni-edge-control-metadata-13` §4. The Streaming Video Technology Alliance lists its open-caching configuration interface as a set of documents on its site; their text could not be retrieved without an account and was not read. `draft-ietf-cdni-processing-stages-metadata-02` was fetched and is not relied on. - RFC 8006 has no metadata for range handling, transformation, request-header variation or a lifetime, and the cache-control draft covers the lifetime only. So those rules travel in one GenericMetadata type of WAI's own, `WAI.ByteStore`, marked mandatory to enforce: RFC 8006 §6.6 then has a cache that does not know it serve nothing, which is the safe failure. The name identifies whose it is, as RFC 8006 §6.5 recommends for a type outside the registry. It is not registered; registering it is left until a cache implements it. - The open-caching form writes the drafts' `MI.CachePolicy`, `MI.StaleContentCachePolicy` and `MI.AllowCompress`, and restates nothing else. If the published interface differs from the drafts in a member's name or default, the form is revised against the published text once it has been read; the `cdni` form does not depend on it. - A reader refuses a configuration that departs from the rules rather than taking the nearest reading, access-control metadata included, which this revision's form does not carry. A configuration is an instruction: no sink relies on one, and no record is added for it.