open-standards/wai/wai-quantum/schemas/provenance.v1.json
Transaction Science a0bd65d6af wai-quantum: the state vector placed on the fabric's members, and split over several
A job's new `fabric` says where the statevector method's state runs: auto
(the default), cpu, accelerator, a member's id or key, or a list of members
(a power of two), the state split by its top qubits into one partition on
each. The CUDA, HIP and OpenCL members' f64 state vectors are discovered
once per process and certified against the CPU on the pinned corpus; only a
member certified bit-exact is placed, so a placed job's answers are the
CPU's byte for byte. A placement the host cannot honour is refused (J013),
never made elsewhere. With no member asked for and none placed, the plan and
the result are what they always were: the existing pins hold.

The partitioned run (sv64::run_split) runs the launches the CPU plans on each
partition's amplitudes; a gate on a partition qubit first has that qubit
exchanged with a local one through the host's copy. Ground truth first: CPU
partitions equal the CPU's state vector bit for bit over the pinned corpus at
every partition count and on wide states with exchanges. On the fleet, one
state split four ways over a laptop GPU (by two backends), the CPU by OpenCL
and the CPU reference gives the CPU's answers byte for byte, as does the
integrated GPU by HIP beside OpenCL.

The result carries `fabric` (member, parity tier, certificate digest, corpus,
energy unmetered with the reason), sealed by the job's receipt, and its
provenance names the members: optional members of the job request, job result
and provenance schemas, and fabric_members in the tools schema. Surfaces:
`wai-quantum run --fabric` and `wai-quantum fabric`, the CLI's cuda, hip and
opencl features, `fabric` in both MCP servers' job tools and `list_fabric` on
the command line's, the service reading it. Members gain run_launches and
max_qubits. Hardware legs in the CUDA and HIP workflows, absent legs and the
CPU-partition tests by name in containers.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-31 09:54:34 -04:00

216 lines
5.6 KiB
JSON

{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://git.transaction.science/Transaction-Science/open-standards/raw/branch/main/wai/wai-quantum/schemas/provenance.v1.json",
"title": "wai.quantum.provenance/1",
"description": "What a result came from, under the five categories cross-platform provenance surveys use: the circuit, the computer, the compilation, the execution and the software. A host adds it to the results it seals (the job service does, and each item of a set); a result without it reads as it always did. wai-quantum-service/docs/provenance.md maps every field to where it is and whether the receipt seals it.",
"type": "object",
"required": [
"schema",
"circuit",
"computer",
"compilation",
"execution",
"software"
],
"properties": {
"schema": {
"const": "wai.quantum.provenance/1"
},
"circuit": {
"type": "object",
"description": "The program: the BLAKE3 digest of its text as given, its qubits and its gates.",
"required": [
"program"
],
"properties": {
"program": {
"type": "string",
"description": "BLAKE3 of the program's text, in hex."
},
"qubits": {
"type": "integer",
"minimum": 0
},
"gates": {
"type": [
"integer",
"null"
]
}
}
},
"computer": {
"type": "object",
"description": "What ran it: a classical simulator, the method and its accuracy class, a device target's hash when the job named one, and the fabric's members when the result names where its state ran.",
"required": [
"kind",
"method"
],
"properties": {
"kind": {
"const": "simulator"
},
"method": {
"type": "string"
},
"accuracy": {
"type": [
"string",
"null"
]
},
"target": {
"type": "string",
"description": "The device target's hash; its layout, routes and noise are in the result's own target."
},
"fabric": {
"type": "object",
"description": "The kernel and the member that ran the state, or each partition's, as the result's fabric names them.",
"properties": {
"kernel": {
"type": "string"
},
"members": {
"type": "array",
"items": {
"type": "string"
}
}
}
}
}
},
"compilation": {
"type": "object",
"description": "Whether the job asked to be compiled; if it did, each pass in order with its check's verdict, the certificate's digest, the gate set compiled to (its basis), the level, the ε budget and the distance the result carries, and that no pass draws a random number.",
"required": [
"asked"
],
"properties": {
"asked": {
"type": "boolean"
},
"passes": {
"type": [
"array",
"null"
],
"items": {
"type": "object",
"properties": {
"pass": {
"type": "string"
},
"verdict": {
"type": [
"string",
"null"
]
}
}
}
},
"certificate": {
"type": [
"string",
"null"
]
},
"basis": {
"type": [
"string",
"null"
],
"description": "The gate set compiled to: clifford_t or standard."
},
"level": {
"type": [
"integer",
"null"
]
},
"epsilon": {
"type": [
"number",
"null"
]
},
"distance": {
"type": [
"number",
"null"
]
},
"seeded": {
"const": false
},
"device": {
"type": "string",
"description": "A job on a device target, compiled exactly to its gates: where its layout and routes are."
},
"status": {
"const": "not-applicable"
},
"why": {
"type": "string"
}
}
},
"execution": {
"type": "object",
"description": "The shots, the seed and the plan the job ran under; its identifier and times are the host's, outside the result.",
"required": [
"plan"
],
"properties": {
"shots": {
"type": [
"integer",
"null"
]
},
"seed": {
"type": [
"integer",
"null"
]
},
"plan": {
"type": "object",
"properties": {
"method": {
"type": "string"
},
"why": {
"type": "string"
},
"memory_bytes": {
"type": "integer",
"minimum": 0
},
"work": {
"type": "integer",
"minimum": 0
}
}
}
}
},
"software": {
"type": "object",
"description": "The engine's name and version, and the host's.",
"required": [
"engine",
"host"
],
"properties": {
"engine": {
"type": "string"
},
"host": {
"type": "string"
}
}
}
}
}