### Parameter sets: where a set is fetched, a successor coded against its predecessor, when a set is worth holding, who may read it, and a set verified piece by piece

- **Set roots** ([http-delivery](extensions/http-delivery.md) §8.5, §8.7): a set is served at
  `<root><sha256>` below a set root, an absolute `https` URI whose path ends in `/`. §8.5 named the
  place `<base>/<sha256>` and never said what `<base>` was; the word also collided with §2's term
  **Base**. An origin serves its sets below `/.well-known/wai-sets/`, so a sink that holds an
  object can always name where to ask.
- **Location hints**: a `wai_priors` entry's member `locations`
  ([moq-streaming-format](extensions/moq-streaming-format.md) §4.2) and a WAI multivariant
  playlist's one `EXT-X-SESSION-DATA` line of `DATA-ID` `science.transaction.wai.sets`, its roots
  separated by spaces (RFC 8216 §4.3.4.4 admits one such line with no `LANGUAGE`, and a reader
  ignores any later one), list roots to ask, read in order, at most eight; an element that holds no
  root is passed over (`set_location_malformed`) and never refuses a track. A sink asks the roots of
  its own configuration, then the hint's, then the origin's well-known root, each once; it holds a
  response's bytes only when their SHA-256 is the digest it asked for, and otherwise asks the next
  root (`set_location_unavailable`, `content_coding_present`, `set_too_large`,
  `set_location_mismatch`). A listing's files are asked first where the listing was found. The pin
  stays identity-only: no member of a pin is read as a location.
- **prior-carriage §15** says where a set is fetched and why the pin carries no location.
- **Sets as compression dictionaries** ([http-delivery](extensions/http-delivery.md) §8.8,
  [prior-carriage](extensions/prior-carriage.md) §16): RFC 9842's `Available-Dictionary` names a
  dictionary by its SHA-256, which is the digest a pin states for a set in a one-file form, so a
  held set is a dictionary under its own name. A server MAY offer a set as one
  (`Use-As-Dictionary: match="<root path>*"`) and answer a request that names a held set with the
  requested set coded against it, `dcz` or `dcb`, with `Vary: accept-encoding,
  available-dictionary`. A client checks, in order, that it asked for the coding
  (`dictionary_unrequested`), the coding's header (`dictionary_coding_malformed`), the dictionary's
  SHA-256 in it (`dictionary_mismatch`), the window RFC 9842 has it decode
  (`dictionary_window_too_large`) and the decoding within its bound, then holds the decoded bytes
  only by the pin's digest; a refused coded response sends it to the same root again without a
  dictionary. A client that writes the field itself names the set the pin `supersedes`. The coded
  bytes are a transfer and never a form: no pin names them. Caches store a coded response under
  its `Vary` and never code a set themselves; a range of a set is never coded. The reference
  decodes `dcz` only, through the Zstandard binding the neural decoders use.
- **When a set is worth holding** ([prior-carriage](extensions/prior-carriage.md) §17): the
  break-even rule that exact-upscale §5 stated for per-title priors is now prior-carriage's, for
  every set, and exact-upscale §5 points to it. A generation's saving to a sink, over the titles it
  is expected to fetch within a stated span, must exceed its cost to that sink: nothing when the
  sink holds the set, the coded bytes of §16 when it holds the predecessor, the set's bytes
  otherwise. The cost is charged per sink, never divided among the sinks a publisher serves. A
  sink holds at most a stated number of generations, the largest net first and, at an equal net,
  the later; every other title takes its classical rendition. A sink that has disclosed no held set
  counts as one that holds none. An origin freezes a set for a catalog epoch, and a re-tuned set
  begins the next as a new generation whose pin names its predecessor in `supersedes`; older
  titles keep their pins and decode where their generation is kept, or are re-encoded. A plan that
  does not read is refused (`plan_malformed`, prior-carriage §20).
- **Usage, access and leakage** ([prior-carriage](extensions/prior-carriage.md) §18): a set's
  **usage statement** (`wai-set-usage`: an SPDX licence expression, a terms URI, whether the set
  was fitted to content, whether a holder may serve it to others, and an ai-usage statement for
  uses of its bytes besides decoding) is bound to a set only inside the bytes its pin covers, as
  the top-level path `wai-usage.json` of a listing or in a sealed set's header; a bound statement
  that does not read leaves the set not held (`set_usage_malformed`); a holder of a set that may
  not be redistributed serves it to no one but as a cache for its origin. **Sealed sets**,
  `wai.prior.sealed` (`WSK1`), registered: a one-file set under AES-128 in counter mode, its key
  named by a 16-byte identifier as a content key is and released by its origin; the pin covers
  the sealed bytes, so any server may serve them, and a sink without the key does not hold the set
  (`prior_not_held`, `set_key_absent`); opened, the plaintext is checked against the SHA-256 the
  header states (`set_key_mismatch`), and both digests are the set's identities for revocation.
  The registry lists it as established exact. **Leakage**: a content-derived set can carry
  features of the frames it was fitted to, and SHOULD be sealed when that content is under access
  control; a per-title prior's digest names its title.
- **What a sink discloses of the sets it holds** ([http-delivery](extensions/http-delivery.md)
  §12.5): sets are kept per top-level site; `held_sets` is off unless turned on for a site and
  then lists only the held sets that site's content pins, a revoked set never; nothing is sent or
  named across sites, `Available-Dictionary` included; clearing a site's data clears its sets; a
  report of held sets is an aggregate. SECURITY.md no longer says these rules are not written.
- **The chunk-tree form**, `wai.prior.tree` (`WTR1`, [prior-carriage](extensions/prior-carriage.md)
  §19), registered: a head names a one-file set by its length, SHA-256 and BLAKE3 hash and lists
  the BLAKE3 chaining value of each piece of 1024 · 2^g bytes, each a subtree of BLAKE3's tree over
  the set, whose values merge to the set's BLAKE3 hash. The pin covers the head; the set is served
  under its own SHA-256 and fetched by range from any peers, each piece checked as it arrives and a
  changed piece refused at that piece (`tree_piece_mismatch`) and fetched elsewhere; the whole set
  is then checked against its SHA-256 (`tree_digest_mismatch`). Its inner form may be a sealed set.
  The registry lists it as established exact.
- **The registry** lists `/.well-known/wai-sets/` and `science.transaction.wai.sets` as wire
  identifiers of http-delivery §8.7, `wai.prior.sealed` and `wai.prior.tree`, and `WSK1`,
  `wai-set-usage`, `wai-usage.json` and `WTR1` of prior-carriage §18 and §19.
- **The corpus** [`live-conformance/prior-carriage/`](live-conformance/prior-carriage/) reads the
  priors of the prior-forms corpus and a listing of the pin corpus. For §8.7: 19 strings tested as
  set roots, 14 hints from catalog entries and playlists (among them playlists with a second line of
  the hint's `DATA-ID` and with one that carries `LANGUAGE`, each ignored), and 14 fetches over
  stated responses, among them a set held from the second root of its hint after the first served
  other bytes, a listing and its files held from two roots, a listed file no root holds
  (`part_mismatch`), a pin whose own member names a location, which no fetch asks, and listings with
  a file named `wai-usage.json`: at the top-level path, held with its terms; there and not reading
  (`set_usage_malformed`); and below the top, which binds nothing. For §8.8: `title`, the upscale
  corpus's per-title prior, fine-tuned from `generic`, coded against `generic`
  (`files/title-from-generic.dcz`), 9 fetches over it (the successor held through its predecessor,
  each check of a coded response refusing, a decoding that yields another set, one past the bound),
  9 field values, and the check a stock client makes, which the Zstandard tool passes: the body
  after its 40-byte header, decoded against `generic`, has `title`'s SHA-256. For §17: 11 worked
  plans, among them a net of exactly 0 (not worth holding), a successor costing its coded bytes
  where its predecessor is held, a sink holding two generations when a third is worth fetching (with
  a cap of two it evicts the one of smallest net; with three it keeps all), and three sinks that
  together would save more than the set's size and each save less, none of which fetches it; and 10
  plans refused. For §18 and §12.5: 16 usage statements, `title` and `generic` sealed under a
  published test key and 13 openings (with the key, without it, under another key, a changed
  ciphertext byte, and headers broken one way each, among them inner forms of a listing, a sealed
  set and a tree), and 9 cases of held sets per site. For §19: 13 heads (of `generic` in pieces of
  one and two chunks, of the sealed `title`, and broken one way each, among them inner forms of a
  listing, a tree and a string no form registers) and 9 fetches from two peers (a byte changed in
  piece 3 at one peer, refused there and fetched from the other; a peer that does not answer; both
  peers wrong at one piece, which leaves the set not held; a content coding; a peer whose bytes end
  early; the sealed `title`; a head that misstates its set's digest). `prior_carriage_verify.py` is
  a second implementation, with a Zstandard decoder of its own written from RFC 8878
  (`_rfc8878_zstd.py`) and an AES-128 written from FIPS 197 (`_fips197_aes.py`), and the BLAKE3 the
  corpora's Python verifiers share; it catches 29 of 29 mutated copies of the corpus and 44 of 44
  weakened copies of itself.
