VerIbmc: Local Neuro-Symbolic Invariant Synthesis
- The paper presents VerIbmc, a neuro-symbolic invariant synthesis system that combines deterministic symbolic invariant generation with local open-weight language models and an SMT-based verifier.
- It employs an escalate-only-as-needed pipeline that utilizes baseline verification, deterministic candidate generation, and iterative LLM refinement to tackle hard instances.
- Experimental evaluations on 499 C programs across multiple benchmarks demonstrate competitive verification performance while ensuring industrial privacy, reproducibility, and resource efficiency.
Searching arXiv for the primary paper and closely related invariant-synthesis work to ground the article. arxiv_search query="(Pirzada et al., 15 Jun 2026) Neuro-Symbolic Software Verification VerIbmc" max_results=5 sort_by="relevance" VerIbmc is a neuro-symbolic loop invariant synthesis and verification system that couples deterministic symbolic reasoning with locally served, open-weight LLMs and a sound SMT-based back end, ESBMC. Its stated goal is to reduce the bottleneck of invariant discovery in deductive and model-checking workflows while meeting industrial requirements for privacy, reproducibility, and resource efficiency by avoiding proprietary cloud APIs. The system follows an escalate-only-as-needed design: it first attempts baseline verification, then performs deterministic symbolic invariant synthesis, and invokes an LLM only on residual hard instances, with all candidate invariants discharged in ESBMC’s loop-invariant mode with k-induction (Pirzada et al., 15 Jun 2026).
1. Problem setting and verification objective
Loop invariant synthesis is presented as central yet undecidable. For many practical C programs, correctness hinges on discovering an inductive invariant that both strengthens the precondition and is preserved by the loop body. In the Hoare-logic formulation used by VerIbmc, an inductive invariant must satisfy three obligations:
- Initiation:
- Consecution (preservation):
- Sufficiency:
Here is the precondition up to the loop head, is the guard, is the loop body, and is the postcondition. Without , weakest preconditions or VC generation cannot proceed. The paper therefore positions invariant synthesis as the core bottleneck across automated verification tools (Pirzada et al., 15 Jun 2026).
VerIbmc is designed for the setting in which recent neuro-symbolic systems would otherwise rely on cloud LLMs. The reported motivation is explicitly industrial: source code may not be allowed to leave the organization; uncontrollable model upgrades and nondeterminism create reproducibility and compliance challenges; and recurring API costs and energy use are operational concerns. By running entirely on a single local machine with open-weight models served via Ollama, the approach is intended to preserve source confidentiality, eliminate API costs, and improve reproducibility and energy efficiency.
2. Pipeline architecture and phase structure
The workflow comprises three tightly integrated phases. In Phase 0, ESBMC is run on the unannotated program . If ESBMC proves safety or finds a concrete counterexample, the pipeline terminates immediately, spending no synthesis budget on problems the verifier can already decide. In Phase 1, VerIbmc performs deterministic symbolic candidate generation. At each loop 0, it enumerates atomic predicates over live variables 1 and integer constants 2 appearing in the body:
3
Each atom is submitted to ESBMC for inductivity checking. Provable atoms are placed in 4, disprovable atoms in 5, and unknown atoms in 6. The conjunction 7 is then tested against the postcondition; if it suffices, VerIbmc terminates without any LLM call (Pirzada et al., 15 Jun 2026).
In Phase 2, VerIbmc enters an iterative LLM refinement loop. For each loop, it constructs a prompt containing the loop source and the three stores 8 as structured feedback. The LLM proposes invariant candidates 9. VerIbmc first attempts whole-program verification with 0; if successful, it terminates. Otherwise, it decomposes 1 into propositional atoms, submits each atom to ESBMC for inductivity checking, updates 2, and tests the recombined conjunction 3 again. This loop continues until success, Unknown, or timeout.
A notable design choice is that counterexamples are not fed directly to the LLM. The authors report that they experimented with including ESBMC traces but found that long context degraded performance for smaller models. The compact atom stores are used instead as verifier feedback. The resulting loop is described as akin to CEGIS, but the refinement is driven by atomic clause classification and recombination rather than explicit trace replay (Pirzada et al., 15 Jun 2026).
3. Formal foundations and ESBMC integration
ESBMC is the verification oracle throughout the system. It supports C/C++ through an LLVM/Clang-based front end and also has front-ends beyond C/C++ such as Python. Programs are compiled to a GOTO IR; ESBMC supports pointer analysis, array bounds checks, arithmetic overflow detection, and SMT-LIB2-based interaction with solvers including Z3, Boolector, MathSAT, Yices, and Bitwuzla. In VerIbmc, user-supplied invariants are injected at loop heads, and ESBMC checks initiation and consecution via k-induction, with sufficiency enforced through the postcondition clause of the whole-program VC (Pirzada et al., 15 Jun 2026).
Two VC forms are central. For an atomic candidate 4, the inductivity test is
5
where pre is the path condition to the loop head, 6 is the guard, body is the transition relation of the loop body, and 7 denotes 8 over primed post-body variables. For a conjunction 9 of provably inductive atoms, whole-program verification uses
0
where 1 is the postcondition. Success implies that all three invariant obligations are satisfied simultaneously.
The symbolic phase has an explicit complexity characterization. For 2 live variables and 3 integer constants in a loop, the number of enumerated atoms is
4
Self-comparisons such as 5 are filtered. The paper states that enumeration is quadratic in 6 and linear in 7, and remained tractable for the benchmark set. Most experiments use unbounded integer semantics, denoted as LIA/LRA, to align with prior tools, though ESBMC also supports bit-precise bit-vector semantics when desired. Non-linear arithmetic appears in the NL suite; there, VerIbmc relies on the LLM to propose polynomial clauses, which ESBMC then checks.
4. Prompting regimes and atom-driven refinement
VerIbmc implements two prompting regimes in Phase 2: Chain-of-Thought (CoT) and Tree-of-Thought (ToT). In the CoT regime, a few-shot prompt elicits step-by-step derivation of invariants. Four derivation styles are available: inductive with explanation, inductive without explanation, Hoare-logic derivation, and Horn-clause derivation. The prompt includes the loop’s C code, the current 8 stores, and syntactic guidance for invariants intended to reduce parse errors. The paper also states that zero-shot CoT using “Let’s derive the invariant step by step” works (Pirzada et al., 15 Jun 2026).
The ToT regime is a two-stage search over the same four derivation styles. Stage 1 issues one call per style and scores each strategy 9 by the inductive atoms it yields:
0
Provable atoms are rewarded, disprovable atoms are penalized, and unknown atoms receive a small positive weight. The top-2 strategies proceed to a bounded refinement loop with 1, and re-ranking occurs every 6 rounds. Solutions are selected by successful discharge of 2.
Phase 1 is not merely a preprocessing stage; it establishes what the paper describes as a verified floor of invariant knowledge. Its templates are all pairwise linear comparisons among variables and constants, and its recombination mechanism tests whether 3 suffices to prove the assertion. The reported impact is substantial: 75 problems are solved by Phase 1 alone across the benchmark pool, deterministically and without any LLM call. Beyond these cases, the structured stores 4 consistently help weaker models. The Basic pipeline gains up to approximately +35 solves over LLM-Only for the weakest model, Llama-3.1-8B; the detailed ablation reports +36. The aggregate conclusion is that ToT can add diversity and occasionally reach instances missed by CoT, but it consumes more wall-clock time and often yields only small deltas for strong models, while weaker models may underperform because scouting consumes budget.
5. Experimental evaluation, models, and benchmark coverage
All inference runs locally via Ollama on Ubuntu 22.04.5 with four NVIDIA RTX A6000 GPUs of 48 GB each, and ESBMC v8.2 serves as verifier. No fine-tuning is used. The five evaluated open-weight models span 7B to 120B parameters: GPT-OSS-120B, GPT-OSS-20B, Qwen2.5-32B-Instruct, Qwen2.5-7B-Instruct, and Llama-3.1-8B. Default temperatures are 1.0 for GPT-OSS and 0.8 for the others. Phase-2 iteration budgets are described as modest; ToT uses 5, and CoT converges in at most 10 rounds for 88% of successes (Pirzada et al., 15 Jun 2026).
The benchmark pool contains 520 problems, of which 21 are excluded because of unavoidable overflow under machine-integer semantics, leaving 499 effective problems. The five benchmark families are as follows:
| Family | Count | Characterization |
|---|---|---|
| Code2Inv (C2I) | 133 | Scalar integer, single-loop programs |
| LaM4Inv-SVCOMP24 (L4I-SVC) | 99 | SV-COMP subset |
| LaM4Inv-SyGuS19 (L4I-SY) | 84 | SyGuS loop suite |
| Clause2Inv Non-Linear (NL) | 50 | Polynomial invariants |
| SV-COMP (SVC) | 154 | Arrays, nested/multiple loops, pointers, function calls |
The headline single-run Basic results are:
| Model | Solved |
|---|---|
| GPT-OSS-120B | 431/499 = 86.4% |
| GPT-OSS-20B | 424 |
| Qwen2.5-32B | 382 |
| Qwen2.5-7B | 352 |
| Llama-3.1-8B | 342 |
For the best single configuration, GPT-OSS-120B with Basic, the per-suite performance is reported as C2I 127, L4I-SVC 87, L4I-SY 77, SVC 85, NL 41, plus 14 integer-relaxed solves. On the four benchmark suites shared with the strongest cloud-API tools, VerIbmc is reported as competitive while running only on a single local machine. The comparison given in the paper is: Clause2Inv (GPT-4o-mini) at 356, LORIS (GPT-4.1) at 351, LaM4Inv (GPT-3.5/GPT-4 variants) at 338, and VerIbmc at 348 when taking the union across all single-LLM strategies. On the comparable SV-COMP subset of 43 programs expressible by those front-ends, LORIS solves 39, VerIbmc 36, Clause2Inv and LaM4Inv 30, pure ESBMC 5, CPAchecker 19, 2ls 14, and Code2Inv 11.
The runtime profile is strongly front-loaded. Across all models and strategies, 65.1% of LLM-solved problems succeed on the first iteration, 85.1% within five iterations, and 88% within ten; the maximum observed is 171 iterations. Phase 1 and the atom filtering and recombination steps add negligible time relative to LLM inference. ToT can introduce up to approximately 6 wall-clock overhead for some weak models.
6. Illustrative example, limitations, and operational implications
A representative example from the Code2Inv suite is the loop
9
Phase 1 enumerates atoms over 7 and 8. ESBMC proves 9 and 0, while atoms constraining 1 alone are disprovable because 2 is unconstrained at entry. Since 3 is insufficient to prove 4, Phase 2 begins. Suppose the LLM proposes
5
Whole-program verification fails because 6 is not inductive. VerIbmc decomposes the proposal, classifies 7 as disprovable and 8 as provable, and recombines the invariant as
9
At loop exit, 0 implies 1, hence 2. Combined with 3, this yields 4, so 5 holds. ESBMC discharges 6, 7, and 8, and the pipeline terminates with a sound proof (Pirzada et al., 15 Jun 2026).
The reported limitations are correspondingly concrete. Complex non-linear invariants are harder, and weaker models struggle on the NL suite. ToT’s diversity often comes with an accuracy and runtime cost for weak models. Prompt sensitivity and malformed outputs increase UNKNOWN outcomes for some models and strategies. Raw counterexample traces were found to degrade performance for smaller models, which is why feedback is kept compact. Most experiments assume unbounded integer semantics, and 21 problems with unavoidable machine-integer overflow are excluded, although ESBMC can be configured for bit-vector semantics. The paper also notes small run-to-run variability from LLM sampling, the use of best-of-three pass@k reporting for the strongest configuration, and the possibility of benchmark contamination because the programs are public.
The practical guidance given is to prefer the Basic pipeline with a locally served, capable open-weight model for privacy-constrained industrial adoption; to prefer CoT for throughput and enable ToT selectively on hard cases; to keep iteration budgets modest, since most solvable instances close early; and to configure ESBMC semantics to match the target, using bit-vectors to detect real overflows and unbounded integers for abstract competition-style comparisons. VerIbmc is also proposed as a CI component: Phase 0 closes a sizable fraction of problems, Phase 1 closes many more without any LLM call, and Phase 2 addresses the remaining hard frontier.
Reproducibility is part of the system’s positioning. The full implementation and benchmark harness are available at https://zenodo.org/records/20690105; scripts include per-suite configuration, 600-second timeouts per problem, and prompt templates for the four derivation styles. The paper’s overall conclusion is that locally deployable, open-weight LLMs paired with a strong SMT back end and a deterministic symbolic floor can deliver competitive invariant synthesis at scale while preserving privacy and reducing cost and energy, with the Basic pipeline consistently dominating and CoT converging rapidly for the vast majority of instances (Pirzada et al., 15 Jun 2026).