Safe Runtime Extensibility and Plugin Ecosystems

Quantum platforms need extensibility. Teams will want custom compiler passes, domain-specific encoders, mitigation plugins, provider adapters, data validators, and dashboard modules. Extensibility without guardrails turns the runtime into an unreviewed execution environment.

OpenAPI and AsyncAPI describe service contracts for synchronous and asynchronous APIs [R202][R203]. OPA provides policy-as-code decisioning with Rego [R221]. A quantum plugin ecosystem should combine typed interfaces, policy gates, signed artifacts, and sandboxed execution.

Diagram loads as you read

Safe Runtime Extensibility and Plugin Ecosystems · Figure 1

View diagram source

flowchart LR
    Plugin[Plugin package] --> Manifest[Manifest]
    Manifest --> Contract[API contract]
    Contract --> Policy[Policy evaluation]
    Policy --> Sandbox[Sandboxed runtime]
    Sandbox --> Telemetry[Telemetry]
    Telemetry --> Evidence[Evidence]

Plugin classes

Plugin class	Risk	Minimum control
problem encoder	changes mathematical problem	domain review
compiler pass	changes executable circuit	equivalence and benchmark tests
mitigation plugin	changes estimate and uncertainty	bias and variance validation
provider adapter	changes external execution path	conformance suite
evidence exporter	changes records and retention	audit review
visualization	changes interpretation surface	provenance and labeling

Diagram loads as you read

Plugin classes · Figure 2

View diagram source

flowchart TB
    Runtime[Quantum runtime] --> Encoder[Encoder plugins]
    Runtime --> Compiler[Compiler plugins]
    Runtime --> Mitigation[Mitigation plugins]
    Runtime --> Provider[Provider adapters]
    Runtime --> Evidence[Evidence exporters]
    Runtime --> UI[Visualization plugins]

Plugin manifest

A plugin should be declarative before it is executable.

Illustrative listing · yaml

plugin:
  name: zne-profile-selector
  version: 2.4.1
  type: mitigation
  owner: qc-platform-mitigation
  entrypoint: wasm:selector.wasm
  input_schema: qmitigation.input.v3
  output_schema: qmitigation.output.v3
  permissions:
    - read:execution_metadata
    - write:mitigation_report
  forbidden:
    - submit:qpu_job
    - read:raw_sensitive_inputs
  evidence_class_max: internal

Diagram loads as you read

Plugin manifest · Figure 3

View diagram source

flowchart TB
    Manifest[Plugin manifest] --> Identity[Owner and signer]
    Manifest --> Interface[Input and output schemas]
    Manifest --> Permissions[Permission request]
    Manifest --> Limits[Evidence class limits]
    Manifest --> Tests[Required tests]

Admission gate

Diagram loads as you read

Admission gate · Figure 4

View diagram source

flowchart LR
    Submit[Submit plugin] --> Verify[Signature verification]
    Verify --> Static[Static checks]
    Static --> Contract[Contract tests]
    Contract --> Policy[Policy evaluation]
    Policy --> Sandbox[Sandbox test]
    Sandbox --> Review[Human review if needed]
    Review --> Registry[Publish to registry]

The registry should reject unsigned plugins, plugins without owners, plugins with ambiguous schemas, and plugins requesting permissions outside their declared class.

Runtime isolation

Diagram loads as you read

Runtime isolation · Figure 5

View diagram source

flowchart TB
    Host[Quantum host runtime] --> Boundary[Isolation boundary]
    Boundary --> Plugin[Plugin process]
    Plugin --> API[Allowed host API]
    Plugin -. blocked .-> Secrets[Secrets]
    Plugin -. blocked .-> Network[Unapproved network]
    Plugin -. blocked .-> QPU[Direct QPU submission]

A compiler plugin should not be able to read customer secrets. A visualization plugin should not be able to submit jobs. A mitigation plugin should not call arbitrary network services during claim-bearing analysis.

Policy examples

Illustrative listing · rego

package quantum.plugins

default allow := false

allow if {
  input.plugin.type == "mitigation"
  not "submit:qpu_job" in input.plugin.permissions
  input.plugin.evidence_class_max != "external_claim"
  input.signature.verified == true
}

Diagram loads as you read

Policy examples · Figure 6

View diagram source

flowchart LR
    Request[Plugin admission request] --> Input[Structured input]
    Input --> Rego[Policy rules]
    Rego --> Decision[Allow or deny]
    Decision --> Audit[Decision record]

Kill switch

Diagram loads as you read

Kill switch · Figure 7

View diagram source

flowchart LR
    Incident[Plugin incident] --> Disable[Disable plugin version]
    Disable --> Resolve[Resolve dependents]
    Resolve --> Quarantine[Quarantine outputs]
    Quarantine --> Rollback[Rollback workflows]
    Rollback --> Postmortem[Postmortem]

Every plugin version needs a kill switch, dependency inventory, and evidence impact query.