QuantaCore™ — Quantum Runtime OS Alpha
Basic Single-Tenant Quantum Runtime OS · Alpha · v0.2.0 · Structured Observables · Near-Term Hardware · Patent Protected

The runtime OS that
quantum computers
have been missing.

Today & Tomorrow

Today: a basic single-tenant Quantum Runtime OS alpha for structured observables on near-term hardware. The kernel primitives are implemented and tested — stabilizer refresh, controller-actionable signal monitoring, hardware abstraction (Q-HAL™), adaptive routing, safe execution via abstention, scheduling, telemetry, and a developer API. 198 tests passing. Simulation mode working end-to-end. Real-QPU API wiring is the next phase.

Tomorrow: multi-tenant, multi-process runtime — the complete OS layer between quantum hardware and quantum applications that every QPU will eventually need.

Why this matters — in plain English

Quantum computers lose their information extremely fast — typically within microseconds — because the surrounding environment constantly disturbs their fragile quantum states. This is the central unsolved problem in making quantum computing practical.

QuantaCore™ has demonstrated a runtime refresh primitive that periodically reinitialises a protected quantum state before it degrades — extending the window during which a classical controller can usefully act on quantum information from 15 microseconds to beyond 30 microseconds on IBM's latest 156-qubit processor. That is a doubling of the actionable lifetime, validated across seven independent hardware experiments with publicly verifiable results. No error correction. No exotic hardware. A smarter way of managing quantum state at runtime — validated on real hardware and now wrapped in a basic OS software layer as a foundation for what comes next.

QuantaCore™ is a basic single-tenant Quantum Runtime OS alpha for structured observables on near-term quantum hardware — implementing stabilizer refresh, controller-actionable signal monitoring, hardware abstraction, adaptive routing, abstention-based safety, scheduling, and telemetry. Kernel primitives validated on IBM's 156-qubit Heron r3 processor across seven independent hardware experiments. Real-QPU API wiring is Phase 5.

Request Technical Report Partnership Inquiry
30 µs
Actionable window extended
vs 15 µs for static hold
89.4%
Average fidelity
116-qubit Kingston validation
7
Published Zenodo records
all IBM job IDs verifiable
198
Tests passing
simulation mode end-to-end
8
Runtime modules built
scheduler · telemetry · API
α
v0.2.0-alpha
QPU wiring is Phase 5
Software OS Layer

A basic runtime OS alpha,
built on validated primitives.

✦ Basic · Single-tenant · Single-process · Alpha · v0.2.0

The validated hardware primitives are now wrapped in a basic OS software stack. Four layers implement the core OS primitives within a single-session execution model. Simulation mode works end-to-end. Real-QPU wiring is explicitly Phase 5 — the honest next step, not a gap in the current claim.

OS Primitive · Hardware abstraction
Q-HAL™ + Orchestrator
Platform-agnostic hardware abstraction. Translates routing policies into validated QPU operations. Safety guardrails prevent unsafe execution. Simulation mode for no-QPU development.
prerunner.py · qhal.py · orchestrator.py · simulator.py
OS Primitive · Health monitoring + memory management
SSM Inference + Refresh Primitive
State-space model tracks latent noise per qubit region via EMA. Stabilizer-frame refresh extends actionable signal from 15 µs to 30+ µs. Actionability thresholds enforced. Honest abstention when evidence is insufficient.
ssm.py · refresh.py
OS Primitive · Scheduling + telemetry
Runtime Scheduler + Telemetry
Three-decision scheduler: RUN_NOW, REFRESH_FIRST, DEFER. Multi-module selection picks highest-fidelity region. Priority queue with FIFO tie-breaking. Structured JSONL event logging with automatic drift detection and six session report types.
scheduler.py · telemetry.py
Developer surface
QuantaCoreAPI
Four clean callables compose all layers into a five-line usage pattern. run_with_refresh() · route_to_best_module() · abstain_if_below_threshold() · warm_up(). Context manager. Batch execution. Full telemetry integration.
api.py
198
tests passing
1.01s
full suite runtime
5/5
OS primitives
0
QPU required

The full OS stack runs end-to-end in simulation without hardware access. Phase 5 wires the API to real IBM Kingston hardware — that is the explicitly stated next step, not an oversight. All scheduling thresholds and refresh trigger logic are grounded in validated Record 7 data: the 15 µs static-hold failure and 30+ µs refresh extension are baked into the scheduler's decision logic from real experimental results.

Core Discovery

The validated runtime primitive:
stabilizer-frame refresh.

Periodically resetting and repreparing the Z⊗Y⊗Z protected quantum stabilizer state extends controller-actionable signal lifetime from 15 µs to beyond 30 µs on IBM Kingston — confirmed across a full delay sweep with matched controls.

Plane fidelity F vs delay — Control run, IBM Kingston module [13,14,15]
τ = 0 µs
0.993
τ = 10 µs
C2 Refresh: 0.892
τ = 15 µs
C2 Refresh: 0.659
τ = 25 µs
C2 Refresh: 0.709
τ = 30 µs
C2 Refresh: 0.651
■ C1 Static hold (fails by 15 µs) ■ C2 Stabilizer refresh (actionable through 30 µs)
Delay τ C1 Static Hold C2 Refresh F C1 Actionable (F>0.6) C2 Actionable (F>0.6) ΔF Gain
0 µs1.0070.993✓✓—
10 µs0.6020.892✓✓+0.290
15 µs ⚑0.4900.659✗ fails here✓ still active+0.169
20 µs0.3900.617✗✓+0.227
25 µs0.4400.709✗✓+0.269
30 µs0.3740.651✗✓+0.277

⚑ Crossover point. Source: Zenodo DOI 10.5281/zenodo.19778714 · Job IDs publicly verifiable on IBM Quantum

Validated Architecture

Three independent pillars
of experimental evidence.

Each pillar was validated independently on IBM Quantum hardware with publicly verifiable job IDs. Together they form a complete platform claim — from single-module foundation through 116-qubit scale to runtime control.

I

Y⊗Z Stabilizer Foundation

The Z⊗Y⊗Z protected stabilizer subspace is orthogonal to the dominant Z-axis dephasing noise on IBM superconducting transmon hardware. Validated at 4-qubit scale with F > 90% fidelity and Z-orthogonality confirmed.

90.4%
Primary stabilizer fidelity
4.86σ
Topology correlation significance
II

116-Qubit Modular Scaling

The protected stabilizer architecture scales across 29 independent 4-qubit modules on IBM Kingston (156-qubit Heron r3) with minimal fidelity degradation and verified module independence.

89.4%
Average fidelity at 116 qubits
99.1%
Module independence
III

Runtime Refresh Primitive

Midpoint stabilizer-frame refresh preserves controller-actionable signal through 30 µs where static hold fails by 15 µs. Validated across full delay sweep with matched controls isolating the refresh mechanism.

2×
Actionable window extension
6/6
Delays where refresh beats static
Published Research

Seven records. One continuous narrative.

Every experiment is publicly archived on Zenodo with IBM Quantum job IDs independently verifiable. The research program runs from anomaly detection through to validated runtime primitive — February through April 2026.

February 5, 2026
Y⊗Z parity-triangle consistency & topology-dependent error correlations
First detection of structured non-random error correlations at 4.86σ significance on IBM Heron r2. Established the foundational anomaly that drives the research program.
DOI 10.5281/zenodo.18498540
February 6, 2026
Non-Markovian error dynamics — spatial correlations & environmental memory
Characterised ~30 µs environmental memory timescale. Temporal memory at 2.8σ. Established the hardware physics that motivates the refresh primitive.
DOI 10.5281/zenodo.18501679
April 9, 2026
116-qubit modular scaling on IBM Kingston
89.39% average fidelity across 29 independent modules on IBM Kingston Heron r3. Demonstrated platform-scale viability with 99.1% module independence.
DOI 10.5281/zenodo.19478241
April 10, 2026
Protected-plane coherence lifetime & stabilizer refresh
F > 80% through ~15 µs. Non-Markovian revival at 25–30 µs. Refresh outperforms passive hold across the 2–50 µs window. First measurement of the actionable lifetime.
DOI 10.5281/zenodo.19501961
April 21, 2026
Hybrid decision workflow — controller actionability primitive
Refresh-cadenced re-injection keeps Y⊗Z stabilizer signal above controller threshold at 15 µs where passive hold fails. First application-layer result.
DOI 10.5281/zenodo.19697551
April 25, 2026
Dynamic stabilizer-frame rotation — candidate runtime primitive
Dynamic rotation of Z⊗Y⊗Z frame combined with refresh shows +23.9% plane fidelity improvement at 15 µs. Introduced rotation as hypothesis for mechanism investigation.
DOI 10.5281/zenodo.19774443
April 25, 2026 Latest
Delay sweep with matched controls — refresh validated as dominant mechanism
Full 0–30 µs sweep with static refresh control confirms: refresh is the dominant mechanism. C2 static refresh alone remains actionable at F>0.6 through 30 µs where static hold fails at 15 µs. Rotation does not add independent value in this implementation.
DOI 10.5281/zenodo.19778714
System Design

Five-layer runtime architecture.

QuantaCore separates developer API, runtime scheduling, classical AI inference, quantum control orchestration, and hardware execution into distinct layers with strict safety boundaries. Layers 0–3 are implemented and tested. Layer 4 QPU wiring is Phase 5.

Layer 0 — Developer Surface
QuantaCoreAPI
Four clean callables: run_with_refresh(), route_to_best_module(), abstain_if_below_threshold(), warm_up(). Batch execution, context manager, telemetry integration. Five-line usage pattern. 198 tests passing.
api.py
v0.2.0-alpha
Layer 1 — OS Kernel
Runtime Scheduler + Telemetry
Three-decision scheduler (RUN_NOW / REFRESH_FIRST / DEFER) with multi-module selection across candidate qubit regions. Priority queue. Structured JSONL event logging with automatic drift detection. Session viewer with six report types.
scheduler.py
telemetry.py
Layer 2 — Classical Inference
SSM Inference Engine
State-space model estimates hidden noise dynamics from hardware measurements. Implements honest abstention — explicitly declines to route when evidence is insufficient. Runs entirely on CPU. Never touches qubits.
Evidence-based
abstention logic
Layer 3 — Orchestration
Q-HAL™ Control Plane
Quantum Hardware Abstraction Layer. Receives AI recommendations, applies safety validation, orchestrates stabilizer refresh cycles, and manages the protected-plane runtime primitive. Acts as safety buffer — overrides AI if confidence is below threshold.
Refresh primitive
management
Layer 4 — Quantum Hardware
Hardware Execution
Executes validated quantum operations specified by Q-HAL. Platform-agnostic — designed for IBM Quantum, Google, and IonQ. Hardware never receives AI instructions directly. Primary validation on IBM Kingston (Heron r3, 156 qubits).
IBM · Google · IonQ
platform-agnostic
Safety architecture: API receives developer intent (Layer 0) → Scheduler selects module and timing (Layer 1) → AI observes and recommends (Layer 2) → Control plane validates and decides (Layer 3) → Quantum hardware executes primitives (Layer 4). Strict separation ensures AI never directly manipulates quantum states. All decisions occur between circuit executions, not during coherence.
Market Position

A basic single-tenant
Quantum Runtime OS alpha.

QuantaCore adds a runtime control layer above IBM Qiskit, Google Cirq, and all major platforms — focused on structured observables on near-term hardware. The stabilizer-frame refresh primitive operates at the multi-qubit observable geometry level, distinct from single-qubit dynamical decoupling and not present in any published platform toolkit. The current scope is single-tenant, single-process, alpha. Multi-tenancy follows as the next engineering milestone.

Standard Quantum Platforms

IBM Qiskit · Google Cirq · Microsoft Q#
  • Prepare → Execute → Measure (one-shot)
  • Static compilation at circuit design time
  • Dynamical decoupling at single-qubit level only
  • No runtime structured observable management
  • No evidence-based controller actionability metric
  • No stabilizer-frame refresh primitive
  • No OS-level scheduling or telemetry
  • Signal lifetime: hardware-limited (~15 µs on Heron r3)

QuantaCore — Runtime OS Alpha

Basic · Single-tenant · Single-process · Structured observables
  • Runtime adaptive stabilizer management
  • Multi-module scheduling with health-based routing
  • Controller-actionability threshold monitoring
  • Evidence-based abstention — safe by default
  • Stabilizer-frame refresh extends signal to 30+ µs
  • Structured telemetry with drift detection
  • Developer API: five-line usage pattern
  • 198 passing tests · no QPU required for development
Patent Protected
U.S. Patent Application No. 19/643,807 (filed April 10, 2026), claiming benefit of Provisional Application No. 63/952,786 (filed January 2, 2026). Covers the stabilizer preparation sequence, basis migration protocol, and stabilizer-frame refresh primitive. All published datasets are non-enabling with respect to the patented methodology.

Interested in where this is going?

QuantaCore is a basic single-tenant Quantum Runtime OS alpha for structured observables on near-term hardware — validated science, working software stack, 198 passing tests. Real-QPU API wiring is the explicitly stated next phase. Available for strategic partnership, technical evaluation, and research collaboration. All hardware results independently verifiable on IBM Quantum.