Define the artifact, not just the topic
A topic is too broad to estimate. A theorem list, a set of definitions and a buildable artifact are scoped. Write down the declarations that must exist and the command that must succeed.
- ✓Source paper or specification revision
- ✓Definitions that must be introduced
- ✓Theorem statements that must compile
- ✓Dependencies that are allowed or forbidden
- ✓Build command and target artifact
Separate assumptions from theorems
Formalization often starts by axiomatizing surrounding theory. That can be legitimate, but each assumption must be visible and approved. A project that proves a theorem from an unstated axiom is not the same artifact as one that proves it from the project's definitions and standard libraries.
Estimate by uncertainty, not line count
A short theorem with unclear definitions can consume more effort than a long but routine induction. Split the work into known, likely and exploratory declarations. Put the exploratory parts behind an explicit checkpoint instead of pretending they are routine.
Write acceptance criteria before intake
Acceptance should be observable. For example: `lake build` completes on the recorded toolchain, every requested theorem is present, no `sorry` remains unless listed, and the diff is limited to the agreed files. A proof pass is easier to evaluate when done means something a reviewer can run.
Frequently asked questions
Can a proof pass cover an open research conjecture?
It can fund bounded exploration and formalization infrastructure, but it cannot guarantee a resolution. Open problems should be separated from milestone work with checkpoints.
What if the repository already has `sorry` declarations?
List them explicitly. The acceptance criteria should say which existing placeholders are allowed, which must be removed and which are out of scope.