open-standards/wai/live-conformance/routes
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Transaction Science 658964c304 What a receipt declares of its own figure moves no verdict, and the corpus holds it
A figure is held to the offer's uncertainty, wider or narrower than the receipt's own. The texts
give that: a declared standard uncertainty bounds nothing (energy-measurement 2.1 and 2.3);
ModelBased, Estimator and a receipt of no class declare none, so a comparison has nothing to read
for them; and with the declaration in the rule, what a hop writes of its figure would buy a verdict
or cost one. A receipt graded below its offer is already held this way, its evidence read beside
the verdict.

The code read it so and no vector held the wider direction: every offer vector's counter declared
the offer's own 20,000 ppm, but for the largest uncertainty, which is narrower. A verifier taking
the wider of the two, or guarding a figure by a declaration past the offer's, passed the corpus.
Three vectors now hold both directions in both verifiers: a declaration of 500,000 ppm at the
figure is within, one of 1,000 ppm at the edge is within, and one of 500,000 ppm a microjoule past
the edge with no flag is refused. Every earlier vector is unchanged.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-11-07 03:01:51 -05:00
..
README.md A delivery's decision states its offer, and its route's receipt is held to it 2026-11-07 03:01:50 -05:00
vectors.json What a receipt declares of its own figure moves no verdict, and the corpus holds it 2026-11-07 03:01:51 -05:00

Route record corpus

The conformance corpus of wai.route.record: one file, vectors.json, written by wai_route_record_vectors gen from fixed seeds (extension §10).

Each vector is a verification document (§7.1) — the request, the price book, the policy and the record, each as its text, the hops' OER/2 receipts of minor version 1 as their texts and the key they are published under — with the outcome §7.3 gives it. The accepted vectors are routed and sealed by the reference; each refused one is a control of one defect, its record signed again over the defect where the defect is not in the signature, and the generator refuses to write a corpus whose control is refused for any reason or at any place but its own.

The vectors of version 1 come first, then those of version 2 (extension §3.4), whose names begin v2_ but for the controls that pair a record with a price book of the other version: a price book that prices each operation of an endpoint and states its measured failures, the ranking by the expected cost and time to first byte per successful job, and the served hop's outputs, to which its receipt is held. The outputs are the content hashes of fixed byte strings standing for the envelopes a hop delivered; the verifier reads only their content hashes. Then those of version 3 (§3.4), on version 2's price book, whose names begin v3_ but for the control that pairs one with a price book of version 1: the served hop's outputs stated by their count and root, to which its receipt is held, 5,000 of them in one record the size of the others. Then those of the third-party hop record (§6.2), whose names begin third_party_: each document carries the records beside the receipts, under route records of versions 2 and 3, with each rule of §6.2 broken once. Then those of the delivery-decision record (§6.3), whose names begin delivery_: each document carries, in deliveries, a job's decisions with each delivery's own request, price book of version 2 and policy, under route records of versions 2 and 3. The routes are priced per gigabyte for the operation http.export, and each rule of §6.3 is broken once. Last come those of a delivery's offer (§6.4), whose names begin offer_ but for the control that pairs a route record with a price book of version 3: each carries a decision of version 2 on a price book of version 3, and, in deliveries, the receipt of its route, published under the route's name, with each rule of §6.4 broken once.

# wai-rs: regenerates byte for byte, and every vector gets its outcome
cargo run --no-default-features --features route_record --bin wai_route_record_vectors -- verify ../live-conformance/routes

# the second implementation, written from the extension's text (needs `cryptography`, which the
# OER/2 reference verifier uses for the hop receipts)
python3 -I ../route_record_verify.py live-conformance/routes

keys names the router's key and the hops' key; both come from fixed seeds and attest nothing.