Autoformalization Framework

• Autoformalization is the automated translation from informal mathematical language into formal code, ensuring semantic and syntactic correctness.
• Frameworks like SITA leverage large language models to iteratively generate and refine Lean code, integrating rule-based fixes and error knowledge bases.
• Modular abstract templates and type-class inheritance enable a structure-to-instance approach, reducing manual efforts and ensuring scalable formalization.

Autoformalization Framework

Autoformalization denotes the automated translation of informal mathematical content, often in natural language, to fully formal statements suitable for proof assistants such as Lean, Coq, or Isabelle. The past several years have seen the emergence of a wide range of frameworks and methodologies that systematically attack both the theoretical and practical barriers to autoformalization at scale, spanning the generation of formal skeletons, the incorporation of LLM-driven feedback loops, the enforcement of semantic and syntactic correctness, and the alignment of abstract mathematical templates with concrete problem instances.

1. Core Principles and Definition

At its foundation, autoformalization is defined as an automated realization of the function

$f: (expr \in L_i) \rightarrow (\psi \in L_f)$

where $L_i$ is an informal language (e.g., mathematical English or LaTeX), $L_f$ is a formal reasoning language (e.g., Lean’s type theory, Isabelle/HOL, PDDL), and $E(expr, \psi)$ is a semantic-equivalence relation that is ideally respected by the transformation (Mensfelt et al., 11 Sep 2025). The field has evolved from a narrow focus on theorem-proving in mathematics to a general paradigm encompassing a variety of logical and knowledge representation tasks.

Central to any autoformalization framework is the pipeline reduction of informal text to symbolic expressions, the evaluation of semantic alignment, and the integration of feedback to guarantee both syntactic and semantic validity.

2. Structural Abstraction: Templates and Modularity

A prevailing methodology is the use of abstract-structure templates that provide a modular and reusable scaffold for formalization (Li et al., 13 Nov 2025). An abstract mathematical theory is encoded as

$$T \;=\; (\mathsf{Defs},\,\mathsf{Assums},\,\mathsf{Ops},\,\mathsf{Thms})$$

where $\mathsf{Defs}$ are definitions, $\mathsf{Assums}$ are assumptions, $\mathsf{Ops}$ are parameterized operations, and $\mathsf{Thms}$ are theorems proved under these assumptions. Instantiation is achieved by generating concrete classes and definitions (e.g., a Lasso optimization problem) and wiring them to the abstract interface via instance declarations in Lean’s type-class system.

In such a design, abstract theorems—proved once at the level of the template—become immediately available for all concrete instances that satisfy the interface. This enables a ‘structure-to-instance’ theorem lifting workflow grounded in type-class and instance mechanisms; for example, linking a class Lasso_pro to the abstract composite_pro, so that every generic theorem about composite_pro applies to Lasso once the required structure is present.

3. Automated Generation and Iterative Refinement

Autoformalization frameworks leverage LLMs to emit initial formal code skeletons. The SITA pipeline (Li et al., 13 Nov 2025) exemplifies this with the following loop:

1. Skeleton Construction: LLM emits Lean classes, operations, theorem statements (with by sorry placeholders), and instance wiring.
2. Error-driven Correction: Up to K iterations of Lean type-checking are performed. If errors are found, rule-based fixes and retrieval-augmented LLM re-prompting are used. Corrections incorporate both static format fixes and usage of an error-knowledge base (KB(e)), which accumulates known failure patterns and their remedies.
3. Proof Refinement: For each remaining ‘sorry’ goal, the LLM is prompted—with local context and potential tactic-state information—to fill in the proof. Failed attempts prompt further corrections based on KB and Lean feedback, iterating up to R times.
4. Postprocessing: Ensures that no leftover partial proofs remain (resorting to sorries only when necessary), checks file compilation, and optionally back-translates formal definitions and theorems to natural language for documentation purposes.

This approach constructs fully-verified Lean files bridging abstract mathematical theory and concrete applications in a manner that is both automated and formally correct.

Pseudocode Outline for SITA Pipeline

Input: abstract template T = (Defs,Assums,Ops,Thms), NL desc I Output: verified Lean file F 1. LLM constructs skeleton: Defs_I, Ops_I, Thms_I (with sorry), instances 2. For up to K times: if Lean.check(F): break else: rule-based fix or LLM re-prompt with error & KB(e) 3. For each sorry goal: up to R iterations: extract context LLM proposes proof term if proof fails: retrieve fix from KB LLM refines 4. Clean up, ensure compilation return F

4. Type-Class Inheritance and Proof Lifting

Lean’s class-instance system is the formal backbone enabling compositional proof reuse. Each abstract structure is specified as a type class with bundled fields for data and assumptions. Concrete classes instantiate the interface via instance declarations. Theorems proved generically at the abstract level (as methods of the class or in terms of the class parameters) are reified on any instance via Lean’s typeclass resolution.

Example schematic:

class AbstractTemplate (α : Type*) extends ... instance ConcreteType.AbstractTemplate : AbstractTemplate ConcreteType := { ... }

Typical deployment involves writing the majority of mathematical infrastructure—algorithms and theorems—over the abstract template, relegating the creation of concrete instance classes, operations, and instance declarations to the template instantiation step.

This design enables instant access to a library of formal results at the instance level, provided the class and instance mechanism is expressive enough for the mathematical objects involved.

5. Error-Knowledge Base and Feedback Propagation

Error-driven refinement is a critical component in autoformalization:

• Error-Knowledge Base (KB(e)): Incrementally accumulates error patterns and successful corrections, guiding static fixes and improving future LLM prompts.
• Integration with LLM Prompts: Type-checking errors are fed back as “chain-of-thought” tokens, forming part of subsequent LLM input, which improves generation quality and alignment with formal requirements.

This feedback loop is not only essential to correct syntactic and type errors, but it also exposes the system to common failure cases, thus enabling targeted prompt and model engineering strategies.

6. Empirical Performance and Case Studies

Structure-aware autoformalization frameworks such as SITA have been evaluated on domains requiring the instantiation of high-level abstract results to concrete settings, notably in convex optimization (Li et al., 13 Nov 2025). In experiments covering 42 optimization problems (logistic regression, Lasso, group Lasso, ADMM), over 50% of instances were fully formalized and verified in Lean, a regime where direct LLM generation typically fails.

Example: Instantiating proximal gradient descent convergence to Lasso involves the generation of:

• Lasso_pro class (bundling Lasso’s data and hypotheses)
• Definition of the objective as the sum of f and g
• pg_Lasso class (algorithm instance)
• Connection via instance declarations to the abstract composite_pro and pg classes

The framework automatically produces a theorem Lasso_convergence as an instantiation of a generic convergence result pg_converge, with all dependencies and structural assumptions checked and wired through Lean’s type-class mechanism.

7. Broader Context and Future Directions

Autoformalization currently faces theoretical challenges in semantic equivalence checking, expressiveness/tractability trade-offs, and cross-domain adaptation (Mensfelt et al., 11 Sep 2025). Structure-to-instance synthesis frameworks show that template-based approaches can significantly reduce human effort in research-level formalization, particularly where large families of concrete examples instantiate a common theoretical motif.

Future research will address managing larger and more complex template libraries, more expressive assumptions (especially with dependent types), code generation for proofs of increasing complexity, and further integration with retrieval and alignment-based approaches for improved feedback and error correction.

Horizontal integration with verification modules, cross-domain application (beyond mathematics, e.g., control, planning), and better semantic metrics for automatic validation are active directions for scaling autoformalization frameworks to broader scientific and engineering practice.