Moving visuals on this page — measured at 0.26% brightness change per frame and zero flashes per second; your reduce motion setting stops them. What moves, and how it was measured

Mathematical plates that draw themselves — prime counts, orbits and lattices rendered live rather than shipped as pictures. It runs continuously while on screen, and it pauses on its own whenever it scrolls out of view.

We measured it rather than guessing: the largest frame-to-frame change in average brightness is 0.26%, and it produces zero flashes per second against the threshold of three set by WCAG 2.3.1. That is well under the limit, and it is not a promise about any individual: if moving images are a problem for you, you should not have to assess ours.

Everything animated on this site honours your system’s reduce motion setting — turn it on in your operating system or browser and these pages stop moving, with nothing else lost. All the mathematics is in the text and the still figures.

Entry 6 of 7 in Numbers & structure Read itMeasured

Quantum hardware, real runs Numbers & structure

GHZ and cluster-state circuits executed on real IBM Quantum hardware

?

Math: quantum states as vectors in a complex Hilbert space — GHZ and cluster states are specific, well-studied entangled states, not a marketing term. Dev: these are recorded outcomes of real hardware runs, not a live call and not a local simulator. The page fetches nothing: every count was produced on ibm_kingston on the date shown and is served as static data (each run is listed with its job identifier, and the fraction that landed on the two ideal strings is tabulated below, per run). That is deliberate rather than a shortcut — a live submission needs an IBM credential, and a public page cannot hold one without handing it to every visitor; jobs also queue for minutes to hours, so there is nothing a page load could usefully wait for. What makes this checkable is not a network request you can watch, it is the job identifiers: each one is a real IBM Quantum job identifier, recorded exactly as IBM assigned it; the counts on this page are the ones those jobs returned.

Not a simulator, not a screenshot. Backend ibm_kingston (156-qubit superconducting processor), run on 2026-07-29, 4096 shots per circuit via IBM Quantum Runtime (SamplerV2). Each identifier below is exactly what IBM's own systems assigned to that job — click one to copy it. For confidentiality, the full manuscript and its citations aren't reproduced here; this is the hardware provenance, not the paper.

GHZ(3), run 1d9kuc78ii2cc73egnv4g
GHZ(3), run 2d9kukujhdfks73ck7g0g
GHZ(3), run 3d9kul9bjf64c739iolog
GHZ(4)d9kumsqbr2fc73e7tsvg
GHZ(5)d9kuolabr2fc73e7tvf0
GHZ(6)d9kv0tibr2fc73e7udjg
GHZ(7)d9kv4ojjf64c739ipdgg
GHZ(3), control (qubits 118–129–128)d9l04c8ii2cc73egqna0
Cluster state K₀ (n=4)d9kveiibr2fc73e7v8k0
Cluster state K₁ (n=4)d9kvfcibr2fc73e7vacg
Cluster state K₂ (n=4)d9kvgr0ii2cc73egprug

What the counts say, one number per run: an exact GHZ circuit returns only the all-zeros and all-ones strings, so the fraction of the 4096 shots that landed on those two is the plainest measure of how noisy the run was. It falls as the circuit grows, which is the noisy middle described on the front page. Computed from the published counts at build time, not typed in.

GHZ(3) — shots on 03 or 133867 / 4096 = 94.4%
GHZ(4) — shots on 04 or 143812 / 4096 = 93.1%
GHZ(5) — shots on 05 or 153755 / 4096 = 91.7%
GHZ(6) — shots on 06 or 163644 / 4096 = 89.0%
GHZ(7) — shots on 07 or 173616 / 4096 = 88.3%