# live-conformance/carousel — when each object passes, and when it is held

The corpus of [`extensions/carousel.md`](../../extensions/carousel.md) §10, in one file,
`vectors.json`.

**Provenance.** Generated here by `wai_carousel_vectors gen` (`wai-rs`, feature `carousel`),
from Ed25519 keys on fixed 32-byte seeds, constant times, and envelopes of exact lengths whose
payloads are opaque test bytes written by the generator; no media and no input from outside this
repository.

`keys` names every key by its role, as 64 lowercase hexadecimal digits: the publisher's
(`publisher`, `did:web:publisher.example#d1`), a second key of its origin (`publisher_d2`), a
sink's (`sink`, signing under its `did:key`), and the roots of the test key logs (`log_root`,
`other_log_root`).

`verdicts` (§6) are each one group of four objects, of 3,200, 896, 288 and 200 octets, as a
verifier holds it:

- `group`: the group receipt (jwp-receipts §2.4.1) and `objects`, each object `receipt` with its
  `envelope` in hexadecimal where the verifier holds the bytes, or `null`;
- `claims`: the transmission and schedule claims, each in its canonical wire form, each signer's
  in the order of its chain;
- `loss_ppm` and `overhead`: the loss bound and overhead (§2); `statement`: `null`, or a
  statement offered (§6.4): `{"kind": "object", "bearer_id", "index", "by_ms"}` or
  `{"kind": "group", "bearer_id", "by_ms"}`;
- `outcome`: `refuse` and its `reason`; or `verdict` with each object's verdict, each claim's
  (`declared`, `stands`, `extended`, `set-aside reason=…`, or `reject step=… reason=…`), a line for each entry
  of each schedule that stands — its `bearer_id`, `leaf_index`, `pass`, `available_ms`,
  `bytes_sent` and `failure_one_in` — and the statement's result.

`claims` are each one schedule claim and its `outcome` through jwp-receipts §3.1 steps 1–4:
`accept`, or `reject step=… reason=…`. Among them every bound of §5.1, §5.2, §5.4, §5.5 and §4.2
rule 3.3 that a schedule can reach, met and passed.

`plans` (§7) are each an `entry` of a schedule, the instant `at_ms` a receiver is at, its
`loss_ppm` and `overhead`, and `held`, the encoding symbols it holds of each source block.
`outcome`: `plan`, with the `passes` it listens to (each `pass`, `start_ms` and `end_ms`),
`complete_ms` and `listen_ms`; or `refuse` and its `reason`.

`inband` (§8.2) are each what a receiver acquired on an instance: its `bearer_id`, the `group`
receipt, the `claims` in chain order, and the key `logs`, each a revision's text keyed by the origin
it was acquired for. `outcome`: `refuse` and its `reason`, for a group that fails; or `inband` with
each claim's label, `set` (`suffices`, or the reason it does not) and `inband_ms`, the interval of
the schedule that stands where the set suffices, `null` otherwise.

Everything is synthetic. Keys attest nothing; bearer instances use the example URN namespace
(`urn:example:`) and origins a reserved example domain. Each case states the outcome it was
written to have, declared in the generator, never copied from a verifier.

`wai_carousel_vectors verify` and `tests/carousel.rs` check that the file regenerates byte for
byte and that `wai-rs` reaches every stated outcome; the test also decodes each RaptorQ object a
case holds available with an independent implementation of RFC 6330, and each Raptor object with one
of RFC 5053, from what a receiver within the case's loss bound holds. `../carousel_verify.py` is the second implementation, written from
the extension's text, which also mutates copies of the corpus and drops each of its own checks
in turn and requires each to be caught. `../../claim-conformance/claim_verify.py carousel
vectors.json` reads every claim through jwp-receipts §3.1 steps 1–4.