Skip to content

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.

WordMeans
checkedaccepted by kernel replay with the pinned Lean 4.34.1 kernel, within the store’s axiom policy above the fixed floor
testedrun and observed: compiled code, executables, sockets, OS behaviour, the Rust store rules
assumedtrusted 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

ComponentApplies
the Lean kernel and compileralways
the reviewed Rust acceptance path: lema-core, lema-check, lema-storealways
canonical validation, and the decoder that turns canonical objects into kernel declarationsalways (roadmap §13)
between full reverify runs, the integrity of hashed .olean modules written by the pinned checkerfor incremental replay (roadmap §13)
glibc, Linux, the local operatoralways
the distribution’s C compiler and linker (leanc, clang, ld.lld) and the Lean runtime they link inalso for native builds (lean-native)
rustls, ring, webpki-roots, the resolver, the network and Lean’s task manageralso 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’salso 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.