Formal Verification Stack
The layered structure by which the formal core of the program is checked.
In plain language
Where theorem and lemma claims are represented in TauLib, they are written in Lean 4 — a programming language that machine-checks proofs — and checked against the pinned Lean environment. The Release Manifest is authoritative for current counts (modules, theorem/lemma declarations, sorry assignments, custom axiom declarations); see it for the current public-release totals. This page lays out the four layers of formal checking: kernel integrity (does Lean's own type-checker accept the proof?), standard-foundation alignment (does the proof use only Mathlib axioms plus the disclosed custom ones?), bridge verification (do the formal claims legitimately support standard mathematical, physical, empirical, or interpretive claims?), and external assessment (do specialists outside the program see the same picture?). Bridge verification is adjacent to formal verification, not identical to it. Each layer is independently inspectable; nothing relies on a single black box.
Stack Overview
Formal verification in this program has multiple levels. They must not be collapsed into one confidence label.
Level 1 — Kernel Integrity Verification
This asks whether the formal kernel holds together internally as a coherent formal system. It includes Lean modules compiling, proof chains closing, theorem dependencies connecting, and the public registry aligning with the corresponding formal objects where such alignment is claimed.
Result: formal certification relative to the Lean kernel and the stated formalization scope.
Level 2 — Standard-Foundation Verification
This asks whether selected hinge theorems can also be re-established in standard foundations. The purpose is to reduce dependence on a custom system for especially load-bearing claims and to build overlap with standard formal mathematics.
Result: independent re-establishment of selected key theorems where such parallel work exists.
Level 3 — Bridge Verification
Bridge verification is adjacent to formal verification, not identical to it. Formal verification checks internal proof obligations where formalized. Bridge verification asks whether formal or internal constructions legitimately support standard mathematical, physical, empirical, or interpretive claims. Internal analogues are not enough; the bridge must be adequate for the transfer burden.
Result: bridge-verified recovery and transfer claims where established.
Current Surfaces
- TauLib — Lean 4 formalization surface.
- Release Manifest — authoritative release counts, pinned commit, trusted-base and filter disclosures.
- Corpus Registry — object IDs, types, dependencies, and source locations.
- Monograph Corpus — narrative construction projection where relevant.
- Verify routes — bridge, domain, prediction, falsification, and assessment surfaces.
- Publications — citable artifact and release shelf.
Meta-Verification Boundary
The formal stack checks internal derivations where the formalization reaches. It does not automatically settle empirical adequacy, interpretive bridge claims, or the residual externality of the verifier itself. That last issue is treated in the Meta-Verification Frontier.
Save or share this page for inspection
Download a portable dossier, copy a reviewer note, or send this page to someone who can inspect it.