---
title: Propose–Solve–Verify Paradigm
url: https://www.emergentmind.com/topics/propose-solve-verify-psv-paradigm
type: topic
---

# Propose–Solve–Verify Paradigm

The Propose–Solve–Verify (PSV) paradigm is a principled meta-algorithmic framework for structuring complex reasoning and problem-solving processes. It decomposes any target task into three iterated stages: (1) proposing or generating candidate problems, solution schemas, or intermediate goals; (2) solving or generating candidate solutions using an automated agent, algorithm, or synthesis procedure; and (3) verifying or certifying the correctness, adequacy, or optimality of the solution via formal, statistical, or executable checks. Variants of the PSV loop are now foundational in areas ranging from self-play training for large language models (LLMs) in code synthesis, to formal verification, automated program synthesis, and interactive knowledge-based configuration.

## 1. Formalization of the Propose–Solve–Verify Loop

The PSV loop comprises three formally defined components, each instantiated according to the domain and verification regime:

1. **Propose**: Generate a candidate problem, partial solution, or new intermediate target. This proposal step typically leverages a distributional generator parameterized by history, difficulty, or context.

2. **Solve**: Deploy an agent or solver to synthesize candidate solutions or fill intermediate holes. In LLM-based approaches, this is a conditional generative model; in formal settings, it can be a proof-search tactic, SMT solver, or model-expansion engine.

3. **Verify**: Certify solution validity via an external, ideally sound, feedback mechanism—e.g., running test suites, formal verification conditions, or symbolic entailment. Only solutions passing this verification are admitted for further training, adaptation, or human presentation.

Algorithmically, the PSV process alternates these stages, optionally training the proposer and solver based on verification-derived feedback, as in expert-iteration or preference-based optimization. A canonical pseudocode schema for the PSV loop in formal code generation is:

```python
# Simplified PSV Skeleton
for t in range(T):
    # Solve
    for x in problems:
        y_samples = solver.generate(x)
        verification = [verifier.check(x, y) for y in y_samples]
        successful = [(x, y) for y, v in zip(y_samples, verification) if v]
    # Update solver via successful pairs
    solver.update(successful)
    # Propose new problems based on solver's current performance
    new_problems = proposer.generate(context=solver.performance)
    problems.extend(new_problems)
```

Mathematical objectives vary: e.g., maximize expected log-probability of verified solutions for the solver, and condition proposal distribution on observed solver pass-rates for the proposer [2512.18160].

## 2. Instantiations in Program Synthesis and Verification

### LLM-Based Code and Test Generation
SOL-VER [2502.14948] operationalizes PSV for joint code and test generation using LLMs. In this setting, the loop consists of problem synthesis (“Propose”), solution synthesis (“Solve” via LLM-as-solver), and test synthesis/execution-based verification (“Verify” via LLM-as-verifier and test oracles). Correct solutions are filtered via test pass rates, and both supervised fine-tuning (SFT) and Direct Preference Optimization (DPO) are used to refine models, only on verified output. This approach yields substantial improvements on MBPP and LiveCodeBench (e.g., MBPP Pass@1 increases from 38.6% to 40.98%, TestAcc from 42.7% to 51.76%; LiveCodeBench Pass@1 from 18.2% to 27.24%) [2502.14948].

### Formal Verification Loops
In predicate constraint satisfaction (pCSP) frameworks [2007.03656], the PSV loop is realized as counterexample-guided inductive synthesis (CEGIS): templates propose candidate solutions; SMT-based solving checks the candidates; verification extracts ground counterexamples or certifies solution correctness; and templates are refined adaptively based on unsatisfiable cores. This stratified CEGIS is proved to be sound and relatively complete for pCSPs and their fixpoint logic encodings.

### Process-Verified Problem-Solving in Formal Proof Systems
FPS and D-FPS frameworks [2505.04528] cast problem solving as a deterministic Markov decision process, where proposal corresponds to tactic suggestion, solving to tactic execution in Lean 4, and verification to either formal proof replay or Restricted Propositional Equivalence (RPE) checks against human-annotated ground truths. This approach ensures process-level soundness and supports modular integration of stronger search models or equivalence criteria.

## 3. Verification Regimes: Tests vs. Formal Methods

Verification modalities in PSV directly determine the reliability of the training or search signal:

- **Unit-test Execution**: Used in LLM-based code generation; provides an empirical but unsound validation signal (solutions may pass all tests but still be incorrect).
- **SMT-Based Formal Verification**: As in Verus-based PSV [2512.18160], defines a deterministic Boolean function $v(x, y)$ that is sound by construction ($v(x, y) = 1$ iff $y$ satisfies $x$ for all inputs).
- **Symbolic/Semantic Equivalence**: RPE [2505.04528] determines if the proposed solution is not just technically correct but aligned with human formulations.

Empirical ablation demonstrates that removing sound formal verification leads to a 50–60% drop in pass@1 for code synthesis tasks [2512.18160]; unit-test-based or heuristic-only verification regimes admit reward hacking and error accumulation.

## 4. Advanced Variants: Difficulty-Curriculum and Self-Play

Recent PSV systems incorporate adaptive curriculum learning via difficulty-aware proposals. The proposer labels and stratifies problems by solver pass-rate (Easy, Medium, Hard, Impossible), then conditions future generation on underrepresented or maximally informative classes [2512.18160]. This encourages solver improvement and prevents overfitting to degenerate proposals. Empirically, excluding difficulty-awareness reduces model performance (e.g., MBPP pass@1 drops from 25.3% to 23.0%) [2512.18160].

Self-play allows PSV agents to bootstrap entirely without human data—jointly synthesizing, solving, and verifying novel tasks. In settings such as code generation with formal verification [2512.18160], this yields multi-fold improvements over inference-only or rejection-finetuning baselines (e.g., 24.1%→65.6% pass@1 on Dafny2Verus; 6.48%→36.8% on MBPP).

## 5. Applications Beyond Program Synthesis

The PSV paradigm generalizes beyond code, proof, and synthesis. In interactive model-expansion [2305.17140], users propose observations or decisions, the system propagates inferred facts according to environmental and solution-theories, and then computes which unknowns must be verified, leveraging relevance computation and unsat-core extraction to guarantee sufficient verification for termination. In such contexts, PSV reduces search effort and provides formal guarantee of correctness, as seen in property-tax registration workflows where user interactions were reduced by 56% [2305.17140].

## 6. Theoretical Guarantees and Empirical Impact

Multiple works prove soundness and completeness for specific PSV instantiations:

- **Process Soundness**: FPS and D-FPS frameworks for problem-solving in Lean 4 guarantee that any produced solution $\hat{a}$ is provable and, where backward checking is performed, is equivalent to ground-truth answers [2505.04528].
- **Relative Completeness**: Stratified CEGIS in pCSP solving ensures that if a finite-rank template exists, the loop discovers it in finite steps [2007.03656].
- **Empirical Performance**: Across code synthesis and formal problem-solving, PSV-based self-play enables 2.6–9.6× improvements over baselines, with improvements scaling smoothly with the number of generated problems and iterations [2512.18160, 2502.14948].

## 7. Limitations and Future Work

Current PSV instantiations inherit the limitations of their underlying solvers and verification oracles. Formalization burden restricts applicability in combinatorics and geometry; underfitting persists in process-split problem-solving; and scalability to broader problem domains requires more efficient proof search and curriculum learning schemes [2505.04528]. A plausible implication is that integrating richer verification regimes or hybridizing with search-guided proposal modulators could yield further gains.

---

**References**:  
- "Learning to Solve and Verify: A Self-Play Framework for Code and Test Generation" [2502.14948]  
- "Program Verification via Predicate Constraint Satisfiability Modulo Theories" [2007.03656]  
- "Interactive Model Expansion in an Observable Environment" [2305.17140]  
- "Beyond Theorem Proving: Formulation, Framework and Benchmark for Formal Problem-Solving" [2505.04528]  
- "Propose, Solve, Verify: Self-Play Through Formal Verification" [2512.18160]

Source: https://www.emergentmind.com/topics/propose-solve-verify-psv-paradigm