### `wai.bearer.receipts`: one receipt on every bearer

- **The defect.** unidirectional-delivery §4 required a receipt for objects sent over a bearer
  with no return path to "declare the bearer as unidirectional", and said a sink's later
  reconciliation is a `claim` "under a class registered for it in jwp-receipts §2.4.4, which none
  yet is". Neither had a mechanism: no field, class or vector. Both are now built, and §4 is
  rewritten so its MUST is met and checked.
- **The extension** ([bearer-receipts](extensions/bearer-receipts.md)) registers the record
  `wai.bearer.receipts`. The group and object receipts stay byte for byte what they were, on every
  bearer; the corpus carries one group on all three bearer classes and checks that its bytes and
  its object verdicts are the same. The bearer is declared beside the receipt, so one group
  carried on several bearers has one receipt and a declaration for each, and no receipt already
  issued changes.
- **Two claim classes in jwp-receipts.** `transmission` (§2.4.14): the publisher's declaration,
  signed by the group's key and naming the group by its link hash, of the bearer's class
  (`bidirectional`, `multicast`, `unidirectional`), the instance, and the transmission's energy
  with its acquisition class or `null`; `attests` is `transmitted`, and anything else is refused
  (`transmission_not_transmitted`). `reconciliation` (§2.4.15): a sink's later statement of the
  objects it received, a bitmap and a root over their leaves under the group's own tree, checked
  against the publisher's root without the objects (`reconciliation_root_mismatch`), refused from
  the publisher's key (`reconciliation_by_publisher`) and over a leaf count or a group not the
  group's; `attests` is `received`. Both are checked against the group at §3.1 step 6, and over
  HTTP against the group of an index item (http-delivery §8.2). Their authorities `transmission`
  and `reconciliation` are registered in §7.5; a transmission's energy figure is an item of its
  own, as a session's is.
- **The verdict over a group** (bearer-receipts §6): `published`, `transmitted` or `reconciled`,
  never delivered on the publisher's word. Declarations of one instance that differ are set aside
  (`bearer_contradicted`); a reconciliation over an undeclared or contradicted instance is counted
  nowhere (`bearer_not_declared`, `bearer_contradicted`); a key is counted once per instance, its
  later reconciliations joined (`reconciliation_duplicate_sink`); a relying party may count only
  keys it confirmed (`sink_not_confirmed`). A statement that a group was delivered to *k* sinks
  holds only when *k* keys reconciled every object (`delivery_not_reconciled`,
  `delivery_exceeds_reconciled`). A sink reports whether the instance it received over was
  declared.
- **Energy per receiver** (§7): an upper bound, ⌈joules / max(1, distinct keys)⌉ at the
  transmission figure's class, tightening as reconciliations arrive; never a measurement, never
  0, none for an unmetered transmission, and stated as a count of keys.
- **No return path** (§8): a sink confirms under anchors provisioned in advance; a key log that
  reaches it over the bearer is held, so a revocation sent over the bearer takes effect, and
  anchors nothing (`anchor_on_bearer`), so a log forged on the bearer confirms nothing.
- **Bearer mappings** (§9), normative for the bytes WAI controls (envelopes whole, receipts and
  claims as http-delivery's receipt files, key logs at their path) and informative for FLUTE
  (RFC 6726), ETSI TS 103 769 V1.2.1, ETSI TS 103 770 V1.2.1, ATSC A/331:2026-04 with
  A/333:2026-04 and A/360:2026-08, 3GPP TS 26.346 V19.3.0 and TS 26.517 V19.3.0,
  `draft-ramadan-moq-multicast-00`, and ETSI TS 102 796 V1.8.1, each at the edition read.
- **Reference implementation and corpus.** `wai-rs` feature `bearer_receipts` (module
  `bearer_receipts`; the bodies in `claim_receipt::bearer`); corpus
  [`live-conformance/bearers/`](live-conformance/bearers/), regenerated by
  `wai_bearer_vectors gen`; second implementation `live-conformance/bearer_verify.py`, written
  from the text, which also mutates the corpus and drops each of its own checks in turn and
  requires each to be caught; `claim-conformance/claim_verify.py bearer` reads the corpus's
  claims through jwp-receipts §3.1 steps 1–4.

