Capabilities
A capability is a cross-platform responsibility: what the platform does across several components and products. NiGeNje capabilities span intent and authority in one dimension, and invariant preservation with safe degradation in the other. Maturity is stated per capability, never as an end-to-end production claim.
Capability vs product
A capability describes a responsibility across the platform. A product is a deployable component with its own maturity, evidence and limitations. One capability may be delivered by several products, and one product may contribute to several capabilities.
A capability is a cross-platform responsibility: an end-to-end responsibility that spans components. It answers what does the platform do? and is not tied to a single deployable boundary. Its maturity reflects verified evidence across the components that provide it.
A deployable component or component group with a defined responsibility, inputs, outputs and limitations. It answers what can be run or evaluated? and carries its own maturity and evidence record.
Capability maturity and product maturity are related but not interchangeable: a capability marked Integrated is integrated in the bounded local, non-production chain; it does not mean every providing product is production-qualified. Read the maturity vocabulary before comparing labels.
Link matrix
Maturity, providing components and the next place to read. Component links open the relevant product page or the architecture component explorer.
| Capability | Maturity | Providing components | Next step |
|---|---|---|---|
| Intent governance | Integrated | ||
| Invariant-aware decision control | Integrated | ||
| Governed safe degradation | Demonstrable | ||
| Explicit authority and admission | Integrated | ||
| Runtime action mediation | Integrated | ||
| Independent observation and reconciliation | Integrated | ||
| Evidence and audit continuity | Integrated | ||
| Security and containment | In progress | ||
| Distributed-system coordination | Demonstrable |
The nine capabilities
What it does, why it matters, which components provide it and the maturity verified to date.
Declared objectives, obligations and scope are made explicit, versioned and approved before action.
Without an inspectable intent there is nothing to authorise against and nothing to be conformant with.
Intent publication and read-back verified in the local demonstration stack.
Supported decidable invariants and admissible-transition rules are compiled, and decisions are evaluated against constraint feasibility.
Safety obligations expressed only in prose cannot be enforced at a boundary.
Compiler and candidate solver verified for supported paths; unsupported obligations refused.
Invariants define admissible operating and degraded modes; transitions are authorised, mediated, observed and assessed for conformance when conditions deteriorate.
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.
An independent authority evaluates requirement gates and issues a scoped permit bound to the action.
The component that executes must not also be the component that authorises.
13-gate admission with eight invalid-permit refusals and zero effects written.
Registered actions are verified against the permit at dispatch time, including arguments and digest.
A decision made earlier is not permission for a changed payload later.
Proposal/dispatch separation and payload-mismatch refusal verified.
External state is observed and compared with the required postcondition after an action.
A successful response is not independent proof that the intended outcome occurred.
DIVERGED and UNKNOWN outcomes verified; observation independence remains partial.
Decision, execution and outcome records are ordered, linked and reconstructible for review.
Governance that cannot be reviewed after the fact is not accountability.
Both component chains verified and lifecycle reconstruction produced.
Actor identity, tenant scope, permit validity, replay protection and containment behaviour at the boundary.
Authority without scope and replay protection is not a security boundary.
Permit and replay paths verified; external identity and autonomous containment in progress.
Lifecycle coordination across services, change assurance and network governance with explicit outcomes.
Distributed action needs coordination that can represent partial failure and unknown states honestly.
Coordination verified locally; network and temporal capabilities are partially integrated.
Next step
Bring a system boundary, an action class and a failure mode. The first step is to agree what should be governed and what evidence would count.
