The single `HwShunt` acquisition class covered both an on-chip vendor counter (RAPL, NVML, SMC, IOReport) and an external calibrated shunt. They are different evidence: a calibrated instrument's uncertainty is traceable to a calibration, while a counter is a vendor's reading whose error the vendor states (RAPL readings are deliberately noised when SGX or TDX is enabled, per security advisory INTEL-SA-00389). - extensions/energy-measurement.md §2 splits hardware evidence into `OnChipCounter` and `CalibratedInstrument`, each with a required declared uncertainty (relative error and integration window). IOReport is an on-chip counter, like RAPL and NVML. `HwShunt` stays readable as the legacy class, ranked below both, and is not sealed into a new WAI receipt. - Every receipt family that carries joules — video, world, film, reel, haptic, score, splat4d, audio scene, ternary, provenance and the wai-quantum receipts — can carry its class. The label is additive: every committed signed vector still verifies, and the signed bytes of unlabelled and legacy-labelled receipts are pinned by tests. A sealed figure declares its 1 µJ resolution, and the floor is stated as the rule verified (0.5/√3 µJ). - The acquisition rules are scoped to the receipt profiles WAI defines, and the text says what enforces each one. - Meters open their window from rest, report an all-zero power reader as unusable rather than clean, and state the running-window count model as conservative. - oer-receipts.md maps OER's evidential grade onto the refined classes. The rule that a producer must not grade `measured` a figure whose class is `Estimator` is kept as settled on main. - wai-quantum verifies a receipt in either form on every in-tree verify path, including wai-quantum-serve's POST /verify. - CI: wai-energy-receipts.yml runs the energy-class, label and legacy-pin tests for wai-rs, wai-quantum and wai-quantum-serve, which no workflow enabled before. Co-Authored-By: Claude Opus 5.5 <[email protected]>
6.7 KiB
WAI Extension: Quantum-Operations Attestation (wai.quantum.calibration · wai.quantum.job)
Status: Draft. Engine: wai-rs/src/quantum_ops.rs (feature quantum_ops).
The verify-half of WAI (wai.asset.provenance's lineage, specialized) applied
to the quantum processing industry.
0. The gap this closes
Every quantum-control stack in the field — Q-CTRL, QuantrolOx, Qruise, Quantum
Machines, Qblox, Zurich Instruments, OrangeQS, QuEL, Origin, Conductor, Classiq —
emits the same three unsigned things: an HDF5 dataset, a JSON state snapshot,
and a dashboard/log. Not one signs, content-addresses, ports, or
meters the joules of a single operation. The industry already reaches for
reproducibility (QM's __package_versions__, QBOM bills-of-materials, QCIVET
hash-chained audit traces, "Vibe Calibration" internal audit records) but stops
exactly short of two axes:
- cryptographic signature + portability — a receipt a third party verifies, not a mutable vendor-cloud dashboard;
- measured joules — every stack sits on a kW-scale dilution fridge + control racks, yet none emits joules-per-calibration or joules-per-job.
This extension is those two axes. It is not a control system and runs no hardware: the calibration/job is performed by the sink's control stack, exactly as WAI dispatches a decode to a sink's codec. WAI owns the receipt.
1. Two receipts, cross-linked
wai.quantum.calibration — CalibrationReceipt
A signed record of one bring-up / tune-up run:
device_id,target("q3","cz(q3,q4)","readout:q3")config_hash— content hash of the applied pulse/gate configevidence[]— each an{kind, blob_hash, summary}: a benchmark outcome (RB / T1·T2 / Rabi / readout-GMM) content-addressed to its raw dataset bytes, so a fidelity claim binds to the exact bytes that produced it (evidence_matches()) — checkable, not assertedjoules_micro— measured energy of the run (attested), with its acquisition class as an optional signed label:quantum_energy::Labelledwraps any receipt here and re-signs it with the class inside the signature, andLabelledQbomlabels a bill of materials per entry (energy-measurement §2.8). An unlabelled receipt keeps its legacy bytes.grant— the authorization (below)parent_receipt_hash— the prior device state this supersedes: the signed "digital twin" lineage vendors keep only as mutable, unsigned data
merkle_root covers [config_hash] ++ evidence leaves; one Ed25519 signature
covers the whole payload.
wai.quantum.job — JobReceipt
A signed record of one dispatched circuit:
backend_id— which QPU/sim actually ran it ("ionq:aria-1","wai.quantum.circuit")circuit_hash,result_hash(counts histogram / statevector),shotscalibration_ref— theCalibrationReceipt::receipt_hashof the device state the job ran under.verify_against_calibration(cal)confirms the job names that calibration and both verify — the QCIVET "the claimed calibration was actually in effect" property, signed.Nonefor a simulator.joules_micro,grant,parent_receipt_hash
2. The grant — gate ⊗ meter ⊗ receipt in one object
GrantRef = capability ⊗ joule-ceiling (⊗ optional funds-ceiling, JCP §4.8
dual ceiling). The full grant lives in the JCP layer; the receipt binds its content
hash plus the ceilings it enforces.
The enforcement is the sharp part: the joule ceiling is checked inside
verify(). A receipt whose measured joules_micro exceeds its grant ceiling is
not valid — an operation that blew its energy grant cannot produce a passing
receipt. This is the whole portfolio thesis (gate, meter, receipt) collapsed into
a single verifiable object. honors_budget() exposes the check on its own; a
grant with joule_ceiling_micro = u64::MAX opts out (still signs everything else).
3. Conformance
- A conforming producer (a control stack, or an adapter over one — see §5)
MUST seal a
CalibrationReceiptper calibration run and aJobReceiptper dispatched job, withjoules_microa measured figure (never fabricated;0/unbounded if genuinely unmetered) and every hash the real content hash. - A conforming verifier MUST accept a receipt iff
verify()passes — Merkle root recomputes, joules within the grant ceiling, signature valid — and, for a job that claims a calibration state,verify_against_calibration()passes. - Receipts are portable: JSON with hex hashes (
to_json/from_json), verifiable with only the public key. No vendor cloud required.
4. What this is NOT
- Not a control system, not a simulator, not a calibration ML. It attests operations others perform. The physical control electronics and the ML tuning models are the dispatched backend — WAI's founding "don't reinvent, dispatch" philosophy (SPEC Appendix B), applied to quantum control.
- Not a reconstruction.
joules_microand the result are attested (only the signer can vouch for their own silicon's energy draw); the hashes, Merkle root, grant ceiling, and cross-link are verifiable by anyone. The receipt states plainly which half is which.
5. Integration (where it attaches)
The natural attach point is the control-system → cloud boundary: the moment a calibration node or a job completes, the control system already holds everything a receipt needs (config, evidence datasets, result, timing, backend identity), and the power rails are already instrumented — so adding a signature + a joule figure is incremental. Ranked open-source insertion points:
- Quantify (
quantify-core) — one HDF5-write chokepoint, co-owned by Qblox + OrangeQS: one adapter covers two vendors (Phase 1 target). - OrangeQS Juice — open lab-OS whose Task-Management + DB layer is a natural control plane; production chip-testing, where a signed pass/fail has direct commercial value.
- QUAlibrate/QUAM — largest install base; the per-node boundary + the existing
__package_versions__hook upgrade cleanly to a signed, metered receipt. - Qubex/qube-calib (QuEL) — fully open, clean
CalibrationNoteartifact.
Adoptability is openness-first: Japan (QuEL/OQTOPUS), India (NQM), Korea (SDT/ NVQLink, Norma/PQC), and the Western merchant vendors (receipt as an anti-lock-in feature). Sovereign closed champions are parallel, not addressable.
6. The unclaimed metric
"Joules per verified calibration" and "joules per QPU job" are unmeasured and unclaimed across the entire field. This extension is the object that carries them — signed, portable, content-addressed, and grant-bounded.