Regulated Quantum Workloads and Compliance Packages

Some quantum workloads will support low-risk exploration. Others may touch controlled information, national-security research, financial decisions, safety-sensitive materials, regulated health or energy data, or public claims. The platform should not treat those workloads as ordinary jobs with a larger warning label. They require a compliance package.

Diagram loads as you read

Regulated Quantum Workloads and Compliance Packages · Figure 1

View diagram source

flowchart LR
    Intake[Workload intake] --> Classify[Regulatory classification]
    Classify --> Controls[Control baseline]
    Controls --> Package[Compliance package]
    Package --> Execute[Controlled execution]
    Execute --> Review[Evidence review]
    Review --> Release[Controlled release]

What a compliance package contains

A compliance package is the controlled wrapper around the experiment.

Section	Contents
workload classification	data type, jurisdiction, customer, export posture
authorization	owner, approver, service identity, provider account
control mapping	baseline controls and exceptions
execution constraints	allowed backends, regions, providers, reservations
evidence requirements	logs, signatures, calibration snapshots, retention
result handling	publication rules, caveats, release path
disposition	archive, deletion, transfer, retention clock

Diagram loads as you read

What a compliance package contains · Figure 2

View diagram source

classDiagram
    class CompliancePackage {
      package_id
      risk_tier
      classification
      jurisdiction
      owner
      approver
    }
    class ExecutionConstraint {
      allowed_provider
      allowed_region
      allowed_backend
      max_runtime
    }
    class EvidenceRequirement {
      logs_required
      signatures_required
      retention_class
    }
    CompliancePackage --> ExecutionConstraint
    CompliancePackage --> EvidenceRequirement

Controlled information

Organizations handling controlled unclassified information can use NIST SP 800-171 Rev. 3 and its assessment companion as a concrete model for security requirements and assessment procedures [R227]. Even when a quantum program is not formally subject to that regime, the structure is useful: identify the controlled data, define requirements, assess implementation, and preserve evidence.

Diagram loads as you read

Controlled information · Figure 3

View diagram source

flowchart TB
    Data[CUI or controlled data] --> Requirements[Security requirements]
    Requirements --> Assessment[Assessment procedure]
    Assessment --> Evidence[Evidence]
    Evidence --> Authorization[Authorization decision]

Execution constraints

A regulated workload should carry constraints into scheduling and provider routing.

Diagram loads as you read

Execution constraints · Figure 4

View diagram source

flowchart LR
    Package[Compliance package] --> Scheduler[Scheduler]
    Scheduler --> Region{Allowed region?}
    Region -- no --> Reject[Reject]
    Region -- yes --> Provider{Allowed provider?}
    Provider -- no --> Reject
    Provider -- yes --> Backend{Allowed backend?}
    Backend -- yes --> Run[Run]
    Backend -- no --> Reject

Examples of constraints include provider allowlists, geographic execution limits, approved service identities, encryption requirements, reservation requirements, and result-export restrictions.

Evidence checkpoints

Regulated workflows should use checkpoints instead of a single final review.

Diagram loads as you read

Evidence checkpoints · Figure 5

View diagram source

sequenceDiagram
    participant Dev as Developer
    participant Gate as Compliance gate
    participant QPU as QPU backend
    participant Evidence as Evidence service
    participant Reviewer as Reviewer
    Dev->>Gate: submit package
    Gate->>Evidence: record admission decision
    Gate->>QPU: authorize constrained execution
    QPU-->>Evidence: execution and calibration metadata
    Evidence->>Reviewer: assemble review bundle
    Reviewer-->>Evidence: approve, reject, or request rerun

Separation of duties

The person who writes the workload should not be the only person who approves its regulated release. A regulated path needs separation among author, platform operator, compliance reviewer, domain reviewer, and release approver.

Diagram loads as you read

Separation of duties · Figure 6

View diagram source

flowchart TB
    Author[Author] --> Submit[Submit]
    Operator[Platform operator] --> Execute[Execute]
    Compliance[Compliance reviewer] --> ControlReview[Control review]
    Domain[Domain reviewer] --> ScienceReview[Scientific review]
    Release[Release approver] --> Publish[Publish or export]
    Submit --> Execute --> ControlReview --> ScienceReview --> Publish

Package states

Diagram loads as you read

Package states · Figure 7

View diagram source

stateDiagram-v2
    [*] --> Draft
    Draft --> Submitted
    Submitted --> ApprovedForRun
    ApprovedForRun --> Executed
    Executed --> EvidenceReview
    EvidenceReview --> ApprovedForRelease
    EvidenceReview --> RerunRequired
    EvidenceReview --> Rejected
    ApprovedForRelease --> Archived

State transitions should be signed and logged. Exceptions should expire automatically.

Operating rule

A regulated quantum workload is not a job. It is a controlled case file that happens to include a quantum execution. Treating it as a case file keeps the execution, evidence, approvals, and release decision aligned.