Governance APIs and Control Evidence Automation

A production quantum platform should not treat governance as a quarterly slide deck. Governance needs to participate in the runtime path: admission, policy evaluation, evidence planning, control mapping, exception handling, review, and audit export.

The purpose of a governance API is to turn decisions into durable objects.

Diagram loads as you read

Governance APIs and Control Evidence Automation · Figure 1

View diagram source

flowchart LR
    Request[Workload request] --> GovAPI[Governance API]
    GovAPI --> Policy[Policy evaluation]
    GovAPI --> EvidencePlan[Evidence plan]
    GovAPI --> Controls[Control mapping]
    Policy --> Admission[Admission decision]
    Admission --> Runtime[Runtime constraints]
    EvidencePlan --> Archive[Evidence archive]
    Controls --> Audit[Audit packet]

The governance object model

A governance API should produce records that can be replayed. The minimum object model is small.

Object	Purpose
workload context	who is asking, what is being run, and why
admission decision	allow, deny, require approval, or require modification
constraint set	provider, region, cost, shot, target, and evidence limits
evidence plan	artifacts that must exist before a claim can be accepted
exception record	approved deviations and their expiry
review record	human or automated review outcome

NIST SP 800-53 provides a catalog of security and privacy controls, and OSCAL provides machine-readable structures for controls and assessments. Quantum platforms can reuse those ideas while adding quantum-specific evidence fields such as target snapshot, calibration epoch, compiler profile, mitigation profile, and shot ledger. [R169] [R170]

Diagram loads as you read

The governance object model · Figure 2

View diagram source

classDiagram
    class GovernanceDecision {
      decision_id
      workload_id
      requester
      policy_bundle
      result
      constraints
      expires_at
      signature
    }
    class EvidencePlan {
      required_artifacts
      validators
      retention_class
      claim_boundary
    }
    class ExceptionRecord {
      exception_id
      scope
      approver
      rationale
      expires_at
    }
    GovernanceDecision --> EvidencePlan
    GovernanceDecision --> ExceptionRecord

Admission is not execution

Governance should not execute workloads. It should decide what execution is allowed to do.

Diagram loads as you read

Admission is not execution · Figure 3

View diagram source

sequenceDiagram
    participant User
    participant Broker
    participant Governance
    participant Runtime
    participant Archive
    User->>Broker: submit workload package
    Broker->>Governance: request admission
    Governance-->>Broker: decision + constraints + evidence plan
    Broker->>Runtime: execute within constraints
    Runtime->>Archive: emit evidence
    Archive-->>Governance: evidence validation status

This separation keeps the platform composable. The broker owns routing and execution. Governance owns policy, evidence obligations, and review state. The archive owns records.

Evidence before execution

A common failure mode is trying to assemble evidence after a surprising result. Production platforms invert that sequence.

Diagram loads as you read

Evidence before execution · Figure 4

View diagram source

flowchart TB
    ClaimIntent[Claim intent] --> EvidencePlan[Evidence plan]
    EvidencePlan --> Admission{Admit?}
    Admission -- no --> Reject[Reject or revise workload]
    Admission -- yes --> Execute[Execute]
    Execute --> Validate[Validate evidence]
    Validate --> Claim{Claim allowed?}

Examples:

Claim type	Evidence required
exploratory result	workload ID, target, shots, compiler version
internal decision	above plus target snapshot, statistics, reviewer
customer-facing claim	above plus admission decision, control mapping, immutable package
regulated or disputed result	above plus applicable retention or preservation obligations, chain of custody, and any approved exception record; apply a legal hold when its legal trigger and scope require it

Policy-as-code

Governance APIs become practical when policies are executable. OPA/Rego is one common pattern for evaluating structured context against rules, but the architectural principle is more important than the specific engine: policy must be versioned, testable, and replayable. [R177]

Diagram loads as you read

Policy-as-code · Figure 5

View diagram source

flowchart LR
    Context[Admission context] --> Bundle[Versioned policy bundle]
    Bundle --> Decision[Decision]
    Decision --> Constraints[Runtime constraints]
    Decision --> Evidence[Evidence obligations]
    Decision --> Log[Audit log]

A useful admission context includes subject, workload type, data classification, target class, provider, region, cost estimate, evidence level, claim intent, and current trust tier.

Eventing and observability

Governance should emit events for every state transition. OpenTelemetry and CloudEvents provide useful models for portable telemetry and event metadata. [R171] [R175]

Diagram loads as you read

Eventing and observability · Figure 6

View diagram source

stateDiagram-v2
    [*] --> Draft
    Draft --> Submitted
    Submitted --> Evaluated
    Evaluated --> Approved
    Evaluated --> Denied
    Evaluated --> NeedsReview
    NeedsReview --> Approved
    Approved --> Executed
    Executed --> EvidenceValidated
    EvidenceValidated --> Reviewed
    Reviewed --> [*]

Operating rule

Every production quantum run should leave behind a governance trace: request, policy bundle, admission decision, constraints, evidence plan, execution status, review status, and claim boundary.

Additional technical sources: [R272].