open-standards/wai/live-conformance/takes

live-conformance/takes — capture binding

The corpus of extensions/capture-binding.md §13: takes, each a room (a signed WRD1 descriptor, its WRG1 grants, the head of its authority's key log, and its principals' WEV1 chains, the device's take_commit events among them), a device-signed WTM1 take manifest, the uploaded parts, the store's WUR1 upload receipts, WCN1 consent records, and an evaluation instant, with the outcome a take verifier gives them.

Take equivalence. For each vector, a conforming take verifier given its room, its manifest, its parts (each an index and its bytes, in the order received), its receipts and consents in order, and its evaluated_at (seconds since 1970) reaches the outcome the vector states (§9.5):

• refuse: the reason and where, at: ["room", …] with the room verifier's own place (live-rooms §9.1), ["manifest"], ["record", c, i] for record i of chain c, ["store"], ["receipt", i] or ["consent", i];
• verdicts: the take id and its stream_id (§11.1); the digests of the held commitments, commits, in order; the last held commitment's size and root; the verdicts of single_take, aligned, complete and publishable for each of live, record, distribute and train, each holds or the reason it fails; whether the manifest stands; and the markers of the room within the master (§10), each with its event digest, its t, its chunk, and its position into_chunk and into_master in microseconds, stated where aligned holds.

A verifier that reaches another outcome, reason, place, verdict, digest or position does not conform.

Provenance. Generated here: wai_capture_take_vectors gen writes every descriptor, grant, key-log head, record, chunk, manifest, receipt and consent from takes authored in code, from fixed seeds. Each key is SHA-256 of a fixed label and the principal's index, each chunk's bytes SHA-256 output under a fixed label and the chunk's index (they stand for an encoded master and encode nothing), every time is a constant (the rooms' t0 is 2026-10-16T00:00:00Z), and Ed25519 signing is deterministic (RFC 8032), so the file is the same bytes on every machine. The generator asserts that each vector reaches the outcome it was written to have before it writes it. The key-log heads are sealed by the reference's key log (jwp-receipts §7.2) under a fixed root. The origins are .example names (RFC 2606). No recorded data.

Layout

One file, vectors.json:

• principals: the keys, by name (informative).
• vectors: each with name, about, descriptor and grants (hexadecimal), key_log_head (a key-log revision's JSON text, or null), chains (lists of records in hexadecimal), manifest, parts, receipts and consents (hexadecimal), evaluated_at, outcome, and as above reason, at, take, stream_id, commits, size, root, verdicts, stands and markers.

Every take is in one lesson room: a director with the record power, the performer's device under a grant whose subject attribute names the performer, an audience; a recording policy of mode 1, a two-second commit interval and 500 ms of jitter, pinned to DE and FR; a key log listing the room authority and the store. Vectors:

• good takes: lesson (the director's record_start with a four-second count-in, ten one-second chunks committed every two seconds, two markers, record_stop, the closing commitment, an upload sealed in DE, the performer's consent to live, record and distribute), resumed_upload (the upload interrupted after four chunks and resumed, chunk 3 sent twice) and minor_guardian (a performer the grant marks a minor, under the guardian's consent); each stands, and publishable for train fails;
• the negatives of §13, each a single defect: commit_gap, spliced_chunk, reordered_chunk, extra_chunk, missing_chunk (complete fails and single-take holds), late_commit, root_not_extending, misaligned, consent_missing, consent_expired, consent_revoked, minor_without_guardian and device_not_bound;
• one vector for each other reason of §12, a manifest of another room, a manifest and a consent with a bad signature, and a room that refuses the device's first commitment.

Running

cd ../../wai-rs
cargo run --no-default-features --features capture_take --bin wai_capture_take_vectors -- verify ../live-conformance/takes
cargo run --no-default-features --features capture_take --bin wai_capture_take_vectors -- gen    ../live-conformance/takes   # regenerate
cargo test --no-default-features --features capture_take --test capture_take
cd ../live-conformance
python3 capture_take_verify.py takes

wai_capture_take_vectors verify and tests/capture_take.rs require the file to regenerate byte for byte and wai-rs to give every vector its outcome; the test also requires every reason of §12 and delivery_gap to appear, the three good takes to stand, and §12 to list exactly the reasons the reference reports. capture_take_verify.py is the second implementation, written from the extension's text and sharing no code with wai-rs: it verifies the room with live_rooms_verify.py (which verifies every event with live_events_verify.py), gives every vector the same outcome, requires the same coverage, and then mutates copies of the corpus, one defect each (a part's byte, two parts swapped, a part dropped, a signature's byte, a descriptor's byte, the seal removed, a consent's byte, a commitment not delivered, a later evaluation instant, and stated roots, ids, positions, verdicts, places and reasons changed), each of which must fail. Pass = an exit status of 0 from each.