Quantum computing & circuit laboratory

Small circuits, honest provenance.

The project's quantum layer today is infrastructure: generating and compiling small parameterized circuits, an abstraction that separates the engine from its state source, and AWS Braket task endpoints. Using verified quantum measurements to drive the manifold is the research goal — not a demonstrated result.

No quantum hardware results are shown on this page. Everything in the lab below is an ideal, noiseless statevector simulation computed in your browser. Noisy simulation and hardware execution are separate categories and appear only when real records exist.

Circuit generation

Qubits

Layers 3

Redundancy (for the optimizer to find) 0.40

Seed

Shots

Compilation passes

Merge adjacent same-axis rotations: R(a)·R(b) → R(a+b)
Cancel adjacent self-inverse pairs: H·H, X·X, CX·CX
Remove identity rotations (θ ≡ 0 mod 4π)

Applied to a fixed point. “Adjacent” means no other gate acts on those qubits in between.

Original circuit

Generated in browser

Optimized circuit

Gate counts

Metric	Original	Optimized	Δ

Min fidelity (test inputs)—

TVD ideal outputs—

Equivalence is checked numerically on all 2ⁿ basis inputs plus four random superpositions (catches relative-phase errors). It is a numerical check, not a formal proof, and says nothing about behaviour under noise.

Output distributions

original · idealoptimized · idealoptimized · sampled shots

Bitstrings read qₙ₋₁…q₀. “Sampled shots” are multinomial draws from the ideal distribution — not hardware counts.

Quantum provider abstraction

The engine doesn't care where its states come from.

The architecture separates the computational engine from its state provider. Today the provider is classical (seeded initial conditions). A quantum-backed provider could, in principle, supply initial or driving data derived from measurement results — the intended integration pathway.

// Illustrative sketch — consult the repository for actual signatures
interface StateProvider {
  id: string;                         // "classical-seeded" | "braket-…"
  provenance(): Provenance;           // backend, device, task id, shots
  initialStates(n: number): Vec3[];   // one (x, y, z) per vertex
}

class ClassicalSeededProvider implements StateProvider { … }  // implemented
class QuantumMeasurementProvider implements StateProvider { … } // intended

Abstraction implemented Quantum-backed provider not demonstrated

AWS Braket integration

Task submission & status polling

The repository includes serverless endpoints to submit a circuit as an Amazon Braket task and poll its status. Real execution requires AWS configuration held server-side — credentials never reach the browser.

Submit task	POST /api/braket/submit
Poll status	GET /api/braket/status?taskId=…

Paths shown are configurable defaults — verify against the repository's api/ directory.

Required configuration (server-side)

AWS access key ID & secret access key (IAM role with Braket permissions)
AWS region supported by the target device
S3 bucket / prefix for task results
Device ARN (managed simulator or QPU)

Deployment base URL (e.g. your Vercel deployment)

Not configured on this site

Quantum task records

Simulator and hardware kept separate · backend · device · status · provenance

Task	Backend	Device	Status	Shots	Provenance	Submitted
Loading records…

Future quantum feedback

The intended research pathway

Each arrow is a claim that needs evidence. The chain as a whole is an intended integration until an end-to-end run has been demonstrated and recorded.

ExternalQuantum taskCircuit submitted to a Braket device.

Not demonstratedVerified measurement resultsCounts with backend, device, shots, task ID.

Interface existsClassical state-providerMaps measurements to vertex states.

ImplementedDynamical evolutionCoupled Lorenz RK4 on the mesh.

ImplementedAdaptive manifold updateValidated, ΔJ-gated edge flips.

ImplementedMeasured objectiveJ recorded against matched baselines.

Category	What it is	What it can't show
Ideal simulation	Exact statevector math, no noise	Anything about real devices, noise robustness or advantage
Noisy simulation	Simulation with an assumed noise model	Results are only as good as the noise model's assumptions
Hardware execution	Counts from a physical QPU with provenance	Advantage, unless compared against strong classical baselines

Not claimed: quantum computational advantage, fault-tolerant behaviour, or error protection arising from the manifold.