Blog / BABYLON-60
How to read the Verification Mirror without overstating its conclusions
A review path that separates consistent files, publishing identity and historical runtime evidence.
Identify the package under review
Start with the repository revision and package manifest. The mirror includes formal sources, claim declarations and reports for inspection without the author’s working tree. A packaging date identifies that publication, while an execution report retains its own date and source. They may describe different moments. Before comparing counts or conclusions, check which files were included and which revision each result refers to. Keep that provenance alongside any notes taken during the review.
Run the command and read its scope
From the repository or extracted ZIP, ./verify.sh checks integrity and manifest bindings before running lake build. It requires Python and the Lean version specified in lean-toolchain. A successful exit establishes those checks and AX0 compilation; it does not rerun the complete runtime harness. Read the recorded failures and distinguish verified from bounded states as well. The exit code is a useful control for a script, but it does not replace interpretation of the report.
Separate identity from execution
A digest published beside the ZIP helps check consistency, but it is not an independent identity anchor. Checking a signature requires a public key obtained through a trusted channel and the corresponding verification mode. Historical reports retain their limits: software P-256 tests do not establish human presence in Secure Enclave, and SIGKILL does not represent power loss. The mirror exposes those distinctions; packaging old reports cannot turn them into a new attestation of the current system.