c4c1294e00
wai/tools/quantum-docs/check_docs.py runs every block marked runnable on the
pages docs.json names (the engine, the command line, the service, Python,
the Studio, the desktop app, the editors, the providers, the compiler,
estimates, verdicts, the feature matrix, the course and the agent skill) in
a scratch directory of fixtures, holds each shown output to the real one,
verifies every receipt a block writes, builds and runs the Rust blocks, and
checks every block that cannot run for the commands and flags it names,
every wai-quantum command in the prose, every relative link and every
dependency shown; a translation must hold its English page's code. ci.sh
builds the command line, the service and the wheel and starts a service, as
wai-quantum-docs.yml runs it, beside the course's and the locales' tests.
Drift fixed: the crate pinned "0.4", named an unrelated crate for the command
line, ran its research tools outside lab, claimed the whole suite under
wasip2, and split its feature table from its header; the command line's
README said the reader refuses while, inv and pow, used placeholders and
optional flags that do not run, and merged versions that do not exist; the
estimate page's output lacked its receipts line; build steps now match CI.
An observable may lead with its coefficient ("0.5 X2"), as documented.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
27 lines
2 KiB
Markdown
27 lines
2 KiB
Markdown
# Reading a receipt
|
|
|
|
Every result carries a receipt: an Ed25519 signature over the BLAKE3 digest of the RFC 8785 canonical text of the request and of the result without its receipt. The command line signs with the user's key; the job service signs with its own, which `GET https://wai.transaction.science/quantum-jobs/v1` publishes.
|
|
|
|
```sh runnable
|
|
wai-quantum run prog.qasm --json > job.json
|
|
wai-quantum verify job.json # signature VALID, and the signer's did:key
|
|
```
|
|
|
|
A result still verifies after any JSON reader has carried it. Change one number, in the request or the result, and it no longer does.
|
|
|
|
## What a job says
|
|
|
|
- `method` and `why`: the method that ran, and why the planner chose it.
|
|
- `result.accuracy.class`: `bit-exact` (the same bits on every machine), `exact` (only double-precision rounding), `bounded` (a bound on the error beside each value), `single` (single precision, on a GPU), `estimate` (with a standard error) or `heuristic` (with the method's own error estimate, not a bound). `wai-quantum docs methods` lists them.
|
|
- `result.counts`: seeded samples, keyed by the classical bits with the highest bit first. `expectations` and `amplitudes` are as asked.
|
|
- `result.energy`: on the service, the CPU energy of the job's process as the kernel counts it, with its uncertainty and what it leaves out. On the command line it is `unmetered`, with the reason.
|
|
- `result.receipt.key`: the key that signed it.
|
|
|
|
## The two receipts of `wai-quantum test`
|
|
|
|
- `receipts/NAME.run.json` is the run, in the job's form above.
|
|
- `receipts/NAME.intent.json` is the check. Its request holds the program, the run, each intent with every reference's text, and the run's receipt digest. Its result holds each verdict and whether all hold. `wai-quantum verify` checks it the same way.
|
|
|
|
## What a receipt shows
|
|
|
|
It shows that this key signed this request and this result, and anyone can rerun the request to compare. It does not show who holds the key, nor that the physics is right: the accuracy class and the intent's verdict say how far the numbers can be trusted.
|