### Energy honesty: the energy order of dispatch, a metered relay, `HwShunt` closed to new profiles, and what fewer bytes do not save

- **The energy order** (SPEC §4, §7.1 step 2). A sink tries the capabilities an envelope
  offers in the energy order unless its deployer configures another, an order over what it
  advertises and never a reason to advertise: `first` for classical decode the platform
  answers supported, smooth and power-efficient, `smooth`, `classical` (any other classical
  decode, every classical capability of a sink with no platform to ask, and a learned
  capability whose decode the sink holds a qualifying measurement of), and
  `learned-without-budget` last; the envelope's order within a rank. A `WAI1`'s fallback is
  tried first when it ranks before the capability, and the capability after it if it does
  not decode, so the order never makes inert an envelope either could decode. In a `WAI2`
  the entries never picked keep their places. So a learned capability without a
  qualifying measurement is never decoded above a classical fallback the sink can decode.
  A sink that takes the manifest's order says so where it reports a decode.
- **The measurement a learned capability needs** is a sink-metered figure of its decode, in
  browser-sink §6's energy entry: it qualifies with the class `OnChipCounter` or
  `CalibratedInstrument` and the coverage `Whole`. The order reads only whether one is held,
  never its value, so a figure still changes no route (browser-sink §6). A deployer may
  compare it with a ceiling per decode as its own policy; the default does not.
- **The browser sink** (browser-sink §4.7): objects that share a `choice` are alternatives
  of one content (a `WAI2`'s entries, a `WAI1`'s capability and fallback, a track's
  renditions), ordered inside the routing: an alternative routed `ua` ranks by the user
  agent's answer, one routed `host` or `wasm` ranks `classical` whatever the user agent said
  (AV1's user-agent tier is `none`, and a decode-equivalence need with no probe run routes
  elsewhere), and one routed `none` comes last; the page decodes the first that routes
  (`no_alternative` where none does). `browser_sink::choose_report`, the page's
  `chooseReport`, and a `choices` section in `live-conformance/browser/` with each
  alternative's rank and synthetic measurements marked as such, checked by `wai-rs`, by the
  page's wasm build in a browser and by `browser_sink_verify.py`.
- **Platform decode capabilities** ([platform-decode](extensions/platform-decode.md)): the
  query a page asks Media Capabilities and WebCodecs, read from the entry's payload (the AV1
  ISOBMFF binding's codec string from the sequence header, the Annex E.3 string from an
  HEVC SPS), never from what an encoder declared; and the answer entered in browser-sink's
  report, `supported` from `isConfigSupported()` alone and `smooth` and `power_efficient`
  from `decodingInfo()` once it said supported, so a Media Capabilities `supported: false`
  overrides nothing. `powerEfficient` and `prefer-hardware` are hints: never an energy
  figure, never evidence of hardware. The extension defines no order and no second meaning
  of advertising: both are browser-sink's. `wai::platform_decode` (`query`,
  `report_answer`), `platform-decode-conformance/queries.json` (two packaging-corpus floors
  and an SPS the platform's encoder wrote with `prefer-hardware`), and `wai-web`'s
  `platform_decode` bundle (`platformQuery`, `platformAnswer`, `platformChoose`), now built
  in CI. In a browser on an arm64 desktop, every AV1 floor of the packaging corpus decoded
  through WebCodecs with its payload's configuration, and an HEVC stream from the platform's
  encoder decoded back with the codec string read from the stream.
- **Reference.** `wai-rs` `energy_order` (`DispatchPolicy`, `PlatformAnswer`, `Rank`,
  `read_measurement`, `qualifies`); `Wai::dispatch_verified` and `WaiMulti::pick` apply the
  energy order, `dispatch_with` and `pick_with` take another, and the HTTP client's default
  order and the C ABI's `wai_envelope_select` follow it. The HTTP corpus's O2 pin cases and
  the pin corpus's selection cases state the table's order they run in; `select_O2_default`
  and `fetch_O2_default` are the default.
- **`HwShunt` is closed to new profiles** (energy-measurement §2.6, *New profiles*): a
  profile, record, claim, table or registration member defined after the hardware class was
  refined refuses `HwShunt` from every producer and reads it as no other class; the profiles
  that could have sealed it keep their acceptance, listed by name. `wai-rs`
  `energy_class::check_new_profile` (`LegacyInNewProfile`). A package counter read through
  RAPL or a system management unit is `OnChipCounter`.
- **The reference relay meters itself** (live-metering §8). `joule-moq-relay` samples a
  counter every 100 ms: its process's own CPU energy on macOS (scope task), or the CPU
  packages' RAPL energy on a Linux host the operator states runs it alone (scope package).
  A room's record carries the advance over its span as `OnChipCounter` with filtering
  `Unknown` and a declared uncertainty, where the counter was live and the relay served
  that room alone; the unmetered marker otherwise. A session's summary stays unmetered.
  `[metering] energy = "auto" | "off"` and `dedicated_host`; a macOS CI job requires a
  measured figure, and a host with no counter prints SKIPPED.
- **No modelled or zero figure shown as measured.**
  - The C settlement kernel (`oer-conformance/settle/`) graded every receipt `measured`
    from `hardware` whatever its meter; it now writes the grade and device the meter states.
    The host harness's figures are constants, so they are `projected`, from a `simulation`,
    by `model_estimated`, and `firmware_vectors.json` is regenerated.
  - `wai-web`: the world demo seals its page-declared estimate labelled `Estimator` and
    shows it as one; the quantum demos seal the unmetered marker in place of invented
    constants.
  - The quantum studio shows a figure with its class, coverage and uncertainty; the quantum
    CLI prints the unmetered marker as unmetered, not `0 uJ`; the metering tools head their
    bracket as a bracket and print the unmetered marker on stdout when they seal it; a
    provenance total names the class it reads at.
  - The reference meters (`wai_meter`, `wai_video_meter`, `wai_world_meter`,
    `wai_quantum_meter`, `wai_prov`, and `wai_stage_measure --energy macmon`) sealed
    `OnChipCounter` from the processor power a non-privileged reader reports, a channel
    they never read. On macOS 27 the processor channels of IOReport's `Energy Model` group
    stop updating for such a reader, and the reader takes its power from another report it
    selects. The meters now seal `ModelBased`, naming the reader in the measurement report
    as the method. `energy_burst::PowerSource` says what a reader's samples are, and
    `Bracket::on_chip_figure` refuses `OnChipCounter` from a reported power whatever its
    brackets show (energy-measurement §3.1, §2.9). A RAPL reader's bracket, the counter's
    own differences, still seals `OnChipCounter`. No committed record changes class: the
    provenance vector's two figures are unlabelled and keep their bytes.
- **What fewer bytes do not save.** Steering by joules per delivered byte (energy-steering
  §5.5), the attribution of a hop's joules to grants by bytes (live-metering §4.6,
  live-rooms' `joules_ceiling`) and an HTTP client's joule budget (http-delivery
  Appendix F) now say what their figures cover: a hop's own energy or a producer's, not the
  network's, which is largely flat against the traffic it carries. The honest gains of
  fewer bytes are cost and a mobile radio's draw; the energy that changes is the sink's
  decode path and display.

