An independent governance and control layer for autonomous and distributed systems. Each product owns a specific responsibility in the governance lifecycle, and each page states the evidence behind its maturity and the limits of what has actually been verified.
18 products6 product familiesNo production qualification claimed
Declare what should happen, who may act and what must remain true.
2 products in this family.
Intent and authorityIntegrated
Chinje
Intent governance, actor identity and authority, obligation tracking, evidence sufficiency, conformance and drift.
Responsibility
Chinje establishes what an actor intends to achieve, which obligations and scope apply, who is authorised to act, and whether the evidence available is sufficient to proceed. It keeps the intent version chain and supports conformance and drift assessment against the original obligations.
Key capabilities
Intent authoring, approval and version chain with a distinct approving principal
Declared obligations, scope and expiry attached to a published intent
Actor identity and authority requirements carried into admission
Intent and authorityIntegrated
Intent-to-Control Bridge
Translation of declared intent and obligations into machine-enforceable contract fragments and compiler inputs.
Responsibility
The Intent-to-Control Bridge resolves a published intent against authority and compilation inputs, then produces a translation package and target fragments that λ-Safe can compile. It preserves the declared scope and refuses when the intent cannot be represented faithfully.
Key capabilities
Intent resolution against authority and compiler inputs
Translation package generation for a published intent version
Target-fragment emission for supported compiler constructs
Family 02
Verification and admission
Compile obligations and decide whether a specific action may proceed.
2 products in this family.
Verification and admissionIntegrated
λ-Safe
Deterministic contract compilation, supported invariant checks and safe handling of unsupported or indeterminate obligations.
Responsibility
λ-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.
Key capabilities
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
Verification and admissionIntegrated
Gatekeeper
Independent admission and authorisation, gate evaluation and signed permit issuance bound to the action.
Responsibility
Gatekeeper is the independent admission authority. It evaluates a fixed set of requirement gates against the caller, the intent, the evidence and the proposed action, then issues a scoped, single-use permit bound to the action digest — or refuses with a specific reason.
Key capabilities
13-gate admission evaluation with explicit refusal reasons
Signed permit issuance with scope, expiry, nonce and action-digest binding
Replay and duplicate-delivery protection
Family 03
Control and decision
Evaluate policy, constraints and uncertainty before anything is dispatched.
3 products in this family.
Control and decisionIntegrated
Control Plane
Policy evaluation, decision coordination, execution state and optimisation across the governance lifecycle.
Responsibility
The Control Plane coordinates a governed transaction: it evaluates policy context, requests or selects a decision candidate, dispatches only against a verified permit, records execution state, and drives observation, reconciliation and audit.
Key capabilities
Policy evaluation and decision coordination
Dispatch only against a verified permit
Execution state tracking including unknown and partial outcomes
Control and decisionImplemented
IDM Solver
Invariant-Dynamic Machine decision model and its supported solver capabilities for constrained decisions.
Responsibility
The IDM Solver produces decision candidates that satisfy specified hard constraints and reports when no feasible candidate exists. It is a decision aid inside the Control Plane, not an authority: feasibility does not imply authorisation.
Key capabilities
α-fair single-resource allocation within declared bounds
Opt-in multi-resource projection (prototype)
Default hard-bounds guard that blocks out-of-bound candidates
Control and decisionImplemented
Confidence Estimator
In-process evidence-sufficiency scoring and an explicitly uncalibrated confidence object attached to decision metadata.
Responsibility
The Confidence Estimator module in the Control Plane records how sufficient the available evidence is for a decision and attaches a confidence object to decision metadata. In the reviewed implementation that object is explicitly uncalibrated: it reports calibrated:false, probability 0 and method "none" rather than inventing a risk score.
Key capabilities
Evidence-sufficiency scoring for a decision context (in-process)
Explicit uncalibrated confidence metadata (calibrated:false, probability 0, method none)
Post-solve chance and CVaR analysis in the IDM path (bounded, synthetic)
Family 04
Runtime and execution
Mediate registered actions and execute through controlled adapters.
3 products in this family.
Runtime and executionDemonstrable
NARG
Runtime action mediation for registered agent and tool actions, separating a proposal from a dispatched effect.
Responsibility
NARG (the NiGeNje Agent Runtime Guard) mediates registered agent and tool actions. It verifies a permit for the specific action, keeps the proposal separate from dispatch, performs its own effect read-back, and reports unknown rather than success when it cannot confirm the outcome.
Key capabilities
Registered action mediation with proposal and dispatch separated
Permit verification bound to action and arguments
Replay protection and single-use permit enforcement
Runtime and executionDemonstrable
Substrate
Controlled execution and resource adapters that apply an action and support independent read-back.
Responsibility
Substrate provides the controlled execution boundary. It verifies a permit before applying an effect through a bounded adapter, then supports read-back so the result can be observed rather than assumed.
Key capabilities
Permit verification before an effect is applied
Controlled execution through a reference adapter
Read-back of resulting state from the effect store
Runtime and executionImplemented
Integrations
A permit-gated Kubernetes Deployment scale boundary with receipt, plus connector and adapter libraries. Never live-cluster validated in the reviewed environment.
Responsibility
Integrations carries governed action beyond the platform boundary. The reviewed implementation is one permit-gated Kubernetes Deployment scale operation with a receipt, supported by connector and adapter libraries that describe how external targets are reached.
Key capabilities
Permit-gated Kubernetes Deployment scale operation with receipt
Connector and adapter libraries for external targets
Connector capability reporting
Family 05
Assurance and evidence
Observe outcomes, reconcile state, contain harm and preserve evidence.
5 products in this family.
Assurance and evidenceIntegrated
Reconciliation and Audit
Independent observation, expected-versus-observed reconciliation and linked evidence across the audit ledger.
Responsibility
This capability group establishes what actually happened. An observer records external state, reconciliation compares expected and observed results, and the certification and audit ledger links decision, execution and outcome evidence so conformance can be evaluated rather than asserted.
Key capabilities
Observation of external state after an action
Expected-versus-observed comparison with explicit divergence
Pressure/quarantine state and an admission veto within defined policies, plus a containment request shape. Not an autonomous detector.
Responsibility
The Immune Engine maintains pressure and quarantine state and can veto admission when that state requires it. The reviewed implementation contains no detector and no autonomous containment actuator: containment is a request shape, and containment actions remain partial.
Key capabilities
Pressure and quarantine state used by admission
Admission veto when immune policy state requires it
Fail-closed behaviour when policy context cannot be observed
Assurance and evidenceDemonstrable
MZiNG
Control Plane change assurance: policy gates, change lifecycle, commit invariant and enforcement planning for system change.
Responsibility
MZiNG governs change inside the Control Plane. It evaluates a proposed change against policy gates and a commit invariant, refuses a candidate that would violate the invariant, and records the decision through the change lifecycle: declare, attest, admit, candidate, commit, enforce, observe, reconcile, audit.
Commit invariant ΔJ/ε with candidate refusal on violation
Assurance and evidenceDemonstrable
MZiNG Network
In-process Control Plane network change and commit assurance: topology, network gates, potential, routing and containment plan surfaces. Not packet-level enforcement.
Responsibility
MZiNG Network is the network-facing change and commit assurance capability inside the Control Plane. It exposes network admission, certificates, topology, gates, potential and routing surfaces so network change can be admitted and planned through the same commit-invariant model. It is not a separate network coordination service.
Key capabilities
Network admission and permit handling
Certificate and trust material surfaces
Topology, gate, potential and routing plan surfaces
Assurance and evidenceDemonstrable
MZiNG Assurance
Separate change-assurance product: no-regression gate, signed evidence, nftables laboratory and PostgreSQL failover testing.
Responsibility
MZiNG Assurance is a separate standalone change-assurance codebase. It implements a no-regression gate, signed evidence and a laboratory for nftables and PostgreSQL failover behaviour. It is not the same codebase as MZiNG Network, and a formal relationship between the two is not established.
Key capabilities
No-regression gate for a proposed change
Signed evidence for change-assurance decisions
nftables laboratory exercises
Family 06
Operations
Read-only operational understanding, temporal coordination and advisory analysis.
3 products in this family.
OperationsIn progress
NTC
NiZiNG Temporal Controller — an in-process temporal scheduler and cadence controller. Not a causal validation engine.
Responsibility
NTC is an in-process temporal scheduler and cadence controller in the Control Plane, with ingress and status surfaces. It schedules and paces work. It is not a separate causal-DAG clock, and the reviewed ADAPTIVE mode is refused at startup.
Key capabilities
In-process temporal scheduling and cadence control
Temporal status and ingress surfaces
Scheduler modes OBSERVE and SHADOW (do not change timers)
OperationsDemonstrable
AIOps
Read-only drift, incident, state and summary analysis over audit chains, using deterministic rules. No forecasting, tuning or decision authority.
Responsibility
AIOps provides read-only operational understanding: it reads recorded audit evidence and control-plane state and produces drift, incident, state and summary findings using deterministic rules. It cannot admit, permit or dispatch, and it does not forecast or tune policy in the reviewed implementation.
Key capabilities
Read-only drift detection over audit chains
Incident, state and summary findings
Deterministic rule-based analysis (no model inference)
OperationsDemonstrable
NiGeNje Console
Same-origin backend-for-frontend operator read surfaces with permission checks and no token leakage. Development/demo surface, not a production operator plane.
Responsibility
The Console is an authenticated operator surface backed by a same-origin backend-for-frontend. It proxies control-plane, admission, AIOps and network read routes with permission checks, and deliberately provides no open proxy and no token leakage to the browser.
Key capabilities
Same-origin backend-for-frontend with no open proxy
Permission-checked read routes over platform services
Operational read models for governance, evidence and network surfaces
Maturity
What the maturity labels mean.
Every label comes from the canonical product register and is backed by engineering evidence recorded outside this site. The vocabulary is deliberately strict.
If a claim is not supported by recorded evidence, it is not made here.
Maturity vocabulary
Qualified
Passed its defined qualification tests.
Integrated
Verified behaviour across the specified components in a bounded local, non-production demonstration chain.
Demonstrable
A working development demonstration exists.
Implemented
Confirmed implementation exists.
In progress
Implementation or integration is underway.
Planned
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.
Start somewhere concrete
Bring the invariant that must not be broken.
The most useful first conversation starts with a system boundary, an action class and a failure mode — not a feature list.
