Proof terms do change. The bigger choice is whether your project will still build after an upgrade.
If you're selecting an assistant for study, research, or software work, compare update risk, dependency pinning, documentation, and the cost of switching later. Rocq, Lean, Agda, and Isabelle can all support serious formal work. None eliminates maintenance.
Your money may not buy a license here, but your time still pays for failed builds, version hunts, and rewritten proof scripts. Be skeptical of precise claims that one tool automatically repairs a certain percentage of proofs or runs twice as fast. Those results depend heavily on the project, versions, hardware, and definition of success.
What actually changes when a proof term changes?
A proof term is the object the assistant checks. The source file is often a script that uses tactics, notation, implicit arguments, and library names to produce that object.
The distinction matters. An upgrade can break the route to a proof term without making the mathematical statement false. A renamed theorem, changed tactic, altered notation, or incompatible library can stop an old file from compiling.
A larger printed term is not automatically a problem. A kernel rejection is more serious.
| What you see after an update | Likely area to investigate | First check |
|---|---|---|
| Unknown identifier or theorem | Library API or import changes | Compare names, imports, and dependency versions |
| Type mismatch | A declaration or inferred argument changed | Inspect the expected and supplied types |
| Universe inconsistency | Universe levels or constraints changed | Reduce the example and inspect universe declarations |
| Timeout or much larger output | Tactic behavior or resource use | Test the tactic on a small example |
| Kernel rejects the final term | The proof no longer typechecks in that environment | Read the first kernel error and build a minimal reproduction |
This table is triage, not a diagnosis. One error can hide another.
The real cost is maintenance
Proof assistants are often available without a traditional license purchase. Free does not mean free to maintain.
Turns out, the largest cost usually appears during upgrades, handoffs, and dependency repairs. A project that builds once but cannot be rebuilt from a clean checkout is expensive software, even if the download costs nothing.
| Decision | Cost to expect | Question to answer |
|---|---|---|
| Adopt an existing project | Time spent matching its toolchain | Can you reproduce the documented baseline? |
| Update an active library | Regression testing and proof repairs | Who will own the migration? |
| Port a proof later | Rewriting source and checking results again | Are the theorem statements documented clearly? |
| Hand the project to someone else | Setup and explanation time | Can another person rebuild it without your machine? |
Treat maintenance as part of the purchase decision. You are choosing a workflow, not just a kernel.
Rocq, Lean, Agda, or Isabelle?
Rocq and Coq projects: If you're inheriting Coq code, identify the exact release before editing proof terms. The Rocq documentation is continuously deployed and includes release-specific material, including Coq 8.20.0 documentation. The Learn Rocq material also describes MetaCoq-based work with terms and declarations at the kernel level. That can help tool builders, but it is not a guarantee that ordinary application proofs will migrate automatically.
Lean projects: Lean and Mathlib should be treated as a pair. The Lean project guidance describes coordinated update steps for projects that depend on Mathlib. A version change can affect the compiler, Mathlib, other packages, or all three. The Mathlib documentation index is useful for checking the library structure before you change imports or theorem names.
Agda projects: Ask for the exact compiler and library versions. Then build a small representative file, not just a toy that avoids the project's difficult features. Do not assume that a language feature, transport method, or refactoring technique will preserve every existing source file.
Isabelle projects: Check the distribution version, session dependencies, external theories, and any Isabelle/ML code. The Isabelle website lists the available distribution and gives resource guidance for projects of different sizes. Isabelle's theory documentation guidance also stresses documenting definitions, major theorems, motivation, and references. That information lowers handoff costs.
A safer proof-maintenance workflow
Use this sequence before making a broad update:
- Freeze the working baseline. Commit the source, project configuration, dependency metadata, and documentation. Record the compiler and assistant version.
- Build the old revision cleanly. Use a fresh checkout or isolated environment. A successful build from your usual editor is not enough.
- List every dependency. Include standard libraries, plugins, external theories, custom tactics, and generated files.
- Read the release and project notes. Look for renamed declarations, changed defaults, deprecated tactics, and required toolchain changes.
- Change one layer at a time. Start with the compiler or distribution, then update libraries, then repair project-specific automation.
- Classify each failure. Separate missing names, type errors, universe errors, timeouts, and actual kernel rejection.
- Recheck the repaired proof. Run the assistant's normal checker and the project's tests. Do not rely only on a successful editor display.
- Keep the migration record. Save the working version, the new version, the changes made, and any assumptions that were removed or added.
Small steps make rollback possible. They also show which dependency caused the break.
Reduce lock-in before it becomes a problem
Lock-in is not automatically bad. A mature library may save more time than a theoretically portable design. The problem is hidden lock-in that appears only when a maintainer leaves or a toolchain disappears.
Keep these safeguards in the repository:
- Store source proofs, theorem statements, comments, and configuration files, not only compiled artifacts.
- Record exact assistant, compiler, library, plugin, and external-theory versions.
- Keep a small smoke-test file that exercises the project's most important imports and tactics.
- Isolate custom automation so another person can find and replace it.
- Document assumptions, trust settings, build commands, and any manual migration steps.
The last item is easy to skip. It is also the one a new maintainer needs first.
How to choose without trusting a headline benchmark
If you're taking over an existing project, compatibility usually beats novelty. Start with the tool named by the project and prove that you can reproduce its baseline before considering a switch.
For a new project, write one modest theorem in each serious candidate. Include the imports, automation, notation, and data structures you expect to use. A tool that feels quick on a tiny arithmetic example may behave differently on your actual workload.
Thing is, the most useful comparison is rarely raw elaboration speed. Check how easily you can find documentation, pin versions, inspect failures, update dependencies, and explain the build to someone else.
Questions worth answering before you switch
Can a theorem remain true while its proof breaks?
Yes. The proposition may be unchanged while the source script no longer produces a term accepted by the new environment. If the new kernel accepts the repaired term, that term is valid under the new system's checking rules, but you should still review its assumptions and dependencies.
Is a textual proof-term diff enough?
No. Textual output can change because of elaboration, pretty-printing, naming, or universe presentation. A diff is useful evidence, not a substitute for rebuilding and checking the proof.
Should you switch from Coq or Rocq to Lean for speed?
There is no universal winner. Compare the exact libraries, automation, project size, and migration work you need. A short pilot with your own theorem is more useful than an unsupported two-times-faster claim.
What should you save before an upgrade?
Save the source, configuration, dependency versions, compiler version, build output, test results, and a clean baseline commit. Add a short note explaining what changed and how you verified it.
Before committing to any assistant, build one representative example from a clean checkout, change one dependency, and rebuild it. That small exercise will expose your maintenance risk early.