Kernel capabilities implemented. End-to-end platform integration and qualification are progressing.Interactive demonstrationPlatform status

Invariant-aware autonomy

Autonomy with boundaries. Systems that preserve their invariants.

NiGeNje governs autonomous and distributed systems through intent formalization, invariant verification, authorization, runtime enforcement and independent outcome assurance. Its architecture connects what systems are permitted to do with the safety constraints they must preserve — including when operating conditions deteriorate.

  • Proposal is not permission
  • Decision is not execution
  • A response is not independent proof
  • Availability is not invariant preservation
NiGeNje / governance consoleLocal simulation

Intent

Reconcile inventory allocation

INT-2026-114 · v3 · approved by second principal

Δ ≥ 0tenant: acme-eu≤ 1 write
01Intentevaluated
02Admissionadmitted
03Mediationverified
04Observationobserved
05Conformanceconformant

Admission gates

  • Actor identityoperator · tenant acme-eu
  • Intent authorityINT-2026-114 · approved v3
  • Invariant checkλ-cert 9f2c… · 2 mandatory · unknown 0
  • Operating envelopeassumptions valid · degraded: no
  • Scope & action digeststate.write · digest 7b41…
  • Replay protectionnonce unused · permit-2.1
Permit issuedpermit-2.1 · exp 04:12

Evidence chain

  • decisiondec-8f31
  • mediationnarg-2210
  • observationobs-4c07
  • reconciliationrec-a91d
Conformantobserved state matches postcondition
Illustrative interface. Local demonstration model — not live telemetry, not a production connection.

Pre-product · Design-partner programme open

Kernel capabilities implemented. End-to-end platform integration and qualification are progressing.

Read platform status

The shift

Autonomous systems need more than execution.

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?”

  1. 01

    Intelligence

    Deciding what might be done.

    Models and planners propose possibilities. Proposing is not permission.

  2. 02

    Intent

    Declaring what should be achieved.

    A versioned, reviewable objective with explicit obligations and scope.

  3. 03

    Authority

    Determining what is permitted.

    An independent admission decision, not a capability inferred from access.

  4. 04

    Control

    Mediating whether the action may execute.

    A permit bound to the exact action, verified again at dispatch.

  5. 05

    Evidence

    Establishing what actually happened.

    Observation and ordered records, not the executor's success response.

  6. 06

    Conformance

    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 these

Two dimensions of governed autonomy

NiGeNje governs what systems may do — and what must remain true.

Intent governance and invariant preservation are complementary. One decides whether an action is authorised; the other constrains which states and transitions the system is allowed to reach, including under degradation.

Dimension A

Intent and authority governance

Establishes what an actor intends, who is authorised, which contracts and policies apply, whether an action is admitted, how execution is mediated and whether the observed outcome conforms to the approved intent.

  1. Intent
  2. Chinje
  3. Intent-to-Control Bridge
  4. Gatekeeper
  5. Control Plane
  6. NARG
  7. Execution
  8. Observation
  9. Reconciliation
  10. Conformance
  • Versioned intent, obligations and scope reviewed by a distinct principal.
  • Machine-enforceable contracts compiled from that intent by the Bridge and λ-Safe.
  • Independent admission and a permit bound to the exact action.
  • Registered runtime mediation, observation and evidence-driven conformance.
Walk the intent lifecycle

Dimension B

Invariant preservation and safe degradation

Establishes which conditions must always hold, which boundaries cannot be violated, which states and transitions are admissible, and how the system responds when capacity, dependencies or operating assumptions deteriorate.

  1. Contracts
  2. λ-Safe verification
  3. Invariant set
  4. Decision constraints
  5. Immune containment
  6. Degraded mode
  7. Recovery verification
  • λ-Safe formalizes contracts and verifies admissible conditions.
  • Compiled invariants constrain decisions made by the Control Plane and IDM solver.
  • Confidence and immune state inform when the operating envelope is degrading.
  • Containment and reduced modes protect mandatory properties — verification, decision and enforcement stay separate.
λ-Safe does not enforce. It verifies contracts and transitions. Gatekeeper admits, NARG mediates and Substrate executes.
Governed safe degradation: the full capability

The two dimensions meet in the same lifecycle: an authorised action must also be an admissible transition, and a degraded system must still be able to evidence what it did.

Core capabilities

Governance across the lifecycle, not at a single gate.

Each capability states what it does, why it matters, which component provides it and its current verified maturity. No production qualification is claimed.

Integrated

Intent governance

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 detail
Integrated

Invariant-aware decision control

Supported decidable invariants and admissible-transition rules 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 detail
Demonstrable

Governed safe degradation

Invariants define admissible operating and degraded modes; transitions are authorised, mediated, observed and assessed for conformance when conditions deteriorate.

Why it mattersAvailability and recovery mechanisms can keep a system serving while it violates the invariant it was built to protect. If no admissible mode exists, denial or containment is the governed answer.

λ-Safe Core · Chinje · Gatekeeper · Control Plane · IDM Solver · Confidence Estimator · Immune Engine · NARG

Capability detail
Integrated

Explicit authority and admission

An 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 detail
Integrated

Runtime action mediation

Registered 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 detail
Integrated

Independent observation and reconciliation

External 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 detail
Integrated

Evidence and audit continuity

Decision, 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 detail
In progress

Security and containment

Actor 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 detail
Demonstrable

Distributed-system coordination

Lifecycle 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 detail

Capability · Governed safe degradation

When conditions fail, system invariants must not.

Demonstrable

A cross-platform capability spanning Chinje, λ-Safe and the control and enforcement path. Grounded in published λ-Safe research and demonstrated as a simulation; end-to-end qualification is not claimed.

Uncontrolled degradation

Service continues while safety quietly erodes.

Fallbacks and retries keep the system up. Nothing checks whether the reduced mode still satisfies consistency, conservation or policy constraints. The system appears healthy while violating exactly the property it was built to protect.

  • Operating assumptions fail silently
  • Fallback paths bypass invariant checks
  • Availability is mistaken for conformance

Governed safe degradation

Reduce what is optional; protect what is mandatory.

Declared invariants define admissible transitions. When conditions deteriorate, the control path authorises and mediates a defined reduced mode, observes the outcome and has Chinje assess conformance. If no admissible mode exists, the system denies or contains rather than inventing an unsafe fallback.

  • Assumptions and constraints are explicit
  • Admissible reduced modes are verified and authorised
  • Recovery is a new, verified transition
  1. 01

    Normal operating conditions

    Capacity, dependencies and operating assumptions are within their declared bounds.

  2. 02

    Deterioration

    A dependency, resource or region degrades; the system is still serving but no longer inside its normal envelope.

  3. 03

    Assumption violated

    The operating assumption behind an invariant is no longer valid; the control path records it instead of ignoring it.

  4. 04

    Admissible responses evaluated

    The system evaluates which reduced modes and transitions the compiled constraints still permit.

  5. 05

    Non-essential capability restricted

    Optional behaviour is reduced or refused so that the mandatory invariants remain protected.

  6. 06

    Invariants preserved

    The system operates in a defined degraded mode. This is not a promise that every service stays available.

  7. 07

    Recovery requires verification

    Returning to normal operation is a new admissible transition, not an automatic rollback.

Safe degradation is not a guarantee of availability.

It is a commitment that defined safety properties remain protected under stated operating assumptions — demonstrated here as a simulation, not as production enforcement.

How NiGeNje works

Intent to evidence, with review in the loop.

Ten control points, logical responsibilities first. Select a stage to inspect the component that carries it.

Select a stage to see the control responsibility at that boundary.

01

Intent

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

  • ChinjeIntegrated

    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

One platform, distinct control responsibilities.

Products are presented with the maturity their evidence supports — implemented, demonstrable or integrated in a bounded non-production chain.

Governance and formal assurance

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

ChinjeIntegrated

Make the promise explicit before action.

Intent governance, actor identity and authority, obligation tracking, evidence sufficiency, conformance and drift.

  • Intent authoring, approval and version chain with a distinct approving principal
  • Declared obligations, scope and expiry attached to a published intent
λ-SafeIntegrated

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.

  • Formalization of machine-enforceable contracts from declared intent
  • Deterministic compilation of supported a deliberately bounded class of hard invariants and invariant checks
Intent-to-Control BridgeIntegrated

Translate intent into enforceable requirements.

Translation of declared intent and obligations into machine-enforceable contract fragments and compiler inputs.

  • Intent resolution against authority and compiler inputs
  • Translation package generation for a published intent version
GatekeeperIntegrated

Admission is a decision, not a side effect.

Independent admission and authorisation, gate evaluation and signed permit issuance bound to the action.

  • 13-gate admission evaluation with explicit refusal reasons
  • Signed permit issuance with scope, expiry, nonce and action-digest binding

Decision and control

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

Control PlaneIntegrated

Coordinate the decision, not only the call.

Policy evaluation, decision coordination, execution state and optimisation across the governance lifecycle.

  • Policy evaluation and decision coordination
  • Dispatch only against a verified permit
IDM SolverImplemented

Feasible decisions inside hard constraints.

Invariant-Dynamic Machine decision model and its supported solver capabilities for constrained decisions.

  • α-fair single-resource allocation within declared bounds
  • Opt-in multi-resource projection (prototype)
Confidence EstimatorImplemented

Uncalibrated confidence, stated as uncalibrated.

In-process evidence-sufficiency scoring and an explicitly uncalibrated confidence object attached to decision metadata.

  • Evidence-sufficiency scoring for a decision context (in-process)
  • Explicit uncalibrated confidence metadata (calibrated:false, probability 0, method none)
Immune EngineImplemented

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.

  • Pressure and quarantine state used by admission
  • Admission veto when immune policy state requires it

Runtime and execution assurance

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

NARGDemonstrable

Propose is not dispatch.

Runtime action mediation for registered agent and tool actions, separating a proposal from a dispatched effect.

  • Registered action mediation with proposal and dispatch separated
  • Permit verification bound to action and arguments
SubstrateDemonstrable

Execute only under a verified permit.

Controlled execution and resource adapters that apply an action and support independent read-back.

  • Permit verification before an effect is applied
  • Controlled execution through a reference adapter
IntegrationsImplemented

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.

  • Permit-gated Kubernetes Deployment scale operation with receipt
  • Connector and adapter libraries for external targets
Reconciliation and AuditIntegrated

A successful response is not proof of outcome.

Independent observation, expected-versus-observed reconciliation and linked evidence across the audit ledger.

  • Observation of external state after an action
  • Expected-versus-observed comparison with explicit divergence
Independent ObserverDemonstrable

A response is not proof of what happened.

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

  • Post-action state capture and read-back
  • Observed state supplied to reconciliation
Certification and Audit LedgerIntegrated

Linked records, not a certification badge.

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

  • Per-component hash-chained audit records
  • Chain verification and ordered lifecycle reconstruction

Extended platform

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

MZiNGDemonstrable

Change only within declared invariants.

Control Plane change assurance: policy gates, change lifecycle, commit invariant and enforcement planning for system change.

  • Change lifecycle: declare → attest → admit → candidate → commit → enforce → observe → reconcile → audit
  • Policy gates over a proposed change
MZiNG NetworkDemonstrable

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.

  • Network admission and permit handling
  • Certificate and trust material surfaces
NTCIn progress

A temporal scheduler inside the control plane.

NiZiNG Temporal Controller — an in-process temporal scheduler and cadence controller. Not a causal validation engine.

  • In-process temporal scheduling and cadence control
  • Temporal status and ingress surfaces
AIOpsDemonstrable

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.

  • Read-only drift detection over audit chains
  • Incident, state and summary findings
MZiNG AssuranceDemonstrable

Change assurance in a standalone lab.

Separate change-assurance product: no-regression gate, signed evidence, nftables laboratory and PostgreSQL failover testing.

  • No-regression gate for a proposed change
  • Signed evidence for change-assurance decisions
NiGeNje ConsoleDemonstrable

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.

  • Same-origin backend-for-frontend with no open proxy
  • Permission-checked read routes over platform services

Why NiGeNje

A control layer, not another execution surface.

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.

Control boundary by dimension
DimensionExecution-oriented architectureNiGeNje approach
IntentOften embedded in application logic, prompts or tickets.Explicit, versioned intent with obligations and scope.
AuthorizationCommonly handled at individual service boundaries.Governed admission and scoped authority independent of the executor.
ActionA tool or service invokes execution directly.Registered runtime mediation binds a permit to the exact action.
InvariantsMay be distributed across implementation and documentation.Explicit, supported invariant formalization with refusal of the undecidable.
DegradationAvailability mechanisms preserve service, not necessarily invariants.Safe-degradation constraints aim to preserve mandatory safety properties in reduced modes.
OutcomeFrequently inferred from the executor's response.Independent observation where integrated; unknown stays unknown.
ConformanceOften post-hoc and application-specific.Evidence-driven conformance model with explicit verdicts.
DriftRequires 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

Fail closed where a boundary is actually enforced.

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.

  • Authenticated actor identity
  • Tenant boundaries
  • Scoped capabilities
  • Permit validity and revocation
  • Action and argument binding
  • Replay protection
  • Tamper-evident evidence
  • Independent observation
  • Fail-closed behaviour
  • Immune containment

Deployment and integration

Evaluate in stages. Claim only what is verified.

The intended deployment model moves from local evaluation to controlled qualification before any production discussion. Implemented connectors are distinguished from intended integrations.

  1. Local development and evaluation

    Implemented path

    The verified way to run the demonstrators: local services, non-production fixtures and a reviewable transaction.

  2. Single-host controlled qualification

    Demonstrable

    A bounded host can exercise admission, mediation, execution and evidence against defined test cases.

  3. Containerised deployment

    Partial

    Compose definitions exist per repository. A Docker daemon was unavailable in the reviewed environment, so container startup is not claimed as verified here.

  4. Kubernetes integration direction

    In progress

    Kubernetes is an integration direction for running platform services. It is not a production-qualified deployment.

  5. External system integration through adapters

    In progress

    Connectors and execution adapters exist behind the control boundary; connector certification is not claimed.

  6. Future distributed deployment

    Planned

    Multi-site coordination, network governance and temporal validation require further integration and evidence.

Interactive demonstration

Run a governed scenario in the browser.

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.

  • 01Select an intent and inspect its declared obligations
  • 02Choose an actor, target resource and proposed action
  • 03Inspect the action digest and declared scope
  • 04Run the governance evaluation and see gate-level results
  • 05Observe admission, permit issuance or denial
  • 06Compare expected and observed state, then read the evidence record

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

See NiGeNje in Action

Placeholder

Platform demonstration coming soon.

Explore how NiGeNje connects intent, formal constraints, authorization, runtime enforcement, independent observation and conformance.

No video URL is configured in this build. No third-party player, script or frame is requested on this page.

The interactive console is a local, deterministic simulation. A video is a recording of the platform, not live production enforcement. Third-party media is requested only after you choose to load it, and the placeholder state makes no external requests.

Research and publications

Research that precedes the platform.

NiGeNje’s engineering direction is grounded in published research, formal specifications and working papers. Research directions are labelled as such and are not presented as production capabilities.

The question connecting the portfolio

How can computational systems evolve, act, adapt and recover while preserving the essential properties, authority and continuity that make their behaviour trustworthy?

λ-Safe

Published

A type-theoretic framework for safe degradation in distributed systems: invariants, admissible transitions and degradation contracts.

Zenodo · 2025 · George Ocharo Onchaba

NiZiNG

Published

State theory, rhythmic computing and infinite-state models: early research and software directions for alternative computational representations.

Zenodo · 26 July 2025 · v0.9

Chinje

Specifications

Intent-aware architecture conformance: evidence sufficiency, identity and authority, drift classification and continuity between declared and realised behaviour.

Design specification · technical spec · concept paper

Portrait forthcomingNo portrait is published. This is an intentional placeholder, not a photograph.

Founder

George Ocharo Onchaba

Founder and Chief Architect, NiGeNje

Systems Architect | Backend and Platform Engineer | Distributed Systems Researcher

George Ocharo Onchaba is a Kenyan software engineer, systems architect and technology founder. He is the founder and Chief Architect of NiGeNje, where he works on governance and control infrastructure for autonomous and distributed systems.

His background is in backend and platform engineering — Java and Spring Boot services, enterprise integrations, distributed systems and cloud infrastructure — combined with research in formal constraints, invariant preservation and runtime governance. The platform is the result of that combination.

Collaboration

Help build the future of governed infrastructure.

NiGeNje is seeking collaborators to engineer, test, research and advance the platform. If you work on distributed systems, formal methods, compilers, security or reliability, there is a concrete way to contribute.

Who we are looking for

  • Distributed systems engineers
  • Backend and platform engineers
  • Formal methods researchers
  • Compiler and language engineers
  • Security and reliability specialists
  • DevOps and SRE professionals
  • Academic researchers
  • Enterprise design partners

Collaboration paths include engineering contributions, technical evaluation, research collaboration, integration development and testing. No employment, compensation or equity is promised, and not every project is open source.

Technical resources

Evaluate the architecture, not the marketing.

Specifications, research and engineering status are provided where they can be published truthfully. Private implementation details remain private.

Documentation

Platform concepts, architecture, security boundaries and evaluation guidance.

Open documentation

Architecture

Interactive component map, lifecycle boundaries and verified integration status.

Explore architecture

λ-Safe research

Type-theoretic framework for invariant-preserving degradation in distributed systems.

Read the research

Commercial engagement

Start with the invariant that must not be broken.

Enterprise governance is adopted in stages. Each stage produces evidence and a decision — not a promise of production deployment.

  1. 01

    Discovery and problem definition

    Agree the system boundary, the action class and the invariant or obligation that must not be broken. No product commitment is implied.

  2. 02

    Architecture and invariant assessment

    Review where the control boundary would sit, which components would be involved and which invariants are expressible with current λ-Safe support.

  3. 03

    Bounded technical evaluation

    Run a non-production evaluation against defined fixtures: admitted, denied, diverged and unavailable paths, with evidence inspected.

  4. 04

    Controlled integration

    Integrate through registered mediation and execution adapters in a bounded environment, with explicit failure and rollback behaviour.

  5. 05

    Qualification and conformance review

    Define qualification tests, inspect conformance evidence and record what passed, what failed and what remains out of scope.

  6. 06

    Deployment planning

    Plan production topology, identity, key management, observability and support boundaries. Production qualification is not implied by earlier stages.

Next step

Bring a system boundary, an autonomous action or a failure mode.

The first conversation is about what should be governed and what evidence would count — before any platform commitment.