Kernel capabilities implemented. End-to-end platform integration and qualification are progressing.Interactive demonstrationPlatform status
Explore the platformBecome a collaborator

Product portfolio

The product portfolio.

An independent governance and control layer for autonomous and distributed systems. The portfolio is organised into four families. The governance family leads with λ-Safe — formal assurance, invariant preservation and safe-degradation constraints — and every product page states the evidence behind its maturity and the limits of what has actually been verified.

20 products4 product familiesNo production qualification claimed
Browse by familyArchitecture model

Family 01

Governance and formal assurance

Declare intent, formalize contracts, verify invariants and authorise what may proceed.

4 products in this family.
  • Governance and formal assuranceIntegrated

    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. In the platform architecture Chinje is the sole evidence-sufficiency and conformance authority; those responsibilities are not delegated to λ-Safe, the Control Plane or the runtime enforcement layer.

    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
    2 lifecycle positionsView Chinje
  • Governance and formal assuranceIntegrated

    λ-Safe

    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.

    Key capabilities

    • Formalization of machine-enforceable contracts from declared intent
    • Deterministic compilation of supported a deliberately bounded class of hard invariants and invariant checks
    • Verification of admissible state transitions for supported contracts
    1 lifecycle positionView λ-Safe
  • Governance and formal assuranceIntegrated

    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
    2 lifecycle positionsView Intent-to-Control Bridge
  • Governance and formal assuranceIntegrated

    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
    1 lifecycle positionView Gatekeeper

Family 02

Decision and control

Evaluate policy, constraints, uncertainty and containment state before anything is dispatched.

4 products in this family.
  • Decision and controlIntegrated

    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
    4 lifecycle positionsView Control Plane
  • Decision and controlImplemented

    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
    1 lifecycle positionView IDM Solver
  • Decision and controlImplemented

    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)
    1 lifecycle positionView Confidence Estimator
  • Decision and controlImplemented

    Immune Engine

    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
    2 lifecycle positionsView Immune Engine

Family 03

Runtime and execution assurance

Mediate registered actions, execute through controlled adapters, observe outcomes and preserve evidence.

6 products in this family.
  • Runtime and execution assuranceDemonstrable

    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
    2 lifecycle positionsView NARG
  • Runtime and execution assuranceDemonstrable

    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
    2 lifecycle positionsView Substrate
  • Runtime and execution assuranceImplemented

    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
    2 lifecycle positionsView Integrations
  • Runtime and execution assuranceIntegrated

    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
    • Outcome classification: conformant, diverged, unknown
    4 lifecycle positionsView Reconciliation and Audit
  • Runtime and execution assuranceDemonstrable

    Independent Observer

    Post-action observation of external state feeding reconciliation — with the current independence boundary stated explicitly.

    Responsibility

    Independent Observer captures external state after an action so reconciliation compares observed reality with the required postcondition instead of trusting the executor's response. In the reviewed implementation the read-back is performed by NARG against the same local effect store; a separate third-party reader has not been built.

    Key capabilities

    • Post-action state capture and read-back
    • Observed state supplied to reconciliation
    • Explicit unknown observation when state cannot be read
    1 lifecycle positionView Independent Observer
  • Runtime and execution assuranceIntegrated

    Certification and Audit Ledger

    Per-component hash-chained decision, permit, execution and outcome records with lifecycle reconstruction and explicit evidence boundaries.

    Responsibility

    The Certification and Audit Ledger keeps ordered, hash-linked records for decisions, permits, execution attempts and reconciliation outcomes. It verifies component chains and builds a lifecycle reconstruction artefact. The name is architectural: no certification, WORM storage or external audit attestation is claimed.

    Key capabilities

    • Per-component hash-chained audit records
    • Chain verification and ordered lifecycle reconstruction
    • Correlation of decision, permit, execution and outcome by identifier
    2 lifecycle positionsView Certification and Audit Ledger

Family 04

Extended platform

Change assurance, network governance, temporal control, operational analysis and the operator console.

6 products in this family.
  • Extended platformDemonstrable

    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.

    Key capabilities

    • Change lifecycle: declare → attest → admit → candidate → commit → enforce → observe → reconcile → audit
    • Policy gates over a proposed change
    • Commit invariant ΔJ/ε with candidate refusal on violation
    3 lifecycle positionsView MZiNG
  • Extended platformDemonstrable

    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
    2 lifecycle positionsView MZiNG Network
  • Extended platformIn 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)
    2 lifecycle positionsView NTC
  • Extended platformDemonstrable

    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)
    2 lifecycle positionsView AIOps
  • Extended platformDemonstrable

    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
    3 lifecycle positionsView MZiNG Assurance
  • Extended platformDemonstrable

    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
    2 lifecycle positionsView NiGeNje Console

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.

Explore a design-partner evaluationTry the interactive demonstrationRequest an architecture review