Navier-Stokes lost in translation: Why Lean verification of AI autoformalisation does not guarantee correct natural language proofs

Abstract: Autoformalisation is increasingly used to verify mathematical texts, including those generated by AI, as in OpenAI's announced proof of blow-up of solutions to the Navier-Stokes equations. In this process, an AI system translates the text from a natural language (NL) into a formal language such as Lean. Once this translation is done, the argument expressed in the formal language can easily be mechanically verified. The purpose of this article is to demonstrate why this process may offer no confidence in the original NL argument, owing to the various difficulties in performing the translation semantically faithfully. In particular, we highlight that the problem of resolving ambiguities in mathematical NL text, which is necessary in order to provide semantically faithful translation, is arbitrarily high up in the Solvability Complexity Index (SCI) hierarchy/arithmetical hierarchy (the SCI $= \infty$). Hence, informally, providing semantically faithful AI autoformalisation is harder than any computational problem including the Halting problem (which has SCI $= 1$). To demonstrate the effect of this result we provide several examples of AI mistranslations of NL statements and proofs into Lean in practice, resulting in mismatches between NL proofs and their Lean `verifications'. These include OpenAI's announced Navier-Stokes proof. In particular, we show that the formalised Lean proof does not correspond to the NL proof of blow-up of solutions to the Navier-Stokes equations.

• The paper highlights that successful Lean verification does not guarantee that formal proofs correspond to natural language proofs.
• It identifies specific examples where Lean proofs differ from the intended arguments, particularly in OpenAI’s Navier–Stokes formalisation.
• The authors demonstrate that semantic preservation requires matching not only the conclusion but the entire reasoning structure of the source, which cannot be universally ensured by compilation

Central thesis and scope

“Navier-Stokes lost in translation: Why Lean verification of AI autoformalisation does not guarantee correct natural language proofs” (2610.08144) distinguishes two substantially different objectives that are often conflated under the term autoformalisation. The first is to obtain Lean code that proves a formally stated theorem. The second is to translate a natural-language (NL) mathematical text into Lean while preserving its semantic content, including definitions, hypotheses, intermediate claims, proof strategy, dependencies, and implicit existence conditions.

The paper’s central claim is that successful compilation addresses only the first objective. A Lean term that type-checks certifies the proposition encoded in Lean and the validity of the formal derivation supplied for that proposition. It does not certify that the encoded proposition is the one expressed in the source text, that the formal derivation follows the source argument, or that the source argument is correct. Consequently, a formal proof can coexist with an incorrect NL proof, or it can establish a different theorem by a different method.

The authors develop this distinction through elementary counterexamples, a detailed examination of two components of OpenAI’s announced Navier–Stokes formalisation, and computability-theoretic arguments concerning the complexity of semantic disambiguation. Their disclaimer is appropriately narrow: the paper does not establish that OpenAI’s NL proof is false. It establishes that the cited Lean formalisation is not, in the examples examined, a semantically faithful translation of the corresponding NL statements and arguments.

Two notions of autoformalisation

The weaker notion begins with a theorem that has already been translated into Lean and asks an AI system to produce any Lean proof accepted by the kernel. Under this criterion, a proof is successful if it compiles without sorry or additional axioms. The source proof functions only as guidance for proof search.

The stronger notion requires semantic preservation. A translation must preserve the mathematical meaning of the source text, not merely produce a proposition or proof with the same informal conclusion. This requires maintaining the source definitions, quantifier structure, side conditions, regularity assumptions, domains, norms, dependencies, and proof-relevant intermediate assertions. For a long mathematical text, the obligation is global: each formalised result must remain compatible with the meanings and dependencies established earlier.

This distinction has an immediate formal consequence. If the NL argument is invalid but the theorem statement is true, an AI system optimizing only for Lean acceptance can silently replace the invalid argument with a valid one. If the NL argument is valid, the system can still replace it with an unrelated formal proof. In either case, kernel verification provides no evidence that the argument requested for translation has been preserved.

The paper summarizes the resulting failure mode as follows:

Lean acceptance of a translation does not imply semantic preservation.

This is not a defect in Lean’s kernel. It is a mismatch between the kernel’s specification and the intended verification task. Lean verifies a formal object relative to its formal declarations; it does not compare that object with an external NL source.

Elementary examples of proof substitution

The first example uses the polynomial

$p(x)=x^3-x^2-x+1.$

The source statement asserts nonnegativity on the relevant domain, but the accompanying NL proof assigns incorrect root multiplicities and therefore gives an incorrect factorization. The paper reports that the AI nevertheless generated a compiling Lean proof by discovering the correct algebraic structure. The result is a valid Lean proof of the theorem, but not a formalisation of the supplied NL proof.

Figure 1: An AI system translates an incorrect natural-language proof into a correct Lean proof by changing the mathematical argument.

This example isolates a particularly important asymmetry: a formaliser evaluated by compilation is incentivized to repair the source proof when repair is easier than faithful encoding. The resulting success may therefore be evidence that the theorem is provable, but it is not evidence that the original proof is sound.

The second example concerns a real symmetric matrix $A$ and the nonnegativity of $\operatorname{tr}(A^2)$. The NL proof diagonalizes $A$ in an orthonormal eigenbasis and then computes the trace as a sum of squared eigenvalues. The Lean proof instead retains the original basis and uses symmetry, $a_{ij}=a_{ji}$, to rewrite

$$\operatorname{tr}(A^2)=\sum_{i,j}a_{ij}a_{ji} =\sum_{i,j}a_{ij}^2.$$

Both proofs are mathematically valid, but the formal proof does not preserve the diagonalization argument.

Figure 2: A correct natural-language proof is translated into a different valid Lean argument that uses symmetry rather than diagonalization.

This example is not a correctness failure at the level of the theorem. It is a failure of proof correspondence. That distinction matters whenever the purpose of formalisation includes auditing a particular argument, checking the use of a delicate lemma, or preserving explanatory mathematical structure.

The Navier–Stokes case study

The paper applies this framework to OpenAI’s announced finite-time blow-up proof for the three-dimensional incompressible Navier–Stokes equations. The authors inspect the NL proof and the Lean repository at a specified commit, comparing source estimates and proof mechanisms with the declarations cited as their formal counterparts.

The first discrepancy concerns an inverse estimate in the source’s Lemma 8.6. The NL statement requires four additional derivatives: $\|N^{-1}F\|_{C_y^m} \leq C_m\|F\|_{C_y^{m+4}},$ whereas the corresponding Lean development requires five: $\|N^{-1}F\|_{C_y^m} \leq K_m\|F\|_{C_y^{m+5}}.$ Here $N=v_t\cdot\nabla_y$ is a directional derivative on $\mathbb{T}^2$, and the inverse is defined on zero-mean functions.

Figure 3: The cited Lean inverse estimate requires one more input derivative than the corresponding natural-language estimate.

The difference is not a superficial notation change. The source argument uses Fourier decay sufficient to produce a summable $A$0 factor in two dimensions after four additional derivatives. The Lean proof instead invokes a coefficient estimate involving a summable fourth-power weight, which leads to the $A$1 requirement. The formal result is therefore weaker with respect to derivative loss. The authors also note that some formal statements are not directly comparable because they use different derivative types, including mixed derivatives rather than precisely the torus derivatives appearing in the NL norm.

The implication is specific: compilation of the Lean theorem does not establish the source’s sharper regularity estimate. At most, it establishes the formally stated estimate under stronger hypotheses. If the source proof depends quantitatively on the $A$2 bound, the formalised result cannot be treated as its verification without an additional argument deriving the source estimate from the Lean development.

The second case concerns the pressure-flux estimate labelled (10.19) in the announced NL proof. The source gives a bound expressed purely through $A$3, schematically

$A$4

for almost every time. The corresponding Lean estimate has a different structure: $A$5 and is asserted for every time in the relevant interval. The formal bound depends on the additional localized gradient quantity $A$6, while the NL estimate does not.

Figure 4: The pressure-flux estimate and proof strategy in Lean differ from both the statement and proof in the natural-language argument.

The discrepancy arises from a substantive change in analysis. The NL proof uses boundedness of the Riesz transform on $A$7, together with a decomposition involving $A$8. The Lean proof instead uses Sobolev embedding to control an $A$9 norm through an $\operatorname{tr}(A^2)$0 gradient norm, applies $\operatorname{tr}(A^2)$1 boundedness of the Riesz transforms, and uses a different Hölder decomposition involving $\operatorname{tr}(A^2)$2 and $\operatorname{tr}(A^2)$3. The derivative of the cutoff then produces the $\operatorname{tr}(A^2)$4 contribution. The two arguments consequently establish different estimates.

The formal assertion that the estimate holds for every time, rather than almost every time, is also obtained through a different route: the Lean development establishes temporal continuity of the relevant integral. This may be a mathematically useful strengthening of a particular formal statement, but it does not repair the semantic mismatch. A stronger time-regularity conclusion combined with a different spatial estimate remains a different proposition and proof.

The paper therefore identifies two independent deviations in this case: the Lean code changes the bound and changes the method used to prove it. The source estimate cannot simply be recovered by observing that another source inequality relates $\operatorname{tr}(A^2)$5 and $\operatorname{tr}(A^2)$6; the authors explicitly state that the cited relation does not eliminate $\operatorname{tr}(A^2)$7 from the Lean expression in a way that reproduces the NL estimate.

Why compilation is an insufficient acceptance criterion

The paper models compilation-driven autoformalisation as an iterative search process. Given a formal theorem and an NL proof, the system revises a candidate Lean proof until the kernel accepts it. The acceptance predicate checks only whether the candidate proves the formal theorem. It does not check whether the candidate preserves the source proof.

This creates three distinct outcomes:

1. The NL proof is incorrect, while the generated Lean proof is correct.
2. Both proofs are correct, but use different arguments.
3. The NL text states a stronger claim than the Lean code proves.

All three outcomes satisfy the same compilation criterion. The third is especially consequential in analysis, where changes in derivative counts, integrability exponents, quantifiers over time, or dependence on auxiliary quantities can alter the applicability of subsequent estimates.

Back-translation from Lean to NL does not solve the problem automatically. One would still need to establish that the generated NL text faithfully represents the formal proof and that it corresponds to the original source argument. The semantic-preservation problem therefore reappears in the reverse direction.

Semantic ambiguity and arithmetical complexity

The paper’s broader theoretical claim is that semantic preservation is not merely difficult because mathematical language is informal. Some ambiguities depend on whether mathematical objects introduced by the source are well-defined, and that question can encode undecidable problems.

The construction uses an effective enumeration of integer-coefficient polynomials $\operatorname{tr}(A^2)$8 and defines $\operatorname{tr}(A^2)$9 as the least natural number $A$0 for which

$A$1

has no solution in natural numbers $A$2. The source may then define $A$3 and state an elementary identity involving $A$4. The identity itself is trivial if $A$5 exists. The semantic issue is whether the defining least number exists at all.

A formal system with default-valued minimization operators can silently assign a value when the intended set is empty. The paper gives a Lean-style construction using Nat.sInf, which returns $A$6 on an empty set. The resulting code can prove the elementary ring identity while changing the source semantics: it has replaced a partial definition with a total one. Compilation therefore conceals, rather than resolves, the existence presupposition.

For $A$7, the authors prove that the set of indices for which such an $A$8 exists is $A$9-complete, using the DPRM theorem and a nine-variable Diophantine representation of computably enumerable relations. Hence deciding whether the source definition is well-defined is not computable relative to the Halting problem. Generalized constructions yield $a_{ij}=a_{ji}$0-complete problems for every finite $a_{ij}=a_{ji}$1, with corresponding unbounded finite levels in the SCI hierarchy.

The paper summarizes this as an SCI value of infinity for the unrestricted problem of determining, across all such constructions, whether a source statement is semantically translatable or whether the formaliser must refrain from translating. The claim should be read in the paper’s precise sense: a universally trustworthy formaliser that always outputs either a faithful translation or an explicit refusal would have to solve ambiguity-resolution problems of arbitrarily high finite SCI. Thus, no fixed finite computational procedure can provide the proposed guarantee over the full class of source texts.

This result does not imply that every mathematical translation is computationally intractable, nor that useful semantic checks are impossible. It establishes a worst-case barrier for universal guarantees. Restricted mathematical languages, explicit well-formedness conditions, proof annotations, and human-supplied specifications may substantially reduce the problem instance, but those restrictions are external assumptions rather than consequences of Lean compilation.

Limitations and open questions

The paper’s empirical conclusions are based on selected examples rather than a systematic audit of the entire Navier–Stokes or Euler repositories. The authors explicitly state that they do not determine whether the OpenAI NL proof is correct, and they do not claim that the identified mismatches invalidate every formal theorem in the repository. Their conclusion is narrower and better supported: the cited Lean declarations do not faithfully formalize the particular NL claims and arguments examined.

The theoretical results concern universal semantic preservation over broad classes of mathematical texts. They do not specify a practical, restricted specification language in which faithful translation might be decidable or mechanically checkable. The paper also does not provide a complete protocol for certifying correspondence between an NL proof and a Lean proof. It leaves open how much correspondence can be established through proof annotations, structured intermediate representations, bidirectional translation, independently verified semantic parsers, or human-authored formal specifications.

A further open question is whether the source and formal developments could be connected by a richer notion of traceability: for example, a proof object augmented with machine-checkable links from each formal lemma to a precisely delimited NL assertion and its hypotheses. Such links would not remove the worst-case computability barrier, but the paper leaves open how effective they could be for restricted, practically important mathematical domains.

Conclusion

The paper establishes a precise separation between formal proof verification and semantic verification of autoformalisation. Lean can certify that a formal proposition follows from formal premises, but it cannot, without an independently checked correspondence layer, certify that those premises and that proof represent the intended NL mathematics.

The elementary examples demonstrate proof substitution, while the Navier–Stokes case study exhibits technically material discrepancies: an $a_{ij}=a_{ji}$2 derivative requirement replacing an $a_{ij}=a_{ji}$3 estimate, and a pressure-flux inequality with different quantities, exponents, time quantifiers, and proof mechanisms. The computability-theoretic analysis explains why such failures cannot be eliminated by a universal compilation-based procedure. The resulting methodological conclusion is direct: Lean-verified autoformalisation should be treated as verification of the formal artefact unless semantic faithfulness to the source has itself been established.