PBLean: Importing VeriPB Proofs into Lean 4

• PBLean is a method that imports VeriPB pseudo-Boolean proof certificates into Lean 4, ensuring formal theorem production via reflection and verified translation of solver evidence.
• It employs a two-layer design that separates an untrusted parser and native-compiled Boolean checker from a narrow trusted core of soundness lemmas, enabling scalability for large certificates.
• PBLean integrates verified encodings and bridge theorems to connect unsatisfiability proofs with original combinatorial problems, as illustrated in the Paley graph independence case study.

Searching arXiv for the specified paper to ground the article in the current record. PBLean is a method for importing VeriPB pseudo-Boolean proof certificates into Lean 4, with the aim of converting solver-generated pseudo-Boolean evidence into Lean theorems that are usable inside larger formal developments (Szeider, 9 Feb 2026). Its central technical device is reflection: a Boolean checker whose soundness is proved in Lean and whose execution is delegated to compiled native code. The system is designed for pseudo-Boolean proofs large enough that explicit proof-term construction would exhaust memory, and it supports all VeriPB kernel rules, including cutting-plane derivations and proof-by-contradiction subproofs. PBLean also includes verified encodings so that the final theorem can be stated about the original combinatorial problem rather than only about a pseudo-Boolean constraint set, thereby formalizing both the translation and its correctness.

1. System architecture and trusted core

PBLean is a standalone Lean 4 project with no Mathlib dependency. It is organized into two layers. The kernel layer, implemented in PseudoBoolean.lean and described as approximately 700 lines, defines the basic objects of pseudo-Boolean reasoning: literals, terms, constraints, valuations, a Boolean satisfiability predicate sat : Constr → Valuation → Prop, and 13 soundness lemmas for the six primitive VeriPB operations (Szeider, 9 Feb 2026). The reflection layer, implemented in Reflect.lean and described as approximately 1800 lines, provides an untrusted parser from VeriPB’s kernel proof format into an abstract syntax tree of proof steps together with a purely functional Boolean checker $k>0,\;(T,d)\;\vdash\;(\{(k·a,\ell)\mid(a,\ell)\in T\},\;k·d)$2 that replays the proof over a mutable, array-backed constraint database.

The workflow is explicitly staged. An OPB problem is passed to a PB solver together with veripb --elaborate, producing a kernel proof π in VeriPB format. PBLean’s reflect command then performs untrusted parsing and invokes native_decide check F π, yielding a Lean theorem that the pseudo-Boolean formula F is unsatisfiable. A bridge theorem, composed with encoding correctness, then produces the final Lean theorem about the original combinatorial problem. The trusted base is correspondingly narrow: the only proof term seen by Lean’s kernel is the one generated by native_decide, so the trust base is Lean’s kernel plus the 13 soundness lemmas, with no heavy tactics or large explicit proof terms.

This organization distinguishes between untrusted operational components and trusted semantic components. The parser and runtime implementation may be optimized aggressively, but the semantic guarantee rests on a proved correspondence between the Boolean checker and unsatisfiability.

2. Reflection-based checking and theorem production

The checker is structured around replay of proof steps: $k>0,\;(T,d)\;\vdash\;(\{(k·a,\ell)\mid(a,\ell)\in T\},\;k·d)$3 Its proved soundness statement is $k>0,\;(T,d)\;\vdash\;(\{(k·a,\ell)\mid(a,\ell)\in T\},\;k·d)$4 with $k>0,\;(T,d)\;\vdash\;(\{(k·a,\ell)\mid(a,\ell)\in T\},\;k·d)$5 and, equivalently, $k>0,\;(T,d)\;\vdash\;(\{(k·a,\ell)\mid(a,\ell)\in T\},\;k·d)$6 (Szeider, 9 Feb 2026)

A key implementation detail is the use of $k>0,\;(T,d)\;\vdash\;(\{(k·a,\ell)\mid(a,\ell)\in T\},\;k·d)$7 which replaces calls to check at runtime by a low-level array-based implementation when Lean is compiled with native_compile. At kernel time, Lean validates only the equation lemmas about check and the application of check_sound. This division is central to PBLean’s scaling behavior: operational work is performed by native code, while the logical kernel sees only a compact reflective certificate.

The proof of check_sound proceeds by induction on π.steps. Each applyStep must preserve the invariant that every derived constraint is a sound consequence of the initial formula F. When the final step derives a contradictory constraint, the primitive lemma contra_unsat is used to conclude unsatisfiability. The paper characterizes the required reasoning as elementary arithmetic over ℕ and finite sums, rather than as large-scale proof reconstruction.

3. VeriPB kernel coverage and soundness lemmas

PBLean supports all VeriPB kernel rules in version 3.0. The supported rule-types are pol, rup, pbc, del, sol or soli, and conclusion. The system demands final conclusion UNSAT and additionally requires that the last step actually derive a contradictory constraint (Szeider, 9 Feb 2026).

The following table summarizes the supported operations and the corresponding Lean lemmas exactly as described.

Operation class	Rule or transformation	Lean lemma
Cutting planes	add	add_sat : sat c₁ → sat c₂ → sat (c₁ +ₚ c₂)
Cutting planes	mul	mul_sat : 0<k → sat c → sat (k⋅ₚ c)
Cutting planes	div	div_sat : 0<k → sat c → sat (c.div_by k)
Cutting planes	saturate	saturate_sat : sat c → sat (c.saturate)
Normalization	cancel pair	cancel_pair_sat : … → sat … → sat …
Normalization	remove zero	remove_zero_sat
Normalization	merge terms	merge_terms_sat
Axioms / contradiction	lit axioms	lit_axiom_pos/neg : ∀ v, sat ([1⋅ℓ],0) v
Axioms / contradiction	contradiction	contra_unsat : coeffSum c < c.deg → ¬ sat c v
Negation / pbc	negation	negate_sat_of_not : … → ¬ sat c → sat c.negate
Negation / pbc	propagation	propagation_forces : … → sat (T,d) v → coeffSum(T\{…})<d → evalLit v ℓ = 1
Negation / pbc	proof by contradiction	pbc_sound

For pol, PBLean supports addition, scalar multiplication, division by a positive scalar, and saturation. The corresponding pseudo-Boolean derivations are given explicitly: $(T_1,d_1),\;(T_2,d_2)\;\vdash\;(T_1 \mathbin{++} T_2,\;d_1+d_2)$ for addition,

$k>0,\;(T,d)\;\vdash\;(\{(k·a,\ell)\mid(a,\ell)\in T\},\;k·d)$

for scalar multiplication, and

$0<k,\;(T,d)\;\vdash\;(\{\bigl(\lceil a/k\rceil,\ell\bigr)\},\,\lceil d/k\rceil)$

for division. The rup rule is justified by negating the target constraint, performing unit propagation to conflict, and using propagation_forces together with lit_axiom_pos/neg. The pbc rule is implemented by inlining a subproof under an assumed negation and then discharging that assumption via pbc_sound; operationally, this uses snapshot and restore of the database together with a recursive call to applyStep. Deletion is justified by monotonicity, since deleting constraints cannot convert an UNSAT proof into a satisfiable one. Solution logging is treated only for checking [SAT](https://www.emergentmind.com/topics/semantic-aware-token-masking-sat) verdicts and is explicitly noted as not covered in the note.

This full kernel coverage is significant because it means PBLean does not rely on a restricted fragment of VeriPB. A plausible implication is that the system is intended as a faithful certificate consumer for full elaborated kernel proofs rather than as a translator for a simplified intermediate format.

4. Scalability via reflection

The paper contrasts two proof-production strategies: explicit proof-term construction, labeled “Direct,” and the reflective checker architecture. Under direct construction, one builds a large Expr for each proof step; the reported consequence is out-of-memory behavior or extreme slowdown once proofs exceed a few thousand steps. Under reflection, Lean receives a single kernel proof term, namely one application of check_sound to a Boolean equality. All detailed proof replay is delegated to the native implementation of check (Szeider, 9 Feb 2026).

The reported benchmark data are as follows.

$p$	Lines	Direct(ms)	Reflect(ms)
13	35	1 150	802
29	233	19 922	926
41	704	TO (> 60 000)	1 536
73	9 808	TO	20 616
101	62 924	TO	200 460

The same benchmark block also records Vars and Cstrs values: for $p=13$, 13 variables and 40 constraints; for $p=29$, 29 variables and 204 constraints; for $p=41$, 41 variables and 411 constraints; for $p=73$, 73 variables and 1 315 constraints; and for $p=101$, 101 variables and 2 526 constraints. On the largest Paley instance, described as approximately 63 000 proof lines, the reflection checker takes approximately 200 seconds, whereas direct proof terms do not complete in an hour.

The quantitative comparison is used to motivate reflection not merely as a convenience layer but as an architectural necessity for large certificates. The system’s central claim about scalability is therefore not that proof checking becomes asymptotically trivial, but that the kernel-facing proof artifact remains compact even when the operational replay is substantial.

5. Verified encodings and bridge theorems

PBLean’s certificates establish unsatisfiability of a pseudo-Boolean formula $F$, but the system is designed to recover theorems about the original combinatorial domain. To do this, it introduces verified encodings and bridge theorems. The encoding function for the independent set problem is presented schematically as $k>0,\;(T,d)\;\vdash\;(\{(k·a,\ell)\mid(a,\ell)\in T\},\;k·d)$8 with a correctness theorem $k>0,\;(T,d)\;\vdash\;(\{(k·a,\ell)\mid(a,\ell)\in T\},\;k·d)$9 (Szeider, 9 Feb 2026)

The bridge step then composes certificate checking with encoding correctness: $0<k,\;(T,d)\;\vdash\;(\{\bigl(\lceil a/k\rceil,\ell\bigr)\},\,\lceil d/k\rceil)$0 A user-facing wrapper is described by $0<k,\;(T,d)\;\vdash\;(\{\bigl(\lceil a/k\rceil,\ell\bigr)\},\,\lceil d/k\rceil)$1 and is said to expand to parsing, veripb --elaborate, check, and the composition of the two lemmas.

This mechanism addresses the trust gap between solver output and problem semantics. The paper states that both the constraint translation and its correctness proof are formalized in Lean. The resulting theorem is therefore not merely a statement that a generated pseudo-Boolean encoding is inconsistent, but a theorem in the vocabulary of the underlying mathematical problem. In the context of interactive theorem proving, that distinction is substantial because the derived result can be reused compositionally as a lemma in subsequent formal developments.

6. Case study: Paley graph independence

The paper’s principal worked example concerns independence numbers of Paley graphs. For G = paley p, the target question is whether $k>0,\;(T,d)\;\vdash\;(\{(k·a,\ell)\mid(a,\ell)\in T\},\;k·d)$0 has an independent set of size at least $k>0,\;(T,d)\;\vdash\;(\{(k·a,\ell)\mid(a,\ell)\in T\},\;k·d)$1. The OPB instance is generated with the constraint $0<k,\;(T,d)\;\vdash\;(\{\bigl(\lceil a/k\rceil,\ell\bigr)\},\,\lceil d/k\rceil)$2 A PB solver together with veripb --elaborate produces an UNSAT kernel proof π, and Lean then combines reflective checking with encoding correctness (Szeider, 9 Feb 2026).

The Lean theorem schema is given as $0<k,\;(T,d)\;\vdash\;(\{\bigl(\lceil a/k\rceil,\ell\bigr)\},\,\lceil d/k\rceil)$3 For concrete primes, the wrapper can be invoked as $0<k,\;(T,d)\;\vdash\;(\{\bigl(\lceil a/k\rceil,\ell\bigr)\},\,\lceil d/k\rceil)$4

The benchmark suite also yields $0<k,\;(T,d)\;\vdash\;(\{\bigl(\lceil a/k\rceil,\ell\bigr)\},\,\lceil d/k\rceil)$5 which is described as following from a verified upper bound via PBLean together with a trivial lower-bound witness in each case.

This example shows the intended use pattern of PBLean: a solver and certificate generator establish infeasibility in the pseudo-Boolean domain, while Lean internalizes both the certificate and the semantic interpretation. A plausible implication is that PBLean is suited not only to isolated unsatisfiability checks but also to theorem-producing workflows in extremal combinatorics and related finite-domain problems.

7. Scope, guarantees, and limitations

PBLean is explicitly contrasted with external verified checkers that produce verdicts. Its integration instead yields Lean theorems, which can then be used as composable lemmas in larger formal developments (Szeider, 9 Feb 2026). This difference is both logical and practical. A verdict checker answers whether a proof is valid; PBLean additionally packages the result as a theorem in Lean’s environment.

The system’s guarantees are correspondingly specific. The parser is untrusted, the runtime implementation used via [implemented_by] is untrusted as executable code, and the proof format replay is validated through the proved soundness of the logical checker. The trusted core therefore consists of Lean’s kernel and the proved soundness lemmas. The paper presents this as closing the trust gap between solver output and problem semantics, because the encoding and its correctness proof are also formalized.

The scope is not universal. The note states that sol and soli are treated only to check SAT verdicts and are not covered there. PBLean also requires a final UNSAT conclusion and an actually derived contradictory constraint. These conditions indicate that the paper’s main focus is reflective certification of unsatisfiability proofs rather than a complete treatment of all solver outputs.

A common misunderstanding would be to view PBLean as simply a faster proof checker. The paper’s presentation suggests a more precise characterization: speed and memory behavior are consequences of reflection, but the primary contribution is the transformation of pseudo-Boolean certificates into Lean theorems with verified semantic bridges. Another potential misunderstanding is to treat the pseudo-Boolean certificate alone as sufficient for formalized combinatorial mathematics; PBLean’s verified encoding layer is included precisely because unsatisfiability of an encoding and impossibility of the original combinatorial object are distinct statements until connected by a proved bridge theorem.