QDevOps is the reproducibility and observability layer for hybrid quantum workloads. Every run is versioned, replayable, auditable — backed by cryptographic evidence, not a Jupyter notebook screenshot.
I got result X in February. Same circuit, same backend — I get Y today. Which one was real?
A package update shipped last week. Did it move my numerics, or is my hardware drifting?
My reviewer is asking for proof. Can I show what code, what container, what dependencies actually executed?
I ran this experiment 40 times to tune a parameter. 40 QPU bills — for results I could have cached.
QDevOps answers all four — automatically, on every run, without writing any infrastructure code.
Not a roadmap. Not a deck. These are the capabilities you get the moment you create an account.
Every run is stamped with a verdict against its environment's pinned image digest and package fingerprint. You can prove which container, which Qiskit version, which RNG seed produced any historical result.
ZNE, PEC, DD, TREX, CDR, and side-by-side Compare modes ship as first-class circuit options. No researcher rewrites their own error-mitigation harness; no team reinvents the comparison plumbing.
Multi-stage SQS queues (sandbox / staging / production), a circuit-hash dedup cache, run lineage, durable S3 artifacts, and a full audit timeline — the plumbing that turns a one-off circuit into a production workflow.
Every successful run is automatically classified against its pinned environment. The verdict travels with the run forever, even if live infrastructure moves later.
The run executed against the exact ECR image digest the Environment was pinned to. Same bytes in, same bytes out.
A different image build, but the Python package fingerprint matches. Numerical results within float tolerance.
Package versions moved since lock. Re-running may produce different scientific output — surfaced as a warning in the UI.
The environment was never pinned. Typically a legacy run from before the feature shipped, or a hard pin failure.
On a project's first successful run, the linked Environment is locked: the Python container's
image digest is recorded, an env-<id> ECR tag is created, and the ECS task definition
ARN is captured. Every subsequent run is measured against that pin.
Every circuit is hashed over (circuit, mode, backend, params) at submission.
If an identical successful run already exists for the same Environment + RNG seed,
the worker short-circuits to SUCCEEDED in zero milliseconds — no wasted QPU time.
?force=1 bypasses dedup when you want a fresh execution.
Three separate queues — sandbox / staging / production — each with its own worker pool,
retry budget, DLQ behaviour, and admin replay UI. Move a circuit from experimentation to production
without changing code.
Every re-run remembers its parent. The ancestry chain is rendered on every run page, and any two sibling runs in a project can be opened in a structured diff view — circuit, mode, backend, params, env, seed.
Five strategies built on top of Qiskit: ZNE (zero-noise extrapolation), PEC (probabilistic error cancellation), DD (dynamical decoupling), TREX (twirled readout error extinction), CDR (Clifford data regression), plus a Compare mode that runs all of them on the same circuit and renders the deltas.
Every successful run's result payload is serialised and uploaded as a hash-verified artifact in S3 (or MinIO in dev). Downloads are presigned, short-lived (15 min), and never proxied through PHP. A lifecycle policy automatically tiers cold artifacts to STANDARD_IA after 30 days.
Every action across the platform — user submissions, cancellations, re-runs, artifact downloads,
worker lifecycle transitions, Python transport retries, verdict stamping — is captured in a
single run_event table with structured context. Filterable by stage, level, kind,
or run ID on the global Logs page.
One submission interface, three backends today (with more in the pipeline). Backend selection is a parameter, not a code rewrite. Credentials are scoped per stage and stored encrypted at rest with a per-access-key audit log.
Before every run, the live Python container's package map is compared against the Environment's locked recipe. If a re-run would land on a different qiskit / numpy / aer build, the user is warned with a per-package diff table before proceeding.
QDevOps lives one layer above the hardware ecosystems — so you keep optionality.
| Capability | QDevOps | IBM Quantum Platform | AWS Braket |
|---|---|---|---|
| Multi-vendor backend routing | ✓ Yes | ✕ IBM only | ~ AWS marketplace |
| Reproducibility verdict | ✓ Built-in | ✕ Manual | ✕ Manual |
| Error-mitigation pipeline (5 strategies) | ✓ ZNE · PEC · DD · TREX · CDR | ~ Qiskit primitives | ✕ DIY |
| Run lineage & diff | ✓ Parent / child graph | ✕ Flat history | ✕ Flat history |
| Circuit dedup cache | ✓ SHA-256 keyed | ✕ None | ✕ None |
| Stage-scoped deployment | ✓ Sandbox · staging · production | ✕ Single tier | ~ Account-level only |
| Audit trail per run | ✓ Full timeline | ✕ Status only | ~ CloudTrail (general) |
We're onboarding research teams and quantum infrastructure engineers. Join the waitlist and help shape the platform.