open-standards/wai/pin-conformance/README.md
Transaction Science 9f42a4a447 wai: the energy order keeps non-selectable entries in place; the HTTP and pin corpora state their order
energy_order reorders only the entries SPEC §7.1 step 2 may pick, each into one
of their table places; a companion or refinement keeps its own, so where
nothing selectable moves the walk is table order. SPEC §7.1 says so.

HTTP (http-delivery §7 step 4): the client's select and fetch default to the
energy order. O2's pin cases walk the table's order, stated in each case as a
deployer policy; select_O2_default and fetch_O2_default are the default, which
picks AVIF before the learned int_mlicpp. http_verify.py's default order is the
energy order too (1057 of 1057 cases; the mutation shard 79 of 79).

The pin corpus's selection cases are about pins, so its runner walks the table's
order, a deployer policy (pin-conformance/README.md). wai-web's pick tests
follow the default order.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 244a715b35)
2026-10-26 08:30:49 -04:00

52 lines
3.2 KiB
Markdown

# pin-conformance — the parameter-set pin
Vectors for the parameter-set pin (SPEC.md §3.1, §4, §7, §7.1).
**Provenance.** Generated here by `wai_pin_vectors`; the parameter-set files under `sets/` are stand-in bytes written for the corpus. No media.
**Reason-equivalence.** A conforming verifier reports exactly the declared outcome
for every case:
- `cases.json` — given a pin, a capability, the forms the sink reads (default
`wai.prior.set`) and the artifacts it holds, the outcome `ok` or the one reason
SPEC §3.1 names: `pin_malformed`, `form_not_registered`, `form_unreadable`,
`form_required`, `prior_not_held`, `digest_superseded`, `set_malformed`,
`part_mismatch`. A held artifact is a `file`, or a `listing` together with the
`root` its paths are read below. Paths are relative to this directory. The cases
model a sink that holds no key log, so check 5 (`prior_revoked`,
`prior_not_authorised`) does not run; it is covered by the parameter-set vectors of
[`../signer-conformance/`](../signer-conformance/) and the `key_log` library tests.
- `selection.json` — given a `WAI2` manifest, its payloads, the capabilities the
sink advertises and the one-file parameter sets it holds, the rendition SPEC §7.1
picks and the reason for each entry it skips (`not_selectable`,
`missing_capability`, `component_digest_mismatch`, or a pin reason); when nothing
is picked, the reason for every entry. Where stated, also the companions applied
with the pick, and the first component-role finding. Selection walks the entries
in the table's order, a deployer policy SPEC §7.1 step 2 allows: the cases are
about pins, and SPEC §4's default energy order would walk a classical entry
before the learned ones that carry the pins, and reach no pin while it is
advertised.
- `static.json` — the first finding a verifier makes about a manifest's pins
without holding a parameter set (`prior_not_applicable`, `pin_malformed`,
`tier_unregistered`, `supersedes_malformed`, `form_not_registered`,
`form_required`, `tier_exceeds_class`, a `replicate_*` reason), or `ok`. For a
`WAI2` manifest the finding is `[entry index, reason]`.
**Listings.** Every `listings/<name>.sha256` is, byte for byte, the listing of
`sets/<name>/`: regular files, names that begin with `.` left out, sorted by path as
bytes. A common checksum utility checks a set against its listing
(`cd sets/demo && sha256sum -c ../../listings/demo.sha256`). Every file under
`listings/bad/` breaks one listing rule and is `set_malformed`.
Files are compared as bytes; `.gitattributes` turns off line-ending conversion.
**Verifiers.**
- `wai_pin_vectors verify pin-conformance` (wai-rs) runs every file through the
reference implementation's in-memory pin core (`wai::pin::verify_bytes`), its
selection (`WaiMulti::pick`) and its static checks (`Wai::check_pin`,
`WaiMulti::check_pins`). It runs in both corpus loops of the conformance workflow.
`wai_pin_vectors generate pin-conformance` rewrites the listings from the sets.
- `pin_verify.py` checks `cases.json` and `listings/` with the Python standard
library alone, re-implementing the listing rules and the ordered checks from the
SPEC text. It shares no code with wai-rs.