---
title: Discover And Prove (DAP) Framework
url: https://www.emergentmind.com/topics/discover-and-prove-dap
type: topic
---

# Discover And Prove (DAP) Framework

Searching arXiv for the cited DAP papers and closely related work to ground the article.
arXiv search: 2604.15839 "Discover and Prove: An Open-source Agentic Framework for Hard Mode Automated Theorem Proving in Lean 4"
Discover And Prove (DAP) denotes a two-stage formal-reasoning pattern in which a system first discovers a latent object needed for the proof—such as a missing answer or a helper lemma—and then constructs a machine-checked proof relative to that discovery. In recent work, the term is used explicitly in two settings: an open-source agentic framework for “Hard Mode” automated theorem proving in Lean 4, and a program-verification formulation in which helper lemmas and proofs are jointly synthesized for verification conditions. A plausible antecedent is deductive theory exploration, where equational lemmas are conjectured symbolically and then proved in a feedback-driven loop, even though that earlier work does not use the DAP name [2604.15839] [2603.22114] [2009.04826].

## 1. Conceptual scope and problem decomposition

DAP is defined by a separation between **discovery** and **proof**. In the Lean 4 theorem-proving formulation, the discovery target is the critical solution `ans` that a human solver would have to derive before the final formal argument can even be stated. The framework then rewrites the original problem into a conventional form solvable by existing ATP systems. In the program-verification formulation, the discovery target is a set of helper lemmas \(L\) that are not explicitly present in the proof-targeted verification conditions but are needed to discharge them in Coq/Rocq [2604.15839] [2603.22114].

This division is not merely organizational. The Hard Mode ATP work states that standard benchmarks often embed the final answer within the formal statement, a convention it calls **Easy Mode**, whereas **Hard Mode** requires the system to discover that answer independently before proof search begins. The program-verification work makes an analogous claim at the level of verification conditions: VC proving benefits from program comprehension because human proof engineers often discover and apply helper lemmas based on program semantics not directly reflected in the VCs produced by VC generators [2604.15839] [2603.22114].

A common misunderstanding is to treat DAP as a single benchmark protocol or a single algorithm. The current literature supports a broader reading: DAP names a general discover-then-prove paradigm, instantiated differently in Lean 4 Hard Mode ATP and in agentic deductive verification. This suggests that the unifying feature is not a particular logic or prover, but the explicit factoring of latent-solution search from downstream proof construction.

## 2. Formalization in Hard Mode automated theorem proving

The Hard Mode formulation is given explicitly in logical terms. In standard ATP benchmarks, an Easy Mode theorem can be written as
\[
\Phi \;\vdash\; Q(ans),
\]
where \(\Phi\) are the premises and the critical solution \(ans\) already appears syntactically in \(Q\). In Hard Mode, the same problem is encoded with two sorry-goals:
\[
\Phi \;\vdash\; (\exists\, ans,\; \Psi(ans)) \quad \text{and} \quad \Psi(ans) \;\vdash\; Q(ans),
\]
or, in Lean-idiomatic form,
\[
\texttt{theorem hard\_problem (… ) :}
\]
\[
\texttt{  (ans : Type) → … → ans = ? → … → Q(ans) := by}
\]
\[
\texttt{    sorry  -- discover ans}
\]
\[
\texttt{    sorry  -- prove Q(ans)}
\]
[2604.15839]

The distinction is also expressed as a difference in search problems. Easy Mode provers solve
\[
solve_E:\ \Phi,\ ans \in \mathfrak{S} \;\vdash\; Q(ans),
\]
whereas Hard Mode solvers must solve
\[
solve_H:\ \text{find } ans \in \mathfrak{S} \text{ such that } \Phi \vdash intermediate(ans)\ \wedge\ intermediate(ans) \vdash Q(ans).
\]
The paper emphasizes that nothing in \(\Phi\) constrains \(ans\), so a Hard Mode prover must explore \(ans \in \mathfrak{S}\). It further states that, in complexity terms, if proof search on \(Q(ans)\) is already intractable, appending an unbounded answer-search layer cannot make the problem any easier, and in practice it dramatically expands the search space [2604.15839].

This formalization matters because it isolates a capability that Easy Mode can mask. Hard Mode benchmarks were introduced precisely to measure systems that must first recover the missing mathematical object and only then execute formal proof search.

## 3. DAP as a Lean 4 agentic framework

The Lean 4 DAP framework is an end-to-end agentic system with two principal modules: a **Discovery Module** and a **Statement Rewriting** stage, after which an existing proving system is invoked. The architecture is summarized as
“Natural-language problem \(\rightarrow\) Discovery Module \(\rightarrow ans \rightarrow\) Rewriter \(\rightarrow\) Easy Mode Lean statement \(\rightarrow\) Proving Module \(\rightarrow\) formal proof” [2604.15839].

The Discovery Module uses an LLM—specifically GPT-OSS-120B—to generate a chain-of-thought solution and then perform explicit self-verification and self-correction before committing to an answer. Its pseudocode has the form `DISCOVER(problem, max_iters)`, with three key stages: `LLM.generate(prompt)` to produce the initial chain of thought, `LLM.self_verify(z)` to return a structured error report identifying incorrect steps, and `LLM.self_correct(z, report)` to revise the solution. The report-driven loop continues for up to `max_iters`, and the paper states that allowing up to 10–30 verification iterations saturates accuracy on Hard Mode benchmarks [2604.15839].

Once \(ans\) has been discovered, DAP transforms the original Hard Mode Lean 4 statement \(S_H\) into an Easy Mode statement \(S_E\) by replacing the first sorry with \(ans\) and deleting that sorry-goal. Formally, if
\[
S_H \equiv \texttt{theorem T (…) :}
\]
\[
\texttt{@sorry}_1 : ans\_correct(ans)
\]
\[
\texttt{@sorry}_2 : proof\_goal(ans),
\]
then the rewriting operator \(\tau\) is defined by
\[
\tau(S_H, ans) = S_E \equiv \texttt{theorem T (…) : @once\_sorry : proof\_goal(ans)}.
\]
The rewriting is itself performed by the LLM via a prompt that injects \(ans\) into the Lean source and removes the now-trivial first sorry-goal. Because \(S_E\) contains only one sorry-goal, it can be fed directly to an existing ATP system; the reported implementation uses Goedel-Prover-V2 [2604.15839].

The resulting architecture is modular in a precise sense stated by the paper: it cleanly separates answer search, which is informal and natural-language driven, from proof search, which is formal. A plausible implication is that improvements in either module can produce immediate gains without changing the other.

## 4. DAP in agentic program verification

In the program-verification setting, DAP is formulated as a joint synthesis problem over source code, specifications, helper lemmas, and machine-checked proofs. Let \(P\) be annotated source code with specifications \(S\); let \(\mathcal{F}\) be a trusted VC generator such as Frama-C/WP, producing proof-targeted verification conditions
\[
\Phi_C = \{\varphi_1,\ldots,\varphi_n\};
\]
let \(L\) be a set of helper lemmas to be discovered; and let \(\Pi\) be a collection of machine-checked proofs in Coq/Rocq. DAP is then the problem of finding
\[
(L,\Pi)\quad \text{such that}\quad \forall\,\varphi\in\Phi_C,\quad S \cup L \vdash_{\mathrm{Coq}} \varphi.
\]
Here \(\vdash_{\mathrm{Coq}}\) indicates that Coq’s kernel accepts the proof in \(\Pi\) [2603.22114].

The LemmaNet instantiation has five principal components. The **VC Generator** produces \(\Phi_C\). The **Offline Lemma Synthesizer** consists of a **Program Semantic Analyzer (PSA)**, which consumes \((P,S)\) and emits a semantics-aware VC \(\varphi_A\) plus a skeletal proof, and an **Obligation-Aligned Lemma Synthesizer**, which takes \(\varphi_A\) together with each \(\varphi_C \in \Phi_C\) and outputs an initial set of offline helper lemmas \(L_{\mathrm{off}}\) and a proof plan. A **Tactic-by-Tactic Proof Agent** then drives Coq proofs using standard tactics augmented by retrieved lemmas. An **Adaptive Lemma Maintainer (ALM)** maintains a working library \(L \supseteq L_{\mathrm{off}}\). Finally, an **Online Lemma Adapter** monitors proof failures and invokes Feedback-Guided Lemma Adaptation to refine or generate lemmas on the fly, producing \(L_{\mathrm{on}}\) and updating \(L \leftarrow L \cup L_{\mathrm{on}}\) [2603.22114].

The offline stage is explicitly driven by program comprehension. The PSA uses an LLM prompt of the form: “Given the code of \(P\) and its ACSL annotations, produce a Coq lemma \(\varphi_A\) in source terms and a proof.” From loops, pointer arithmetic, type predicates, and related patterns, it extracts high-level invariants such as “pointer increment by two preserves address order” and “if \(\mathtt{is\_uint16}(x)\) then \(0 \le x \le 2^{16}-1\).” The paper also lists template families including monotonic pointer shift,
\[
\forall p,q:\mathit{addr},\; p\leq_{\mathrm{addr}} q \Longrightarrow p+k \leq_{\mathrm{addr}} q+k,
\]
zero-shift identity,
\[
\forall p:\mathit{addr},\; \mathrm{shift}(p,0)=p,
\]
type-predicate range extraction,
\[
\forall x:\mathbb{Z},\; \mathrm{is\_uintN}(x)\Longrightarrow 0\le x\le 2^N-1,
\]
and arithmetic rewriting of \((h \ll 4)\lor l\) as \(16\cdot h + l\) [2603.22114].

The online stage is proof-state driven. At each step the prover maintains open goals \(G=\{g_1,\dots,g_m\}\), a context \(C\), and the current lemma library \(L\). Whenever standard tactics fail on some goal \(g\), the agent invokes
\[
\mathrm{adapt\_lemmas}:(C,G,L)\longrightarrow L_{\mathrm{new}},
\]
updates \(L \leftarrow L \cup L_{\mathrm{new}}\), and retries. The adaptation procedure first tries to **Refine** an existing lemma \(l \in L\), for example by fixing type or name mismatches, and then to **Generate** a new lemma by invoking the LLM on \((C,g)\) together with failure diagnostics. The underlying VCs are encoded over quantified or quantifier-free linear integer arithmetic, bitvector theory for overflow, an uninterpreted memory function \(\mathit{load}\), and pointer arithmetic axioms [2603.22114].

## 5. Deductive theory exploration as a precursor pattern

A plausible antecedent to DAP is the deductive theory-exploration framework developed for bottom-up lemma discovery. That work considers the input of algebraic inductive datatypes and a vocabulary \(V\) of constructor and recursively defined symbols, and seeks an ideally complete set of new equational lemmas
\[
\forall x_1\ldots x_n.\ s(x_1\ldots x_n)=t(x_1\ldots x_n)
\]
over \(V\) that are not already provable from the input definitions [2009.04826].

Its core inference machinery already exhibits a discover-then-prove structure. It maintains a set \(E\) of known equations and uses: **constructor introduction / structural induction** to generate base and step obligations; **congruence closure / rewrite** to treat equations in \(E\) as bidirectional rewrite rules; **symbolic observational equivalence (SOE)** to conjecture \(s=t\) when symbolic examples up to fixed depth rewrite into the same congruence-closure class; and **speculative generalization**, which replaces repeated placeholders with fresh ones and attempts to prove the more general formula first [2009.04826].

The overall pipeline proceeds by iterative deepening on term depth. A growing e-graph \(G\) contains all \(V\)-terms of depth \(\le d\), modulo congruence closure under the current \(E\). At each depth, the procedure enumerates terms, inserts them into \(G\), infers conjectures by SOE, screens out conjectures already equivalent in \(G\), and then attempts proofs by one round of structural induction on the first inductive-type placeholder. If all cases close using only congruence closure plus \(E\), the equation is added to \(E\), the e-classes are merged, and the process returns to conjecture inference so that newly discovered lemmas can seed further discoveries [2009.04826].

The running list example makes the loop concrete. Starting from the definitions of list concatenation and `filter`, depth \(d=2\) yields terms
\[
l_1 ++ (l_2 ++ l_3)
\quad\text{and}\quad
(l_1 ++ l_2) ++ l_3.
\]
SOE over symbolic examples \(l_i \in \{[], [v_1], [v_2,v_1]\}\) conjectures associativity, which is then proved by one-step structural induction on \(l_1\). Once associativity enters \(E\), the system can derive filter fusion:
\[
\forall p\, l_1\, l_2.\ \mathrm{filter}\ p\ (l_1 ++ l_2)=\mathrm{filter}\ p\ l_1 ++ \mathrm{filter}\ p\ l_2.
\]
The paper contrasts this purely deductive method with testing-based explorers such as IsaCoSy and QuickSpec/Hipster, arguing that symbolic examples, congruence closure, and shallow rewriting avoid random-testing filters and repeated SMT queries, yield more nonredundant lemmas, produce fewer spurious conjectures, and offer comparable or better runtime on standard benchmarks [2009.04826].

## 6. Empirical findings, significance, and open issues

The Hard Mode Lean 4 work evaluates DAP on four benchmarks: MiniF2F-Hard with 244 total problems and 197 “solution-style” problems, FIMO-Hard with 149 total and 70 solution-style, a Hard Mode CombiBench variant with 100 total and 45 solution-style combinatorics problems, and PutnamBench Hard Mode with 660 total and 340 solution-style problems. After rewriting, the system invokes Goedel-Prover-V2 at Pass@32. The reported table gives DAP (w/o Agent) as \(32/15\) on Putnam, \(10/2\) on Combi, \(204/171\) on miniF2F, and \(3/0\) on FIMO; DAP (w/ Agent) as \(36/19\), \(9/1\), \(201/168\), and \(3/0\), respectively. The same work states that on PutnamBench it is the first public system to solve any Hard Mode problems, with 36 total theorems, and that on CombiBench Hard Mode it improves from the prior 8 to 10 theorems solved; the abstract also reports an increase from 7 (previous SOTA, Pass@16) to 10 [2604.15839].

The discovery-only numbers are substantially higher than the formal-proof numbers. Without self-reflection, the Discovery Module achieves approximately \(78\%\) on PutnamBench and \(100\%\) on MiniF2F-Hard; with self-reflection these rise to \(86\%\) and remain at \(100\%\). By contrast, the same source states that the formal prover succeeds on under \(10\%\) of Putnam Bench problems in pure Easy Mode, and summarizes the resulting gap as over \(80\%\) answer accuracy versus under \(10\%\) formal-proof success on the same Hard Mode problems [2604.15839].

The LemmaNet instantiation reports results on 941 VCs from two suites, SV-COMP and NTP4VC, including Linux-kernel modules, Contiki OS, the standard C++ library, and an X.509 parser, with a 10 min timeout. LemmaNet proves \(298/641\) on SV-COMP and \(66/300\) on NTP4VC, for a total of 364, compared with AutoRocq at 287 total, Copra at 240, and CoqHammer at 123. The paper states a \(+26.8\%\) total improvement over AutoRocq and \(+195.9\%\) over CoqHammer, with median time per VC of approximately \(0.3\,\mathrm{s}\) on SV-COMP and \(1.0\,\mathrm{s}\) on NTP4VC, comparable to baselines [2603.22114].

Two substantive conclusions recur across these works. First, DAP exposes a structural bottleneck: discovering the right mathematical object or lemma can be much easier than converting that discovery into a fully formal proof. Second, the discovery stage is highly domain-sensitive. In Hard Mode ATP, explicit self-reflection improves answer discovery; in program verification, program comprehension bridges the gap between source-level semantics and mechanically encoded VCs. The main open challenges are also explicit in the literature: offline synthesis may miss deep domain-specific invariants, proof-state-driven generation can introduce redundancy, lemma-selection policies remain to be optimized, and extending to richer theories such as floating-point and concurrency requires new templates and adaptation strategies [2603.22114].

Taken together, these results place DAP at the intersection of theorem proving, deductive verification, and theory exploration. The common pattern is stable across domains: discover the missing object, rewrite or recontextualize the task around that object, and then prove within an existing formal kernel or ATP stack.

Source: https://www.emergentmind.com/topics/discover-and-prove-dap