Control Evidence Graphs and Queryable Assurance

A mature quantum platform should not treat audit evidence as a pile of screenshots, tickets, notebooks, and export files. Evidence should form a graph: workloads connect to identities, identities connect to approvals, approvals connect to policies, policies connect to controls, controls connect to telemetry, and telemetry connects to claims.

The reason is practical. A quantum result is rarely self-explanatory. It depends on calibration windows, compiler versions, backend topology, shot budgets, mitigation settings, optimizer traces, and human approvals. If those facts live in separate systems, reviewers cannot determine whether a result is reproducible, compliant, or fit for purpose.

flowchart LR
    Workload[Workload] --> Identity[Identity]
    Workload --> Runtime[Runtime contract]
    Runtime --> Execution[Execution record]
    Execution --> Telemetry[Telemetry]
    Execution --> Calibration[Calibration snapshot]
    Execution --> Result[Result artifact]
    Policy[Policy] --> Decision[Admission decision]
    Decision --> Workload
    Result --> Claim[Claim]
    Claim --> Review[Review record]
    Review --> Assurance[Assurance case]

Why a graph instead of a folder

Folders preserve files. Graphs preserve relationships. Quantum operations need relationships because the same artifact can mean different things under different conditions.

A histogram from a superconducting backend is not a result by itself. It becomes useful when connected to the circuit, qubit map, shots, error-mitigation method, calibration version, backend status, queue mode, and acceptance criteria. This is why evidence packages should use structured identifiers and machine-readable relations, not only PDFs or notebooks. Existing compliance automation and control-mapping approaches can be adapted from machine-readable control languages and audit-evidence practices already discussed in earlier chapters [R169], [R170].

flowchart TB
    Artifact[Artifact] -->|has subject| Workload
    Artifact -->|generated by| Run
    Run -->|used| Backend
    Run -->|used| Compiler
    Run -->|occurred during| CalibrationWindow
    Run -->|produced| Measurements
    Measurements -->|supports| Claim
    Claim -->|reviewed by| Reviewer
    Reviewer -->|approved under| Policy

Evidence node types

A minimal graph should represent at least these node types.

classDiagram
    class Workload {
      workload_id
      kind
      owner
      risk_tier
    }
    class Execution {
      execution_id
      backend
      started_at
      completed_at
    }
    class CalibrationSnapshot {
      snapshot_id
      valid_from
      valid_to
      backend_version
    }
    class Claim {
      claim_id
      claim_type
      confidence_level
      caveats
    }
    Workload --> Execution
    Execution --> CalibrationSnapshot
    Execution --> Claim

Query patterns

The graph should answer operational questions without a meeting.

flowchart LR
    Question[Question] --> Query[Graph query]
    Query --> Evidence[Evidence subgraph]
    Evidence --> Answer[Bounded answer]
    Answer --> Action[Accept, rerun, escalate, or reject]

Useful queries include:

Assurance as a live object

An assurance case should not be written once and filed away. It should subscribe to changes in evidence. If a compiler bug is discovered, if a calibration snapshot is invalidated, or if a policy changes, the affected claims should be marked for review.

sequenceDiagram
    participant Defect as Defect report
    participant Graph as Evidence graph
    participant Claims as Claim index
    participant Review as Review queue
    Defect->>Graph: match affected versions
    Graph->>Claims: find dependent claims
    Claims->>Review: open revalidation tasks
    Review->>Graph: attach disposition

This turns governance from a retrospective paperwork exercise into an operational control loop.

Evidence freshness

Evidence loses value when it becomes stale. A result may remain scientifically useful, but its operational meaning changes when dependencies age.

flowchart TB
    Evidence[Evidence object] --> Fresh{Fresh?}
    Fresh -- yes --> Use[Use for claim]
    Fresh -- no --> Revalidate[Revalidate or annotate]
    Revalidate --> Use
    Revalidate --> Reject[Reject for high-assurance use]

Freshness policies should vary by artifact type. Calibration evidence may expire in hours. compiler-validation evidence may expire on release. identity evidence may expire with role changes. regulatory evidence may expire when the control baseline changes.

Implementation pattern

A practical implementation does not need a single monolithic database. It can use an evidence index layered over existing systems.

flowchart TB
    Logs[Logs] --> Index[Evidence index]
    Traces[Traces] --> Index
    DataLake[Experiment lake] --> Index
    Tickets[Review tickets] --> Index
    IAM[IAM] --> Index
    GRC[GRC controls] --> Index
    Index --> API[Queryable assurance API]
    API --> ReviewUI[Reviewer UI]
    API --> CI[CI gates]
    API --> Dashboards[Dashboards]

The key requirement is stable identifiers and immutable references. Every important action should emit an event with a workload ID, execution ID, actor ID, policy ID, artifact digest, and claim ID where applicable.

Failure modes

flowchart LR
    MissingID[Missing identifiers] --> BrokenLineage[Broken lineage]
    BrokenLineage --> Unverifiable[Unverifiable claim]
    SilentPolicy[Silent policy change] --> Drift[Assurance drift]
    ManualEvidence[Manual evidence upload] --> TamperingRisk[Tampering risk]
    AmbiguousReview[Ambiguous signoff] --> WeakAuthority[Weak authority]

The worst pattern is “evidence by attachment.” Attachments are useful for humans, but not sufficient for control. The platform should treat unlinked evidence as incomplete.

Operating rule

A claim is not production-grade unless its evidence path can be queried. If the platform cannot answer who requested it, what ran, where it ran, what state the hardware was in, what policy allowed it, and what review accepted it, the claim should remain exploratory.