A quantum computer can factor commercially relevant RSA cryptographic keys faster than any classical computer.
Verification position derived from the record’s assessments; dates show when Faultline first recorded each stage.
Causal mechanisms recorded for this claim. The State Warrant above remains the authoritative current assessment.
The engineering gap — three to four orders of magnitude. The Gidney-Ekerå estimate requires approximately 20 million physical qubits for 2048-bit RSA factorisation. Current systems have hundreds to low thousands. The gap is not merely quantitative — scaling by three to four orders of magnitude in qubit count while maintaining below-threshold error rates and the necessary connectivity involves engineering challenges that are not simply extensions of current work. Crosstalk, control complexity, fabrication yield, and classical control overhead all scale non-linearly. The resistance mechanism is not that the gap is unbridgeable in principle, but that it is not bridgeable on any near-term timescale without engineering advances that have not yet been demonstrated even in prototype form.
Classical algorithm improvement. The claim requires factoring RSA keys faster than any classical computer. Classical factorisation algorithms continue to improve. The general number field sieve has been optimised continuously since 1990. If classical algorithms improve substantially — through better mathematical insights, specialised hardware, or distributed computing advances — the bar for quantum advantage in this specific application rises. The claim is a race; the classical side of the race is not standing still. The resistance mechanism is therefore not just about quantum hardware but about the relative improvement rate of both sides.
Sequential substrate dependency. This claim cannot be satisfied until FR-QE-0003 (scaling behaviour) and FR-QE-0004 (below-threshold operation) are not merely demonstrated but extended to the scale required. The claim sits at the top of the PROG-QE capability stack; it is the last claim to be satisfiable, dependent on all substrate claims being satisfied first at sufficient scale. This is a sequential dependency bottleneck similar to FR-AM-0004's BN-001, but with a higher and more precisely quantified requirement. The bottleneck is not ambiguous — the Gidney-Ekerå estimate provides a specific qubit and error rate target — but the engineering path to that target is long and undemonstrated at the required scale.
Demonstration of fault-tolerant logical qubit count at hundreds, then thousands. The specific milestones that would move this record from ESCALATING toward RESOLVING are stepwise: demonstration of 100 fault-tolerant logical qubits at below-threshold error rates, then 1000, then 10,000. Each milestone narrows the engineering gap by approximately one order of magnitude. No single experiment resolves the claim; it resolves through a series of engineering milestones, each of which is a necessary but not sufficient condition. The attractor is therefore a progression rather than a single event, distinguishing it from the attractors in FR-QE-0003 and FR-QE-0004.
Historical narrative recorded for this claim. It does not override the current State Warrant.
Questions retained in this record. The current State Warrant may have narrowed or reframed earlier questions.
What is the realistic timeline for reaching the Gidney-Ekerå qubit count? Current hardware roadmaps from IBM, Google, and Microsoft project millions of physical qubits within 10–15 years, but roadmap projections have historically been optimistic. The engineering challenges at 20 million qubits are not simply extensions of current work.
Raised 2024-01-15INST-004 (NIST PQC standards) is the second occurrence of anticipatory institutional evidence as an evidence object type (the first was FR-AM-0004 INST-003, the Helion/Microsoft contract). The corpus now has two instances. Whether anticipatory institutional acts constitute evidence for a claim — and at what weight — is a recurring question that may warrant attention before a third occurrence.
Raised 2024-01-15This claim sits at the top of the PROG-QE capability stack and depends on all substrate claims being satisfied first. If FR-QE-0003 or FR-QE-0004 encounter unexpected obstacles at larger scales, this claim's trajectory changes without any direct evidence bearing on it. How should a record respond when its substrate records encounter setbacks? No governed procedure exists.
Raised 2024-01-15IN-006 documents three independent downward revisions to the RSA/ECC resource estimate within roughly eighteen months, compared with one major revision in the preceding decade. Is this pace itself evidence of anything — a maturing theoretical toolkit converging on a real figure, or a sequence of estimates each exploiting a different unproven architectural assumption (surface codes, then QLDPC codes, then a third approach not yet proposed)? Until a fourth estimate either confirms or breaks the trend, this question cannot be answered from the evidence available at AS-002.
Raised 2026-06-29| Mutation | Date | Field | Prior value | Current value |
|---|---|---|---|---|
| M-013 | 2026-09-06 | description_restored | Legacy ingestion cutoffs: mechanisms:RM-001, mechanisms:RM-002, mechanisms:BN-001, mechanisms:AT-001 | Source-restored complete descriptions |
| M-012 | 2026-07-09 | description_reordered | — | DESCRIPTION-REORDERED |
| M-011 | 2026-07-08 | reference_corrected | — | REFERENCE-CORRECTED |
| M-010 | 2026-07-08 | realization_note_added | — | REN-001 |
| M-009 | 2026-06-29 | open_question_raised | — | OQ-RAISED |
| M-008 | 2026-06-29 | assessment_issued | AS-001 | AS-002 |
| M-007 | 2026-06-29 | instances_logged | — | INSTANCES-LOGGED |
| M-006 | 2024-01-15 | programme_panel_added | — | PROGRAMME-PANEL-ADDED |
| M-005 | 2024-01-15 | null_condition_met | — | NULL-CONDITION-MET |
| M-004 | 2024-01-15 | mechanisms_recorded | — | MECHANISMS-RECORDED |
| M-003 | 2024-01-15 | assessment_issued | — | ASSESSMENT-ISSUED |
| M-002 | 2024-01-15 | instances_logged | — | INSTANCES-LOGGED |
| M-001 | 2024-01-15 | record_created | — | RECORD-CREATED |