open-standards/wai/wai-web/reach/test/vectors/provenance

A provenance vector for the reach conformance runs

captured.jpeg.wai is a wai.image.jpeg envelope and captured.receipt.json its signed asset-provenance receipt (wai::provenance::AssetReceipt): three steps (origin.synthesize, encode.png, encode.jpeg), a Merkle root over them, the total joules, and an Ed25519 signature. Its pixels are a synthesized pattern (rings and a gradient), not a photograph.

Provenance. Both files are written by wai_prov (wai-rs/src/bin/wai_prov.rs), which synthesizes the pixels, encodes them to PNG and then to JPEG, wraps the JPEG and signs the lineage. The key is the tool's published test seed, the byte 0x70 repeated 32 times (public key 19204c8c…ef067791), and the signer_id is the tool's label, did:example:wai-prov: a key whose seed is published attests nothing, so its id names no origin (jwp-receipts §7.1, §7.8). The figures, 426844 µJ for encode.png and 140425 µJ for encode.jpeg (unlabelled; origin.synthesize is unmetered), are the ones wai_prov measured on the host's on-chip energy counters when it first wrote this asset, at an earlier revision that signed under an origin-bound id. --carry carries them onto the same bytes and signs them again under the label; nothing is measured again. wai_prov carries a figure only from a receipt that verifies and whose steps have this run's operations, input and output hashes and work.

To regenerate, from wai/wai-rs (the codecs feature links the system codec libraries):

cargo run --release --no-default-features --features provenance,codecs,receipt_claims --bin wai_prov -- \
  ../wai-web/reach/test/vectors/provenance \
  --carry ../wai-web/reach/test/vectors/provenance/captured.receipt.json

The receipt is carried onto itself, so the command writes both files again byte for byte; on a host whose synthesis or encoders give other bytes, the lineage differs and the command refuses. Without --carry, wai_prov measures each encode afresh (a usable figure is labelled OnChipCounter), and the receipt and its hash below change.

The receipt profile of the reach builds exists to check receipts like this one, so the conformance runs (../../conformance.js) verify it on every rung: the content hash and the signature must verify, a copy with one bit changed must fail the content check, and a copy with its joule total raised by one must fail the signature check. The receipt's hash, signer id, step count and joule total must read as the receipt states them; the total crosses the JavaScript boundary as a 64-bit integer, a BigInt where the engine has one and a Number where it does not.

file	SHA-256
captured.jpeg.wai	4382082d2bbd1ef5358315afd578fc533d74bf973a57d4c45033c89c847a22a3
captured.receipt.json	97c5c24a03eae1c6a2d0e5374ad13c5ca00de00d696f40116f41c66b7097ff64