ca4fd375ef
A price book of version 3 states each entry's declared uncertainty. A delivery-decision record of version 2 rests on one and states offer: the route's entry by its place in the book, what the delivery carries, its estimates and its energy figure's class, uncertainty and grade, which a verifier recomputes. A delivery in a verification document may carry its route's OER/2 receipt, signed under the route's name, naming the decision and the delivered objects' root. The receipt's grade is no higher than the offer's. A figure more than one declared uncertainty above the offer's states price_exceeded as its work.outcome, an open member of the receipt the hop signs, and no other does. So no document kind is added and no earlier record reads differently. route_record_verify.py recomputes the offer and holds each receipt to it. The controls of an unknown version move on to a price book of version 4 and a decision of version 3; every other vector is unchanged. Co-Authored-By: Claude Opus 5.5 <[email protected]>
43 lines
3 KiB
Markdown
43 lines
3 KiB
Markdown
# Route record corpus
|
|
|
|
The conformance corpus of [`wai.route.record`](../../extensions/route-record.md): 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.
|
|
|
|
```sh
|
|
# 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.
|