To verify an AI-generated proof, first check the exact claim, assumptions, definitions, and every inference by hand. For stronger, mechanical checking, formalize the theorem and proof in Lean or Rocq/Coq and build the project. A successful check establishes that the formal proof term matches the formal statement under the project’s declarations and imports—not that the formal statement captures what you meant to ask.
How do you check an AI-generated proof by hand?
- Write down the exact claim. State the domain, hypotheses, definitions, and quantifiers explicitly. Keep the original problem beside your rewritten version so you can compare them.
- Check the translation. Match each phrase in the problem to the corresponding part of the claim. Look for missing conditions, changed domains, or a conclusion that is weaker or different from the original. Lean community guidance recommends expert confirmation that a formal theorem corresponds to the mathematical claim being made: Did you prove it?
- Trace every assumption. Identify where each hypothesis is used. Check definitions and any imported results the argument relies on; a proof can depend on declarations or axioms that are not obvious from the displayed steps.
- Justify each inference. For every equation or implication, name the definition, algebraic rule, or earlier result that makes it follow. Expand skipped steps, especially where the proof divides by an expression, changes signs, or applies a result with domain restrictions.
- Test edge cases and intermediate claims. Check boundary values, zero cases, and examples that might expose a false lemma. A counterexample can disprove a universal claim, but passing example checks does not prove it.
What should you inspect most carefully?
- Quantifiers: Is the claim for every value, some value, or a particular value? Has the proof silently changed the order or scope?
- Domains: Do all variables remain in the set or structure where the operations and theorems apply?
- Division and cancellation: Is the quantity being divided by or cancelled actually nonzero?
- Boundary cases: Do zero, endpoints, equality cases, or degenerate inputs satisfy the hypotheses?
- Intermediate lemmas: Does each lemma say exactly what the proof needs, and is it no stronger than the argument establishes?
Fluent prose is not evidence that a step follows. If you cannot identify the rule supporting a transition, treat that step as unresolved rather than filling the gap with an assumption.
How do you check a proof with Lean or Rocq/Coq?
- Formalize the statement. Encode the intended theorem, including its hypotheses and definitions. Compare it line by line with the original natural-language problem before trying to prove it.
- Formalize the argument and build the project. In Lean, scripts and tactics produce a proof term checked by the kernel; Rocq/Coq likewise checks that a proof term is well-typed and has the theorem statement’s type. The relevant documentation describes the mechanisms: Lean’s FAQ, Lean’s proof validation reference, and the versioned Rocq/Coq 8.16.1 proof-mode documentation.
- Inspect the theorem and dependencies. Confirm which statement was accepted, and review its declarations, imports, and any axioms or prior results on which it depends. Acceptance is relative to that project context.
- Report what was checked. Distinguish a human review of the informal argument from kernel acceptance of a formal proof, and state whether both were done.
What does it mean if Lean accepts the proof?
It means the kernel accepted a proof term for the formal theorem as elaborated from the current file and its imports. Lean’s documentation explains that scripts and tactics produce an explicit term in its foundational logic for checking by a small trusted kernel; this is not a check of the original prompt’s meaning. A mistaken translation, unintended definition, broad axiom, or imported result can yield a formally valid proof that does not answer the intended question. Check the correspondence between claim and formal statement, as well as the dependencies, rather than relying on a green check alone.
Which proof assistant should you use?
There is no universal best choice established by these sources. Start with the project and theorem you actually need to check, then consider the system’s foundations, checking workflow, and the reviewer’s familiarity.
#1 Best Overall
| Decision point | What to check |
|---|---|
| Existing formalization | Whether the relevant theorem or library already exists in the project’s system. |
| Foundations and logic | Lean uses dependent type theory. Lean’s FAQ describes Isabelle/HOL as based on higher-order logic and the LCF approach; Lean and Rocq/Coq share common foundations but have technical differences. |
| Kernel and workflow | What the trusted kernel checks and how scripts, tactics, or automation produce proof objects. |
| Readability and expertise | Whether the system’s documentation and community support fit the proof and the people who must review it. |
For Lean, Theorem Proving in Lean is identified in Jon Bell’s paper as a textbook-style resource; the cited source does not establish its current print availability.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How should you describe the result?
Be precise about the level of checking: for example, say that you manually checked an informal proof, that Lean or Rocq/Coq accepted a formal proof of a specified statement, or that both happened. Do not present formal acceptance as proof that an AI’s natural-language answer was correctly translated or that its intended claim was proved.
Quick Recap
Rank #2
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
