Local Simulation vs Real Quantum Hardware
The Quantum Hub runs entirely in the browser. The Resilience Lab and the SatMesh preview use a noiseless statevector simulator written in JavaScript. No job is sent to a quantum processing unit, and no cloud quantum API is called. This article describes what that design choice makes possible and what it deliberately leaves out.
What a local noiseless simulator does
A statevector simulator stores the complex amplitudes of every computational-basis state. For six qubits that is 64 amplitudes. Applying a gate multiplies those amplitudes by the corresponding unitary. Measurement draws bitstrings according to the Born rule. Because the simulation is noiseless, every gate is applied exactly as written; there is no decoherence, readout error, or cross-talk. The classical optimizer that adjusts the QAOA angles also runs locally. The only network traffic is the ordinary loading of the page and its assets from the website host.
What real hardware would add
A physical quantum processor introduces noise, limited connectivity, calibration drift, queue time, and a cost or access control. Results from hardware are statistical estimates that must be compared with error-mitigation techniques or with a noise-aware simulator. The Hub does not perform those steps. It also does not claim that the circuits it shows would produce the same distribution on any particular device. The arXiv reference on the lab page points to the original QAOA paper; it is not a claim that the browser run matches a hardware experiment.
Why the Hub stays local for this prototype
Local execution keeps the research preview free of external accounts, API keys, and variable queue latency. It also makes the full statevector available for verification: the test suite checks energies, gate references, and reproducibility against a seeded random number generator. Those checks would be harder to perform if the only output were a set of hardware shots. For a teaching and verification size of six qubits, exact simulation is both feasible and preferable.
How to read the lab with this boundary in mind
When the lab reports a feasible fraction, a best coverage score, or an energy, those numbers come from an ideal circuit. They are useful for understanding the algorithm and for confirming that the implementation matches its specification. They are not device benchmarks, noise characterizations, or evidence that the same circuit would run successfully on a quantum processor. The page states the boundary directly: ideal noiseless simulation, no hardware noise, no production network protection.
The local simulator is a deliberate scope decision. It lets the Hub show working QAOA mechanics and honest classical comparisons without requiring quantum hardware access.