# live-conformance/sink-energy — sink decode energy

The corpus of [`extensions/sink-energy.md`](../../extensions/sink-energy.md) §9: decode
tables, segment receipts and their chains, and session receipts with their per-hop split,
each with the outcome a verifier gives it; and, under `tables/`, the measured decode tables
of the reference sinks, each with its readings and its procedure.

**Equivalence.** For each case, a conforming verifier given the case's `record`, the
`readings` file (or none, when `null`), the `tables` it holds, the `segments` it holds and the
hop records it holds (`hops`, by digest, from the top-level `hops`) reaches the outcome the
case states (§7): `accept`, or the first reason §7 refuses it with. For `subject` `chain` the
record is `null`, and the case is the stream of receipts in `segments`, in segment order:
each receipt is verified (§7 steps 1–5) and then the chain (§5.3); the outcome is the first
receipt's refusal, or `segment_chain_broken`, or `accept`. An accepted case states the
`identity` of its record (for a chain, of its last receipt). A verifier that reaches another
outcome does not conform.

Each measured table under `tables/<sink>/` is accepted with its `readings.json` held:
`table.json` is the record, `readings.json` the readings file whose SHA-256 is its
`readings_sha256`, and `procedure.txt` the procedure text whose SHA-256 is its
`procedure_sha256`.

**Provenance.** The cases are generated here: `wai_sink_energy_vectors gen` writes
`vectors.json` from values written in code and keys derived from fixed seeds (each key is
SHA-256 of the corpus's fixed label and the key's name), and Ed25519 signing is
deterministic (RFC 8032), so the file is the same bytes on every machine. The bracket
values, figures and estimator inputs of the cases are synthetic constants chosen to exercise
the rules, and were measured by nothing. The measured tables are not synthetic: each was
taken by `wai_sink_table` on the sink its `machine` names, on the date its `measured`
states, and its readings are the counter readings it took. They are signed with the
corpus's fixed-seed table key, which names the corpus, not a machine.

## Layout

`vectors.json`:

```
{ "wai_sink_energy_corpus": 1,
  "keys":  { "<name>": "<public key, hex>" },             informative
  "hops":  { "<digest, hex>": "<per-hop record WMH1, hex>" },
  "cases": [ { "name": string,
               "subject": "table" | "segment" | "chain" | "session",
               "record": object | null,
               "readings": object | null,
               "tables": [ object ],
               "segments": [ object ],
               "hops": [ "<digest, hex>" ],
               "expect": "accept" | "<reason>",
               "identity": "<hex>" | null } ] }
```

- A `table` case's `record` is a decode table, and `readings` its readings file where the
  verifier holds it.
- A `segment` case's `record` is one segment receipt, verified on its own (no chain), with
  the decode tables in `tables`.
- A `chain` case's `segments` are one stream's receipts in segment order, with the decode
  tables in `tables`.
- A `session` case's `record` is a session receipt, `segments` the session's segment
  receipts (every stream's, each stream in segment order), `tables` the decode tables they
  name, and `hops` the digests of the per-hop records the verifier holds.

The hop records are live-metering's `WMH1` (live-metering §3), each of its own room, read as
that extension's §3.6 reads them.

`tables/<sink>/table.json`, `readings.json`, `procedure.txt`: the measured tables (§4).