wai-quantum: receipts say where their counts come from and what was set at the provider, and a second verifier checks them #660

Merged

dcharlot merged 24 commits from wai/quantum-receipt-fields into main 2026-11-06 14:45:15 -05:00

Conversation 0 Commits 24 Files changed 259 +27034 -955

dcharlot commented 2026-11-05 15:11:18 -05:00

Owner

Copy link

Stacked on #654 (wai/quantum-cloud-tasks): that branch is merged in here at its current head, and main with it (through #652).

This adds the receipt fields WAI Quantum needs before its first hardware receipt, since a signed receipt can't gain fields later. It also adds a second verifier of job receipts, written in another language from the spec alone. This is Phase 0 of the platform plan: the gate is that the second verifier agrees with the reference on every receipt.

The fields

• counts_source: shots, vendor_counts or probabilities. Counts rebuilt from probabilities are derived, not shot records, and now say so.

  • native-turns always rebuilds them.
  • cloud-tasks reads a task's rows, and rebuilds only when its result has none.
  • sampler-v2 tallies shots.
  • prx-circuits takes the service's counts.

• execution: whether each of mitigation, twirling, decoupling, remapping and optimisation is off, on, or default (the request sets nothing for it). It also records whether the gates were to run as written, and what was sent. Each client builds it from the very body it posts (Provider::execution), and a test holds every kind to the body its scripted service received:

  • sampler-v2 turns decoupling and twirling off;
  • native-turns turns debiasing off;
  • cloud-tasks puts a processor's gates in the verbatim box;
  • prx-circuits sends only circuits and shots, so it sets nothing and says so.

  A provider on the open protocol states both in its result answer (§5.5), and a wrapper around another service must.

• Simulators are not measured. The class follows the provider's provenance: measured for silicon, simulated for a simulator or emulator, plus approximate: true when the provider says so. The old note claimed "no mitigation", which no client turned off or recorded; it no longer does. Receipts sealed before these fields still verify, and a verifier reads their class by provenance and says so.

• compiled.qasm3: the program's text now sits beside its hash, so the hash can be checked.

All of these are additions under the protocol's §10. This PR's own changes to the crates' public API are additions only: provided trait methods, #[non_exhaustive] structs, a #[non_exhaustive] CountsSource, and functions. The wai-quantum-qpu 0.5.0 in this branch is #654's, for its new kind.

The second verifier, and what it found

quantum-conformance/tools/receipt_verify.py was written in Python from the text alone, by an agent forbidden to read the Rust, the other tools or any reference output. It is standard library only, with its own BLAKE3, Ed25519, RFC 8785 text and strict reader.

Its first pass on the old text listed 44 gaps. §8 was rewritten from them, and the next three passes found 30 more, each settled in the text. The rewritten §8 covers the seal byte for byte, the strict reader, the canonical text and the first form's, the strict Ed25519 rules, the per-kind rows, seventeen named reasons, and what a receipt proves. VERSIONING, the receipt schema and the service README now agree with it.

The reference was too lenient. It accepted:

• a receipt under the identity key for any content;
• any alg, and canon: null;
• hex in upper case or spelt with +;
• duplicate member names.

It also panicked on a two-byte character in a key. It now refuses each of these:

• it decodes keys and R canonically;
• it checks S < ℓ itself rather than leaving it to a library feature;
• it keeps a first-form result's member order when it removes the receipt.

wai-quantum verify --json and --lines give the verdict as data.

The second review, and what changed

The second review, of 7671774f0, found seven that held, and the planner found one more. Each fix has a test or corpus vector that failed on the old code, and the second verifier agrees on every one, written again from the text by the same clean-room agent.

Finding	Fix	Test or vector
§8.2 promised a result verifies after any JSON reader and writer has carried it, but inexact_number refused RFC 8785's own spelling of a large whole double (2^60 as 1152921504606847000)	That spelling, the double's one canonical text, is taken; every other spelling of an inexact whole number is refused. A host screens every number of a request it seals, as it writes it and as RFC 8785 does	a_large_whole_double_verifies_as_its_canonical_text_writes_it; crafted-number-{canonical,exact,exponent}-spelling (valid), -near-canonical and -padded-past (inexact_number); plant no-canonical-spelling
Python's text and path inputs and verify --lines judged a set as a plain job, so every genuine set got digest_mismatch; §8 never defined sets	§8.6 defines a set's receipt, with three reasons (set_items, set_item, set_root), the Merkle tree spelled out, and what the tree does not fix stated. Every surface judges a set by it	a_set_is_judged_by_its_own_rules, lines_judge_a_set_as_a_set, Python test_a_set_s_text_is_judged_as_a_set; two sets made by the command line and fourteen crafted; plant set-seal-only
The Studio, the desktop app and the npm README verified an object written out again by JavaScript, so a genuine first-form receipt failed	The text is passed end to end (jobText); an object is written out only when it is all there is. README shows the text path and the answer's shape	verify-text.test.mjs (the desktop engine and the worker's helper), the browser's and the desktop's tests through engine_verify and verify on text
Set requests were sealed unscreened: sweep values, a set's own fields	sets::run and the service's set planning screen the whole request. The first-form exemption at sets::verify now comes from §8.6's check, and §8.4's text names every host that sealed such a number	a_set_request_s_every_number_is_screened; crafted-set-sweep-inexact
The parsed-JSON tools could not report unreadable or past-u64 inexact_number, and their tests skipped exactly those	Both tools take a job's text (job), and their tests hold them to the whole corpus, skipping only what a JSON string cannot hold (bytes that are not UTF-8). §9 says exactly what a parsed job cannot show	the_mcp_tool_given_a_job_s_text_gives_the_corpus_s_verdict, the_service_gives_every_receipt_the_verdict_the_corpus_gives_it
compiled.qubit_names was checked only against the layouts	Every $i that qasm3 acts on must be named, in both verifiers	qubit_names_name_every_qubit_the_text_acts_on; crafted-kind-tasks-names-short-of-text; plant names-layout-only
The service's verify schema did not describe signer	Described, and the schema test calls the tool with a job's text so the answer carries it	every_tool_s_answer_follows_its_output_schema fails without it
Merge with #659	Not merged here, as agreed

The clean-room verifier's reading of §8.6 found further gaps, each now settled in the text and in both verifiers: an empty set, null members, a failed item's numbers (a forgery path: now set_item, read as a canonical receipt reads them whatever the set's form, since a leaf is the canonical form's digest), an item sealed by another key (compared with the set's receipt's key member as it stands, missing included), an item that is itself a set, the path length, and two properties of the inherited tree that count and the item's receipt cover. An item is read for its index, request, result, error and path; its status, method, why and a sweep's point are the host's, unsealed, and the differential's oracle now expects a change there to leave the verdict as it was (the full differential first found 26 such one-member changes refused by neither verifier, as they should not be, and flagged them).

On this head: the corpus is 156 receipts (47 valid, 109 not), all agreeing three ways; 11,532 one-member and edge changes, all agreeing; ten plants, each caught; the second verifier's self-test 232 of 232.

The views page. The Studio browser step found what no other step did: the committed page was built before wai-quantum-views changed, so build-views --check failed, and rebuilt it was past its 1 MiB limit, since job::verdict carried the engine's re-derivation of a sweep into the page. The views' verify now holds the receipt's rules alone (job::check), and the page is 984,188 bytes, built on Linux as CI builds it.

The first review, and what changed

An independent review confirmed twenty-three findings on this PR (with #654's, thirty-four). Each has a test that failed on the old code for the stated reason, then the fix. None was disputed.

Every verify surface holds every rule. Before, only wai-quantum verify applied §8.4. POST /v1/verify and the service's MCP tool checked the seal alone, so a simulator's counts labelled measured, counts that do not sum, and a member named twice came back valid. job::verify skipped inexact_number though its doc said it applied every rule, and the command line's MCP tool, the Python package, the desktop app and the browser all called it. Now:

• job::verify runs job::check; job::verdict and job::verdict_of_text give every surface one answer, valid, reasons, key, form, signer.
• The service reads /v1/verify's body as text (check_text), so a member named twice is unreadable; its tool runs check.
• The command line's set, estimate and algorithm branches read the text strictly first (job::text_refusal), and --json on them gives JSON.
• Python's verify reads text, bytes and paths as text, and gives reasons.
• A set's items are held to a job's rules, and a set is verified as a set on every surface that takes a job (the sweep found the desktop, browser, Python and views read a good set as invalid).
• Tests that hold each surface to the corpus's manifest: the_service_gives_every_receipt_the_verdict_the_corpus_gives_it (HTTP and the tool, every receipt), the_mcp_tool_gives_the_corpus_s_verdict_on_what_a_parsed_job_shows, a_member_named_twice_is_unreadable_on_every_kind_of_job, json_output_is_json_on_every_kind_of_job, verify_holds_what_check_holds, Python test_every_receipt_of_the_corpus_gets_its_verdict_here, the desktop's verify_reads_a_job_s_text_and_holds_every_rule, the browser's engine_verify_reads_a_job_s_text_and_holds_every_rule, an_item_is_held_to_the_rules_of_a_job, a_surface_that_takes_a_job_verifies_a_set_as_a_set.

A host seals nothing its own verifier refuses. qec took a seed of any size, sealed its double and printed "receipt verifies"; verify then refused the file. The sweep found compile, pulse, estimate, @Seal, a project's intent check, the service's sealers and set items open the same way. Each now refuses a request with a whole number past ±(2^53 − 1) where it reads it (job::exact_request), and receipt::seal_into writes a whole number no double holds in a result as the double sealed. The provider path checks its own receipt before giving it, so a provider's word cannot produce a receipt this host refuses. A receipt already sealed with such a number stays refused: its signature holds, and written as that double's digits it verifies. VERSIONING and §8.4 say so. Tests: a_host_never_seals_what_its_verifier_refuses, a_result_s_number_no_double_holds_is_written_as_the_double_sealed, a_receipt_sealed_with_a_number_no_double_holds_verifies_written_as_what_was_sealed, a_host_gives_no_receipt_its_verifier_refuses_whatever_a_provider_answers.

The rest:

Finding	Fix	Test
High: a job recorded by the published 0.4.1 and collected by this release was sealed with a receipt this release refuses	Its program's text is added from its record, and execution stated by nobody is taken on every kind (§8.3, §8.4, §8.5 say so)	a_job_recorded_by_the_last_release_is_sealed_with_a_receipt_this_one_accepts (sampler-v2, prx-circuits, native-turns, each record as 0.4.1 wrote it)
The reference capped every whole number at 2^53 − 1; §8.4 and the second verifier cap only a count. Equal strings as shots read as different	§8.4 was right: the cap is on counts only, sums are exact, "the request's" is by value. The differential now tries numbers past a double's whole numbers and shots in both request and result, sealing each again; a whole-cap plant, and corpus receipts, prove it can see this	a_whole_number_has_no_ceiling_and_only_a_count_has_one, shots_are_the_requests_when_the_two_are_the_same_value, counts_sum_exactly_past_what_a_double_adds
verify --json --history skipped the history	It checks it, and --history on a set, an estimate or an algorithm's answer is refused	json_output_does_not_skip_the_history_it_was_asked_to_check
compiled.qasm3 is on the client's indices, not the device's qubits (cloud-tasks, prx-circuits)	compiled.qubit_names seals the device's name for each index, as on the day it was sent; required of those two kinds when their client states what it sent	a_receipt_names_the_device_s_qubits_as_the_program_was_sent_on_them, a_client_that_names_its_qubits_seals_the_names
sampler-v2 hard-coded silicon	It reads the backend's simulator	a_simulated_backend_is_not_silicon
Nothing kept the corpus's made receipts	made.lock.json pins each by SHA-256; --check fails on one dropped, changed or unnamed; generate.py --self-test shows each way	generate.py --self-test (5 checks)
The small-order R rule had no test that could fail	Vectors whose equation holds (S = k·a, R the identity and its non-canonical alias), in the corpus, the engine and the second verifier, with a lax-small-order-r plant	an_r_of_small_order_or_ill_spelled_is_refused_where_the_equation_holds
Quadratic time on execution.sent	A binary search in the reference; a set in the second verifier	what_was_sent_is_checked_in_time_proportional_to_it, and the second verifier's self-test
An open-protocol provider's counts_source read as the host's act	§8.3 says whose word it is by provider.kind; verify adds "in the provider's word" on http and process	what_verify_says_is_only_what_the_receipt_shows
§9 claimed a person's-account receipt and first-form receipts it did not hold	§9 corrected. The corpus now holds two receipts sealed by the first form's own writer: the job service built at 72d18742d (18 October) and run here	the corpus
A signer can choose the earlier form, and the verifier claimed when it was sealed	The form is by design (§8.5); the wording now names a form and no time	the_earlier_form_is_named_and_no_time_is_claimed_for_it

The second verifier was brought up to the new text by the same clean-room agent, from the text alone. Its reading found one disagreement between §8.1 and §8.4 (does a cloud-tasks simulator name its qubits: yes, each index itself) and four choices the text left open (a number's value is its double on every form, null is given, -0 is 0, nobody on any kind is stated in §8.5); each is settled in the text, and the reference agrees.

The corpus and the differential

quantum-conformance/receipts/ holds 156 receipts (47 valid, 109 not):

• made by the CLI and the free job service;
• every built-in kind through a scripted service;
• the engine's fixtures;
• receipts crafted to break one rule each, with every expectation written by hand from §8.4.

receipt_differential.py holds both verifiers and the manifest to each other on every receipt and on every one-member change of each valid one. Each defect planted in the second verifier must be caught. CI runs this beside the CLI's build (wai-quantum-cli.yml), and runs the second verifier against the manifest among the independent verifiers.

On this head, run locally on Linux:

• Corpus: 156 of 156 receipts agree three ways (manifest, reference, second verifier).
• Changed receipts: 11,532, all agreeing. 6,035 are refused, as every change inside the seal must be; 579 stay valid, as every change outside it must; 4,918 are numbers at the edges, judged only by the other verifier.
• Plants: all ten are caught.
• Self-test: the second verifier passes 232 of 232 checks.

The differential's first full run found one more error in the spec, after the second verifier's four passes: §8.2's first-form rule wrote a positive exponent without its +. The first form was sealed only from 17 to 20 October 2026, by one writer, which writes 1e+16. The text now says so. The reference also no longer leans on today's serde_json for that text: it writes the first form by §8.2's rules, and a test pins that writer to serde_json's output.

Tests, each workflow's own Linux step replayed on a build host:

• engine: 845 library tests, the feature-subset checks under -D warnings, and the verdict and answer sets;
• qpu: 112 tests (81, 2, 15, 2 and 12, the workflow pinning 81, 15 and 12), including each built-in kind's statement held to the body it posted;
• command line: its tests, both clippy runs, the smoke checks, and the two-verifier step;
• contract: API compatibility (no break in the engine or the command line; the qpu's breaks are #654's, allowed under 0.5.0), and all five schema steps, a full JSON Schema implementation among them;
• job service, Python package (85 tests and the notebooks) and docs (81 documents): pass;
• Studio in a browser, in the image CI gives that job: passes; the views page's own job, and every view drawn by a scripted host (81 checks), pass;
• the desktop app's tests on macOS (22): pass;
• the repository checks: pass.

Not run locally: the other macOS, Windows and hardware legs, and the wide conformance workflows; CI runs those. Emulated and signal-processor legs are not evidence until this branch carries main's cache fix.

Replaying the steps found one more fault before CI did: the job service's committed tool list was stale, since the schemas changed after it was last regenerated. It is regenerated, and the qpu workflow's pinned test counts are raised for this branch's three new tests.

The real cloud-tasks receipts from the service's simulator verify under both verifiers, and are read as simulated. They are not in the corpus, because they seal the account's number in job.id (--extra DIR checks them locally).

🤖 Generated with Claude Code

**Stacked on #654** (`wai/quantum-cloud-tasks`): that branch is merged in here at its current head, and main with it (through #652). This adds the receipt fields WAI Quantum needs before its first hardware receipt, since a signed receipt can't gain fields later. It also adds a second verifier of job receipts, written in another language from the spec alone. This is Phase 0 of the platform plan: the gate is that the second verifier agrees with the reference on every receipt. ## The fields - **`counts_source`**: `shots`, `vendor_counts` or `probabilities`. Counts rebuilt from probabilities are derived, not shot records, and now say so. - `native-turns` always rebuilds them. - `cloud-tasks` reads a task's rows, and rebuilds only when its result has none. - `sampler-v2` tallies shots. - `prx-circuits` takes the service's counts. - **`execution`**: whether each of mitigation, twirling, decoupling, remapping and optimisation is `off`, `on`, or `default` (the request sets nothing for it). It also records whether the gates were to run as written, and what was sent. Each client builds it from the very body it posts (`Provider::execution`), and a test holds every kind to the body its scripted service received: - `sampler-v2` turns decoupling and twirling off; - `native-turns` turns debiasing off; - `cloud-tasks` puts a processor's gates in the verbatim box; - `prx-circuits` sends only `circuits` and `shots`, so it sets nothing and says so. A provider on the open protocol states both in its `result` answer (§5.5), and a wrapper around another service must. - **Simulators are not measured.** The class follows the provider's provenance: `measured` for silicon, `simulated` for a simulator or emulator, plus `approximate: true` when the provider says so. The old note claimed "no mitigation", which no client turned off or recorded; it no longer does. Receipts sealed before these fields still verify, and a verifier reads their class by provenance and says so. - **`compiled.qasm3`**: the program's text now sits beside its hash, so the hash can be checked. All of these are additions under the protocol's §10. This PR's own changes to the crates' public API are additions only: provided trait methods, `#[non_exhaustive]` structs, a `#[non_exhaustive]` `CountsSource`, and functions. The `wai-quantum-qpu` 0.5.0 in this branch is #654's, for its new kind. ## The second verifier, and what it found `quantum-conformance/tools/receipt_verify.py` was written in Python from the text alone, by an agent forbidden to read the Rust, the other tools or any reference output. It is standard library only, with its own BLAKE3, Ed25519, RFC 8785 text and strict reader. Its first pass on the old text listed 44 gaps. §8 was rewritten from them, and the next three passes found 30 more, each settled in the text. The rewritten §8 covers the seal byte for byte, the strict reader, the canonical text and the first form's, the strict Ed25519 rules, the per-kind rows, seventeen named reasons, and what a receipt proves. VERSIONING, the receipt schema and the service README now agree with it. The reference was too lenient. It accepted: - a receipt under the identity key for any content; - any `alg`, and `canon: null`; - hex in upper case or spelt with `+`; - duplicate member names. It also panicked on a two-byte character in a key. It now refuses each of these: - it decodes keys and `R` canonically; - it checks `S < ℓ` itself rather than leaving it to a library feature; - it keeps a first-form result's member order when it removes the receipt. `wai-quantum verify --json` and `--lines` give the verdict as data. ## The second review, and what changed The second review, of `7671774f0`, found seven that held, and the planner found one more. Each fix has a test or corpus vector that failed on the old code, and the second verifier agrees on every one, written again from the text by the same clean-room agent. | Finding | Fix | Test or vector | |---|---|---| | §8.2 promised a result verifies after any JSON reader and writer has carried it, but `inexact_number` refused RFC 8785's own spelling of a large whole double (2^60 as 1152921504606847000) | That spelling, the double's one canonical text, is taken; every other spelling of an inexact whole number is refused. A host screens every number of a request it seals, as it writes it and as RFC 8785 does | `a_large_whole_double_verifies_as_its_canonical_text_writes_it`; `crafted-number-{canonical,exact,exponent}-spelling` (valid), `-near-canonical` and `-padded-past` (`inexact_number`); plant `no-canonical-spelling` | | Python's text and path inputs and `verify --lines` judged a set as a plain job, so every genuine set got `digest_mismatch`; §8 never defined sets | §8.6 defines a set's receipt, with three reasons (`set_items`, `set_item`, `set_root`), the Merkle tree spelled out, and what the tree does not fix stated. Every surface judges a set by it | `a_set_is_judged_by_its_own_rules`, `lines_judge_a_set_as_a_set`, Python `test_a_set_s_text_is_judged_as_a_set`; two sets made by the command line and fourteen crafted; plant `set-seal-only` | | The Studio, the desktop app and the npm README verified an object written out again by JavaScript, so a genuine first-form receipt failed | The text is passed end to end (`jobText`); an object is written out only when it is all there is. README shows the text path and the answer's shape | `verify-text.test.mjs` (the desktop engine and the worker's helper), the browser's and the desktop's tests through `engine_verify` and `verify` on text | | Set requests were sealed unscreened: sweep values, a set's own fields | `sets::run` and the service's set planning screen the whole request. The first-form exemption at `sets::verify` now comes from §8.6's check, and §8.4's text names every host that sealed such a number | `a_set_request_s_every_number_is_screened`; `crafted-set-sweep-inexact` | | The parsed-JSON tools could not report `unreadable` or past-u64 `inexact_number`, and their tests skipped exactly those | Both tools take a job's text (`job`), and their tests hold them to the whole corpus, skipping only what a JSON string cannot hold (bytes that are not UTF-8). §9 says exactly what a parsed job cannot show | `the_mcp_tool_given_a_job_s_text_gives_the_corpus_s_verdict`, `the_service_gives_every_receipt_the_verdict_the_corpus_gives_it` | | `compiled.qubit_names` was checked only against the layouts | Every `$i` that `qasm3` acts on must be named, in both verifiers | `qubit_names_name_every_qubit_the_text_acts_on`; `crafted-kind-tasks-names-short-of-text`; plant `names-layout-only` | | The service's verify schema did not describe `signer` | Described, and the schema test calls the tool with a job's text so the answer carries it | `every_tool_s_answer_follows_its_output_schema` fails without it | | Merge with #659 | Not merged here, as agreed | | The clean-room verifier's reading of §8.6 found further gaps, each now settled in the text and in both verifiers: an empty set, `null` members, a failed item's numbers (a forgery path: now `set_item`, read as a canonical receipt reads them whatever the set's form, since a leaf is the canonical form's digest), an item sealed by another key (compared with the set's receipt's `key` member as it stands, missing included), an item that is itself a set, the path length, and two properties of the inherited tree that `count` and the item's receipt cover. An item is read for its `index`, `request`, `result`, `error` and `path`; its `status`, `method`, `why` and a sweep's `point` are the host's, unsealed, and the differential's oracle now expects a change there to leave the verdict as it was (the full differential first found 26 such one-member changes refused by neither verifier, as they should not be, and flagged them). On this head: the corpus is 156 receipts (47 valid, 109 not), all agreeing three ways; 11,532 one-member and edge changes, all agreeing; ten plants, each caught; the second verifier's self-test 232 of 232. **The views page.** The Studio browser step found what no other step did: the committed page was built before `wai-quantum-views` changed, so `build-views --check` failed, and rebuilt it was past its 1 MiB limit, since `job::verdict` carried the engine's re-derivation of a sweep into the page. The views' `verify` now holds the receipt's rules alone (`job::check`), and the page is 984,188 bytes, built on Linux as CI builds it. ## The first review, and what changed An independent review confirmed twenty-three findings on this PR (with #654's, thirty-four). Each has a test that failed on the old code for the stated reason, then the fix. None was disputed. **Every verify surface holds every rule.** Before, only `wai-quantum verify` applied §8.4. `POST /v1/verify` and the service's MCP tool checked the seal alone, so a simulator's counts labelled `measured`, counts that do not sum, and a member named twice came back valid. `job::verify` skipped `inexact_number` though its doc said it applied every rule, and the command line's MCP tool, the Python package, the desktop app and the browser all called it. Now: - `job::verify` runs `job::check`; `job::verdict` and `job::verdict_of_text` give every surface one answer, `valid`, `reasons`, `key`, `form`, `signer`. - The service reads `/v1/verify`'s body as text (`check_text`), so a member named twice is `unreadable`; its tool runs `check`. - The command line's set, estimate and algorithm branches read the text strictly first (`job::text_refusal`), and `--json` on them gives JSON. - Python's `verify` reads text, bytes and paths as text, and gives `reasons`. - A set's items are held to a job's rules, and a set is verified as a set on every surface that takes a job (the sweep found the desktop, browser, Python and views read a good set as invalid). - Tests that hold each surface to the corpus's manifest: `the_service_gives_every_receipt_the_verdict_the_corpus_gives_it` (HTTP and the tool, every receipt), `the_mcp_tool_gives_the_corpus_s_verdict_on_what_a_parsed_job_shows`, `a_member_named_twice_is_unreadable_on_every_kind_of_job`, `json_output_is_json_on_every_kind_of_job`, `verify_holds_what_check_holds`, Python `test_every_receipt_of_the_corpus_gets_its_verdict_here`, the desktop's `verify_reads_a_job_s_text_and_holds_every_rule`, the browser's `engine_verify_reads_a_job_s_text_and_holds_every_rule`, `an_item_is_held_to_the_rules_of_a_job`, `a_surface_that_takes_a_job_verifies_a_set_as_a_set`. **A host seals nothing its own verifier refuses.** `qec` took a seed of any size, sealed its double and printed "receipt verifies"; `verify` then refused the file. The sweep found compile, pulse, estimate, `@Seal`, a project's intent check, the service's sealers and set items open the same way. Each now refuses a request with a whole number past ±(2^53 − 1) where it reads it (`job::exact_request`), and `receipt::seal_into` writes a whole number no double holds in a result as the double sealed. The provider path checks its own receipt before giving it, so a provider's word cannot produce a receipt this host refuses. A receipt already sealed with such a number stays refused: its signature holds, and written as that double's digits it verifies. VERSIONING and §8.4 say so. Tests: `a_host_never_seals_what_its_verifier_refuses`, `a_result_s_number_no_double_holds_is_written_as_the_double_sealed`, `a_receipt_sealed_with_a_number_no_double_holds_verifies_written_as_what_was_sealed`, `a_host_gives_no_receipt_its_verifier_refuses_whatever_a_provider_answers`. **The rest:** | Finding | Fix | Test | |---|---|---| | **High:** a job recorded by the published 0.4.1 and collected by this release was sealed with a receipt this release refuses | Its program's text is added from its record, and `execution` stated by `nobody` is taken on every kind (§8.3, §8.4, §8.5 say so) | `a_job_recorded_by_the_last_release_is_sealed_with_a_receipt_this_one_accepts` (sampler-v2, prx-circuits, native-turns, each record as 0.4.1 wrote it) | | The reference capped every whole number at 2^53 − 1; §8.4 and the second verifier cap only a count. Equal strings as shots read as different | §8.4 was right: the cap is on counts only, sums are exact, "the request's" is by value. The differential now tries numbers past a double's whole numbers and shots in both request and result, sealing each again; a `whole-cap` plant, and corpus receipts, prove it can see this | `a_whole_number_has_no_ceiling_and_only_a_count_has_one`, `shots_are_the_requests_when_the_two_are_the_same_value`, `counts_sum_exactly_past_what_a_double_adds` | | `verify --json --history` skipped the history | It checks it, and `--history` on a set, an estimate or an algorithm's answer is refused | `json_output_does_not_skip_the_history_it_was_asked_to_check` | | `compiled.qasm3` is on the client's indices, not the device's qubits (cloud-tasks, prx-circuits) | `compiled.qubit_names` seals the device's name for each index, as on the day it was sent; required of those two kinds when their client states what it sent | `a_receipt_names_the_device_s_qubits_as_the_program_was_sent_on_them`, `a_client_that_names_its_qubits_seals_the_names` | | `sampler-v2` hard-coded silicon | It reads the backend's `simulator` | `a_simulated_backend_is_not_silicon` | | Nothing kept the corpus's made receipts | `made.lock.json` pins each by SHA-256; `--check` fails on one dropped, changed or unnamed; `generate.py --self-test` shows each way | `generate.py --self-test` (5 checks) | | The small-order R rule had no test that could fail | Vectors whose equation holds (S = k·a, R the identity and its non-canonical alias), in the corpus, the engine and the second verifier, with a `lax-small-order-r` plant | `an_r_of_small_order_or_ill_spelled_is_refused_where_the_equation_holds` | | Quadratic time on `execution.sent` | A binary search in the reference; a set in the second verifier | `what_was_sent_is_checked_in_time_proportional_to_it`, and the second verifier's self-test | | An open-protocol provider's `counts_source` read as the host's act | §8.3 says whose word it is by `provider.kind`; `verify` adds "in the provider's word" on `http` and `process` | `what_verify_says_is_only_what_the_receipt_shows` | | §9 claimed a person's-account receipt and first-form receipts it did not hold | §9 corrected. The corpus now holds two receipts sealed by the first form's own writer: the job service built at 72d18742d (18 October) and run here | the corpus | | A signer can choose the earlier form, and the verifier claimed when it was sealed | The form is by design (§8.5); the wording now names a form and no time | `the_earlier_form_is_named_and_no_time_is_claimed_for_it` | The second verifier was brought up to the new text by the same clean-room agent, from the text alone. Its reading found one disagreement between §8.1 and §8.4 (does a `cloud-tasks` simulator name its qubits: yes, each index itself) and four choices the text left open (a number's value is its double on every form, `null` is given, `-0` is 0, `nobody` on any kind is stated in §8.5); each is settled in the text, and the reference agrees. ## The corpus and the differential `quantum-conformance/receipts/` holds 156 receipts (47 valid, 109 not): - made by the CLI and the free job service; - every built-in kind through a scripted service; - the engine's fixtures; - receipts crafted to break one rule each, with every expectation written by hand from §8.4. `receipt_differential.py` holds both verifiers and the manifest to each other on every receipt and on every one-member change of each valid one. Each defect planted in the second verifier must be caught. CI runs this beside the CLI's build (`wai-quantum-cli.yml`), and runs the second verifier against the manifest among the independent verifiers. On this head, run locally on Linux: - **Corpus:** 156 of 156 receipts agree three ways (manifest, reference, second verifier). - **Changed receipts:** 11,532, all agreeing. 6,035 are refused, as every change inside the seal must be; 579 stay valid, as every change outside it must; 4,918 are numbers at the edges, judged only by the other verifier. - **Plants:** all ten are caught. - **Self-test:** the second verifier passes 232 of 232 checks. The differential's first full run found one more error in the spec, after the second verifier's four passes: §8.2's first-form rule wrote a positive exponent without its `+`. The first form was sealed only from 17 to 20 October 2026, by one writer, which writes `1e+16`. The text now says so. The reference also no longer leans on today's serde_json for that text: it writes the first form by §8.2's rules, and a test pins that writer to serde_json's output. Tests, each workflow's own Linux step replayed on a build host: - engine: 845 library tests, the feature-subset checks under `-D warnings`, and the verdict and answer sets; - qpu: 112 tests (81, 2, 15, 2 and 12, the workflow pinning 81, 15 and 12), including each built-in kind's statement held to the body it posted; - command line: its tests, both clippy runs, the smoke checks, and the two-verifier step; - contract: API compatibility (no break in the engine or the command line; the qpu's breaks are #654's, allowed under 0.5.0), and all five schema steps, a full JSON Schema implementation among them; - job service, Python package (85 tests and the notebooks) and docs (81 documents): pass; - Studio in a browser, in the image CI gives that job: passes; the views page's own job, and every view drawn by a scripted host (81 checks), pass; - the desktop app's tests on macOS (22): pass; - the repository checks: pass. Not run locally: the other macOS, Windows and hardware legs, and the wide conformance workflows; CI runs those. Emulated and signal-processor legs are not evidence until this branch carries main's cache fix. Replaying the steps found one more fault before CI did: the job service's committed tool list was stale, since the schemas changed after it was last regenerated. It is regenerated, and the qpu workflow's pinned test counts are raised for this branch's three new tests. The real `cloud-tasks` receipts from the service's simulator verify under both verifiers, and are read as simulated. They are not in the corpus, because they seal the account's number in `job.id` (`--extra DIR` checks them locally). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 3 commits 2026-11-05 15:11:19 -05:00

wai-quantum-qpu: a built-in provider kind for a cloud service of quantum tasks ... ba429af757

`cloud-tasks`: one device on the person's own account. Requests are signed
with their keys (Signature Version 4), and results land in their own storage
bucket. On a processor the program is OpenQASM 3 in a verbatim box on physical
qubits. A device of `rx rz cz` takes the `rzsxxcz` basis, with `sx` and `x` as
`rx`, since they differ only by a global phase. A device whose native gates
fit no basis is refused with what it runs. The estimate gives the device's
price and says the service's per-task fee is left out.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-quantum-qpu: cloud-tasks as the real service takes it, with the whole charge ... fe1c9be9ad

Running it on the service's simulator showed two things the scripted tests
could not: a program must measure explicitly, and a simulator refuses a register
with a qubit no gate touches. So every program now assigns its measurements, and
a simulator's idle qubits get an identity.

The estimate now includes the service's fee per task, which its API does not
state, so a job on a processor shows what it will cost. And a simulator can
compile to a processor's basis (`--set basis=gpizz`), so the gates can be checked
before paying for the processor.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-quantum: receipts say where their counts come from and what was set at the provider, and a second verifier checks them ... 265b2f0ffd

A provider's result now states counts_source (shots, vendor_counts or
probabilities, since counts rebuilt from probabilities are derived) and
execution (what each client set off at the provider, built from the very body
it posts). It labels a simulator's counts simulated rather than measured, and
carries the compiled program's text beside its hash. Receipts sealed before
these fields still verify, and are read by their provenance.

Section 8 of the provider protocol is rewritten so that a verifier can be
written from it alone: the seal byte for byte, the strict reader, the canonical
text and the first form's, strict Ed25519, the per-kind rows, seventeen named
reasons, and what a receipt proves. A second verifier was written in Python
from that text by a reader who had not seen the reference, and its gaps became
the text. The reference had accepted a receipt under a small-order key for any
content, any alg, upper-case or +-spelled hex and duplicate members, and
panicked on a two-byte character in a key; it refuses each now.

A corpus of receipts made by the command line, the job service and every
built-in kind, plus receipts crafted to break one rule each, is judged by both
verifiers on every receipt and every one-member change of each valid one, and
each planted defect must be caught. CI runs it beside the CLI's build.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot added 6 commits 2026-11-05 16:32:20 -05:00

Merge origin/main (#638, #652: parameter sets, and the relay loop test's ports) into wai/quantum-cloud-tasks ... 266f690bd4

Co-Authored-By: Claude Fable 5.1 <[email protected]>

wai-quantum-qpu 0.5.0: a new kind and a new method break its API, and are the last to ... 876818767b

`Kind::CloudTasks` and `Method::Put` were added to exhaustive public enums. That
breaks a downstream `match`, so the API check failed with the crate still at
0.4.1. The crate is now 0.5.0, as VERSIONING.md asks of a breaking change before
1.0, and the command line and the desktop app require it.

`Kind` and `Method` are `#[non_exhaustive]` from this version, and `Kind::ALL` is
a slice. A kind is a value of a list that grows, which a minor release may add
to; with the enum exhaustive, every new kind was a breaking release. Inside the
crate a `match` stays exhaustive.

The changelog entry moves from the head of CHANGELOG.md to a file of wai/changes/
and says what to do instead. The API job's baseline step took the version
`cargo info` selects (`0.4.0 (latest 0.4.1)`) for the last one published and
warned on every run; it now reads the latest.

Co-Authored-By: Claude Fable 5.1 <[email protected]>

CI: the qpu library's test count, and the keys the guide's cloud-tasks provider reads ... d59daf4c08

The qpu workflow pins each test binary's count, and the library's was still 46.
The cloud-tasks client adds 15, so it is 61, and three of its tests are named.

The guide's block that adds a `cloud-tasks` provider reads `keys.txt`, which the
documentation's fixtures did not hold. The block stopped there, so the next
block's `providers remove turns` found no provider. The fixture is added.

Co-Authored-By: Claude Fable 5.1 <[email protected]>

quantum-studio: a code's summary, certificate and lattice change in one step ... 9db46c96d5

The error-correction pane set a new code's summary and decoders, then checked
its seal, then drew its lattice. The browser test waits for the summary and
reads the lattice at once, and on this branch's run it read the surface code's
two faces where the colour code's nine were due. The file is main's, so the
race is on main too; the job passed on the eight other runs around this one.

The seal is now checked first and the pane changes together, as a decode
already did. A threshold had the same split, its plot drawn before the check
and its reading after: with the check slowed by 800 ms the test fails there
too, so it is fixed the same way. With that delay the test fails on main's
ordering and passes on this one. The test is unchanged.

Co-Authored-By: Claude Fable 5.1 <[email protected]>

Merge wai/quantum-cloud-tasks (#654: main, wai-quantum-qpu 0.5.0, and its CI fixes) into wai/quantum-receipt-fields ... 7fabdd0fde

Co-Authored-By: Claude Fable 5.1 <[email protected]>

wai-quantum: the receipt work on wai-quantum-qpu 0.5.0, and what replaying CI's steps found ... b3fdad50a9

This follows the merge of #654's new head, and a replay of the workflows' own
steps on Linux.

- The qpu workflow pins each test binary's count. This branch adds two tests
  to the library and one to the clients, so the pins are 63 and 9, and the
  three are named.
- The job service's committed tool list was stale. The receipt and job-result
  schemas changed after it was last regenerated, so the service's own test
  failed. It is regenerated.
- `CountsSource` is `#[non_exhaustive]` and its `ALL` is a slice, by the rule
  #654 applied to `Kind`: a later text may add a source in a minor release.
- The Chinese command-line README now says of a provider's result what the
  English one does.

Co-Authored-By: Claude Fable 5.1 <[email protected]>

dcharlot added 7 commits 2026-11-06 02:34:02 -05:00

wai-quantum-qpu: cloud-tasks reads a job through the qubits it was sent on, and refuses what it could not read ... 80528577db

A job's record keeps the device's own names for its program's qubits, and
collection reads through those without asking the device again. Logical qubits
are read from a row by label, so a qubit past the sixty-fourth can be read, and
one the program ended on that was not measured is an error. Region and bucket
are checked before they go into a host; a dotted bucket is read by path, from
the bucket the task names. An endpoint this kind would not use is refused. A
named credential that gives nothing is an error on every built-in kind, and
every part of the keys comes out of a message, whole or cut short. wai-qpu asks
for --yes wherever a job spends. A simulator's estimate says it is the minimum.
The client now has a fake that follows the service's contract, temporary keys
among what it checks.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Merge wai/quantum-cloud-tasks into wai/quantum-receipt-fields ... 951cfd26a1

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-quantum-qpu: the guide's cloud-tasks example names a region and a bucket that are names ... 760abf0750

The guide's runnable block used an ellipsis for each, which adding a provider now refuses.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-quantum: every verify surface holds every rule, and a host seals nothing its verifier refuses ... 6b947aa379

job::verify runs job::check. POST /v1/verify, the service's tool, the command
line's tool and its verify on a set, an estimate or an algorithm's answer, the
Python package, the desktop app and the browser all apply section 8.4, reading
a job's text as text where they hold it, so a member named twice is found. Each
gives reasons beside valid and key, and a set's items are held to a job's rules.

A local host's qec, compile, pulse, estimate, @Seal and intent check now refuse
a request holding a number no double holds, as a run does, and seal_into writes
one in a result as the double sealed. A receipt already sealed with one stays
refused, its signature good, and verifies written as that double's digits.

A job recorded by the last release gets a receipt this one accepts: its program's
text from its record, and execution stated by nobody, which every kind takes.
compiled.qubit_names says which of the device's qubits each index was. sampler-v2
reads a backend's simulator member. The reference's ceiling on every whole number
is gone, as section 8.4 has it, with sums exact, and the differential now tries
numbers past a double's whole numbers, with a plant that proves it can see them.
verify --json keeps --history. The earlier form claims no sealing time. A made
receipt is pinned by digest. R of small order is tested where the equation holds.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Merge wai/quantum-cloud-tasks into wai/quantum-receipt-fields ... 41945f54ce

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-quantum: a set is verified as a set everywhere, a host gives no receipt it would refuse, and the corpus keeps what it holds ... 3bec9b4a01

A surface that takes a job takes a set, and verified it against a seal over its
head as if over the whole result, so a good set read as invalid. The provider
path checks its own receipt before giving it: a provider's word reaches the
seal. A made receipt is pinned by digest, and generate.py --self-test shows each
way the pins fail. The corpus gains two receipts by the first form's own writer,
from the service as it was on 18 October. A second verifier's reading settled
four sentences of section 8, and -0 as an index, where the two disagreed.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-quantum: the desktop app, the browser and the notebook held to the corpus; qubit_names and whole numbers in it ... 7671774f03

The desktop app's verify and the browser's engine_verify each have a test that
reads the corpus's text and gives section 8.4's reasons. The command line's tool
answers a set as a set, and its schema says so, with signer. The corpus gains
receipts for qubit_names (missing, null, a leading zero, short), a job stated by
nobody on a kind with rows, and whole numbers past 2^53 - 1 with only a count's
value capped, so a ceiling on every whole number is caught by the corpus alone,
as the second-only run in the conformance step needs. The notebook's stored
verdict names its reasons and form. Tool lists and agent docs regenerated.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot referenced this pull request from a commit 2026-11-06 03:23:42 -05:00

ci: the wai-quantum legs build the commit they test, and fail when they did not

dcharlot referenced this pull request 2026-11-06 03:23:54 -05:00

ci: the wai-quantum legs build the commit they test, and fail when they did not #666

dcharlot referenced this pull request 2026-11-06 07:16:04 -05:00

wai-quantum: the planner under a contract, its reasoning sealed, a provider's answer shadowed (stacked on #660) #668

dcharlot referenced this pull request 2026-11-06 08:13:23 -05:00

wai-quantum: an energy ceiling held by a live reading, and the command line can give one (stacked on #668) #670

dcharlot added 8 commits 2026-11-06 13:43:09 -05:00

wai-quantum-qpu: cloud-tasks asks after a task where it is, signs as the published suite does, and keeps a list's unknown kinds ... 72f127376b

The second review's six. A list of providers holding a kind this build does
not know is read, the entry kept as it is and noted; the changelog says plainly
that earlier builds cannot read a list holding a cloud-tasks entry. A client
reads a processor's task through the qubits it read only when it submitted the
task; a task's region comes from its id. wai-qpu asks for --yes on anything not
stated free. providers test says "at least" of a minimum. Signing is held to the
published v4 test suite, by both path rules and with a body. The fake service
takes the bucket from the host or the path, walks a task through its states and
a cancel, and writes results in the published result schema's form.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Merge wai/quantum-cloud-tasks into wai/quantum-receipt-fields ... 10adefebde

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-quantum: the second review's seven, and a set's receipt in section 8 ... 8436745b66

RFC 8785's spelling of a large whole double is taken; a set's receipt is section
8.6, with three reasons, and every surface judges a set by it; a receipt is
checked on its text in the Studio, the desktop app and the npm example; set
requests are screened; the tools take a job's text; qubit_names covers every
qubit qasm3 acts on; the service's verify schema describes signer. Corpus:
two sets made by the command line, fourteen set vectors, five number vectors,
one names vector; three more plants. Work in progress: its battery is running.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-quantum: a set's item read for what is sealed, keyed to its set, a failed item's numbers by its leaf; tool lists regenerated ... 6d6b774472

An item's key is compared with the set's receipt's key member as it stands. An
item is read for its index, request, result, error and path; what else it
holds is unsealed, and the differential's oracle now says so. A failed item's
numbers are read as a canonical receipt reads them, whatever the set's form,
since its leaf is the canonical form's digest. Two first-form set vectors.
The second verifier, from the text, agrees on all 156 receipts. The service's
and the command line's tool lists are regenerated, signer among the verify
answer's members.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-quantum: the views page built again from its sources ... 4d4a5ebba9

The Studio's English words for an estimate's minimum ("at least") are among
the page's sources, and the committed page was built before them.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Merge wai/quantum-cloud-tasks into wai/quantum-receipt-fields ... 28927d4862

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-quantum: the views page built again, its verify without the engine's set re-derivation ... 7e0901bd1f

The page is built from wai-quantum-views, whose verify now holds every rule of
the receipt; through job::verdict it also carried the engine's re-derivation of
a set's sweep, which put the page past its 1 MiB limit. It checks the receipt's
rules alone (job::check), and the page is 984,188 bytes, built on Linux as CI
builds it.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-quantum: seal_into passes its function, as clippy asks ... fc44eb3445

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot merged commit 08c826b79f into main 2026-11-06 14:45:15 -05:00

dcharlot referenced this pull request from a commit 2026-11-06 14:45:17 -05:00

Merge pull request 'wai-quantum: receipts say where their counts come from and what was set at the provider, and a second verifier checks them' (#660) from wai/quantum-receipt-fields into main

dcharlot referenced this pull request from a commit 2026-11-07 02:56:19 -05:00

Merge wai/quantum-receipt-fields (#660 at fc44eb344, #654's cloud-tasks in it) into wai/quantum-planner-contract

dcharlot referenced this pull request from a commit 2026-11-07 02:56:19 -05:00

wai-quantum: the contract test on cloud-tasks at #660's test endpoint; the tool lists blessed again

dcharlot referenced this pull request from a commit 2026-11-07 02:56:19 -05:00

Merge main (#660 and #654 landed) into wai/quantum-planner-contract

dcharlot referenced this pull request from a commit 2026-11-07 03:50:34 -05:00

Merge wai/quantum-planner-contract (#660 merged, the contract now section 8.7) into wai/quantum-cli-energy-estimate

dcharlot referenced this pull request from a commit 2026-11-07 03:50:34 -05:00

Merge wai/quantum-planner-contract (main, #660 and the verification's fixes), and hold a ceiling by a live reading

dcharlot referenced this pull request 2026-11-07 08:29:34 -05:00

wai: wasmQ, an OpenQASM 3 program and the WebAssembly its externs call, run the same everywhere, metered and receipted #659

dcharlot referenced this pull request from a commit 2026-11-07 08:30:57 -05:00

Merge main into wasmQ: #660 single verify path, keeping the bounded read

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!660

No description provided.