Apply for AI Grants India

Lean 4 theorems are machine-checked claims about programs, data, and mathematics. They let you state a property precisely and ask the Lean kernel to verify that the accompanying proof follows from trusted rules. For Indian researchers, engineering teams, and students, Lean 4 offers a practical route into formal methods without requiring a large verification infrastructure.

This guide explains the core syntax, proof patterns, libraries, tooling, and project decisions that matter when working with Lean 4 theorems in 2026.

What a Lean 4 theorem is

A theorem is a named proposition together with a proof. In its simplest form:

theorem add_zero (n : Nat) : n + 0 = n := by
  simp

The statement says that adding zero to a natural number leaves it unchanged. The by block contains tactics that construct a proof, while Lean checks the result against the theorem's type.

This distinction matters: Lean does not merely execute a test or trust an informal explanation. It verifies that the proof term has exactly the required type. Definitions, propositions, and proofs all live within Lean's dependent type system, allowing a theorem to describe both mathematical facts and properties of software.

A theorem may include:

• Parameters, such as n : Nat or xs : List α.
• Hypotheses, such as h : n > 0.
• A target proposition, such as an equality or implication.
• A proof, written with terms, tactics, or a combination of both.

A practical theorem example

Consider a property of list reversal:

 theorem reverse_reverse (xs : List α) : xs.reverse.reverse = xs := by
  simp

In a real file, the type variable may require an explicit declaration, depending on the project settings. The important idea is that the theorem describes a reusable contract for a function. Once proved, other proofs can invoke it without reopening the implementation details.

For a theorem with assumptions, use arrows or named hypotheses:

theorem double_positive {n : Nat} (h : 0 < n) : 0 < 2 * n := by
  omega

Here, h is evidence supplied by the caller. Tactics such as simp, omega, aesop, and linarith can use available hypotheses, but each has a different purpose. Choosing the smallest suitable tactic generally produces proofs that are easier to maintain.

The proof workflow

A productive Lean 4 workflow is iterative rather than speculative:

1. Write the proposition first. Make the desired behaviour precise before choosing tactics.
2. Check types early. Use the editor's diagnostics and commands such as #check to inspect expressions.
3. Try simplification. simp handles rewriting with known simplification lemmas.
4. Split structure when needed. Use cases, constructor, intro, or induction according to the proposition's shape.
5. Use automation selectively. Arithmetic goals may suit omega or linarith; search-heavy logical goals may suit aesop.
6. Compile continuously. A proof is finished only when Lean accepts the complete file.

For arithmetic, an example may look like this:

example (a b : Nat) : a + b = b + a := by
  omega

The exact tactic support depends on imported modules and the types involved. When a tactic fails, inspect the goal state rather than adding automation blindly. A short explicit proof is often more robust than a broad search.

Core theorem patterns to learn

Equality and simplification

Many early proofs establish equalities between expressions. rfl proves definitional equality—cases where both sides reduce to the same expression. simp applies registered rewrite rules and is more powerful, but it should not be treated as a universal solver.

Implication and hypotheses

To prove P → Q, introduce the assumption with intro h. To use an assumption, reference its name or pass it to a tactic. This mirrors ordinary mathematical reasoning while making every dependency explicit.

Conjunction and existence

To prove P ∧ Q, use constructor and prove both parts. To prove an existential statement, provide a witness followed by its proof. These patterns are especially useful when specifying API invariants or data-structure properties.

Induction

Use structural induction for recursive data such as natural numbers, lists, and trees. A typical induction proof has a base case, an inductive case, and an induction hypothesis. Keep recursive definitions and their theorems aligned: clear equations make induction and simplification substantially easier.

Mathlib, imports, and project structure

Lean 4's standard library is complemented by Mathlib, a large community-maintained collection of definitions, theorems, tactics, and mathematical notation. Use the library before writing foundational results yourself, but verify the relevant namespace and import. Excessive imports can slow builds and make dependencies unclear.

A small project should normally separate executable definitions from proofs, keep theorem names descriptive, and pin compatible Lean and Mathlib versions. This is as important for reproducibility as dependency management in an application. Teams building AI systems can apply the same discipline used in building scalable machine learning models on a lean budget: define a narrow target, measure the cost of each tool, and avoid infrastructure that does not improve the result.

Where Lean 4 theorems are useful

Lean is valuable when correctness requirements justify the cost of formalisation. Common applications include:

• Algorithm verification: prove that sorting, parsing, searching, or transformation functions preserve stated properties.
• Compiler and systems work: specify semantics and verify selected transformations or invariants.
• Mathematics: formalise definitions and proofs in a reproducible, machine-checked form.
• Security-sensitive logic: reason about access-control rules, protocol states, and information-flow properties.
• Education and research: expose hidden assumptions and make proof steps executable and inspectable.

Formal proof is not a replacement for testing. Tests explore examples; theorems cover all inputs satisfying their assumptions. In production, use both, and decide which properties deserve formal treatment based on risk, change frequency, and proof effort.

A sensible learning path

Start with Lean's expression syntax, functions, inductive types, and propositions. Then practise small theorems involving equality, lists, natural numbers, and finite structures. Learn to read goal states before learning large automation tactics. After that, study namespaces, type classes, modules, and Mathlib conventions.

An editor with Lean language support is essential because diagnostics, goal views, completions, and source navigation shorten the feedback loop. If your broader work involves AI-assisted software, treat generated proofs as drafts: review every imported lemma, assumption, and tactic, just as you would evaluate code produced while developing an AI assistant.

Common mistakes to avoid

• Proving an underspecified claim: a theorem can be correct but fail to express the property you actually need.
• Using `sorry` in finished work: it bypasses proof completion and should be tracked as technical debt.
• Relying on opaque automation: understand why a tactic succeeds before making it a critical dependency.
• Ignoring assumptions: a result may hold only for a restricted type or input domain.
• Mixing versions casually: Lean and Mathlib changes can affect syntax, imports, and tactic behaviour.
• Writing one enormous theorem: smaller lemmas create clearer interfaces and better error messages.

Conclusion

Lean 4 theorems turn specifications into checked artefacts. The most effective practice is to begin with precise statements, use small reusable lemmas, rely on Mathlib where appropriate, and compile often. For Indian builders and research teams exploring dependable software, Lean 4 is particularly useful when a property must be demonstrated rather than merely claimed. Start with a modest invariant, prove it end to end, and expand the formal boundary as the value becomes clear.