Architecture
A lifecycle position can be governed by a role that is not a separately deployable process, and a running service is not automatically part of one production execution chain. Formal verification, decision-making and runtime enforcement are separate responsibilities — λ-Safe sits in the formal-assurance zone and never replaces the Control Plane or NARG.
How to read this model
Every component in this model is described by a logical responsibility and by a deployment form. Confusing the two is how architecture diagrams become deployment claims.
What role must exist in the lifecycle — an intent authority, an admission authority, a mediation point, an observer. A role can be fulfilled inside another implementation boundary, and may be recorded as logical rather than deployed as its own service.
What can actually be run and operated: a process, endpoints, configuration and an owner. Running a service does not prove it is connected to the bounded integrated chain, and being connected there is still not production qualification.
Passed its defined qualification tests.
Verified behaviour across the specified components in a bounded local, non-production demonstration chain.
A working development demonstration exists.
Confirmed implementation exists.
Implementation or integration is underway.
Not yet implemented.
No capability on this site is marked Qualified. Integrated means verified across the specified components in a bounded local, non-production demonstration chain — never production qualification.
The registry records deployment (service, logical, open-source, CLI) and maturity (evidence across components) separately. Neither substitutes for the other, and a component can be integrated in the bounded chain while remaining a logical responsibility.
Bounded integrated chain
The bounded chain records lifecycle positions where behaviour was verified across components in a local, non-production demonstration. It is evidence of integration, not evidence of production readiness.
8 components are marked Integrated — verified in a bounded local, non-production demonstration chain.
No verified component at this stage.
No verified component at this stage.
No verified component at this stage.
This is not one production execution chain. Components marked In Progress, Demonstrable or Planned are absent from this view; several integrated responsibilities are logical rather than separately deployable; and evidence across components is correlated by identifier, not by a single signed lifecycle envelope.
Formal assurance zone
λ-Safe is the contract and formal-assurance component: it compiles supported invariants, verifies admissible state transitions and models safe-degradation constraints. Its outputs inform admission and decisions; they never become a permit, a decision or an execution on their own. Governed safe degradation is a capability in its own right: when conditions fail, system invariants must not.
Contract and formal-assurance zone
Formal contract and invariant foundation: compiles supported invariants, verifies admissible transitions and models safe-degradation constraints.
Not an enforcer. Not a decision engine. Verification produces constraints and evidence; it does not admit, mediate or execute.
Compiled from
Verified at admission
Informs decisions
Acts on violated assumptions
Enforced downstream
Observed and evidenced
λ-Safe constrains decisions and execution; it does not replace the Control Plane, Gatekeeper, NARG or Substrate. These are responsibility relationships, not a single production execution chain.
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.
Chinje is the sole evidence-sufficiency and conformance authority. λ-Safe defines and verifies admissible boundaries — contracts, invariants and degradation constraints — but it does not execute or enforce anything, and it does not judge conformance. Gatekeeper admits, NARG mediates, Substrate executes, and Chinje evaluates evidence sufficiency and conformance against the original intent.
λ-Safe establishes what is admissible; the Control Plane and IDM Solver decide within those constraints; Gatekeeper admits, NARG mediates and Substrate executes. λ-Safe does not intercept actions, issue permits, dispatch effects or contain failing dependencies. Safe degradation is a research model and a simulation, not production runtime enforcement.
Component explorer
Select any component to see its responsibility, inputs, outputs, dependencies, lifecycle position, verified maturity, product page and limitation.
Components marked chain are integrated in the bounded local, non-production chain. Components marked In Progress, Demonstrable or Planned are not part of it. Several integrated responsibilities are logical rather than separately deployable, and every external integration remains unqualified for production.
Selected component: Chinje. Detail panel updated.
Intent, contract formalization, λ-Safe invariant verification, admission and the decision itself. Formal assurance establishes admissibility, the Control Plane decides and Gatekeeper admits — three separate responsibilities.
Registered mediation, controlled execution and external adapters. This group enforces an admitted decision at the action boundary.
Observation, reconciliation, containment, change assurance and hash-linked records. This group establishes what actually happened.
Read-only operational understanding, temporal coordination, the console and advisory analysis. This group reads and explains without holding authority.
chain marks a component verified as Integrated in the bounded local, non-production demonstration chain. Logical components are responsibilities, not separately deployable services.
Governance lifecycle
The same canonical lifecycle used on the platform overview. Selecting a stage reveals the components with a responsibility there, including logical responsibilities.
Stage 01 of 10: Intent selected.
Stage 01 of 10
Declare the objective, obligations and scope.
A governed operation begins with an explicit, reviewable intent: what should be achieved, which obligations and invariants apply, who is acting and what scope is claimed. Intent is versioned and approved rather than inferred from a prompt.
Intent governance: versioned intent, obligations, actor authority, evidence sufficiency and conformance/drift assessment.
Limitation: No intent listing API; intents are read by id/version.
Product pageIntegration status
The terms on this site are used precisely. A bounded demonstration is a real engineering result; it is not a production qualification, and this page does not blur the two.
No component on this site is marked Qualified. Release-candidate classification is recorded too: NARG is EXCLUDED_NO_GO with finding F-01 open, and Substrate is a reference boundary its own documentation describes as parked (D-1 unresolved). Read the public status page for the current engineering state and the security boundaries for what is not enforced.
Continue
The platform overview explains the control model; the product portfolio states what each boundary does, what evidence exists and what still limits it.
