Quantum operations data comes from hardware control, calibration systems, cloud providers, compilers, notebooks, workflow engines, cost systems, ticketing, and governance tools. Without a semantic layer, teams debate names instead of operating the platform.
View diagram source
flowchart LR
Lab[Lab telemetry] --> Fusion[Semantic fusion layer]
Cloud[Cloud runtime] --> Fusion
Compiler[Compiler lineage] --> Fusion
Governance[Governance events] --> Fusion
Cost[Cost records] --> Fusion
Fusion --> Ops[Operations views]
Fusion --> Evidence[Evidence packages]
Fusion --> Analytics[Analytics]Canonical entities
View diagram source
classDiagram
class Workload
class Execution
class TargetSnapshot
class CalibrationEpoch
class CompilerProfile
class EvidencePackage
class Claim
class PolicyDecision
Workload --> Execution
Execution --> TargetSnapshot
TargetSnapshot --> CalibrationEpoch
Execution --> CompilerProfile
Execution --> EvidencePackage
EvidencePackage --> Claim
PolicyDecision --> ExecutionEach entity needs a stable identifier, owner, lifecycle state, timestamp policy, and provenance record.
Naming discipline
| Ambiguous term | Clarify as |
|---|---|
| target | hardware endpoint, target class, or provider backend |
| job | broker job, provider job, workflow task, or experiment run |
| calibration | full calibration, partial update, or metadata snapshot |
| error | physical, compiler, runtime, policy, or claim error |
| result | raw counts, mitigated observable, reviewed claim, or product decision |
View diagram source
flowchart TB
RawTerms[Raw terms] --> Ontology[Operational ontology]
Ontology --> CanonicalIDs[Canonical IDs]
CanonicalIDs --> Joins[Reliable joins]
Joins --> Views[Operational views]Event fabric
CloudEvents provides a common event envelope, while OpenTelemetry provides data models and semantic conventions for telemetry. Quantum platforms can use those patterns while adding quantum-specific fields. [R171] [R175]
View diagram source
sequenceDiagram
participant Broker
participant Runtime
participant Evidence
participant Warehouse
Broker->>Warehouse: workload.submitted
Runtime->>Warehouse: execution.started
Runtime->>Warehouse: execution.completed
Evidence->>Warehouse: evidence.validated
Evidence->>Warehouse: claim.reviewedA quantum event should include workload ID, execution ID, provider, target snapshot, calibration epoch, compiler profile, runtime options, evidence package, and status.
Reliable joins
View diagram source
flowchart LR
WorkloadID[workload_id] --> Join[Join fabric]
ProviderJob[provider_job_id] --> Join
TargetSnapshot[target_snapshot_id] --> Join
EvidenceID[evidence_package_id] --> Join
CostID[cost_record_id] --> Join
Join --> Record[Unified operational record]Bad joins create false conclusions. A result linked to the wrong calibration epoch can produce the wrong root cause. A cost record detached from the workload contract makes unit economics unusable.
Operational views
| View | Users |
|---|---|
| fleet health | operators and SREs |
| workload lineage | researchers and platform engineers |
| cost and capacity | FinOps and executives |
| audit evidence | legal, security, compliance |
| reproducibility | scientific reviewers |
View diagram source
flowchart TB
SemanticLayer[Semantic layer] --> Fleet[Fleet health]
SemanticLayer --> Lineage[Workload lineage]
SemanticLayer --> Cost[Cost view]
SemanticLayer --> Audit[Audit view]
SemanticLayer --> Repro[Reproducibility view]OpenAPI can describe stable broker, evidence, scorecard, and governance APIs. Verifiable credentials can represent issuer-backed facts such as training status, benchmark certification, or provider tier. [R174] [R176]
Operating rule
A quantum platform needs a semantic control plane. Without it, every serious analysis becomes custom data archaeology.