Governance and formal assurance
Keep systems within their safety boundaries, even when conditions fail.
Formal contract and invariant-verification foundation: verify admissible conditions, constrain state transitions and model safe degradation when operating assumptions break.
Responsibility
λ-Safe is the formal contract and invariant foundation of the NiGeNje governance lifecycle. It formalizes machine-enforceable contracts, compiles supported invariants, specifies admissible operating and degraded modes, defines minimum service floors and fallback constraints where the contract specifies them, and verifies whether proposed transitions satisfy those formal constraints. It does not execute or enforce runtime transitions itself.
Distributed systems fail in ways that availability mechanisms do not fix. A node can stay up while its data drifts, a fallback can preserve throughput while violating a conservation or consistency invariant, and a recoverable resource can be double-spent. λ-Safe exists to make those constraints formal before they become runtime decisions.
It formalizes supported contracts and invariants, verifies which state transitions are admissible, and produces a a scoped verification record with an explicit checked/not-checked boundary. When a mandatory obligation cannot be expressed or decided, it refuses rather than approximating — "unknown is not proof".
The same formal model carries the safe-degradation research direction: under specified operating assumptions, a system may have to reduce functionality or capacity while preserving defined safety properties. λ-Safe constrains what degradation is admissible; deciding and enforcing it at runtime belongs to the Control Plane, the Immune Engine and the execution boundary.
λ-Safe is therefore a verification component, not an enforcer. It informs admission and decisions with formal constraints; Gatekeeper admits, NARG mediates and Substrate executes.
In depth
Each section below is drawn from the product register and states the context this product is built for, in the product's own terms.
Distributed systems rarely fail by stopping cleanly. They fail while continuing to serve: a replica returns stale data, a fallback skips a reconciliation check, a retry double-applies an effect. Availability and recovery mechanisms are designed to keep serving; they do not, by themselves, guarantee that a safety or consistency invariant still holds.
Failover, retry, caching and graceful shutdown preserve service continuity. They do not reason about which state transitions remain admissible. A system can therefore remain available while violating exactly the property it was built to protect.
Invariant preservation requires a different question: given the current operating conditions, which transitions are still permitted, and which reduced mode preserves the mandatory properties?
λ-Safe turns declarative obligations into machine-enforceable contract artifacts. Only supported invariants are checked; unsupported or indeterminate clauses are refused with an explicit record. The resulting verification record carries a checked/not-checked boundary so no reader can mistake what was established for what was assumed. The internal compiler and solver mechanisms are not published on this site.
A proposed action is admissible only if its state transition satisfies the checked constraints. λ-Safe answers that admissibility question for supported contracts. A verified record is evidence an admission decision can rely on — it is not a permit and not an execution.
The λ-safe research model explores how a system can degrade — reducing functionality, capacity or optional capability — while preserving mandatory invariants. Degradation is admissible only within constraints derived from the original obligations and the stated operating assumptions.
This is not a guarantee that every service stays available. It is a commitment that defined safety properties remain protected while the system operates in a reduced mode, and that recovery to normal operation requires fresh verification.
Verification establishes that a contract or transition is admissible. It does not intercept a live action, revoke a permit or contain a failing dependency. Those are runtime responsibilities: Gatekeeper for admission, NARG for registered action mediation, Substrate for execution, the Immune Engine for containment and the Control Plane for coordination.
The website therefore labels λ-Safe's maturity separately from the maturity of runtime enforcement and from the maturity of the platform end to end.
λ-Safe participates in contract formalization, immediately after intent translation. Its outputs are consumed at admission, in decision constraints and in conformance evidence. Its invariants are revisited when reconciliation detects drift and when degradation changes the admissible operating envelope.
Lifecycle position
Stage numbering is canonical across the site. Open the interactive lifecycle to see every component with responsibilities at each stage.
Translate intent into machine-enforceable requirements.
Verified capabilities
Capabilities are drawn from the product register. Each one is bounded by the limitations stated further down this page.
Each variant states its own maturity and verification boundary. The shared responsibility above applies to the product as a whole.
Open-source compiler for a deliberately bounded class of hard invariants and invariant checks.
Enterprise packaging, verification-record handling and integration with admission.
Two dimensions
Intent and authority form one dimension; invariant preservation and safe degradation form the other. An action is admissible only when it is both authorised and inside the compiled safety constraints.
Dimension A · Intent and authority
Declared intent becomes scoped authority. Admission is independent of the component that executes, and every action leaves an evidence trail.
Establishes authority and evidence: intent → admission → mediation → execution → observed outcome → conformance.
Dimension B · Invariant preservation
Formal constraints define admissible transitions and admissible degraded modes. Verification constrains; it does not decide or enforce.
Preserves safety properties: a reduced mode is admissible only within compiled degradation constraints.
λ-Safe informs decisions; it does not replace the Control Plane or NARG. Formal verification establishes what is admissible, the Control Plane decides what to do, and Gatekeeper, NARG and Substrate enforce the admitted action.
Contract and invariant formalization
Formalization is the controlled translation step: supported obligations become contract artifacts and an invariant set with an explicit checked / not-checked boundary.
Versioned objective, obligations and scope from Chinje.
Resolves authority and emits a translation package with target fragments.
Machine-enforceable requirements for supported constructs.
Checking of a deliberately bounded class of hard invariants.
Recorded checked / not-checked boundary; signed bundles in Enterprise.
Constraints consumed at admission, in decisions and in conformance.
Only supported, decidable invariants are compiled. A mandatory clause that cannot be expressed or decided produces a BLOCKED outcome with zero compiler inputs — it is never silently weakened. Unknown is not proof.
Admissible-transition verification
λ-Safe answers the admissibility question for supported contracts: given the compiled invariant set and the proposed transition, is the transition still permitted?
Inputs
λ-Safe evaluation
Is this transition admissible?
Answered only for supported, decidable contracts. Undecidable obligations are refused rather than approximated.
VerificationVerdict
Evidence an admission decision can rely on. Not a permit, not a dispatch.
Inadmissible transition or undecidable obligation. No permit; no dispatch.
A verdict answers only the admissibility question. Gatekeeper still decides admission, NARG still mediates the exact action and Substrate still executes it. Verification, decision-making and enforcement are separate responsibilities.
Safe degradation
When conditions fail, system invariants must not. The seven-step model describes how a system can reduce capability while keeping mandatory safety properties protected — and why recovery must be verified rather than assumed.
Safe degradation · Seven steps
Availability mechanisms keep a system serving; they do not establish that its safety properties still hold. Degradation is admissible only within constraints derived from the original obligations and stated operating assumptions, and recovery is never assumed.
Research-grounded and simulated. Safe degradation is a published type-theoretic research model and a labelled browser simulation. Production runtime degradation enforcement is not implemented or verified, and end-to-end safe-degradation qualification is not established. This page does not claim either.
Verification vs enforcement
Verification establishes what is admissible. It does not intercept a live action, revoke a permit or contain a failing dependency. Those are runtime responsibilities with their own maturity.
Verification, decision-making and enforcement answer different questions. Treating any one of them as the others is how an architecture acquires authority claims it cannot support.
Is this contract or state transition admissible under supported invariants?
Produces
Does not
Decide what to do, admit actions, mediate dispatch or contain failures.
What should be done, and is it feasible within the constraints?
Produces
Does not
Prove invariants, issue permits or execute actions.
May this exact action proceed, and what actually happened?
Produces
Does not
Decide policy, prove invariants or substitute for formal verification.
λ-Safe informs decisions and enforcement; it does not replace the Control Plane or NARG. Formal verification constrains what may be considered admissible. The Control Plane decides, Gatekeeper admits, NARG mediates, Substrate executes and the Immune Engine acts on violated operating assumptions.
Evidence and maturity
Maturity describes verified engineering evidence in a bounded environment. It is not a production-readiness statement.
λ-Safe Core is an open-source Rust compiler (Apache-2.0) for supported a deliberately bounded class of hard invariants; it is demonstrable. λ-Safe Enterprise was exercised on the recorded intent chain as a enterprise packaging path, and its verification-record checking is used by Gatekeeper. Safe degradation is a published research model and a demonstrated simulation; production runtime degradation enforcement is not implemented.
This label describes verified engineering evidence only. No production deployment, certification, benchmark or customer outcome is claimed.
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
Limitations are stated before the evaluation questions so they cannot be missed, downplayed or treated as future-work footnotes.
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
λ-Safe supplies the formal constraints that admission and decisions must respect. Gatekeeper verifies its bundles; the Control Plane carries its artifacts into execution and evidence; the Immune Engine acts on state that violates operating assumptions. λ-Safe never replaces the Control Plane or NARG: verification, decision-making and enforcement are separate responsibilities.
XERJ Corpus Hub
XERJ identified a specific λ-Safe compiler contribution for potential inclusion in its public Corpus Hub. The contribution focuses on compiler assurance, solver boundaries and end-to-end safety testing.
The selection concerns one engineering contribution, not the whole λ-Safe project, and it is not certification, approval or production validation by XERJ. No public corpus record URL is claimed.
Next step
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.
