# live-conformance/cache-authority — who served what a node holds

The corpus of [`extensions/cache-authority.md`](../../extensions/cache-authority.md) §12, in one
file, `vectors.json`.

**Provenance.** Generated here by `wai_cache_authority_vectors gen` (`wai-rs`, feature
`cache_authority`), from Ed25519 keys on published seeds of one byte repeated 32 times
(jwp-receipts §7.8), constant instants, and envelopes of 2,000 bytes whose payloads are opaque test
bytes written by the generator; no media and no input from outside this repository.

`keys` names every key by its role, as 64 lowercase hexadecimal digits: the publisher `P`
(`did:web:publisher.example#d1`), the nodes `C1` to `C8` and the receivers `R1` to `R4` and `R9`.
`groups` gives the link hashes of `G` (four objects, the tallied group), `G9` (nine), `GL` (labelled
leaves), `GX` (a `group_start` that is not a date-time) and `GF` (four, its object 2 a floor derived
from its object 1). `heads` holds the two test logs' head revisions, of `https://operator.example`
and `https://other.example`; `C2` is in neither.

- `claims` (§5) are each a `claim`, the signer's `earlier` claims in chain order, the `context`
  it is checked against (a group receipt, another receipt, or `null`) and the `objects` held under
  it; `outcome` is `accept`, `unchecked` (no group: it stops at step 5) or
  `reject step=N reason=…`.
- `placements` (§4.4) are each a `key`, an instant `at_ms` and the `heads` named, keyed by origin;
  `outcome` is the placement as §4.4 writes it.
- `verdicts` (§7) are each the `group`, the `objects` (receipt, and envelope or `null`), the
  `claims`, a `sink`'s own instance, a statement offered (`assertion`), `count_only` and the
  `heads`; `outcome` gives each object's and each claim's label, the status, `sinks`, `whole`,
  `received_by`, the publisher's `bearers` and the `caches` that stand, the sink's outcome and the
  statement's (`holds` or `reject reason=…`), or `refuse reason=…` for a group that fails.
- `tallies` (§8) are a verdict's inputs, the `acknowledgements` (each a record and its item lists,
  in hexadecimal), the holdings `records`, the object's `index`, a `deadline_ms` or a timeliness
  `deadline_claim`, the `region`, the `population` and `miss_target_ppm`; `outcome` is `met` or
  `refuse reason=miss_target_exceeded` with §8.5's figures, or `refuse reason=…` for §8.2.
- `lines` (§9) are a verdict's inputs, acknowledgements and holdings records, a timeliness `claim`
  and an `index`; `outcome` is timeliness §6.3's lines for that object's entry, from held-at
  statements of all three kinds.

Everything is synthetic: keys attest nothing, both key logs are test logs, origins and bearer
instances are reserved example domains, and regions are ISO 3166-1's user-assigned codes. Each case
states the outcome it was written to have, declared in the generator, never copied from a
verifier. §8.1's bound of 1,048,576 keys is carried by no vector (32 MiB of hexadecimal); both
implementations check it themselves.

`wai_cache_authority_vectors verify` and `tests/cache_authority.rs` check that the file regenerates
byte for byte and that `wai-rs` reaches every stated outcome. `../cache_authority_verify.py` is the
second implementation, written from the extension's text, which also mutates copies of the corpus
and drops each of its own checks in turn and requires each to be caught.