One operation, from authority to outcome
Nikxius Runtime is a customer-controlled execution boundary for supported production automation. An agent proposes an operation. The Runtime checks its exact authority and current native state, records dispatch before external I/O, and reconciles what the native system establishes afterward.
The first evaluation workflow is a Kubernetes Deployment rollback to an explicitly permitted prior image. The Runtime is not a general-purpose agent framework, identity provider or arbitrary tool gateway.
The execution lifecycle
| Stage | What the Runtime does | Important limit |
|---|---|---|
| Propose | Persist a typed request under a registered principal | Creation is not authorization or completion |
| Authorize | Check the effect-bound grant, policy and any required review | Identity alone does not grant arbitrary tool access |
| Bind | Freeze the exact operation and independently read native baseline | Cached agent context is not authoritative state |
| Execute | Persist possible-dispatch identity before using the Node’s constrained credential | PostgreSQL and the native API do not share a transaction |
| Observe | Inspect native response and retained observations | Desired-state commitment does not prove application health |
| Reconcile | Establish the original effect when evidence permits | Missing history can leave UNKNOWN indefinitely |
| Evidence | Export the recorded lifecycle and assurance limits | Signing does not make observations independently true |
The same identity follows the operation through those stages. Reusing its proposal key with changed input is refused. A new request key does not reset a root task’s consumed or uncertain authority.
A customer-controlled boundary
The customer Node holds the native credential. The agent receives a registered Runtime workload identity rather than that resource credential. Existing identity systems, native RBAC, admission, controllers and monitoring retain their responsibilities.
The prevention claim depends on closing alternate write routes. A broad Kubernetes token in a Secret, shell access, CI credentials or another tool can bypass an otherwise correct mediator. The Runtime does not automatically discover every bypass and does not defend against a compromised trusted Node or privileged administrator. Read the security boundary before evaluating deployment.
Recovery is explicit
The Runtime separates lifecycle, native commitment and later observation. RESOLVED is not a universal success label. A committed image change can be degraded; a no-change operation can resolve without dispatch.
After possible dispatch, the current Kubernetes recovery path reads retained native evidence rather than blindly sending another mutation. A current matching image alone cannot prove the original operation caused it. When evidence is insufficient, the outcome stays unknown and its relevant reservation remains in place.
This is an explicit limitation, not an automatic recovery guarantee. The recovery model explains the operational consequences.
Start with the native stack
Identity, RBAC, admission control, protected delivery, workflow durability and native APIs already solve substantial parts of this problem. A GitOps workflow may already supply the correct write path. An additional runtime should not create an unnecessary competing writer.
Evaluate Nikxius only when a meaningful authority, integration or recovery gap remains for one operation. The comparison should include stale state, revocation, duplicate proposals, response loss, history gaps and operator recovery effort. If your current stack satisfies the complete contract economically, use it.
Current evidence
The verification record, dated 12 September 2026, reports 232 distinct Runtime tests, including 27 native Kubernetes cases and three demo scenarios. These are local conformance results in the documented disposable environment, with synthetic identity/MFA fixtures. They are not customer production validation, external security certification or evidence of product-market fit.
The recorded walkthrough demonstrates an exact-image change and a response-loss case. It is not a live cluster connection or a customer rollback deployment. The current public documentation distinguishes implemented profiles and validation limits.
Evaluate one operation
Proposed scope: four weeks, one supported workflow, one named nonproduction environment. Establish the credential boundary, define the native baseline, run the same failure cases and compare the engineering and operational burden. Fees, access, responsibilities and acceptance criteria require a separate agreement.
Discuss one blocked operation, or begin with the Agent Action Contract.