### When an object is still worth delivering, and whether it was delivered in time

- **Timeliness** ([extensions/timeliness.md](extensions/timeliness.md)), the record
  `wai.delivery.timeliness`: a publisher's signed statement, a jwp-receipts claim of class
  `timeliness` (§2.4.17) beside the group receipt and one for every bearer, of when each object of
  a group is of use: the instant it is useful from, the deadline by which a receiver must hold it
  for its full value, how that value falls after it — a stated piecewise-linear function in parts
  per million, floored, of one to sixteen points, every one a change of slope, 0 from its end —
  and the rendition a receiver presents in its place, a separate object whose `derived_from` names
  the primary, as packaging's floor objects do. Each entry is held to its group, its object's
  content hash, and its fallback's position and derivation where they are held; an entry for a
  staged layer, and a layer named as a fallback, are refused, since staged-delivery §8 alone
  decides a layer's lateness. Two statements that differ for one object set both aside.
- **Judging delivery.** From holdings records (a holder's word that it held an object at an
  instant), a verifier judges each object for each holder, as a sink that decides at the deadline
  with what it holds would present: on time, replaced by its fallback, held only after its
  deadline and at what value at least, or not shown. Every instant is an upper bound on arrival,
  so every value is a lower bound; a record dated before its group began is refused; an object
  with no statement is never on time.
- **Planning.** An asker plans each object from an instant it states, over its sources in its own
  order — a carousel's passes, a neighbour's holdings, the origin — and gets the first source on
  time, the fallback, or the best late source. Planned from each object's own `from_ms` over one
  instance, it is the promise a publisher's schedule makes to a receiver that tunes in when the
  object becomes of use; carousel §6.4 at the deadline is the promise to one that hears every
  pass.
- **Mappings**: the MoQ per-hop `OBJECT_DELIVERY_TIMEOUT` (MOQT -23 §5.2, §10.2; numbered as in
  -22) from the slack to the object's end, never 0 and never below a base's floor; priorities
  unchanged; an HTTP client's abandonment at the end (http-delivery §10.1 admits it) and CMCD `dl`
  (CTA-5004-B §4.3); DVB multicast ABR's `@targetAcquisitionLatency` for carouselled resources; an
  ATSC 3.0 entry package's HELD `@validFrom`; a bundle's `Lifetime` (RFC 9171 §4.3.1).
  delivery-telemetry §5's switch reasons gain `not-held-by-deadline`. The end-to-end MoQ timeout
  draft is read and not bound.
- **The corpus** [`live-conformance/timeliness/`](live-conformance/timeliness/): claims at every
  bound of the rules, the value function at every edge (a span whose products pass 2^64 among
  them), verdicts, and plans. `timeliness_verify.py` is a second implementation;
  `claim_verify.py timeliness` reads every claim through steps 1–4; the claim corpus holds a
  `reconstruct-session` claim that switches for `not-held-by-deadline`, which both claim verifiers
  accept; and http-delivery §8.2's receipt-index check holds a `timeliness` claim to its group in
  both implementations.
- **Breaking:** `api:rust:wai::claim_receipt::ClaimClass::Timeliness` and
  `api:rust:wai::claim_receipt::ClaimBody::Timeliness`: the class jwp-receipts §2.4.17 registers,
  which an exhaustive match over either needs.
- **Breaking:** the reasons of the class, which an exhaustive match over `Reason` needs:
  `api:rust:wai::claim_receipt::Reason::TimelinessNotValued`,
  `api:rust:wai::claim_receipt::Reason::TimelinessObjectsMalformed`,
  `api:rust:wai::claim_receipt::Reason::TimelinessWindowInvalid`,
  `api:rust:wai::claim_receipt::Reason::TimelinessDecayInvalid`,
  `api:rust:wai::claim_receipt::Reason::TimelinessFallbackInvalid`,
  `api:rust:wai::claim_receipt::Reason::TimelinessSubjectMismatch`,
  `api:rust:wai::claim_receipt::Reason::TimelinessSignerMismatch`,
  `api:rust:wai::claim_receipt::Reason::TimelinessLeafOutOfRange`,
  `api:rust:wai::claim_receipt::Reason::TimelinessBeforeGroup`,
  `api:rust:wai::claim_receipt::Reason::TimelinessContentMismatch`,
  `api:rust:wai::claim_receipt::Reason::TimelinessOnLayer`,
  `api:rust:wai::claim_receipt::Reason::TimelinessFallbackMismatch` and
  `api:rust:wai::claim_receipt::Reason::TimelinessFallbackNotDerived`.
