Governance and formal assurance
Declare intent, formalize contracts, verify invariants and authorise what may proceed.
Platform overview
One control model for autonomous and distributed systems.
NiGeNje is an intent- and invariant-governed control platform for autonomous and distributed systems. NiGeNje separates what a system intends to do, what it is authorised to do, what it actually executes and what can subsequently be verified. The platform governs two dimensions: intent and authority, and invariant preservation with safe degradation.
Engineering status
Kernel capabilities implemented. End-to-end platform integration and qualification are progressing.
NiGeNje is not production-qualified. No production deployment, certification, benchmark, customer outcome or integration count is claimed on this site.
Positioning
Autonomous systems need more than execution.
Execution is the floor, not the guarantee. A governed system must also establish what was intended, who was authorised, which invariants applied, what actually happened and whether the outcome conformed — and preserve the invariants that must remain true when conditions fail.
This comparison is a design position. Every maturity claim is made per capability and per component — never as an end-to-end production claim.
Intelligence
A system can choose an action without establishing that the action was permitted.
Intent
Objectives, obligations and scope made explicit and versioned — not inferred from a prompt.
Authority
Admission decided independently of the component that executes.
Control
Policy, constraint feasibility and uncertainty coordinated before dispatch.
Evidence
Observation and reconciliation recorded separately from the executor's claim.
Conformance
Outcomes evaluated against the original obligations, with unknown kept explicit.
Conventional execution vs governed execution
A design position, not a claim that every dimension is implemented end to end. Maturity is stated per capability and per component.
- IntentConventional
Often embedded in application logic, prompts or tickets.
NiGeNjeExplicit, versioned intent with obligations and scope.
- AuthorizationConventional
Commonly handled at individual service boundaries.
NiGeNjeGoverned admission and scoped authority independent of the executor.
- ActionConventional
A tool or service invokes execution directly.
NiGeNjeRegistered runtime mediation binds a permit to the exact action.
- InvariantsConventional
May be distributed across implementation and documentation.
NiGeNjeExplicit, supported invariant formalization with refusal of the undecidable.
- DegradationConventional
Availability mechanisms preserve service, not necessarily invariants.
NiGeNjeSafe-degradation constraints aim to preserve mandatory safety properties in reduced modes.
- OutcomeConventional
Frequently inferred from the executor's response.
NiGeNjeIndependent observation where integrated; unknown stays unknown.
- ConformanceConventional
Often post-hoc and application-specific.
NiGeNjeEvidence-driven conformance model with explicit verdicts.
- DriftConventional
Requires application-specific monitoring.
NiGeNjeDefined drift classification and resolution, partially integrated.
Two dimensions
Two dimensions of governed autonomy.
NiGeNje governs intent and authority in one dimension, and invariant preservation in the other. The dimensions meet in decision-making: an action is admissible only when it is both authorised and inside the compiled safety constraints.
When conditions fail, system invariants must not. λ-Safe formalizes invariants and safe-degradation constraints; it informs decisions and does not replace the Control Plane or NARG. Read the λ-Safe product page. Read the Governed Safe Degradation capability.
Dimension A · Intent and authority
What may happen, and who authorises it.
Declared intent becomes scoped authority. Admission is independent of the component that executes, and every action leaves an evidence trail.
- Intent
- Chinje
- Bridge
- Gatekeeper
- Control Plane
- NARG
- Execution
- Observation
- Reconciliation
- Conformance
Establishes authority and evidence: intent → admission → mediation → execution → observed outcome → conformance.
Dimension B · Invariant preservation
What must remain true when conditions fail.
Formal constraints define admissible transitions and admissible degraded modes. Verification constrains; it does not decide or enforce.
- ContractsObligations formalized from the published intent.
- λ-Safe verificationAdmissibility checked within supported invariants.
- Invariant setCompiled constraints with an explicit checked/not-checked boundary.
- Decision constraintsControl Plane decisions must respect the compiled invariant set.
- Immune containmentContainment state responds when operating assumptions are violated.
- Degraded modeNon-essential capability is restricted; mandatory invariants stay protected.
- Recovery verificationNormal operation resumes only after fresh verification.
Preserves safety properties: a reduced mode is admissible only within compiled degradation constraints.
How the dimensions meet
λ-Safe informs decisions; it does not replace the Control Plane or NARG. Formal verification establishes what is admissible, the Control Plane decides what to do, and Gatekeeper, NARG and Substrate enforce the admitted action.
- Dimension A authorises: intent → admission → mediation → execution → observed outcome → conformance.
- Dimension B constrains: contracts → invariants → decision constraints → admissible degraded modes → recovery verification.
- Verification is evidence, not authority: an admissible verdict is not a permit, a decision or an execution.
Safe degradation · Seven steps
Preserve invariants while capability is reduced.
Availability mechanisms keep a system serving; they do not establish that its safety properties still hold. Degradation is admissible only within constraints derived from the original obligations and stated operating assumptions, and recovery is never assumed.
- Normal operationThe system operates within its stated operating assumptions.
- DeteriorationCapacity, dependency or environmental conditions degrade.
- Operating assumption violatedA condition the design relied on no longer holds.
- Admissible responses evaluatedCompiled constraints determine which reduced modes remain admissible.
- Non-essential capability restrictedOptional functionality is reduced to protect mandatory properties.
- Invariants preservedMandatory safety properties remain protected in the reduced mode.
- Recovery requires verificationReturning to normal operation requires fresh verification; recovery is not assumed.
Maturity boundary
Research-grounded and simulated. Safe degradation is a published type-theoretic research model and a labelled browser simulation. Production runtime degradation enforcement is not implemented or verified, and end-to-end safe-degradation qualification is not established. This page does not claim either.
Governance lifecycle
Intent to conformance, with review in the loop.
Ten canonical stages. Selecting a stage shows the components with a responsibility there, the verified maturity of each, and the limitation that still applies.
Stage numbering is canonical across the site: /platform#lifecycle is the reference view used by product pages and the architecture model.
Stage 01 of 10: Intent selected.
Stage 01 of 10
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.
Component responsibilities
- ChinjeServiceIntegrated
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 page
Capabilities
Nine capabilities across the lifecycle.
Each capability states what it does, why it matters, which components provide it and the maturity verified to date — including invariant preservation and safe degradation.
Maturity follows the product register. Read the maturity vocabulary.
- 01Integrated
Intent governance
What it does
Declared objectives, obligations and scope are made explicit, versioned and approved before action.
Why it matters
Without an inspectable intent there is nothing to authorise against and nothing to be conformant with.
Provided by
Intent publication and read-back verified in the local demonstration stack.
- 02Integrated
Invariant-aware decision control
What it does
Supported decidable invariants and admissible-transition rules are compiled, and decisions are evaluated against constraint feasibility.
Why it matters
Safety obligations expressed only in prose cannot be enforced at a boundary.
Provided by
Compiler and candidate solver verified for supported paths; unsupported obligations refused.
- 03Demonstrable
Governed safe degradation
What it does
Invariants define admissible operating and degraded modes; transitions are authorised, mediated, observed and assessed for conformance when conditions deteriorate.
Why it matters
Availability 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.
Invariant compilation is verified for supported bounds; the governed safe-degradation model is published research plus a labelled browser simulation. This is not production runtime enforcement; end-to-end qualification is not established.
- 04Integrated
Explicit authority and admission
What it does
An independent authority evaluates requirement gates and issues a scoped permit bound to the action.
Why it matters
The component that executes must not also be the component that authorises.
Provided by
13-gate admission with eight invalid-permit refusals and zero effects written.
- 05Integrated
Runtime action mediation
What it does
Registered actions are verified against the permit at dispatch time, including arguments and digest.
Why it matters
A decision made earlier is not permission for a changed payload later.
Proposal/dispatch separation and payload-mismatch refusal verified.
- 06Integrated
Independent observation and reconciliation
What it does
External state is observed and compared with the required postcondition after an action.
Why it matters
A successful response is not independent proof that the intended outcome occurred.
Provided by
DIVERGED and UNKNOWN outcomes verified; observation independence remains partial.
- 07Integrated
Evidence and audit continuity
What it does
Decision, execution and outcome records are ordered, linked and reconstructible for review.
Why it matters
Governance that cannot be reviewed after the fact is not accountability.
Provided by
Both component chains verified and lifecycle reconstruction produced.
- 08In progress
Security and containment
What it does
Actor identity, tenant scope, permit validity, replay protection and containment behaviour at the boundary.
Why it matters
Authority without scope and replay protection is not a security boundary.
Provided by
- Gatekeeper
- Immune Engine
- Identity and trust authority
Permit and replay paths verified; external identity and autonomous containment in progress.
- 09Demonstrable
Distributed-system coordination
What it does
Lifecycle coordination across services, change assurance and network governance with explicit outcomes.
Why it matters
Distributed action needs coordination that can represent partial failure and unknown states honestly.
Coordination verified locally; network and temporal capabilities are partially integrated.
Product family
One control model, expressed as four product families.
The portfolio is organised into four families. Each product owns a specific responsibility in the lifecycle and states its maturity, evidence and limitations.
No production qualification is claimed for any product. Maturity labels describe verified engineering evidence, not readiness for a regulated production deployment.
Decision and control
Evaluate policy, constraints, uncertainty and containment state before anything is dispatched.
Runtime and execution assurance
Mediate registered actions, execute through controlled adapters, observe outcomes and preserve evidence.
Extended platform
Change assurance, network governance, temporal control, operational analysis and the operator console.
Security and trust
Broad authority claims are not made.
The security model is narrow on purpose: authority is explicit, permits are scoped, and the boundary of enforcement is stated rather than implied.
- Independent admission. Gatekeeper issues permits; an executing component cannot authorise itself.
- Scoped, single-use permits. A permit is bound to the caller, tenant, target, action digest, expiry and nonce.
- Runtime mediation (under review). NARG verifies a permit against the exact action at a registered mediation point; an altered payload was refused in the recorded dispatch. NARG is currently classified NO-GO in the release-candidate assessment record, so this is demonstrated behaviour under review — not a shipping security control.
- Formal constraints inform, they do not enforce. λ-Safe compiles supported invariants and safe-degradation constraints; those constraints inform admission and decisions but never admit, mediate or execute an action themselves.
- Evidence continuity. Decision, execution and reconciliation records are ordered and hash-linked per component, with lifecycle reconstruction in the reviewed environment.
- Containment state, not autonomous containment. Immune pressure and quarantine state can veto admission, and an unobserved policy context blocks rather than permits. There is no detector and no autonomous containment actuator.
Deployment and integration
What can be run today, and what remains a direction.
Implemented environments are distinguished from intended ones. Nothing in this table is a production deployment claim.
Prior evidence recorded for MZiNG and MZiNG Network was not re-verified in the current review pass; their maturity labels reflect that.
| Environment | Status | What exists | What remains |
|---|---|---|---|
| Local development | Implemented | Kernel capabilities are exercised in the local demonstration stack, including admitted, denied, diverged and unknown paths. | This is not a production topology. A local development identity is used; production key management is not configured. |
| Single-host controlled qualification | In progress | A bounded qualification target for defined fixtures, with conformance evidence inspected after each run. | Qualification has not been completed, so no Qualified maturity is claimed for any component. |
| Containerised deployment | Partial | Container packaging is partial in the reviewed environment. | Containerised operation is not verified as a supported deployment path. |
| Kubernetes integration | Partial | One permit-gated Kubernetes Deployment scale operation with a receipt is implemented in Integrations, supported by connector and adapter libraries. | Never validated against a live cluster; one mutation type, a static token and no provider validation. Kubernetes integration is not production-qualified. |
| External adapters | Partial | An implemented Kubernetes mutation boundary plus connector and adapter libraries behind the control boundary. | Standalone and not running in the reviewed stack. No certified integration estate is claimed and no supported-integration count is published. |
| Future distributed deployment | Intended | Cross-region coordination, distributed key management and network governance are design directions under investigation. | Not implemented. Network enforcement currently operates at file and HTTP plan boundaries, not on packets or devices. |
A single-host controlled qualification path is the intended next step; it has not been completed. See platform status for the honest engineering state, and security boundaries for what is not enforced.
Get started
Staged adoption, with the evidence stated at every step.
Adoption is deliberately staged. Each step produces evidence that can be inspected before the next step is considered, and no stage implies production qualification.
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.
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.
03 Bounded technical evaluation
Run a non-production evaluation against defined fixtures: admitted, denied, diverged and unavailable paths, with evidence inspected.
04 Controlled integration
Integrate through registered mediation and execution adapters in a bounded environment, with explicit failure and rollback behaviour.
05 Qualification and conformance review
Define qualification tests, inspect conformance evidence and record what passed, what failed and what remains out of scope.
06 Deployment planning
Plan production topology, identity, key management, observability and support boundaries. Production qualification is not implied by earlier stages.
Programme boundary
The programme is bounded evaluation, not a promise of production deployment. Production qualification is a separate step that has not been achieved.