Internal LLM Proof Draft for a Long-Standing Conjecture Passes Formal Verification

A recent case that deserves attention from the technical community emerged in public discussion: a research team used a non-public internal large model to produce a proof draft for a long-standing open conjecture in quantum computing complexity within days, and then completed machine checking with an interactive theorem prover. The significance of this case is not whether a model can solve math problems. Rather, it demonstrates a new discovery process: the large model explores, associates ideas, and generates proof drafts; formal tools convert natural-language reasoning into machine-checkable propositions and proofs; and the result forms an auditable, reproducible, and iterable verification loop.

For developers and enterprise technical teams, the more important question is the engineering method behind this process: how to embed unreliable generative capabilities into a reliable verification system, how to design human-machine collaboration boundaries, and how to avoid misreading a single high-intensity internal model demonstration as general production capability.

1. Event Abstraction: From “Model Answers” to “Verifiable Discovery”

Traditionally, the performance of large models on mathematical and logical tasks has often been questioned: natural-language proofs may look fluent but can contain hidden skipped steps, incorrect lemmas, or circular reasoning. The key change in this case is that the proof result did not stop at “looking correct in text” but entered formal verification. Formal verification requires theorem statements, definitions, lemmas, and proof steps to be written in a machine-checkable form and verified item by item by a proof checker. As long as the checker and its logical foundation are trusted, the correctness of the proof no longer depends on the subjective judgment of reviewers.

This brings an important engineering paradigm shift: the large model is no longer the final judge but a candidate generator for proof search and draft generation; the verifier is not an auxiliary tool but the final gate. The model can make mistakes, but mistakes must be intercepted by the verifier. For complex system development, this is highly similar to “generated code + automated tests + static checks + human audit,” except that the object under test is now a mathematical proof.

2. Why Formal Verification Is a Watershed

Formal verification has three core values. First, it reduces hallucination risk. Phrases such as “obviously” and “by the same reasoning” in natural-language proofs are where errors most easily hide, while formal proofs must explicitly provide the justification for every step. Second, it improves auditability. Proof scripts, dependency libraries, checker versions, and runtime environments can all be placed under version control, forming a traceable evidence chain. Third, it supports incremental collaboration. Once a lemma is verified, it can serve as a reliable building block for later proofs, and teams can divide work around failed goals instead of repeatedly arguing about whether an entire proof holds.

However, formal verification is not a panacea. It can only guarantee that “the formal statement is proved,” not automatically guarantee that “the formal statement faithfully expresses the original mathematical intuition.” If the theorem statement is written incorrectly or definition boundaries are omitted, the verifier will still accept a correct proof of an incorrect proposition. Therefore, a high-quality process must include a comparison step across “informal statement—formal statement—independent review.”

3. How to Interpret Differences Between Internal and Public Models

The case emphasizes a non-public internal model. Typically, an internal version may be more fully provisioned in inference budget, tool calling, post-training feedback, long-context organization, and integration with the verification loop; a public version is constrained by cost, latency, safety, and generality, so its capability may differ. But it must be emphasized that one case cannot be used to infer that a certain class of models already has general mathematical discovery capability. Specific differences should be based on official disclosures and reproducible experiments.

For teams, what can be learned is not “pursuing a particular internal version” but building a capability portfolio: a strong reasoning model proposes lemmas and proof strategies; a retrieval system locates relevant definitions and existing results; formal tools perform checking; an orchestration layer handles failure retries and task decomposition; and logs and monitoring preserve evidence.

4. A Reusable Technical Workflow

A practical closed loop can be abstracted into the following pseudocode:

Input: problem description, existing definitions, target proposition
1. Generate an informal proof draft and a list of key lemmas
2. Formalize the target proposition and lemmas as machine-checkable statements
3. Invoke the proof checker to verify the formal statements and proof scripts
4. If verification fails, collect error locations and counterexample hints, and feed them back to the model
5. The model revises the proof or splits lemmas, then enters the next round
6. After verification passes, perform independent review: faithfulness of statements, dependency boundaries, reproducibility
7. Archive proof scripts, environment information, failure paths, and audit records

The key to this workflow is “verification in small steps.” Do not generate a complete large proof at once; instead, verify definitions and simple lemmas first, then gradually expand the scope. Failure information should be returned in a structured way, such as error line numbers, unmet goals, and type mismatches, rather than simply telling the model “wrong.” At the same time, failure paths should be retained, because failed attempts often reveal incorrect assumptions.

5. Implications and Boundaries for Quantum Computing Complexity

The long-standing conjecture involved in this case concerns whether quantum computing has an exponential advantage over classical computing under a specific computational model. If the relevant proof holds, its value is primarily theoretical: it can provide stronger evidence for the complexity classification of “quantum advantage” and help researchers understand the conditions under which quantum algorithms may achieve exponential speedup.

But a distinction must be made between “theoretical separation” and “engineering usability.” An exponential advantage in a theoretical model is not equivalent to an exponential speedup runnable on real hardware; the latter is also affected by noise, error-correction overhead, compilation optimization, data loading, and problem instance distribution. Therefore, the case should be read as “combining formal methods with large models may improve the efficiency of theoretical proofs,” not as “quantum computing will immediately and comprehensively outperform classical computing.”

6. Engineering Lessons for Developers and Enterprise Teams

First, put generative capabilities inside a verifiable loop. For any high-risk output, automated checks, static analysis, tests, or formal specifications should be configured rather than relying on human reading. Second, specification first. The quality of formal statements determines the value of verification, and teams should include definitions, boundary conditions, and counterexamples in specification review. Third, build a tool orchestration layer. Models, retrieval, checkers, logs, and alerts should be managed by unified orchestration to avoid manual copy-paste. Fourth, pay attention to cost and latency. Multi-round proof search may consume substantial compute, so budgets, timeouts, and tiered retries should be set. Fifth, preserve audit evidence. Proof scripts, checker versions, dependency locks, and environment snapshots should all be archived.

7. Risks, Governance, and Implementation Recommendations

Main risks include model hallucination leading to incorrect lemmas; formal statements that are inconsistent with the original problem; trust boundaries of the verifier or dependency libraries that have not been audited; a single successful case being over-extrapolated into general capability; and non-reproducible demonstration environments. Governance recommendations are: perform dual-path proofs or independent review for key conclusions; manually compare formal statements; pin versions and security-review the verification toolchain; label the scope of applicability of demonstration results; and remain cautious about undisclosed model capabilities, without treating them as production commitments.

Overall, the most valuable lesson from this case is transforming the large model from an “answer generator” into a “candidate generator in a verifiable discovery process.” In the future, truly competitive systems will not be models with the most impressive single answer, but engineering systems that connect generation, verification, audit, and reproduction into a closed loop. For developers, this has more long-term value than chasing a single model version.