Trusted base
What Lema checks with the kernel, what it tests by running, what it assumes without proof, and what it does not claim.
Lema labels evidence with three words. This page lists what each one covers, as docs/architecture.md (“Trust boundaries”) and docs/roadmap.md (§13, “Not claimed”) state it. Checked, tested and assumed explains why the three are kept apart.
| Word | Means |
|---|---|
| checked | accepted by kernel replay with the pinned Lean 4.34.1 kernel, within the store’s axiom policy above the fixed floor |
| tested | run and observed: compiled code, executables, sockets, OS behaviour, the Rust store rules |
| assumed | trusted without proof |
Checked
Kernel replay of the objects, within the store’s axiom policy above the fixed floor, under the module cache’s assumption: Lean does not re-check imported modules and reads their axioms from each module’s recorded table. lema reverify checks from scratch, without modules.
A Lean file that the pinned Lean elaborates outside a store is checked locally, not accepted. The merge gate (decision 0033) claims “tested” or “checked locally”, never “accepted”.
Tested
- compilation;
- the worker runner and loopback service (the HTTP v1 execution chain, retired under decision 0033);
- OS behaviour;
- the output of an execution manifest’s program (
lema run,lema test); - the capability applications’ runner (
lean/cap/Runner.lean) and shims (crates/lema-cap), at their boundary; - the project-reference rules and their actor check, a local bearer-token comparison that separates cooperating actors but not the store’s own OS user.
The executable vocabulary, the startup check and the IR profiles read an inventory from the process that elaborated the source, so they guard against honest mistakes, not a hostile draft. No proof receipt is issued for executed output.
Assumed
| Component | Applies |
|---|---|
| the Lean kernel and compiler | always |
the reviewed Rust acceptance path: lema-core, lema-check, lema-store | always |
| canonical validation, and the decoder that turns canonical objects into kernel declarations | always (roadmap §13) |
between full reverify runs, the integrity of hashed .olean modules written by the pinned checker | for incremental replay (roadmap §13) |
| glibc, Linux, the local operator | always |
the distribution’s C compiler and linker (leanc, clang, ld.lld) and the Lean runtime they link in | also for native builds (lean-native) |
| rustls, ring, webpki-roots, the resolver, the network and Lean’s task manager | also for capability applications; the lema-cap shims and the runner themselves are tested |
that the C emitted with the compared Lean.IR is that IR’s | also for standalone builds |
Receipts are store-local and never trusted from another store: objects moved between stores are replayed again (decision 0027).
Not claimed
docs/roadmap.md §13 claims no:
- proof of the Lean compiler, the Rust code generator (the Rust backend, on hold under decision 0029),
rustc,tokio, the OS or network delivery; - public foundation or production assurance;
- human-qualified review.
Two limits follow from the model itself. A contract guarantees only what it states, and a review record says who approved a statement under which authority, not that the statement captures the intended requirement. Contracts state behaviour, not cost.
Written against lema-lang at commit 5a94951, 17 Oct 2026.