Invariant-aware autonomy
NiGeNje is an intent- and invariant-governed control platform for autonomous and distributed systems. Govern the transition from declared intent to authorized action, runtime enforcement and independently reviewable outcomes.
Intent
Reconcile inventory allocation
INT-2026-114 · v3 · approved by second principal
Admission gates
permit-2.1 · exp 04:12Evidence chain
dec-8f31narg-2210obs-4c07rec-a91dPre-product · Design-partner programme open
Kernel capabilities implemented. End-to-end platform integration and qualification are progressing.
Read platform statusThe shift
Capability answers “can this be done?”. Governance answers “should this be done, by this actor, under these conditions, and can we prove what happened afterwards?”
Deciding what might be done.
Models and planners propose possibilities. Proposing is not permission.
Declaring what should be achieved.
A versioned, reviewable objective with explicit obligations and scope.
Determining what is permitted.
An independent admission decision, not a capability inferred from access.
Mediating whether the action may execute.
A permit bound to the exact action, verified again at dispatch.
Establishing what actually happened.
Observation and ordered records, not the executor's success response.
Evaluating the outcome against the original obligations.
A verdict derived from evidence — aligned, drifted or unknown.
A proposal is not permission. A decision is not execution. A successful response is not independent proof of outcome.
How NiGeNje separates theseCore capabilities
Each capability states what it does, why it matters, which component provides it and its current verified maturity. No production qualification is claimed.
Declared objectives, obligations and scope are made explicit, versioned and approved before action.
Why it mattersWithout an inspectable intent there is nothing to authorise against and nothing to be conformant with.
Chinje · Intent-to-Control Bridge
Capability detailSupported decidable invariants are compiled, and decisions are evaluated against constraint feasibility.
Why it mattersSafety obligations expressed only in prose cannot be enforced at a boundary.
λ-Safe Core · λ-Safe Enterprise · IDM Solver
Capability detailAn independent authority evaluates requirement gates and issues a scoped permit bound to the action.
Why it mattersThe component that executes must not also be the component that authorises.
Gatekeeper
Capability detailRegistered actions are verified against the permit at dispatch time, including arguments and digest.
Why it mattersA decision made earlier is not permission for a changed payload later.
NARG · Substrate
Capability detailExternal state is observed and compared with the required postcondition after an action.
Why it mattersA successful response is not independent proof that the intended outcome occurred.
Independent Observer · Reconciliation
Capability detailDecision, execution and outcome records are ordered, linked and reconstructible for review.
Why it mattersGovernance that cannot be reviewed after the fact is not accountability.
Certification and Audit Ledger
Capability detailActor identity, tenant scope, permit validity, replay protection and containment behaviour at the boundary.
Why it mattersAuthority without scope and replay protection is not a security boundary.
Gatekeeper · Immune Engine · Identity and trust authority
Capability detailLifecycle coordination across services, change assurance and network governance with explicit outcomes.
Why it mattersDistributed action needs coordination that can represent partial failure and unknown states honestly.
Control Plane · MZiNG · MZiNG Network · NTC / NiZiNG Temporal Controller
Capability detailHow NiGeNje works
Ten control points, logical responsibilities first. Select a stage to inspect the component that carries it.
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.
Control responsibility
Intent governance: versioned intent, obligations, actor authority, evidence sufficiency and conformance/drift assessment.
Chinje product page →Logical responsibilities are shown here. They are not all connected in one production execution chain: see the architecture and integration status for what is verified.
Product family
Products are presented with the maturity their evidence supports — implemented, demonstrable or integrated in a bounded non-production chain.
Declare what should happen, who may act and what must remain true.
Make the promise explicit before action.
Intent governance, actor identity and authority, obligation tracking, evidence sufficiency, conformance and drift.
Translate intent into enforceable requirements.
Translation of declared intent and obligations into machine-enforceable contract fragments and compiler inputs.
Compile obligations and decide whether a specific action may proceed.
Unknown is not proof.
Deterministic contract compilation, supported invariant checks and safe handling of unsupported or indeterminate obligations.
Admission is a decision, not a side effect.
Independent admission and authorisation, gate evaluation and signed permit issuance bound to the action.
Evaluate policy, constraints and uncertainty before anything is dispatched.
Coordinate the decision, not only the call.
Policy evaluation, decision coordination, execution state and optimisation across the governance lifecycle.
Feasible decisions inside hard constraints.
Invariant-Dynamic Machine decision model and its supported solver capabilities for constrained decisions.
Uncalibrated confidence, stated as uncalibrated.
In-process evidence-sufficiency scoring and an explicitly uncalibrated confidence object attached to decision metadata.
Mediate registered actions and execute through controlled adapters.
Propose is not dispatch.
Runtime action mediation for registered agent and tool actions, separating a proposal from a dispatched effect.
Execute only under a verified permit.
Controlled execution and resource adapters that apply an action and support independent read-back.
One governed external boundary, built carefully.
A permit-gated Kubernetes Deployment scale boundary with receipt, plus connector and adapter libraries. Never live-cluster validated in the reviewed environment.
Observe outcomes, reconcile state, contain harm and preserve evidence.
A successful response is not proof of outcome.
Independent observation, expected-versus-observed reconciliation and linked evidence across the audit ledger.
Pressure and quarantine state at the admission boundary.
Pressure/quarantine state and an admission veto within defined policies, plus a containment request shape. Not an autonomous detector.
Change only within declared invariants.
Control Plane change assurance: policy gates, change lifecycle, commit invariant and enforcement planning for system change.
Network change assurance inside the Control Plane.
In-process Control Plane network change and commit assurance: topology, network gates, potential, routing and containment plan surfaces. Not packet-level enforcement.
Change assurance in a standalone lab.
Separate change-assurance product: no-regression gate, signed evidence, nftables laboratory and PostgreSQL failover testing.
Read-only operational understanding, temporal coordination and advisory analysis.
A temporal scheduler inside the control plane.
NiZiNG Temporal Controller — an in-process temporal scheduler and cadence controller. Not a causal validation engine.
Read-only findings over recorded evidence.
Read-only drift, incident, state and summary analysis over audit chains, using deterministic rules. No forecasting, tuning or decision authority.
A development operator surface.
Same-origin backend-for-frontend operator read surfaces with permission checks and no token leakage. Development/demo surface, not a production operator plane.
Why NiGeNje
This is a conceptual comparison with execution-oriented architectures. It is not a claim that every other platform lacks these features; it explains where NiGeNje places the control boundary.
| Dimension | Execution-oriented architecture | NiGeNje approach |
|---|---|---|
| Intent | Often embedded in application logic, prompts or tickets. | Explicit, versioned intent with obligations and scope. |
| Authorization | Commonly handled at individual service boundaries. | Governed admission and scoped authority independent of the executor. |
| Action | A tool or service invokes execution directly. | Registered runtime mediation binds a permit to the exact action. |
| Invariants | May be distributed across implementation and documentation. | Explicit, supported invariant formalization with refusal of the undecidable. |
| Outcome | Frequently inferred from the executor's response. | Independent observation where integrated; unknown stays unknown. |
| Conformance | Often post-hoc and application-specific. | Evidence-driven conformance model with explicit verdicts. |
| Drift | Requires application-specific monitoring. | Defined drift classification and resolution, partially integrated. |
Where NiGeNje depends on work still in progress — independent observation, external identity, packet-level enforcement — the platform says so instead of implying completeness.
Security and trust
NiGeNje treats authority, scope and evidence as separate controls. A permit is scoped to an action, a tenant and an expiry; a successful response is not trusted as proof; and an unobserved policy context blocks instead of permitting.
Important boundary
NARG protects registered mediation paths. It is not universal interception of arbitrary shell commands, direct sockets or unwrapped filesystem writes. No certification, regulatory compliance or production security guarantee is claimed.
Deployment and integration
The intended deployment model moves from local evaluation to controlled qualification before any production discussion. Implemented connectors are distinguished from intended integrations.
The verified way to run the demonstrators: local services, non-production fixtures and a reviewable transaction.
A bounded host can exercise admission, mediation, execution and evidence against defined test cases.
Compose definitions exist per repository. A Docker daemon was unavailable in the reviewed environment, so container startup is not claimed as verified here.
Kubernetes is an integration direction for running platform services. It is not a production-qualified deployment.
Connectors and execution adapters exist behind the control boundary; connector certification is not claimed.
Multi-site coordination, network governance and temporal validation require further integration and evidence.
Interactive demonstration
Follow an autonomous agent attempting a registered state-changing operation. Choose the intent, actor, target and action, then inspect admission, mediation, observation, evidence and conformance.
Simulation disclosure
Interactive product simulation. Results are generated by a local demonstration model and do not represent live production enforcement.
Scenarios include a valid action, a denied action and a divergent outcome where the executor reports success but observed state does not match the required postcondition.
Local simulationNo account requiredNo backend connection
Technical resources
Specifications, research and engineering status are provided where they can be published truthfully. Private implementation details remain private.
Platform concepts, architecture, security boundaries and evaluation guidance.
Open documentationInteractive component map, lifecycle boundaries and verified integration status.
Explore architectureType-theoretic framework for invariant-preserving degradation in distributed systems.
Read the researchWhat is enforced at the boundary, what is not, and how to evaluate it.
Review security boundariesCommercial engagement
Enterprise governance is adopted in stages. Each stage produces evidence and a decision — not a promise of production deployment.
Agree the system boundary, the action class and the invariant or obligation that must not be broken. No product commitment is implied.
Review where the control boundary would sit, which components would be involved and which invariants are expressible with current λ-Safe support.
Run a non-production evaluation against defined fixtures: admitted, denied, diverged and unavailable paths, with evidence inspected.
Integrate through registered mediation and execution adapters in a bounded environment, with explicit failure and rollback behaviour.
Define qualification tests, inspect conformance evidence and record what passed, what failed and what remains out of scope.
Plan production topology, identity, key management, observability and support boundaries. Production qualification is not implied by earlier stages.
Next step
The first conversation is about what should be governed and what evidence would count — before any platform commitment.