# live-conformance/models — which models a fleet's sinks may run, and what they ran

The corpus of [`extensions/model-governance.md`](../../extensions/model-governance.md) §11, in one
file, `vectors.json`.

**Provenance.** Generated here by `wai_model_policy_vectors gen` (`wai-rs`, feature
`model_policy`), from Ed25519 keys on fixed 32-byte seeds and constant instants. Every set is
named by the SHA-256 of a label, except DRED's weights, which carry the digest
[opus-dred](../../extensions/opus-dred.md) §4.1 names (the file itself is neither read nor held
here). Every dispatch report is written by the reference's `neural_dispatch` functions, and every
presentation statement is signed as exact-upscale §6.2 has it, with synthetic picture digests and
claim link hashes; nothing from outside this repository.

`keys` names every key by its role, as 64 lowercase hexadecimal digits: the operator and a rogue
operator, the root of the operator's key log, an attestation key and a rogue one, three set-top
boxes the policy enrols (the third silent), two signage players the attestation key vouches for,
a device no class holds, and five kiosks a class names by a roster (§4.5; the successor's roster
drops the third).

Each entry of `vectors` is a `bundle` (§8.1) and the `outcome` §8.3 gives it: `accept` with the
policies and the end of the time each is in force, the key log's head and revocations, each run
report and the roll-up's class lines; or `refuse` with the `reason` and the place (`at`) §8.2
writes. Each vector states the outcome it was written to have, never copied from a verifier: an
accepted bundle's statement is built by the generator from what the bundle was made of, and the
roll-up's class lines are declared in the generator. A bundle of the kiosks also holds `rosters`,
the roster documents its roll-up rests on, and each kiosk's report carries its membership proof.

Each entry of `batches` is a list of `bundles` and their `outcomes` (§8.4): the bundles are
verified in order by one verifier that keeps the policies it has read, and each must also get its
outcome from a verifier that keeps nothing. `batch_policy_changed` gives a policy changed after
it was signed after the policy it was signed as; `batch_window` gives a report under a policy its
bundle's window does not hold after a bundle that held it.

The vectors `stop`, `stop_report_under_no_class`, `successor_issued_after_report`,
`successor_issued_before_report` and `report_issued_inside_its_period` give a successor of no
class (§4.3) and the chain a report is held to (§6.4 step 2): a successor issued after a report
does not reach back over it, one issued before it does, and a report dated inside its own period
does not read (§6.1).

`rollup_states_refusals` and the vectors after it give a roll-up that states refusals (§7.3):
reports counting the decodes their sinks refused (§6.1), the refused reports the bundle holds in
`refused`, each refused again for its stated reason, and each set line's decodes by tier.

`wai_model_policy_vectors verify` and `tests/model_policy.rs` check that the file regenerates byte
for byte and that `wai-rs` reaches every stated outcome, each batch's with a verifier that keeps its
policies and with a fresh one. `../model_policy_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. Everything is synthetic: the
keys attest nothing.