One Python SDK. Three backend classes today. Native QONTOS at G2.
Submit a circuit. The QONTOS runtime ingests it, partitions it across modules, schedules each partition onto the best-scoring backend, executes concurrently, aggregates the results, and emits a three-layer SHA-256 proof of execution. Apache-2.0. Operational today against simulator and external-provider backends.
The runtime that QONTOS-1 will use at G2 is the runtime you can install today.
Platform at a glance
One runtime. Five backends. One verifiable proof.
The QONTOS runtime is a single Python SDK that compiles a circuit once and runs it anywhere — simulator, external provider, or native QONTOS-1 at first-module bring-up. The numbers below define the platform's footprint today.
PYTHON SDK
qontos
≥ Python 3.11 · Apache-2.0
BACKEND CLASSES
4
simulator · provider · native · research
PARTITIONERS
3
Greedy · Spectral · Manual
PROOF LAYERS
3
SHA-256 · integrity · plan · result
OPEN-SOURCE REPOS
6
github.com/qontos
SYSTEM ARCHITECTURE
One stack. Seven layers. Open at every layer.
The QONTOS platform spans the user's laptop to a millikelvin transmon module on a single signal path. Every layer has a public artifact: SDK, IR, scheduler manifest, ExecutorContract, telemetry, control firmware schema, device descriptor. Nothing is opaque.
FIG.A · END-TO-END ARCHITECTURE · L7 (CLIENT) DOWN TO L1 (DEVICE)
Module B · QC1-DT-500-TaSiMirror module · synchronised dilution refrigerator
paired through photonic link · single logical qubit at G4
Every horizontal slab is independently versioned. The highlighted backend is the QONTOS-1 native trajectory. A single trace ID rolls observability up across all seven layers.
Runtime pipeline
Six stages, plan-time and runtime split, one proof.
Circuit normalisation, partitioning, scheduling, and backend binding complete deterministically before any hardware tick. The real-time loop executes the prepared plan with no further planning overhead. The proof chain emits one SHA-256 hash at each layer, binding the run end to end.
COMPILATION · DEEP DIVE
From user code to microwave pulse, every transform recorded.
QONTOS does not hide the compilation pipeline. Each pass is a named, deterministic transform with a stable input and output schema. Replays use the same passes in the same order. You can inspect the IR between any two passes from the SDK or CLI.
Each row is reproducible by running qontos compile --emit-stage <pass> against the same circuit. Pass order is fixed; pass parameters are configurable. Identical IR re-runs produce identical SHA-256.
REPLAYABILITY
Each pass is content-addressable.
The IR at every pass boundary hashes to the same SHA-256 across hosts. A replay with the same compiler version and circuit reproduces the byte-identical output.
INSPECTABILITY
Stop after any pass, dump the IR.
qontos compile circuit.qasm --until partition --emit json writes the intermediate state to disk for diffing, debugging, or external tooling.
OPENNESS
Every pass is open source.
The full pipeline ships under Apache-2.0 in qontos-sdk/compiler. Pass interfaces are documented; third-party passes can be inserted between any two stages.
Backend ecosystem
One ExecutorContract. Every backend speaks it.
Each backend implements the same six-method ExecutorContract — validate, submit, poll, cancel, normalise_result, normalise_error. Adding a new backend is a single class implementation. Compile once, route anywhere.
Backend status · live dashboard
Five backends, one health surface.
The QONTOS runtime maintains a normalised health signal for every backend in scope. Queue depth, mean two-qubit fidelity, calibration epoch, throughput, and cost per shot are all surfaced through the same telemetry interface — the same numbers the scheduler reads when it scores a backend at submission time.
Scheduler · 4-factor scoring
How a backend is picked for a partition.
The scheduler scores every candidate backend with a weighted sum of four factors: two-qubit fidelity, queue depth, cost per shot, and qubit-capacity fit. Weights are configurable per submission. The top-scoring backend takes the partition. The same scoring is reproducible from the Layer-2 plan hash.
SCHEDULER · MULTI-TENANT THEATRE
Three priority lanes. One fair scheduler.
QONTOS-1 is a shared resource. The scheduler reserves capacity across three lanes — interactive, batch, and bulk — and runs a deficit-round-robin pass so no tenant can starve another. Lane policy is published; lane assignment is logged in the manifest.
FIG.F · MULTI-TENANT QUEUE · LANE OCCUPANCY · 60 S WINDOW
Interactive jobs (solid) pre-empt batch and bulk when their lane reservation is hot. Bulk jobs (hatched) coalesce to fill idle windows. Fairness metric: standard deviation across tenant wait time stays under 12 s.
FAIRNESS · DRR
Deficit round-robin.
Each tenant has a quantum proportional to its reservation. Unused quantum carries forward up to a cap. No tenant can monopolise the device beyond its share without yielding capacity from another.
PRIORITY
Three lanes, fixed weights.
40 % interactive · 40 % batch · 20 % bulk. Reservations are statutory; lane policy can only change through a governance vote of the steering committee, never by request.
EVIDENCE
Public scheduler trace.
Every scheduling decision lands in the manifest with a four-factor breakdown. Customers can query their own decisions; aggregate fairness metrics are published weekly.
Partition strategies
Three partitioners. Picked by circuit size.
The compiler picks the partitioner automatically; an explicit override is always available. Each one trades off computational cost against partition quality. The spectral partitioner is the default for circuits at module-scale qubit counts.
STRATEGY · GREEDY
GreedyPartitioner
complexity · O(n)
Below roughly 20 logical qubits. Walks the circuit in topological order and assigns gates to partitions as they appear. Fast iteration for development.
STRATEGY · SPECTRAL · DEFAULT
SpectralPartitioner
complexity · O(n log n)
Default for larger circuits. Constructs the gate-connectivity graph and applies spectral clustering on its Laplacian to minimise the number of cross-partition Bell-pair CNOTs.
STRATEGY · MANUAL
ManualPartitioner
complexity · O(1)
Used when an explicit qubit-to-module mapping is supplied. Typical for benchmarks, replay-from-proof workloads, or expert override of scheduling decisions.
Quickstart · 20 lines of Python
From pip install to a verifiable result.
A Bell-state circuit, partitioned across modules, executed against the chosen backend, aggregated, and verified. The same code targets the simulator today and QONTOS-1 hardware at G2.
Install
Python 3.11 or later. Apache-2.0. Pinned dependencies for reproducible plan hashes.
# Python ≥ 3.11 pip install qontos
A first circuit
Build a Bell state, route it through the runtime, get a result with a SHA-256 proof chain you can replay against any other backend.
from qontos importCircuit, Runtimefrom qontos.executors importSimulator# Define a Bell-state circuit
c =Circuit(qubits=2)
c.h(0)
c.cx(0, 1)
c.measure_all()
# Compile, schedule, execute, aggregate
runtime =Runtime(backends=[Simulator()])
result = runtime.submit(c, shots=1000)
# Verifiable artefactsprint(result.counts) # {'00': 503, '11': 497}print(result.proof.layer3) # H₃ = SHA-256(H₂ ∥ result)# Switch backend without recompiling
runtime.bind(IBMQuantum('ibm_brisbane'))
result = runtime.submit(c, shots=1000)
Partition benchmarks
Partition time scales as expected with circuit size.
Median wall time of the three partitioners measured on the qontos-benchmarks circuit corpus. The Spectral partitioner is the default; Greedy is faster for small circuits but the Spectral cut produces fewer inter-partition Bell-pair CNOTs at every size above n ≈ 32.
The default isn't picked by speed — it's picked by inter-partition cost. Spectral pays a small wall-time premium below 32 gates but pays it back in lower Bell-pair consumption at every size above. The compiler chooses Spectral by default; Greedy is preferred only when iteration time during development matters more than partition quality.
REAL-TIME LOOP · LATENCY BUDGET
Sub-microsecond from measurement to feed-forward.
Fault-tolerant primitives like magic-state injection demand that the result of a measurement turns into a conditional gate before the next syndrome cycle ends. QONTOS-1 holds a hard 500 ns decoder budget. The chart below is the timing budget that ships in the calibration record.
200 ns of the 500 ns budget is held for the union-find decoder; everything else is dispatch and DAC arming. If the decoder ever runs over, the controller raises a non-recoverable error and the run is aborted before the next cycle.
DECODER · UF
Union-find · distance 5 · CPU-free.
The decoder runs on the OPX FPGA. No host CPU sits in the loop. The detector graph is updated each cycle and resolved with a constant-time union-find pass.
SAFETY
Budget violations halt the run.
A hard timer aborts the experiment if any step exceeds its allotment. The proof record carries the violation reason. No silent re-tries.
EVIDENCE
Histograms are public.
Every job stores per-cycle timing histograms in layer1.timing. qontos status --jobs <id> --timing prints them.
ERROR MITIGATION · QEC STACK
Mitigation today, codes tomorrow, one interface.
Surface-code QEC is the destination. Until G4 the workhorse is principled error mitigation: zero-noise extrapolation, probabilistic error cancellation, dynamical decoupling, and post-selected verification. Both surfaces ship through the same SDK call.
L4_M · MITIGATION · PRE-QEC
ZNE
Zero-noise extrapolationscale 1.0, 1.5, 2.0 · Richardson · linear fit
cost: 3× shots · variance ↑ √3
Mitigation routerpicks stack from calibration & circuit profile
user override available
L3_C · QEC CODE · POST-G4
Surface code · d = 525 data qubits · 24 measure ancillae
cycle: syndrome extract + decode
p_L target: < 10⁻⁶ per cycle
decoder: union-find · 200 ns budget
activates at QONTOS-1 G4
DETECTOR GRAPH · UF DECODE
Decoder · detector graph viewedges weighted by p_x and p_z · matched via UF
3 detector events
1 pair + 1 boundary-match
UF closes both clusters in 18 ops
Mitigation calls and QEC-aware calls share the same SDK signature. Switching is one keyword: runtime.execute(circuit, error="mitigation") vs runtime.execute(circuit, error="surface", d=5). The mitigation router records which stack ran and at what cost.
PROOF CHAIN · ANATOMY
A run you cannot replay is a result you cannot trust.
QONTOS-1 emits a proof artifact for every job. The artifact is a content-addressed JSON document whose Merkle root is signed by the host's attestation key. Anyone with the same circuit, the same compiler version, and the proof can audit the run end-to-end.
FIG.E · PROOF MERKLE TREE · L1 INTEGRITY · L2 PLAN · L3 RESULT
PROOF ROOT
SHA-256 + Ed25519 sig
3df7a4..82d0
LAYER 1 · INTEGRITY
device cal · pulse · sensor · cycle
94f3c..1aa2
LAYER 2 · PLAN
IR per pass · partition · schedule
b4d09..3f15
LAYER 3 · RESULT
shots · aggregates · provenance
7eb20..b07d
cal_recorda710..
pulse_packa3c4..
sensor_logf8d1..
ir_passes71b9..
partition_map22a0..
schedule_plancd7a..
shots_blob5b13..
aggregate4ef0..
provenance99fc..
$ qontos verify --proof bell-2026-05.qproof
layer 1: ok · layer 2: ok · layer 3: ok · signature: verified · root: 3df7a..82d0
qontos verify --proof job_01HXZ8A.qproof walks every leaf, recomputes the root, and checks the signature against the published attestation chain.
REPRODUCE
Plan → byte-identical replay.
Given Layer 2 alone, anyone with the same compiler version reproduces the IR exactly. Given Layer 3, the result histogram is the canonical answer.
ARCHIVE
WORM bucket. 10-year retention.
Proofs are stored in an audit-grade write-once bucket. They survive backend deprecation. A QONTOS-1 result will still be verifiable when QONTOS-3 is in operation.
Code playground · examples
Five workflows, one runtime.
The same compiled plan structure carries every workflow. Switch tabs to see the pattern for a Bell-state demo, a VQE on H₂, magic-state injection at distance d = 5, multi-backend dispatch, and replay-from-proof verification.
Bell state · simulator
The minimum runnable example: define a Bell state, dispatch to the default simulator, read the Layer-3 hash.
BACKEND
Simulator
QUBITS
2
SHOTS
1 000
PROOF
Layer 3 emitted
from qontos import Circuit, Runtime
from qontos.executors import Simulator
c = Circuit(qubits=2)
c.h(0); c.cx(0, 1); c.measure_all()
runtime = Runtime(backends=[Simulator()])
result = runtime.submit(c, shots=1000)
print(result.counts)
# → {'00': 503, '11': 497}print(result.proof.layer3.hex())
# → 9f4c…1bd2 (Layer-3 SHA-256)
Variational ground state · H₂
A two-qubit hydrogen-molecule VQE with the UCCSD ansatz, dispatched to the digital twin and then re-bound to a provider backend without recompiling the plan.
METHOD
VQE · UCCSD ansatz
BACKEND
qontos-sim → IBM Quantum
ITERATIONS
≈ 80 SPSA steps
PROOF
per-iteration L3 hash
from qontos.chemistry import H2Hamiltonian
from qontos.ansatze import UCCSD
from qontos.optimisers import SPSA
from qontos.executors import QontosSim, IBMQuantum
H = H2Hamiltonian(bond_length=0.74)
ansatz = UCCSD(qubits=2)
runtime = Runtime(backends=[QontosSim()])
energy = SPSA().minimise(
cost=lambda θ: runtime.expval(ansatz(θ), H),
initial=ansatz.zero_params(),
)
print(f"E_min = {energy:.6f} Ha")
# → E_min = -1.137270 Ha# Replay against IBM Quantum, same plan
runtime.bind(IBMQuantum('ibm_brisbane'))
energy = runtime.expval(ansatz(SPSA.best_params), H)
Magic-state injection · d = 5
Inject a distilled magic state into a distance-5 surface-code patch and run a non-Clifford rotation. The runtime threads the lattice surgery + distillation cycle through the decoder pipeline.
CODE
Surface code · d = 5
NON-CLIFFORD
T gate · injected
DECODER
MWPM · 5 μs ingest
FACTORY
15-to-1 distillation
from qontos.ftqc import SurfaceCode, MagicFactory, inject_T
logical = SurfaceCode(distance=5)
factory = MagicFactory(protocol="15-to-1")
circuit = Circuit.logical(qubits=1, code=logical)
circuit.h(0)
inject_T(circuit, qubit=0, factory=factory)
circuit.h(0)
circuit.measure_all()
result = runtime.submit(
circuit,
decoder="mwpm-sparse-blossom",
shots=10_000,
)
print(result.logical_error_rate)
# → validation metric; ε_L < p_phys is not required at QONTOS-1 G4
Multi-backend dispatch
Submit a single circuit to a fleet of backends. The scheduler partitions it, scores each candidate, and dispatches each partition to its highest-scoring backend.
Take any Layer-3 SHA-256 proof artefact and re-execute the bound plan, optionally against a different executor. Replays are bit-exact if the executor is deterministic.
INPUT
Proof artefact (.qproof)
OUTPUT
New L3 hash + counts
VERIFY
chained hash equality
USE CASE
regression · audit
from qontos.proof import ProofArtefact, replay
artefact = ProofArtefact.load("run-2026-04-18.qproof")
# Layer-1 + Layer-2 are immutable - check before runningassert artefact.layer1_intact() and artefact.layer2_intact()
# Replay against a different executor
new_result = replay(
artefact,
executor=IBMQuantum("ibm_brisbane"),
shots=1000,
)
print(new_result.proof.layer3.hex())
# → 7e83…91ca (new L3, same L1/L2)print(new_result.differs_from(artefact.result))
# → KL = 0.012 (sampling distance)
Command line · qontos CLI
Compile, submit, replay — from the terminal.
The qontos CLI exposes the same runtime through the shell. Every command emits machine-readable artefacts (plan, proof, manifest) so the same workflow drives both interactive sessions and CI.
A quantum runtime that wants to live in production has to publish what classical infrastructure publishes: an SLA surface, a cost model, and a security posture. QONTOS commits to all three, and every commitment is testable.
SLA SURFACE · 2026 H2
Uptime, queue, fidelity — all measured.
Metric
Target
Window
Penalty
API availability
99.9 %
monthly
10 % credit
Interactive p95 queue
< 30 s
weekly
5 % credit
Batch p95 turnaround
< 30 min
weekly
5 % credit
Two-qubit fidelity
> 0.997
per cal
cal recall
Proof publish
< 60 s post-run
per job
10 % credit
Calibration drift
< 5 % / 24 h
continuous
cal recall
All metrics are scraped from the public telemetry stream. No self-reporting.
Pricing for QONTOS-1 native activates at G2 and tracks operating cost, not margin. Provider rates are pass-through; we mark them clearly in the invoice.
SECURITY POSTURE · ATTESTED
Identity, signing, attestation.
Identity. OIDC + mTLS at the gateway. PASETO v4 tokens with five-minute expiry. Per-tenant API keys are signed and rotated.
Signing. Every proof root is signed with an Ed25519 batch key whose certificate chains to the QONTOS-1 attestation root. Keys are rotated daily.
Attestation. The control host boots into a measured runtime. Each release carries a SLSA-3 provenance attestation. Firmware versions are pinned in the manifest.
Data residency. Job inputs and outputs stay in the user's selected region. Proof artifacts are mirrored to a separate audit region under WORM lock.
Isolation. Tenants share the device, not memory. Calibration state, telemetry buffers, and queues are namespaced per tenant.
Incident response. Sev-1 incidents are disclosed inside 24 hours with a public root-cause memo.
API REFERENCE · CATALOG
Two protocols. One contract.
Every operation has a REST and a gRPC form. Schemas are versioned; request and response shapes are stable within a major version. The SDK calls these endpoints; nothing the SDK does is hidden.
The QONTOS runtime reads circuits written in OpenQASM 3, Qiskit, PennyLane, Cirq, or the native QPL, normalises them to one canonical IR, and compiles once for every backend. The matrix below lists the operations supported through each frontend.
Capability
OpenQASM 3
Qiskit
PennyLane
Cirq
QPL (native)
Circuit ingest
FULL
FULL
FULL
FULL
FULL
Pulse-level IR
FULL
PARTIAL
—
—
FULL
Parameterised circuits
FULL
FULL
FULL
FULL
FULL
Auto-differentiation
—
PARTIAL
FULL
PARTIAL
FULL
Mid-circuit measurement
FULL
FULL
PARTIAL
FULL
FULL
Classical control flow
FULL
FULL
PARTIAL
PARTIAL
FULL
Surface-code encoding
PARTIAL
PARTIAL
—
—
FULL
Replay from proof
FULL
FULL
FULL
FULL
FULL
Open source
Six repositories. Apache-2.0. Public source.
The whole runtime, the digital twin, the benchmarks, the examples, the research papers, and the organisation standards — all under github.com/qontos. The platform's role in the engineering programme is to make QONTOS-1 hardware integration the only novel risk at first-module bring-up.
Software risk retires on a timeline independent of the hardware.
ARCHITECTURE · 01
Separation of planning from runtime.
Circuit normalisation, partitioning, scheduling, and backend assignment complete deterministically before any hardware tick. The real-time loop executes the prepared plan without further planning overhead. Result: the plan is reproducible from its Layer-2 hash alone.
ARCHITECTURE · 02
Provider-agnostic execution.
Every backend, simulator, IBM Quantum, Amazon Braket, future native QONTOS, is addressed through a single ExecutorContract. Circuits compile once and run anywhere. The native QONTOS-1 executor at G2 plugs in through the same interface — no scheduler or planner changes are required.
ARCHITECTURE · 03
Cryptographic execution integrity.
Every run emits a three-layer SHA-256 proof chain that binds the circuit, the plan, and the result. The same proof structure is produced on every backend, making results across backends directly comparable. Replay from any proof is supported in qontos-examples.
The runtime that QONTOS-1 will use at G2 is the runtime you can install today. The plan-time path is already exercised against simulator, IBM Quantum, and Amazon Braket. When the native QONTOS-1 executor binds at G2, plan-time work is identical; only the executor changes.
Engineering bulletin
Platform dispatches.
26.04.20
Software runtime v2 deployed against simulator and IBM Quantum backends
The QONTOS runtime, including the spectral partitioner, MWPM decoder, and three-layer SHA-256 proof chain, is operational against multiple external backends and ready for native-executor binding at G2.
qontos-sim ships the QONTOS-1 digital twin with full module decoherence model
The digital twin emulates module decoherence, photonic-link statistics, and decoder latency. The same compiled plan exercised against qontos-sim today will run unchanged on native QONTOS-1 at G2.
ExecutorContract interface frozen at v1.0 for the QONTOS-1 programme
The six-method ExecutorContract (validate, submit, poll, cancel, normalise_result, normalise_error) is now stable. New backends require a single class implementation; existing plan-time code is unchanged.
The QONTOS platform exists so that hardware integration is the only novel risk at first-module bring-up. The runtime is operational against simulator and external-provider backends today; plan-time work is identical regardless of executor. When QONTOS-1 hardware accepts its first compiled circuit at G2, the runtime switches its executor binding; the rest of the stack does not change.
The platform is open source under Apache-2.0 and lives at github.com/qontos. Six repositories cover the SDK, the digital twin, the benchmarks, the examples, the research, and the organisation standards.