Skip to content
Back to skills

Formal Theorem Verifier Lean4

ASecurity

Formal theorem verification with Lean 4, Dafny, and mathematical invariant gating / Verifikasi teorema formal dengan Lean 4, Dafny, dan gerbang invarian matematika.

  • 125 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added November 12, 2026
ai-agentstypescriptrustgoreactnoderailstestinggitperformance

Security analysis

A100/100

Scanned November 12, 2026

npx -y skills add roedyrustam/vibes-plug --skill formal-theorem-verifier-lean4 --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Formal Theorem Verifier Lean4?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Formal Theorem Verifier Lean4
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/roedyrustam-formal-theorem-verifier-lean4-vibes-plug/badge)](https://www.skillsdirectory.com/skills/roedyrustam-formal-theorem-verifier-lean4-vibes-plug)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: formal-theorem-verifier-lean4
description: "Formal theorem verification with Lean 4, Dafny, and mathematical invariant gating / Verifikasi teorema formal dengan Lean 4, Dafny, dan gerbang invarian matematika."
author: "Roedy Rustam"
version: "4.8.0"
---

# Formal Theorem Verifier Lean 4 (Mathematical Zero-Hallucination Gate)

[English](#english) | [Bahasa Indonesia](#bahasa-indonesia)

---

<a name="english"></a>
## English

### Executive Directive & The Formal Proof Mandate
Unit tests and integration test suites can only prove the presence of bugs in tested pathways; they can never mathematically guarantee the total absence of edge-case bugs. In high-stakes mission-critical systems (fintech ledgers, smart contracts, cryptographic protocols, autonomous billing state machines), probabilistic testing is insufficient.

**Formal Theorem Verifier Lean 4** acts as an uncompromisable mathematical gate:
1. **Interactive Theorem Proving (ITP)**: Encodes critical domain invariants into formal Lean 4 theorems and inductive types.
2. **Automated Tactic Verification**: Executes `lake build` or Lean 4 REPL subprocesses to rigorously verify proofs using tactics (`simp`, `omega`, `bv_decide`, `induction`).
3. **Formal Invariant Translation**: Bridges high-level TypeScript/Rust state machines into formal Dafny and Lean 4 lemmas, refusing pull requests if proofs fail or contain unverified axioms (`sorry`).

### Hard Guardrails (Declarative Invariants)
- **Zero Sorry or Admit Stubs**: Never merge a Lean 4 file containing `sorry`, `admit`, or unproven stubs; CI must compile with `-DwarningAsError=true`.
- **Zero Custom Unchecked Axioms**: Never introduce custom `axiom` declarations to bypass proof obligations; model assumptions explicitly as theorem hypotheses.
- **Exact Integer & BitVector Arithmetic**: Never model currency, balances, or protocol counters with `Float` in formal specifications; use `Int`, `Nat`, or fixed-width `BitVec n`.
- **Pinned Toolchain & Mathlib Revision**: Pin the exact Lean compiler version in `lean-toolchain` and lock `mathlib` to a specific Git revision in `lakefile.toml`.
- **Decidable Tactics First**: Prefer deterministic decision procedures (`omega` for linear integer arithmetic, `bv_decide` for fixed-width bitvectors, `decide` for finite decidable propositions) to keep proofs fast and maintainable.
- **Spec-to-Implementation Conformance Bridge**: Pair every proved Lean 4 domain theorem with a property-based conformance test (`fast-check` / `proptest`) running against the production code.

---

#### 3. Automated Proof Obligation & Invariant Gate Harness / Harness Verifikasi Bukti Formal Otomatis

```typescript
export interface ProofObligationResult {
  theoremName: string;
  hasSorryAxiom: boolean;
  verifiedByKernel: boolean;
  executionTimeMs: number;
}

export function enforceLean4ProofGate(results: ProofObligationResult[]): { passed: boolean; verifiedCount: number } {
  for (const res of results) {
    if (res.hasSorryAxiom || !res.verifiedByKernel) {
      throw new Error(`Unverified theorem or 'sorry' axiom detected in ${res.theoremName}`);
    }
  }
  return { passed: true, verifiedCount: results.length };
}
```

## Orchestration & Integration
- **Upstream Multi-Agent & Code Synthesis**: `formal-spec-z3-verifier`, `neurosymbolic-genetic-synthesizer`, `speculative-multi-draft-synthesizer`.
- **Ledgers & High-Stakes FinTech**: `double-entry-ledger-fintech-expert`, `agentic-m2m-settlement`, `saas-billing`.
- **Testing & Hardening**: `autonomous-tdd-debugger`, `property-mutation-testing-expert`, `production-ready-hardener`, `anti-slop`.
- **Master Orchestrators**: `brainstorming`, `zero-to-prod-orchestrator`.

---

### Production Implementation Blueprints

#### Blueprint 1: Formally Verified Double-Entry Invariant in Lean 4 (`proofs/LedgerBalance.lean`)
```lean
-- Production Lean 4 Formal Verification for Financial Conservation of Balance
namespace FintechVerification

structure LedgerEntry where
  debit : Nat
  credit : Nat
  deriving Repr

def balanceSum (entries : List LedgerEntry) : Int :=
  entries.foldl (fun acc e => acc + (Int.ofNat e.debit - Int.ofNat e.credit)) 0

-- Invariant: If every entry has debit == credit, total balance sum is strictly zero
theorem balance_conservation (entries : List LedgerEntry)
    (h : ∀ e ∈ entries, e.debit = e.credit) :
    balanceSum entries = 0 := by
  induction entries with
  | nil =>
    rfl
  | cons head tail ih =>
    have h_head : head.debit = head.credit := h head (List.Mem.head tail)
    have h_tail : ∀ e ∈ tail, e.debit = e.credit := fun e mem => h e (List.Mem.tail head mem)
    unfold balanceSum
    simp [h_head]
    exact ih h_tail

end FintechVerification
```

---

#### Blueprint 2: Lean 4 Subprocess Verifier & Axiom Auditor (`engine/lean4-verifier.ts`)
```typescript
import { spawn } from 'node:child_process';
import fs from 'node:fs/promises';
import path from 'node:path';

export interface LeanVerificationResult {
  verified: boolean;
  containsSorryAxiom: boolean;
  stdout: string;
  stderr: string;
  durationMs: number;
}

export class Lean4VerifierEngine {
  public static async verifyProofFile(leanFilePath: string): Promise<LeanVerificationResult> {
    const content = await fs.readFile(leanFilePath, 'utf8');
    const start = performance.now();

    // Check for cheat axioms or incomplete proofs
    const containsSorryAxiom = /\b(sorry|axiom)\b/.test(content);
    if (containsSorryAxiom) {
      return {
        verified: false,
        containsSorryAxiom: true,
        stdout: '',
        stderr: 'Formal verification rejected: proof contains forbidden "sorry" or "axiom" stub.',
        durationMs: performance.now() - start
      };
    }

    return new Promise((resolve) => {
      const proc = spawn('lean', [leanFilePath], { stdio: ['ignore', 'pipe', 'pipe'] });
      let stdout = '';
      let stderr = '';

      proc.stdout.on('data', (d) => { stdout += d.toString(); });
      proc.stderr.on('data', (d) => { stderr += d.toString(); });

      proc.on('close', (code) => {
        const durationMs = performance.now() - start;
        // Lean exits with 0 on total proof success
        const verified = code === 0 && stderr.trim().length === 0;
        resolve({
          verified,
          containsSorryAxiom: false,
          stdout,
          stderr,
          durationMs
        });
      });

      proc.on('error', (err) => {
        resolve({
          verified: false,
          containsSorryAxiom: false,
          stdout,
          stderr: `Lean 4 compiler invocation error: ${err.message}`,
          durationMs: performance.now() - start
        });
      });
    });
  }
}
```

---

#### Blueprint 3: Atomic Account Transfer Conservation & Non-Negativity Proof (`proofs/AccountTransfer.lean`)
Prove using Lean 4's `omega` linear integer arithmetic solver that an atomic transfer with a sufficiency check preserves total system money and never drives either balance negative:

```lean
-- proofs/AccountTransfer.lean
namespace FintechVerification

structure AccountPair where
  sender : Int
  receiver : Int
  deriving Repr, DecidableEq

def executeTransfer (s : AccountPair) (amount : Int) : AccountPair :=
  if amount > 0 ∧ s.sender ≥ amount then
    { sender := s.sender - amount, receiver := s.receiver + amount }
  else
    s

theorem transfer_preserves_total_supply (s : AccountPair) (amount : Int) :
    (executeTransfer s amount).sender + (executeTransfer s amount).receiver = s.sender + s.receiver := by
  unfold executeTransfer
  split <;> omega

theorem transfer_preserves_non_negative (s : AccountPair) (amount : Int)
    (h_sender : s.sender ≥ 0) (h_receiver : s.receiver ≥ 0) :
    (executeTransfer s amount).sender ≥ 0 ∧ (executeTransfer s amount).receiver ≥ 0 := by
  unfold executeTransfer
  split <;> omega

end FintechVerification
```

---

#### Blueprint 4: Inductive Billing State-Machine Safety Proof (`proofs/SubscriptionMachine.lean`)
Model subscription lifecycle transitions as an inductive relation and prove that a `canceled` subscription can never transition to `past_due` without explicit reactivation:

```lean
-- proofs/SubscriptionMachine.lean
namespace BillingStateMachine

inductive SubStatus where
  | trialing
  | active
  | pastDue
  | canceled
  deriving Repr, DecidableEq

inductive SubEvent where
  | invoicePaid
  | paymentFailed
  | cancelRequested
  deriving Repr, DecidableEq

def stepStatus (s : SubStatus) (ev : SubEvent) : SubStatus :=
  match s, ev with
  | .trialing, .invoicePaid => .active
  | .trialing, .paymentFailed => .pastDue
  | .active, .paymentFailed => .pastDue
  | .pastDue, .invoicePaid => .active
  | _, .cancelRequested => .canceled
  | .canceled, _ => .canceled
  | s, _ => s

theorem canceled_is_absorbing (ev : SubEvent) :
    stepStatus .canceled ev = .canceled := by
  cases ev <;> rfl

end BillingStateMachine
```

---

#### Blueprint 5: 64-Bit Fixed-Width Overflow Safety Proof (`proofs/BitVecOverflow.lean`)
Verify fixed-width 64-bit integer fee calculations against arithmetic wrap-around using Lean 4's built-in `bv_decide` bit-blasting procedure:

```lean
-- proofs/BitVecOverflow.lean
import Std.Tactic.BVDecide

namespace FixedWidthSafety

def computeFeeBps (amountCents : BitVec 64) (bps : BitVec 64) : BitVec 64 :=
  (amountCents * bps) / 10000#64

theorem fee_never_exceeds_principal (amountCents : BitVec 64) (bps : BitVec 64)
    (h_amount : amountCents ≤ 100000000000#64)
    (h_bps : bps ≤ 10000#64) :
    computeFeeBps amountCents bps ≤ amountCents := by
  unfold computeFeeBps
  bv_decide

end FixedWidthSafety
```

---

#### Blueprint 6: Reproducible Lake Configuration & Spec-to-Code Property Test (`lakefile.toml` & `test/transfer.property.test.ts`)
Pin Lean 4 package dependencies in `lakefile.toml` and mirror the proved Lean theorems with `fast-check` property tests against the TypeScript implementation:

```toml
# lakefile.toml
name = "vibes-formal-proofs"
version = "0.1.0"
defaultTargets = ["FintechVerification"]

[leanOptions]
warningAsError = true
autoImplicit = false

[[lean_lib]]
name = "FintechVerification"
srcDir = "proofs"
```

```typescript
// test/transfer.property.test.ts
import fc from 'fast-check';
import assert from 'node:assert/strict';

export interface AccountPair {
  sender: bigint;
  receiver: bigint;
}

export function executeTransfer(s: AccountPair, amount: bigint): AccountPair {
  if (amount > 0n && s.sender >= amount) {
    return { sender: s.sender - amount, receiver: s.receiver + amount };
  }
  return s;
}

export function verifyTransferConformance(): void {
  fc.assert(
    fc.property(
      fc.bigInt({ min: 0n, max: 10_000_000_000n }),
      fc.bigInt({ min: 0n, max: 10_000_000_000n }),
      fc.bigInt({ min: -1_000_000n, max: 10_000_000_000n }),
      (sender, receiver, amount) => {
        const after = executeTransfer({ sender, receiver }, amount);
        assert.equal(after.sender + after.receiver, sender + receiver);
        assert.ok(after.sender >= 0n && after.receiver >= 0n);
      }
    ),
    { numRuns: 1000 }
  );
}
```

---

### Verification Checklist & Anti-Slop Safeguards
- [x] **Zero "sorry" Stubs**: Rejects any theorem or lemma relying on `sorry` or unproven axioms.
- [x] **Lean 4 Standard Syntax**: Verified against official Lean 4 v4.14+ syntax semantics.
- [x] **Inductive Type Invariant**: Proofs mathematically sound via explicit structural induction.

---

### Sovereign Invariants & Model Routing
| Dimension | Sovereign Mandate & Deterministic Contract |
| :--- | :--- |
| **Model Cascade** | High / Extended Thinking (`Claude Sonnet 5.5 High`, `Gemini 4 Pro`) for Lean 4 tactic synthesis |
| **Availability Fallback** | `Gemini 4 Pro` -> `Gemini 3.8 Flash`; `Claude Sonnet 5.5` -> `Claude Opus 4.6` |
| **KV-Cache Protocol** | Pin standard mathlib import prefixes; transmit only target inductive definitions |
| **Anti-Slop Invariant** | Absolute rejection of incomplete proofs or placeholder assertions |

---

<a name="bahasa-indonesia"></a>
## Bahasa Indonesia

### Direktif Eksekutif & Mandat Pembuktian Formal
Pengujian unit (*unit test*) dan rangkaian uji integrasi hanya mampu membuktikan adanya bug pada alur yang diuji; mereka tidak pernah bisa menjamin secara matematis ketiadaan total bug pada kondisi batas (*edge cases*). Pada sistem bisnis bertaruh tinggi (buku besar fintech, smart contract, protokol kriptografi, state machine billing otonom), pengujian probabilistik semata tidak lagi memadai.

**Formal Theorem Verifier Lean 4** berfungsi sebagai gerbang verifikasi matematis tanpa kompromi:
1. **Interactive Theorem Proving (ITP)**: Memetakan invarian bisnis kritis ke dalam teorema formal dan tipe induktif Lean 4.
2. **Otomasi Taktik Verifikasi**: Menjalankan subprocess compiler Lean 4 untuk memverifikasi keabsahan pembuktian dengan taktik formal (`simp`, `omega`, `linarith`, `induction`).
3. **Penerjemahan Invarian Formal**: Menjembatani model state machine TypeScript/Rust ke dalam lemma Dafny dan Lean 4, serta menolak perubahan kode jika bukti formal gagal atau mengandung stub `sorry`.

---

### Guardrail Wajib (Invarian Deklaratif)
- **Nol Stub Sorry atau Admit**: Dilarang menggabungkan file Lean 4 yang mengandung `sorry`, `admit`, atau bukti yang belum tuntas; CI wajib menjalankan `-DwarningAsError=true`.
- **Nol Deklarasi Axiom Tanpa Bukti**: Dilarang membuat deklarasi `axiom` kustom untuk melewati kewajiban pembuktian; modelkan asumsi secara eksplisit sebagai hipotesis teorema.
- **Aritmetika Integer & BitVector Eksak**: Dilarang memodelkan saldo uang atau penghitung protokol dengan tipe `Float` di spesifikasi formal; gunakan `Int`, `Nat`, atau `BitVec n`.
- **Pinning Toolchain & Revisi Mathlib**: Kunci versi compiler di `lean-toolchain` dan revisi Git `mathlib` di `lakefile.toml`.
- **Utamakan Prosedur Keputusan Deterministik**: Gunakan taktik `omega`, `bv_decide`, dan `decide` untuk menjaga pembuktian tetap cepat dan deterministik.
- **Jembatan Konformansi Spesifikasi ke Implementasi**: Pasangkan setiap teorema domain Lean 4 dengan pengujian berbasis properti (`fast-check` / `proptest`) pada kode produksi.

### Integrasi Orkestrasi
- **Multi-Agen & Sintesis Kode**: `formal-spec-z3-verifier`, `neurosymbolic-genetic-synthesizer`, `speculative-multi-draft-synthesizer`.
- **Buku Besar & FinTech Bertaruh Tinggi**: `double-entry-ledger-fintech-expert`, `agentic-m2m-settlement`, `saas-billing`.
- **Pengujian & Pengerasan**: `autonomous-tdd-debugger`, `property-mutation-testing-expert`, `production-ready-hardener`, `anti-slop`.
- **Orkestrator Utama**: `brainstorming`, `zero-to-prod-orchestrator`.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

View all in ai-agents →

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.