How a paper is checked
- Run their code. Each paper's artifact is run as its authors ran it, and every operation it schedules (each split, move, junction crossing, merge and gate, with its start and end time) is written out.
- Rebuild their machine in our language. The traps, junctions and segments become an architecture document, priced by the paper's own timing table.
- Replay under their rules. Each paper's model is written as a rule set: one assertion per rule about the machine and the schedule, such as where every ion is, trap capacity at every instant, one ion per rail and per junction, one operation per trap, which end of a chain an ion leaves from, how long each operation takes, and whether the gates run are the circuit's. The schedule is replayed event by event and every rule of the set evaluated on it; each paper's page lists every run against every rule.
- Compare three numbers. What their code printed, what our replay measures (these must be identical), and what the paper reports.
- Then schedule it ourselves. The same circuit on the same machine, checked by the same checker under the same rules, more strictly: an operation the paper's timing law does not price is refused, and every qubit keeps the circuit's gate order. The schedule comes from a scheduler we wrote for that paper's model, each named on its page; only H2's circuits are compiled by this website's own compiler, which works in our stricter machine model.
The rules are each paper's, not ours. Our own machine model is stricter in places (one waveform per cycle, gates and transport never in the same cycle), and under it most of these schedules would not be legal at all; that is a different question, and it is not the one asked here.
The same goes for the Studio pages. Each replayed run opens in the Studio as a programme in our language, and the Studio plays it one instruction at a time (the operations of one kind that start together), so the runtime it shows is its instructions added up. Its Report shows the paper's rule set first, as the replay judged the run, and then this website's own rules, which the paper did not assume. Where a paper's operations overlap in time, that sum is longer than the schedule; the time that is checked, and compared, is the one in the tables, on the paper's clock.
The rules each paper's model has
✓ the paper's model has the rule, and every replay is held to it; (✓) only some of its configurations do; – the paper's model does not have it, so it is not checked. Each rule is written out on the Rules page.
| rule | QCCDSim | Muzzle the Shuttle | Cyclone | Surface-code QCCD | TISCC | Position Graph | Moveless | TrapSIMD | MQT IonShuttler |
|---|---|---|---|---|---|---|---|---|---|
| R0 Every operation finds its ions where it says they are | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| R1 A site holds at most its capacity | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| R2 A junction holds one ion at a time | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | (✓) |
| R3 A rail carries at most its capacity | ✓ | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | (✓) |
| R6b A two-ion gate acts on two ions standing in one site | ✓ | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | – |
| R8 An ion does one thing at a time | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| R14 A split takes the ion at the end of its chain, or pays to reorder | ✓ | ✓ | (✓) | ✓ | – | ✓ | ✓ | – | – |
| R24 Every two-qubit gate of the circuit is performed, and no other | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| R25 Each qubit's operations keep the circuit's order | ✓ | ✓ | (✓) | – | – | ✓ | – | – | ✓ |
| R26 Each qubit's gates keep the circuit's order, up to commuting CNOTs | – | – | (✓) | ✓ | – | – | – | ✓ | – |
| R27 One operation at a time in a trap | ✓ | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | – |
| R29 Every operation lasts what the clock says | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| R30 Operations that hold the same component never overlap | – | – | – | ✓ | – | – | – | – | – |
| R31 Broadcast transport moves in lockstep | – | – | – | – | – | – | – | ✓ | – |
| R32 Single-ion operations run only in the zones the model allows | – | – | – | – | ✓ | – | – | – | – |
| R33 A two-ion gate acts on ions in one zone or in neighbouring zones | – | – | – | – | ✓ | – | – | ✓ | – |
A note on a paper is written only when running its code shows it.
Papers we read and did not reproduce
Every one of these was read in full, with its code where there is any. A paper is reproduced only when its machine, its timing and its circuits can be pinned down well enough that a mismatch would mean something.
| paper | why it is not here |
|---|---|
| S-SYNC arXiv:2505.01316 | No code and no results tables; the headline gains cannot be recomputed from the paper's own figures, and its two baselines need internals it does not publish. |
| Ovide et al. (three QCCD resource studies) arXiv:2408.00225 | No code or data; timing, heating and fidelity parameters are not stated. |
| Kreppel et al. and the Mainz linear-trap compilers arXiv:2207.01964 | Results are operation counts from an unpublished shuttling compiler on circuits that are not published; only one 16-operation reference schedule could be replayed. |
| Lee et al., QEC ion-trap chip arXiv:2501.15200 | No results tables; the available code is an earlier version with different constants and emits only logical-level, randomised schedules. |
| TILT arXiv:2010.15876 | Its machine moves the whole chain under a fixed laser window, a primitive our language does not express; no code is published. |
| WISE wiring arXiv:2305.12773 | A hardware wiring paper whose results are closed-form counts and worst-case reconfiguration times; there is no schedule to replay. |