PyVeritas: Verifying Trees and Python Programs

• PyVeritas is a dual framework that verifies both tree ensembles through A*-style search and Python programs via LLM-based C transpilation.
• It employs a clique-based exploration and relaxed scoring in tree ensembles to certify robustness, fairness, and generate counterexamples efficiently.
• For Python code, it uses bounded model checking with CBMC and MaxSAT fault diagnosis to precisely localize errors after transpiling code to semantically faithful C.

PyVeritas refers to two distinct verification frameworks in the literature: the first is a Python implementation of VERITAS for property verification over tree ensembles (notably, random forests and gradient boosting decision trees), while the second is a recent LLM-enabled system targeting the formal verification and fault localisation of Python programs via transpilation to C. Both frameworks address core challenges in program and model verification, though they operate in different domains—machine learning model guarantees and general-purpose program correctness, respectively. This article synthesizes both uses and their respective technical underpinnings.

1. Verification of Tree Ensembles: The Veritas Algorithm and PyVeritas Implementation

PyVeritas, as published in the context of machine learning verification, implements the VERITAS algorithm for property checking in tree ensemble models such as random forests (RFs) and gradient-boosted decision trees (GBDTs). VERITAS views verification tasks (robustness, fairness, dominance, etc.) as generic constrained optimization problems:

• General Two-Instance Formulation:

$$\max_{x^{(1)},\,x^{(2)}\in\mathcal X} [T_2(x^{(2)}) - T_1(x^{(1)})] \quad\text{s.t.}\quad C(x^{(1)}, x^{(2)})$$

Here $T_1$, $T_2$ are trained ensembles on input space $\mathcal X$, and $C$ encodes side constraints. Robustness and adversarial queries reduce to single-instance maximization.

• Search Space: Instead of relying on MILP or SMT-based encoding, VERITAS uses a clique-based exploration of the exponentially large space defined by the leaf-overlap graph of the ensemble. Each search state corresponds to a partial clique across tree leaves with non-empty joint boxes.
• A* Anytime Search: The algorithm employs a best-first (A*-style) search using:
  • $g(s)$: Accumulated sum of partial clique leaf values.
  • $h(s)$: Admissible heuristic—maximal extension value across remaining trees.

The first time a full-depth state is removed from the frontier, the true maximum is obtained. During incomplete runs, all states yield valid upper ($b$) and lower ($b^-$) bounds: - Upper bound: best $f(s)$ among open nodes. - Lower bound: best complete (full clique) found.

Relaxed scoring $T_1$0 (for $T_1$1) enables rapid anytime suboptimal solutions, tightening as $T_1$2.

• API Structure: PyVeritas exposes:
  • Model wrappers: Model.from_xgboost, Model.from_sklearn, Model.from_joblib
  • Query types: Query.robustness, Query.fairness, Query.dominance
  • Solver: Verifier.solve, with customizable time/memory limits and $T_1$3-scheduling.
• Practical Examples: Robustness certification, fairness gap maximization, and concrete counterexample generation are supported, with example workflows for both scikit-learn and XGBoost models.

2. PyVeritas for Python Program Verification via LLM-Based C Transpilation

A distinct line of work introduces PyVeritas as a verification pipeline for Python programs, leveraging LLMs for high-level transpilation to C, and then using mature verification infrastructure available for C:

• Motivation: Python lacks model checkers capable of handling realistic code. Existing tools (e.g., ESBMC-Python) support at most shallow, loop-free code, while traditional transpilers (Cython, shedskin) produce unmanageable and verbose C not suited for analysis.
• Pipeline Architecture:

1. LLM-Based Transpilation: Python code (including assert-style specifications) is converted into idiomatic, semantically faithful C. The system currently targets small, contest-style Python programs—excluding advanced Python features like dynamic typing, classes, or exceptions.
2. Sanity Checking: The C code is compiled and tested for consistency.
3. Formal Verification: Bounded Model Checking (CBMC) is applied to the C code, using loop unwinding up to a default bound ($T_1$4), and verifying all translated assertions.
4. Fault Localisation: If verification fails, the C counterexample is analysed via MaxSAT-based diagnosis (CFaults), mapping faulty C statements to their Python origins through iterative LLM prompting.

• Transpilation Success Rates:

| LLM | LiveCodeBench | Refactory | |-------------|--------------|-----------| | Qwen (32B) | 83.7% | 92.0% | | Deep (16B) | 65.1% | 64.8% | | Gra (8B) | 55.9% | 52.0% | | Lla (3B) | 43.0% | 28.0% |

The LLM's effectiveness is further enhanced by providing intent descriptions and interactive correction of failed transpilation attempts.

• Specification Preservation: For each Python program $T_1$5 and input $T_1$6, the mapping aims to preserve (bounded) execution semantics:

$T_1$7

where $T_1$8 is the transpiled C program, and $T_1$9 denotes execution semantics.

3. Bounded Model Checking and MaxSAT-Based Fault Diagnosis

• Bounded Model Checking (CBMC):
  • The LLM-generated C is wrapped in a driver that tests the original Python assertions, using CBMC's --unwind k to control loop coverage.
  • The CBMC analysis proceeds on the formula:

  $T_2$0

  where $T_2$1 is the generated program and $T_2$2 is the conjunction of assertions. - If the formula is unsatisfiable, all properties are verified up to $T_2$3.

• MaxSAT-Based Localisation (CFaults):
  • When a counterexample is found, the execution trace is encoded as a CNF formula. Each statement corresponds to a soft variable $T_2$4, with hard clauses enforcing control/data flow.
  • The MaxSAT objective seeks the minimal set $T_2$5 whose disabling restores consistency, i.e., the likely faulty statements.
  • Example formula:

  $T_2$6

  Minimizing $T_2$7 isolates errors.

• Mapping Faults Back to Python: The identified faulty C snippet is then translated by the LLM back into the corresponding Python statement.

4. Empirical Results and Usage Scenarios

• Benchmarks: LiveCodeBench (479 programs) and Refactory (2,447 programs, 125 sampled) are used for evaluation, with injected fault types—wrong binary operators and assignment duplication—used to measure localisation effectiveness.
• Fault Localisation Performance (WBO mutation, Refactory):

| Model | % Bug Localised | % Spurious | % Code Fixed | % Compilation Error | |-------|----------------|------------|--------------|--------------------| | Qwen | 36.2 | 14.3 | 49.5 | 0 | | Deep | 31.4 | 19.0 | 44.8 | 4.8 | | Gra | 52.4 | 29.5 | 8.6 | 9.5 | | Lla | 30.5 | 23.8 | 3.8 | 41.9 |

A plausible implication is that while LLMs can “heal” some faults during transpilation, this can reduce localisation recall, and smaller models are less reliable especially as code complexity grows.

• Workflow Example: In the case study of the Python function distributeCandies, an artificial fault is preserved through transpilation by the Qwen model, detected by CBMC, and then isolated to the precise line via MaxSAT/CFaults, before being mapped back to the original Python code.

5. Limitations and Open Challenges

• Model Verification: For ensemble models, VERITAS (and thus PyVeritas) scales to tree ensembles with hundreds of trees (depth 8–10), achieving >99% proof rate for MNIST robustness and up to 95% success on large constraint tasks, with runtime and memory advantage over MILP competitors such as MERGE. Its bound gaps remain below 1% in most feasible cases.
• Program Verification: For Python code, PyVeritas currently supports only a subset of the language—primarily simple, contest-style functions without classes, exceptions, nested functions, or dynamically typed containers. Scaling CBMC and MaxSAT-based techniques to non-trivial, real-world Python codebases remains nontrivial and open.
• LLM Transpilation Risks: LLMs can introduce new errors during transpilation or inadvertently “fix” known faults, complicating systematic fault localisation. Ensuring semantic preservation remains nontrivial, especially in the absence of rich specification or with complex constructs.
• Mapping Complexity: Translating between C and Python remains straightforward only for in-scope constructs; handling heap objects, pointers, or advanced C features requires substantial bookkeeping.

6. Context and Significance

PyVeritas, in both its incarnations, exemplifies current strategies for leveraging existing verification tooling—either by exploiting algorithmic structure in tree ensembles for ML verification (Devos et al., 2020), or by harnessing the maturity of C program checkers via LLM-powered semantic bridges for Python correctness (Orvalho et al., 11 Aug 2025). Both approaches underline the importance of formal methods in high-level, widely used environments (ML pipelines, Python ecosystems), and the practical need for soundness, counterexample generation, and interpretable fault diagnosis.

A plausible implication is that as LLMs and verification backends advance, the gap between specification-driven verification and practical deployment for both models and code may narrow further. Current limitations, such as language coverage, scalability, and semantic fidelity in translation, represent active areas for research. PyVeritas provides both a technical template and a benchmark for assessing future progress in property verification and program correctness analysis.