The Quantum Bridge

Simplex is not becoming a quantum programming language. It's becoming a language that knows when to use a quantum processor, how much it will cost, and whether the result is trustworthy. Version 0.14.0 introduces the Quantum Bridge—a hybrid classical-quantum architecture where classical AI workloads run on CPUs and GPUs as they do today, while specific subproblems that benefit from quantum speedup are offloaded to cloud QPU services. The dispatch decision is cost-aware. The gradient computation uses dual numbers. The measurement uncertainty flows into the epistemic belief system. All of it is pure Simplex.

---

Why Hybrid, Not Quantum

The quantum computing industry has a narrative problem. The headlines promise revolution. The hardware delivers noisy intermediate-scale processors with dozens to hundreds of qubits, limited coherence times, and error rates that make long circuits unreliable. Building a "quantum programming language" today means building for hardware that doesn't exist yet.

The honest engineering question isn't "how do we go quantum?" It's "which specific subproblems benefit from quantum acceleration on today's hardware, and is the cost justified?"

Simplex answers this with a hybrid bridge. Your classical code—the training loops, the actor systems, the cognitive hives—stays exactly where it is. When a computation hits a problem with the right structure (combinatorial optimization, molecular simulation, certain search problems), the bridge can offload it to a quantum processor. When it doesn't, it stays classical. The decision is explicit, budgeted, and reversible.

---

When Quantum Is Worth the Cost

Before diving into architecture, let's be honest about where quantum helps and where it doesn't. This decision matrix guides the dispatcher:

The sweet spot for today's NISQ hardware is variational algorithms: VQE for molecular simulation and QAOA for combinatorial optimization. These algorithms are inherently hybrid—a classical optimizer tunes parameters for a quantum circuit, runs it on a QPU, measures the result, and iterates. This is exactly the loop Simplex's dual numbers were built for.

---

Architecture: The Bridge in Three Layers

The Quantum Bridge is structured as three layers, each with a clear responsibility:

Layer 1: Circuit Builder & Gate Library

The foundation is a circuit builder that constructs quantum circuits from standard gates. Circuits are data structures—they don't execute until submitted to a backend.

use quantum::{QuantumCircuit, Qubit, gates};

// Build a Bell state circuit
let circuit = QuantumCircuit::new(2)
    .h(0)           // Hadamard on qubit 0
    .cnot(0, 1)     // CNOT: qubit 0 controls qubit 1
    .measure_all();  // Measure both qubits

// The circuit is just a description - nothing has executed yet
println(circuit.depth());       // 2
println(circuit.gate_count());  // 3 (H + CNOT + measure)

The gate library includes the standard set:

Critically, the parameterized gates (Rx, Ry, Rz, CRz) accept Dual parameters. This means variational circuits carry derivative information natively—no separate parameter management layer required.

Layer 2: Backend Abstraction

A circuit is just a description. To execute it, you submit it to a backend. The QuantumBackend trait abstracts over four implementations:

use quantum::backend::{QuantumBackend, Braket, IBM, Azure, Simulator};

// Local simulator - no credentials, no cost, up to ~20 qubits
let sim = Simulator::new();

// Amazon Braket - Rigetti Ankaa-3, IonQ Aria/Forte, SV1
let braket = Braket::new()
    .credentials(aws_creds)
    .device("arn:aws:braket:::device/qpu/rigetti/Ankaa-3");

// IBM Quantum - Eagle/Heron processors
let ibm = IBM::new()
    .api_key(ibm_key)
    .backend("ibm_brisbane");

// Azure Quantum - IonQ, Quantinuum, Rigetti via marketplace
let azure = Azure::new()
    .subscription(azure_sub)
    .provider("ionq");

// Same circuit, any backend
let job = sim.submit(&circuit, shots: 1000)?;
let result = sim.result(job)?;
println(result.counts);  // {"00": 498, "11": 502}

The trait interface is deliberately minimal: submit, poll, result, cancel, and cost_estimate. Backend-specific details (OpenQASM serialization for Braket, Qiskit runtime for IBM) are isolated inside each implementation. Switch backends by changing one line—not your algorithm.

Layer 3: Cost-Aware Dispatcher

The dispatcher is the brain of the bridge. Given a problem, it analyzes complexity, estimates cost, and decides: classical, quantum, or hybrid?

use quantum::dispatch::{Dispatcher, Budget, DispatchDecision};

let budget = Budget::new()
    .max_spend(50.0)        // $50 USD hard limit
    .warn_at_percent(80);   // Alert at $40

let dispatcher = Dispatcher::new(budget);
let decision = dispatcher.analyze(problem);

match decision {
    DispatchDecision::Classical => {
        // Problem too small or quantum advantage insufficient
        classical_optimizer::solve(problem)
    }
    DispatchDecision::Quantum(backend, device) => {
        // Clear quantum advantage, within budget
        run_variational(backend, problem, budget)
    }
    DispatchDecision::Hybrid(strategy) => {
        // Classical preprocessing, quantum core, classical postprocessing
        let reduced = classical_optimizer::reduce(problem);
        let quantum_result = run_variational(strategy.backend, reduced, budget);
        classical_optimizer::refine(quantum_result)
    }
}

The dispatcher considers four factors: estimated classical runtime, required qubit count, circuit depth, and quantum advantage factor. It supports four policies: always_classical (for testing), always_quantum (for benchmarking), cost_optimized (minimize spend), and quality_optimized (maximize solution quality within budget).

The budget tracker enforces per-session and per-project spending limits. It warns at configurable thresholds and hard-stops at the limit. No silent budget overruns.

---

The Variational Bridge: Where Dual Numbers Meet Quantum Circuits

This is the technical heart of the Quantum Bridge and the reason it belongs in Simplex specifically.

Variational quantum algorithms follow a loop: prepare a parameterized circuit, run it on a QPU, measure the result, compute a classical loss function, compute gradients, update parameters, repeat. The gradient computation is the expensive part—and it's where Simplex's dual numbers provide a natural advantage.

The Parameter-Shift Rule

You can't backpropagate through a quantum measurement. The wavefunction collapses—there's no gradient to propagate. Instead, variational algorithms use the parameter-shift rule: to compute the gradient of a quantum expectation value with respect to a gate parameter θ, evaluate the circuit at θ + π/2 and θ − π/2, then take the difference:

∂f/∂θ = [f(θ + π/2) − f(θ − π/2)] / 2

This requires two additional circuit evaluations per parameter. For a circuit with N parameters, that's 2N QPU calls per gradient step. Expensive—but exact.

Dual Numbers as the Gradient Bridge

Here's where Simplex's existing infrastructure pays off. The parameter-shift rule gives us the quantum gradient. Dual numbers carry that gradient through the classical loss function without any additional machinery:

use quantum::variational::{ParameterizedCircuit, parameter_shift};
use simplex_ad::{Dual, dual_var};

// Circuit with dual-typed parameters
let theta = vec![dual_var(0.5), dual_var(1.2), dual_var(0.8)];

let circuit = ParameterizedCircuit::new(4)
    .ry(0, theta[0])    // Dual parameter flows into gate
    .cnot(0, 1)
    .rz(1, theta[1])
    .cnot(1, 2)
    .ry(2, theta[2])
    .measure_all();

// Parameter-shift gradient on QPU
let quantum_grads = parameter_shift(&circuit, &backend, shots: 1000)?;

// Classical loss with dual arithmetic - gradient flows naturally
let target_energy = dual_var(-1.137);  // H2 ground state
let measured = Dual::new(result.expectation_value(), quantum_grads[0]);
let loss = (measured - target_energy) * (measured - target_energy);

// loss.value  = classical loss
// loss.deriv  = gradient through the entire hybrid pipeline

The quantum gradient (from parameter-shift) and the classical gradient (from dual numbers) compose seamlessly. No tape. No computation graph. No framework boundary where gradients get lost. The hybrid pipeline is differentiable end-to-end.

Integration with Self-Learning Annealing

Variational algorithms are prone to barren plateaus—regions of parameter space where gradients vanish and the optimizer stalls. Self-learning annealing, introduced in v0.9.0, provides a natural escape mechanism. The learnable temperature schedule can detect vanishing gradients and reheat, pushing the variational optimizer out of barren plateaus:

use simplex_training::{LearnableSchedule, MetaOptimizer};
use quantum::variational::{VQE};

let schedule = LearnableSchedule::new()
    .initial_temp(5.0)
    .min_temp(0.01);

let vqe = VQE::new(hamiltonian, ansatz)
    .optimizer(MetaOptimizer::adam(0.01))
    .annealing(schedule)       // Temperature-modulated exploration
    .max_iterations(200)
    .convergence_threshold(1e-6);

let ground_state = vqe.run(&backend, budget)?;

The meta-optimizer adjusts the annealing schedule based on the variational loss landscape. If the optimizer is converging, it cools aggressively. If it detects a plateau, it reheats. The schedule itself is learned via meta-gradients—the same mechanism that optimizes classical hyperparameters now optimizes quantum variational loops.

---

Quantum-Enhanced Optimization

The bridge ships with four optimization modules, each targeting a specific problem class:

QAOA for Combinatorial Problems

The Quantum Approximate Optimization Algorithm encodes combinatorial problems (MaxCut, TSP, scheduling) as QUBO formulations and solves them via alternating layers of problem and mixer unitaries:

use quantum::optimize::combinatorial::{QAOA, MaxCut};

// Encode a graph problem
let graph = Graph::new()
    .edge(0, 1, weight: 1.0)
    .edge(1, 2, weight: 2.0)
    .edge(0, 2, weight: 1.5);

let qaoa = QAOA::new(MaxCut::from(graph))
    .depth(3)           // Number of QAOA layers
    .depth_adaptive();  // Increase depth if quality plateaus

let solution = qaoa.run(&backend, budget)?;
// solution.partition = [0, 1, 0]  (cut value: 3.0)

VQE for Molecular Simulation

The Variational Quantum Eigensolver finds molecular ground states using hardware-efficient ansätze. The Hamiltonian is encoded as a sum of Pauli operators, and the variational circuit minimizes the expectation value:

use quantum::optimize::molecular::{VQE, Hamiltonian, Ansatz};

// H2 molecule at 0.74 Angstrom bond length
let h2 = Hamiltonian::h2(bond_length: 0.74);

let vqe = VQE::new(h2, Ansatz::hardware_efficient(4))
    .optimizer(Adam::new(0.05))
    .shots(4000)
    .max_iterations(100);

let result = vqe.run(&backend, budget)?;
// result.energy = -1.137 Hartree (within chemical accuracy)

Grover-Based Search

For problems with a boolean oracle (constraint satisfaction, database search), Grover's algorithm provides quadratic speedup. The bridge constructs the oracle from Simplex predicates:

use quantum::optimize::search::{GroverSearch};

let search = GroverSearch::new(n_bits: 8)
    .oracle(|x| x * x % 17 == 1)  // Find square roots mod 17
    .optimal_iterations();          // Auto-calculate iteration count

let result = search.run(&simulator)?;

Hybrid Annealing

The bridge between classical simulated annealing and quantum sampling. Classical annealing explores the landscape; when it detects a region worth exploring more deeply, it offloads to quantum sampling for a more thorough search of that region:

use quantum::optimize::hybrid_anneal::{HybridAnnealer};

let annealer = HybridAnnealer::new(objective)
    .classical_steps(1000)
    .quantum_refinement_threshold(0.1)  // Offload when improvement stalls
    .backend(&backend)
    .budget(budget);

let solution = annealer.run()?;

---

Quantum Meets the Cognitive Hive

The Quantum Bridge isn't a standalone library—it integrates with Simplex's cognitive architecture at three points:

1. Meta-Annealing

The highest-ROI integration. Self-learning annealing uses a meta-optimizer to learn cooling schedules. Classical annealing explores this meta-parameter landscape sequentially. Quantum annealing via QAOA can explore it in superposition, finding global optima for cooling rates and temperature bounds that classical search misses.

2. Epistemic Belief Resolution

When specialists in a hive disagree, the dissent phase must resolve conflicting beliefs. This is a constraint satisfaction problem: find an assignment of belief values that maximizes consistency across all specialists. For hives with many specialists and complex belief dependencies, QAOA can solve this faster than classical constraint solvers.

3. Specialist Routing

Assigning tasks to specialists in a cognitive hive is an NP-hard scheduling problem when you account for dependencies, specialist capabilities, and load balancing. The dispatcher can offload routing decisions to QAOA when the hive is large enough to benefit.

Quantum Uncertainty as Epistemic Beliefs

This is perhaps the most elegant integration. Quantum measurements are inherently probabilistic—you get a distribution of outcomes, not a single answer. Simplex's epistemic belief system already handles uncertain knowledge with calibrated confidence levels. Quantum measurement results flow naturally into this system:

use quantum::epistemic::{QuantumEvidence};
use simplex_learning::epistemic::{BeliefStore, Evidence};

// Quantum measurement produces a distribution
let result = backend.result(job)?;
// result.counts = {"00": 498, "01": 12, "10": 8, "11": 482}

// Convert to epistemic evidence
let evidence = QuantumEvidence::from(result)
    .confidence_from_shots()  // More shots = higher confidence
    .noise_adjusted();        // Account for hardware error rates

// Update beliefs with quantum evidence
beliefs.update("ground_state_energy", evidence);
// Belief confidence reflects both shot count and hardware noise

Quantum results aren't treated as ground truth—they're treated as evidence with quantified uncertainty. The belief system integrates them alongside classical evidence, weighing confidence based on shot count, hardware noise characteristics, and consistency with existing beliefs.

---

The Local Simulator

Not everyone has QPU credentials or a research budget. The local statevector simulator enables full development and testing without cloud access:

• Exact statevector evolution via matrix multiplication on complex arrays
• Up to ~20 qubits (~16MB for 2²⁰ amplitudes)
• Optional shot sampling for realistic noise simulation
• Same QuantumBackend trait—switch to real hardware by changing one line

The v0.13.0 complex number and matrix modules are the foundation here. Quantum state vectors are complex arrays. Gate application is matrix multiplication. The Kronecker product composes single-qubit gates into multi-qubit operations. All of this was shipped in 0.13.0 as "mathematical foundations"—now it's clear what those foundations were for.

---

Module Layout

The entire Quantum Bridge is pure Simplex. No Python. No Qiskit. No Cirq. No external quantum frameworks. Backend communication uses Simplex's HTTP client and JSON parser (both shipped in v0.13.0).

---

Implementation: Eight Phases, ~13,700 Lines

The Quantum Bridge ships across eight phases, each with clear success criteria:

---

Risks and Honest Constraints

Quantum computing is surrounded by hype. Here's what can actually go wrong:

• NISQ noise: Current quantum hardware is noisy. Results are approximate. The epistemic belief system mitigates this by treating quantum results as uncertain evidence rather than ground truth, but noise still limits circuit depth and solution quality.
• QPU availability: Cloud quantum services have queues and scheduled downtime. The backend abstraction handles this via job polling and automatic fallback to classical methods when quantum resources are unavailable.
• Cost management: A poorly configured variational loop can exhaust a budget in hours. The budget tracker is safety-critical infrastructure, not a convenience feature.
• API instability: Cloud QPU APIs change. The trait-based backend design isolates API-specific details so that a Braket API change requires updating one file, not every algorithm.

None of these are showstoppers. All of them require engineering discipline. The Quantum Bridge is designed to make the discipline structural—enforced by the type system, the dispatcher, and the budget tracker—rather than relying on developers to remember.

---

Why This Belongs in Simplex

You could build a quantum computing bridge in any language. Here's why it belongs in this one:

1. Dual numbers provide exact forward-mode autodiff for variational parameter gradients. No tape, no graph, no framework boundary. The parameter-shift rule gives the quantum gradient; dual numbers carry it through the classical loss function. End-to-end differentiability without glue code.
2. Self-learning annealing provides learnable temperature schedules that can detect and escape barren plateaus in variational optimization. This is a real problem in VQE and QAOA that most quantum frameworks don't address.
3. Epistemic beliefs provide a principled framework for handling quantum measurement uncertainty. Shot-based statistics map directly to confidence levels. Quantum results become evidence to be weighed, not answers to be trusted blindly.
4. The actor model provides natural concurrency for managing multiple QPU jobs. A hive can submit jobs to different backends simultaneously, with the supervisor handling failures and the scheduler managing completion callbacks.

These aren't features bolted on for quantum support. They're features that existed for classical AI and happen to be exactly what variational quantum computing needs. The Quantum Bridge is the natural extension of infrastructure that was already in place.

---

Getting Started

The Quantum Bridge will ship with v0.14.0. In the meantime, the mathematical foundations are available in v0.13.0:

// Available now in v0.13.0
use simplex_std::complex;     // Complex amplitudes
use simplex_std::matrix;      // Gate matrices, Kronecker products
use simplex_ad::diff;         // Gradient, Jacobian, Hessian

// Coming in v0.14.0
use quantum;                  // Circuit builder, gate library
use quantum::backend;         // Simulator, Braket, IBM, Azure
use quantum::variational;     // VQE, QAOA, parameter-shift
use quantum::dispatch;        // Cost-aware dispatcher
use quantum::optimize;        // Quantum-enhanced optimization

Most quantum programming frameworks ask you to learn a new paradigm. Simplex asks a different question: what if quantum computing was just another backend your existing code could dispatch to when the problem justified the cost? The Quantum Bridge is that question, answered in ~13,700 lines of pure Simplex.