Inputs
- Translated contract requirements from the Intent-to-Control Bridge
- Supported hard invariants and bound pairs
- Signing keys and trust-store material (Enterprise)
- Bundle and certificate artifacts from prior compilation
Verification and admission
λ-Safe
Unknown is not proof.
Deterministic contract compilation, supported invariant checks and safe handling of unsupported or indeterminate obligations.
Responsibility
What λ-Safe is responsible for
λ-Safe compiles supported, decidable hard invariants into a manifest and a λ-certificate that runtime components can verify. Obligations it cannot decide are refused rather than approximated, and signed bundles carry the boundary of what was actually checked.
λ-Safe is the constraint-compilation edge of the platform. It takes contract obligations expressed as supported numeric integral invariants, decides them deterministically, and produces artifacts that downstream components can verify without re-implementing the analysis.
The design position is deliberately conservative: a compulsory clause that cannot be expressed or decided is blocked with zero compiler inputs rather than silently weakened. That is what "unknown is not proof" means in practice — a positive result is a statement about exactly what was analysed, not a general assurance claim.
Lifecycle position
Where it sits in the governance lifecycle
Stage numbering is canonical across the site. Open the interactive lifecycle to see every component with responsibilities at each stage.
Contract formalization
Translate intent into machine-enforceable requirements.
Verified capabilities
What is verified today
Capabilities are drawn from the product register. Each one is bounded by the limitations stated further down this page.
- Deterministic compilation of supported numeric integral bounds and static checks
- Manifest and λ-certificate generation with a recorded checked/not-checked boundary
- Refusal of unsupported mandatory clauses instead of permissive fallback
- Signed bundle compilation and verification with a trust store
- Permit-v2 bundle intent-binding verification used at admission
Outputs
- λ-Safe manifest and λ-certificate
- Signed bundle with an explicit checked/not-checked list
- Verification verdict for an admission decision
- Explicit BLOCKED outcome for unsupported or contradictory obligations
Variants
Each variant states its own maturity and verification boundary. The shared responsibility above applies to the product as a whole.
λ-Safe Core
Open-source Rust compiler for supported numeric integral bounds and λ-certificates.
- Compile supported numeric integral bounds into a manifest and certificate
- Expose unsupported obligations as refusals
- Apache-2.0 open-source implementation
λ-Safe Enterprise
Signed bundle compilation, trust-store verification and integration with admission.
- Sign and verify bundles against a configured trust store
- Verify permit-v2 bundle intent binding for Gatekeeper
- Record the not-checked boundary inside the artifact
Evidence and maturity
What the evidence supports
Maturity describes verified engineering evidence in a bounded environment. It is not a production-readiness statement.
Maturity note
λ-Safe Core is an open-source Rust compiler (Apache-2.0) for numeric integral bounds and static verification; it is demonstrable. λ-Safe Enterprise was exercised on the recorded intent chain as a signed-bundle compiler with a trust store, and its permit-v2 bundle verification is used by Gatekeeper.
Not production-qualified
This label describes verified engineering evidence only. No production deployment, certification, benchmark or customer outcome is claimed.
Evidence recorded
- Open-source compiler repository: github.com/GeorgeOnchaba/lambda-safe (Apache-2.0).
- Acceptance steps 13 and 16: unsupported HARD clause blocked with zero compiler inputs; contradictory bound pair refused as CONTRADICTORY_CONSTRAINTS.
- Local chain hop 3: signed certificate verified against a trust store (verified:true).
- Permit-v2 cross-language test vectors and Gatekeeper bundle verification.
Dependencies
- Intent-to-Control Bridge
- Gatekeeper
- Intent authority (Chinje)
Dependencies are stated as the product register records them. A dependency is not automatically production-qualified; see its own product or component page for its maturity and limitations.
Limitations
What this product does not do (yet).
Limitations are stated before the evaluation questions so they cannot be missed, downplayed or treated as future-work footnotes.
Limitations — read before evaluating
- Supported invariants are numeric integral bounds only: there is no proof-assistant or SMT backend, and unsupported or indeterminate obligations are blocked rather than proven.
- A runtime constraint violation inside a successfully compiled bundle is not exercised end to end.
- The Enterprise verifier exposes health and verify endpoints only; there is no public HTTP compile API.
- No independent benchmark, reproducible-build proof or production qualification of the compiler is claimed on this site.
No capability on this page should be read as production qualification. If a limitation is material to your use case, it belongs in the evaluation scope — not after it.
Relationship to the platform
How it fits
λ-Safe turns intent into something checkable at runtime. Gatekeeper uses its bundle verification at admission, while the Control Plane carries the resulting artifacts into execution and evidence. λ-Safe does not decide whether an action is authorised; that remains Gatekeeper's responsibility.
Evaluation questions
- Which invariants are decidable and supported by the current compiler?
- What exactly is recorded in the certificate's checked and not-checked lists?
- How does the system behave when an obligation cannot be expressed?
Next step
Evaluate λ-Safe against a real control problem.
Bring a system boundary, an action class and a failure mode. The first step is to agree what should be governed and what evidence would count.