Policy-as-Code and Guardrail Enforcement — Operating Quantum Computers

Quantum platforms accumulate rules. Some are scientific: minimum shots, calibration freshness, benchmark acceptance thresholds. Some are operational: reservations, budget caps, target eligibility, maintenance windows. Some are security and governance rules: who can run sensitive workloads, which targets can receive which data, and when a public claim requires review.

If these rules live in documents, they will drift. If they live only in application code, they will become inconsistent. Mature platforms express repeatable rules as policy-as-code and place policy decision points in the execution path. Open Policy Agent is one established pattern for externalizing policy decisions with a declarative language and APIs. [R141]

Diagram loads as you read

Policy-as-Code and Guardrail Enforcement · Figure 1

View diagram source

flowchart LR
    Request[Quantum request] --> PDP[Policy decision point]
    Context[User, target, artifact, budget, data class] --> PDP
    PDP --> Decision{Allow?}
    Decision -- allow --> Runtime[Runtime execution]
    Decision -- deny --> Explain[Explain denial]
    Decision -- exception --> Review[Human review]

Why policy belongs in the runtime path

Quantum jobs are expensive, scarce, and state-dependent. The same circuit may be safe on a simulator, questionable on a noisy public QPU, and prohibited on a restricted lab system. Policy must be evaluated against live context.

Diagram loads as you read

Why policy belongs in the runtime path · Figure 2

View diagram source

flowchart TB
    Static[Static request] --> Enrich[Context enrichment]
    Enrich --> Target[Target state]
    Enrich --> Cal[Calibration state]
    Enrich --> User[User role]
    Enrich --> Data[Data classification]
    Enrich --> Cost[Budget state]
    Target --> Policy[Policy evaluation]
    Cal --> Policy
    User --> Policy
    Data --> Policy
    Cost --> Policy

Decision points

The platform should have several policy decision points, not one monolithic gate.

Diagram loads as you read

Decision points · Figure 3

View diagram source

flowchart LR
    Submit[Submit] --> Admission[Admission policy]
    Admission --> Compile[Compile]
    Compile --> Release[Artifact release policy]
    Release --> Schedule[Scheduling policy]
    Schedule --> Execute[Execution policy]
    Execute --> Publish[Publication policy]

Typical policy checks:

Decision point	Example rule
Admission	Reject jobs without provenance metadata
Compile	Block deprecated compiler profiles
Schedule	Deny QPU execution if simulator validation failed
Execute	Require fresh calibration for high-sensitivity workloads
Publish	Require evidence package and claim review

Policy inputs

A policy engine is only as useful as its input document. For quantum platforms, the input must include scientific and operational attributes.

Diagram loads as you read

Policy inputs · Figure 4

View diagram source

flowchart TB
    Input[Policy input] --> Identity[Identity]
    Input --> Workload[Workload]
    Input --> Target[Target]
    Input --> Artifact[Artifact]
    Input --> Calibration[Calibration]
    Input --> Budget[Budget]
    Input --> Data[Data class]
    Input --> Claim[Claim intent]

Example input:

Illustrative listing · json

{
  "user": {"role": "research_engineer", "team": "chemistry"},
  "workload": {"shots": 50000, "depth": 184, "claim_intent": "internal_report"},
  "target": {"type": "qpu", "region": "us", "available": true},
  "calibration": {"age_minutes": 37, "readout_error_ok": true},
  "artifact": {"signed": true, "compiler_profile": "approved-2026-04"},
  "budget": {"remaining_units": 3200},
  "data": {"classification": "internal"}
}

Policy outputs

The output should be machine-readable and human-explainable.

Diagram loads as you read

Policy outputs · Figure 5

View diagram source

flowchart LR
    Decision[Decision] --> Result[allow deny review]
    Decision --> Reason[reason codes]
    Decision --> Evidence[evidence required]
    Decision --> Expiry[decision expiry]
    Decision --> Audit[audit record]

A useful output shape:

Illustrative listing · json

{
  "decision": "review",
  "reason_codes": ["shots_exceed_team_budget", "publication_intent_requires_approval"],
  "required_evidence": ["simulator_baseline", "calibration_snapshot", "claim_review"],
  "expires_at": "2026-04-20T00:00:00Z"
}

Exception handling

Quantum teams will need exceptions. The point is not to eliminate judgment. The point is to make judgment visible, bounded, and reversible.

Diagram loads as you read

Exception handling · Figure 6

View diagram source

stateDiagram-v2
    [*] --> Denied
    Denied --> ExceptionRequested
    ExceptionRequested --> Approved: owner accepts risk
    ExceptionRequested --> Rejected: risk too high
    Approved --> Active
    Active --> Expired: time limit reached
    Active --> Revoked: incident or policy change
    Expired --> [*]
    Rejected --> [*]
    Revoked --> [*]

Exception records should include:

rule overridden;
owner;
reason;
blast radius;
expiry;
compensating controls;
linked evidence package.

Guardrails for scientific claims

Policy-as-code should also protect the language of claims. The platform can classify claim intent and require evidence depth.

Diagram loads as you read

Guardrails for scientific claims · Figure 7

View diagram source

flowchart TB
    Result[Result] --> ClaimIntent{Claim intent}
    ClaimIntent -- exploratory --> Light[Notebook-level record]
    ClaimIntent -- internal decision --> Medium[Evidence package]
    ClaimIntent -- customer or public --> Heavy[Independent review]
    Heavy --> Legal[Legal and comms review]
    Heavy --> Technical[Technical replication]

Examples:

Claim language	Required guardrail
“Observed under these parameters”	provenance and notebook record
“Improved over baseline”	baseline lock, confidence interval, reanalysis path
“Quantum advantage”	adversarial review, classical baseline audit, publication review

Policy distribution

Policy must be versioned and deployed like infrastructure.

Diagram loads as you read

Policy distribution · Figure 8

View diagram source

sequenceDiagram
    participant Author as Policy author
    participant Repo as Policy repo
    participant Test as Policy tests
    participant Registry as Policy registry
    participant PDP as Decision point

    Author->>Repo: Submit policy change
    Repo->>Test: Run fixtures and regression tests
    Test->>Registry: Publish signed policy bundle
    PDP->>Registry: Pull approved bundle
    PDP-->>PDP: Evaluate requests with bundle version

Policy test fixtures

Policy tests should include golden requests:

Illustrative listing · yaml

fixtures:
  - name: simulator_smoke_test_allowed
    input: examples/simulator_smoke_test.json
    expect: allow
  - name: unsigned_qpu_job_denied
    input: examples/unsigned_qpu_job.json
    expect: deny
  - name: public_claim_requires_review
    input: examples/public_claim.json
    expect: review

Diagram loads as you read

Policy test fixtures · Figure 9

View diagram source

flowchart LR
    Policy[Policy bundle] --> Fixtures[Test fixtures]
    Fixtures --> Regression[Regression test]
    Regression --> Publish{Publish?}
    Publish -- pass --> Registry[Registry]
    Publish -- fail --> Block[Block release]

Operating rule

A quantum platform without policy-as-code will eventually run an expensive, invalid, or noncompliant job because a rule was remembered by one person and missed by another.