What Is Lean 4 Proof Engineering?

From prose to a checked term

A theorem statement is not a proof. In Lean, the statement is a type, and a proof is a term that inhabits that type. The kernel checks the term against the rules of the dependent type theory used by the project.

Most practical effort sits around that kernel check: choosing the right definitions, finding library lemmas, making reductions visible to the simplifier, and keeping theorem statements aligned with the informal claim.

• ✓Definitions determine whether a statement says what the author intended.
• ✓Imports determine which lemmas and typeclass instances are available.
• ✓Tactic state determines why a proof script gets stuck.
• ✓The kernel check is the final authority, not a green editor decoration.

What proof engineers actually do

Proof engineering combines mathematical reading with software maintenance. A useful pass begins by reproducing the build, isolating the failing declaration, and distinguishing a wrong statement from a hard proof.

The output should be more than a patched file. It should include a replayable build command, a short explanation of the repair, and a list of assumptions or unfinished branches that remain.

Track verification state explicitly

A small theorem like this makes the review loop concrete: the statement is readable, the induction variable is obvious, and the simplifier has a narrow job. That is a better starting point than a large theorem with hidden setup.

When a proof does not close, record the exact goal and context. A useful handoff includes the Lean version, dependency revisions, the command that fails and the smallest reproducible declaration.

theorem append_length {α : Type} (xs ys : List α) :
    (xs ++ ys).length = xs.length + ys.length := by
  induction xs with
  | nil => simp
  | cons x xs ih => simp [ih]

When an external pass is useful

An external proof-engineering pass is most useful when the local loop is blocked: a statement is ambiguous, an import graph is unstable, or a proof attempt keeps expanding without converging. The pass should reduce uncertainty and leave a reproducible next action.

It is less useful as a promise to solve an open mathematical problem. Scope, assumptions and verification criteria need to be explicit before work begins.