Intent and authority
Declare what should happen, who may act and what must remain true.
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.
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.
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.
- 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.
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
Eight capabilities across the lifecycle.
Each capability states what it does, why it matters, which components provide it and the maturity verified to date.
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 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.
- 03Integrated
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.
- 04Integrated
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.
- 05Integrated
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.
- 06Integrated
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.
- 07In 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.
- 08Demonstrable
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 product boundaries.
The portfolio is organised into six 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.
Verification and admission
Compile obligations and decide whether a specific action may proceed.
Control and decision
Evaluate policy, constraints and uncertainty before anything is dispatched.
Runtime and execution
Mediate registered actions and execute through controlled adapters.
Assurance and evidence
Observe outcomes, reconcile state, contain harm and preserve evidence.
Operations
Read-only operational understanding, temporal coordination and advisory analysis.
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 manifest, so this is demonstrated behaviour under review — not a shipping security control.
- 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.