### The relay and the quantum service answer GET /metrics

- **`wai-relay`** answers `GET /metrics` on its control listener, the operator's surface (a TCP
  address on loopback, or a Unix socket of its own user), after the same check of its peer as
  every control request: a connection that opens with an HTTP/1 request line is answered as HTTP,
  once, and closed, and every other connection keeps the control surface's JSON lines. The
  counters, in the text exposition format (`wai/wai-metrics`): sessions open and opened, the
  tracks held and the downstream subscriptions across them (its fan-out), what its schedulers
  hold, the objects counted in, FETCHes and fills by where they came from, what the receipts door
  refused and dropped, requests refused by why, requests sent upstream by outcome, the rating
  claims held, whether it is going away, `wai_relay_energy_unmetered` (1 when no meter samples its
  own energy, so every record it signs carries the unmetered marker), and the control surface's
  own requests by `op` and refusals by why. `HEAD` is answered as `GET` without the text, another
  method `405`, and another path or a request carrying a field a front sets `404`.
- **`wai-quantum-service`** answers `GET /metrics` before the API key and the client's limits,
  outside its OpenAPI document and its MCP endpoint: its requests by route, method and status
  (the route a path matched, never the path), the jobs it holds by status, the memory its running
  jobs hold, what its store held when it started, and `wai_quantum_energy_unmetered`. A request
  through a front is answered `404`, as a path the service does not have.
- **No party is a label**: every label value of either is fixed in its code, so no room, track,
  job, principal, token, key or address appears. Each one's test reads its answer strictly with
  wai-metrics' reader, moves its series with real sessions or a real job, and finds no label value
  that names a party.