Architecture overview
Components, dependency boundaries and the control points between intent, admission, mediation, execution, observation and evidence.
Documentation
Documentation for the public boundary.
Architecture, platform concepts, λ-Safe and invariant preservation, safe degradation, security boundaries, evaluation guidance and integration scope. This hub documents what is actually public; operator documentation and interface contracts are provided under engagement rather than invented for the website.
Documentation map
Start with the question you need answered.
Each entry points to material that exists. Where a document is not public, the page says so instead of publishing a placeholder.
Platform concepts
Intent governance, invariant compilation, independent admission, scoped permits, registered mediation, observation and conformance.
Security boundaries
What is enforced, what is partial and what is outside the NARG mediation boundary. Includes the buyer evaluation checklist.
Evaluation and deployment
How a bounded evaluation is scoped, what deployment planning involves and why production qualification is a separate stage.
Integration information
What is publicly stated about registered mediation, permit verification and execution adapters — and what is not published.
Status and readiness
Public integration state, maturity labels from the engineering registers and an honest account of what is unconfigured.
λ-Safe and invariant preservation
How supported invariants are compiled and refused, what must remain true in a degraded mode, and what the research does and does not establish.
λ-Safe and invariant preservation
What must remain true when conditions change.
λ-Safe is the verification and refusal component of the lifecycle. It formalizes supported contracts, compiles supported invariants, verifies admissible transitions and refuses what it cannot decide. It does not execute, permit or enforce anything at runtime.
Contract, invariant and certificate
A governed operation begins with explicit obligations. λ-Safe turns the supported ones into machine-checkable contract artifacts and produces a a scoped verification record with a recorded checked/not-checked boundary. Supported invariants are currently a bounded numeric fragment; unsupported, indeterminate or contradictory mandatory clauses are refused rather than approximated. “Unknown is not proof” is the design rule.
Invariant preservation
Invariant preservation is the requirement that declared safety properties remain true across every admitted action and every admissible mode, including a reduced or degraded mode. It is not the same question as availability: failover, retry, caching and health checks preserve service continuity, but they do not by themselves establish that a transition is still admissible. The security page states this distinction and the failure modes that follow from it.
Safe degradation
The λ-safe research model explores degradation as an explicit, verification-gated transition: a system may reduce functionality or capacity while preserving mandatory invariants, and recovery requires fresh verification rather than a stale certificate. This is a published research direction with a conceptual published model, plus a deterministic simulation in the interactive demo. Production runtime degradation enforcement is not implemented or verified.
Where it sits in the lifecycle
λ-Safe participates in contract formalization, after intent translation. Its outputs are consumed at admission, in decision constraints and in conformance evidence. Its invariants are revisited when reconciliation detects drift and when degradation changes the admissible operating envelope.
Supported invariants
Compiled support is a bounded numeric fragment: a deliberately bounded class of hard invariants and admissible transitions for supported contracts. Symbolic, relational, fractional and unrepresentable window constraints are excluded or refused rather than approximated.
Invariant preservation
Which conditions must hold in every admissible mode, how availability mechanisms differ from invariant preservation, and the three failure modes a degraded system can hide.
Safe degradation
A published research model with a conceptual published model and a labelled local simulation. Research-grounded, not production-enforced, and with any reported overhead attributed to the paper.
Publication boundary
What is public, what is under engagement, what is not published.
Buyers need to know which documentation exists before they ask for it. This table is the publication boundary for NiGeNje material.
| Surface | Access | What that means |
|---|---|---|
| λ-Safe research record | Public | Published on Zenodo with a stable DOI. Maintained by the publisher, not by this site. |
| λ-Safe Core source | Public · Apache-2.0 | Open-source Rust compiler repository. Licences and terms are governed by the repository. |
| Architecture and concepts | Public summary | Responsibilities, lifecycle and boundaries are described publicly. This is not an interface contract. |
| Platform source code | Private | Platform repositories are private and are deliberately not linked from this website. |
| Public HTTP API contract | Not published | No endpoint list, request schema, authentication flow or rate-limit policy is published. The site does not invent one. |
| Operator documentation | Under engagement | Runbooks, configuration and operational procedures are provided within a defined engagement, not on the public site. |
| Evaluation and qualification evidence | Under engagement | Detailed engineering evidence is reviewed with an evaluator. It is not a published certification. |
| Safe-degradation material | Public research + labelled simulation | The published research record and a deterministic demo scenario. No production runtime degradation enforcement exists to document. |
Operator documentation
Operator documentation is provided under engagement. It is not published here because it depends on the agreed deployment topology, identity configuration and support boundaries. Requesting it does not create a support or service-level commitment.
Integration information
What is publicly stated about integration.
Public material describes the integration model and its boundaries. It does not publish endpoint names, request schemas or authentication flows, because no public API contract exists yet.
Registered mediation
NARG mediates actions at registered points, verifies a permit against the exact action and arguments, keeps proposal separate from dispatch, and reads the effect back. Actions outside registration are not mediated.
Admission and permits
Gatekeeper evaluates requirement gates independently of the executor and issues scoped, expiring, single-use permits bound to the action digest — or refuses with a specific reason.
Execution adapters
Substrate applies effects through bounded adapters under a verified permit and supports read-back. Connector coverage is limited and no connector certification is claimed.
API contract status
No public HTTP API contract is published. There is no endpoint catalogue, schema, token exchange or rate-limit promise on this site. Integration work is scoped against a confirmed contract under engagement.
Do not guess an endpoint
This site intentionally publishes no API URLs. Anything that presents itself as a NiGeNje API endpoint without a confirmed contract should be treated as unverified.
Evaluation guidance
Deployment and evaluation, staged deliberately.
The sequence below keeps a bounded evaluation separate from deployment planning. Each stage is agreed on its own; completing one does not imply the next.
Define one system boundary
Choose one workflow, one class of action and the invariant or obligation that must not be broken. A broad scope makes an evaluation unreadable.
Map registered mediation points
Identify which actions would pass through a registered mediation path and which bypass paths remain. Bypass paths are part of the evaluation, not an afterthought.
Establish identity and evidence readiness
Confirm which identity provider, policy context and evidence sources are available. Where they are absent, admission should fail closed and say why.
Run a bounded, non-production evaluation
Exercise the admitted, denied, diverged and unavailable paths against defined fixtures. Do not use production systems or production personal data.
Review evidence and gaps
Inspect what was recorded, what was observed independently and what remained unknown. Record what the evaluation did not cover.
Plan deployment separately
Production topology, identity, key management, observability and support boundaries are a separate stage. Earlier stages do not imply production qualification.
Documentation questions
What people ask before evaluating.
Where is the public API reference?
There is no public API reference. No endpoint list, request schema, authentication flow or rate-limit policy for the NiGeNje platform is published today. This page deliberately does not invent one. Integration scopes are defined under engagement and against a confirmed contract.
Is operator documentation available?
Operator documentation — runbooks, configuration, deployment procedures and operational limits — is provided under engagement. It is not published on this website because it depends on the deployment topology and the agreed scope.
How current is this documentation?
Public pages are maintained with the site source and the engineering registers behind it. Maturity labels describe verified engineering state at the time of writing; they are not a service-level statement. Re-verify the specific claims that matter to you during an evaluation.
Can NiGeNje generate a compliance or security pack?
No certification, compliance attestation or audit pack is claimed or offered. Evaluation evidence can be reviewed with you under an engagement, and the security page states plainly what is not claimed.
Do these docs cover a supported integration list?
No supported-integration count is published, because connector coverage is still being built and certified connectors are not claimed. Integration work is scoped per engagement rather than sold as a catalogue.
Does λ-Safe enforce invariants at runtime?
No. λ-Safe is a verification and refusal component: it formalizes supported contracts, compiles supported invariants, verifies admissible transitions and records the checked/not-checked boundary. It does not intercept actions, issue permits or contain failures. Gatekeeper, NARG, Substrate and the Control Plane own runtime admission, mediation, execution and coordination.
Is safe degradation documented as a production capability?
No. Safe degradation is a published research model with a conceptual published model and a labelled, deterministic simulation in the interactive demo. The documentation describes the model and its boundaries; production runtime degradation enforcement is not implemented or verified, so it is not documented as a shipped capability.
Looking for the published research record? It is available at doi.org/10.5281/zenodo.17067644.
Next step
Request the material that matters to your evaluation.
If a document you need is not public, ask whether it is covered under engagement. Nothing on this page is a substitute for a confirmed contract.