### Timeliness: a ladder of fallbacks, and the reference scheduler a sink runs its plans with

- **The ladder** ([extensions/timeliness.md](extensions/timeliness.md) §4.1, §4.2, §5.3, §6.3,
  §7.3). An entry's `fallback` is now an ordered ladder of renditions: `null`, one rung as an
  object, or two to eight rungs as an array in strictly falling `value_ppm`, no object named twice
  (`timeliness_ladder_invalid`, §4.2 rule 3.4). One rung has one form, the object, and an array of
  one is refused, so an entry with one fallback object is a ladder of one rung, read, judged and
  planned as it was, and two entries that state one ladder are written alike. Every rung is held to
  §4.3's steps 6 to 8 and derives from the primary itself.
- **Which rung, when** (§5.3). At `by_ms` a sink presents the primary it holds, else the first rung
  of the ladder it holds, the highest valued. Holding neither, it has passed every rung, states
  `passed`, and presents no rung in the primary's place from then on; it presents the primary when
  it first holds it, at its value then, where that is at least 1, and at the primary's end, having
  presented nothing, it abandons any request and states `ended`. A line's *f* is one instant for a
  ladder of one rung and the list of them for more (§6.3), and a plan names the rung it chooses, by
  its index (§7.3).
- **Running a plan** (§7.5), the reference `timeliness::scheduler`: from a sink's plans and the
  instants at which it first held each object, the sink's decisions (`fetch`, `abandon`, `present`,
  `passed`, `ended`) by exact steps, a function of those inputs alone. A later plan replaces the
  one in force wholly: a fetch it does not continue from the same source is abandoned, an object it
  no longer wants is no longer run, and what is settled stays settled. `plans_invalid` and
  `arrivals_invalid` refuse a run's inputs (§7.5.1).
- **The corpus** [`live-conformance/timeliness/`](live-conformance/timeliness/) gains the group E,
  ladder claims, verdicts and plans, and `runs`: the traces and edges of §7.5.3, among them a late
  object, every rung passed and a plan replaced mid-run. `timeliness_verify.py` writes the ladder
  and the run from the text and is required to give every case its stated outcome, and
  `claim_verify.py` holds rule 3.4 and reads every run's claims. A plan's choices in the corpus gain
  the member `rung`.
- **Breaking:** `api:rust:wai::claim_receipt::Reason::TimelinessLadderInvalid`: the reason rule 3.4
  raises, which an exhaustive match over `Reason` needs.
- **Breaking:** `api:rust:wai::claim_receipt::TimelinessEntry::fallback` and
  `api:rust:wai::claim_receipt::timeliness::TimelinessEntry::fallback`: the field is a `Ladder`
  rather than an `Option<Fallback>`, since a fallback may hold several rungs, and each form is kept
  as read so a claim writes back to its own bytes. An `Option<Fallback>` converts with `.into()`,
  and `fallback.rungs()` reads the rungs of any form.
- **Breaking:** `api:rust:wai::timeliness::Choice::rung` and
  `api:rust:wai::timeliness::Line::rungs_ms`: a plan's choice names its rung, and a line holds each rung's instant, which a struct literal of
  either needs. `Line::fallback_ms` keeps its meaning for one rung and is `None` for an array.
