Quantum Operations Knowledge Graphs and Ontologies

Quantum operations generate many small facts: which workload used which compiler, which compiler assumed which target profile, which target profile depended on which calibration, which calibration was valid during which window, which evidence package supported which claim. A file tree is not enough.

A knowledge graph gives the platform an operational memory. It connects artifacts, people, devices, policies, results, costs, and claims so the organization can answer questions that matter after the original operators have moved on.

81.1 Why a graph

Diagram loads as you read

81.1 Why a graph · Figure 1

View diagram source

flowchart TB
    Question[Operational question] --> Lineage[What produced this result?]
    Question --> Impact[What breaks if this target changes?]
    Question --> Access[Who can read this evidence?]
    Question --> Cost[What did this claim cost?]
    Question --> Drift[Was the device drifting?]
    Question --> Reproduce[Can we reproduce it?]

These questions cross system boundaries. They require relationships, not just logs.

81.2 Core ontology

Diagram loads as you read

81.2 Core ontology · Figure 2

View diagram source

classDiagram
    class Workload
    class SourceProgram
    class CompilerVersion
    class TargetProfile
    class CalibrationSnapshot
    class RuntimeJob
    class ResultArtifact
    class EvidencePackage
    class Claim
    class Policy
    class CostRecord

    Workload --> SourceProgram : defined_by
    SourceProgram --> CompilerVersion : compiled_with
    CompilerVersion --> TargetProfile : targets
    TargetProfile --> CalibrationSnapshot : valid_under
    Workload --> RuntimeJob : executed_as
    RuntimeJob --> ResultArtifact : produced
    ResultArtifact --> EvidencePackage : included_in
    EvidencePackage --> Claim : supports
    Policy --> EvidencePackage : governs
    RuntimeJob --> CostRecord : incurred

The ontology should be small enough to use and strict enough to preserve meaning.

81.3 Knowledge graph ingestion

Diagram loads as you read

81.3 Knowledge graph ingestion · Figure 3

View diagram source

sequenceDiagram
    participant Runtime as Runtime
    participant Compiler as Compiler
    participant Store as Artifact store
    participant Graph as Knowledge graph
    participant Review as Review system
    Compiler->>Graph: write compilation facts
    Runtime->>Graph: write execution facts
    Store->>Graph: write artifact hashes
    Review->>Graph: write decision facts
    Graph-->>Review: lineage and impact context

The graph should be populated automatically from the systems of record. Manual graph editing creates another unreliable database.

81.4 Impact analysis

Diagram loads as you read

81.4 Impact analysis · Figure 4

View diagram source

flowchart LR
    Change[Changed target profile] --> Query[Graph impact query]
    Query --> Workloads[Affected workloads]
    Query --> Benchmarks[Affected benchmarks]
    Query --> Claims[Affected claims]
    Query --> Policies[Affected policies]
    Query --> ReRuns[Required reruns]

Impact analysis turns a target change from a vague concern into a concrete worklist.

81.5 Evidence lineage

Diagram loads as you read

81.5 Evidence lineage · Figure 5

View diagram source

flowchart TB
    Claim[Claim] --> Evidence[Evidence package]
    Evidence --> Result[Result artifact]
    Result --> Job[Runtime job]
    Job --> Compiled[Compiled workload]
    Compiled --> Source[Source program]
    Job --> Target[Target profile]
    Target --> Calibration[Calibration snapshot]

A claim without lineage is a slide. A claim with lineage is an auditable artifact.

81.6 Policy queries

Diagram loads as you read

81.6 Policy queries · Figure 6

View diagram source

flowchart TB
    PolicyQuery[Policy query] --> Access[Which evidence is restricted?]
    PolicyQuery --> Expiry[Which artifacts expire soon?]
    PolicyQuery --> Export[Which claims need export review?]
    PolicyQuery --> Vendor[Which results depend on vendor X?]
    PolicyQuery --> Compiler[Which claims used compiler Y?]

The graph becomes valuable when governance questions can be answered without convening a meeting.

81.7 Schema evolution

Diagram loads as you read

81.7 Schema evolution · Figure 7

View diagram source

stateDiagram-v2
    [*] --> Draft
    Draft --> Experimental: used by one workflow
    Experimental --> Stable: reviewed and versioned
    Stable --> Deprecated: replacement exists
    Deprecated --> Retired: no active evidence depends on it

Ontologies evolve. Version them. Attach schema versions to evidence packages. Preserve readers for old schemas.

81.8 Operating rule

If the platform cannot trace a claim back to source, compiler, target, calibration, runtime, raw results, analysis, cost, and review decision, the claim is not operationally mature.

Diagram loads as you read

81.8 Operating rule · Figure 8

View diagram source

flowchart LR
    Claim[Claim] --> Trace{Trace complete?}
    Trace -- yes --> Mature[Mature evidence]
    Trace -- no --> Draft[Draft claim only]