Current contract
Nikxius Runtime is a customer-controlled service for enrolled, typed operations. The private customer Node API is separate from nikxius.com and the historical Payment Evidence server. These public documents explain the implemented contract and its current limits; they are not an open-source release or a self-service production installation guide.
Start with the Agent Action Contract technical note, the Kubernetes rollback workflow and the security boundary.
Supported profiles and limits
| Profile | Permitted effect | Boundary |
|---|---|---|
kubernetes.deployment.set_image.v1 |
Change one enrolled container to an allowed immutable image | Requires the supported native baseline; committed image does not prove application health |
kubernetes.deployment.rollback_image.v1 |
Reverse the image relationship of an explicitly permitted prior committed operation | Same tenant, target and UID; new authority and outcome; no schema/data restoration claim |
kubernetes.deployment.scale.v1 |
Set an exact bounded stateless Deployment replica count | No competing HPA ownership; desired count is not verified serving capacity |
kubernetes.configmap.patch_keys.v1 |
Change registered existing typed non-secret keys | No arbitrary configuration; persistence does not prove consumer adoption |
kubernetes.cronjob.suspend.v1 |
Set future scheduling suspension | Existing or in-flight Jobs can continue; no resume profile |
terraform.run.apply_saved_plan.v1 |
Confirm one exact saved HCP Terraform plan | Declared commit is apply-queue admission; provider behavior is mock-tested, real account validation pending |
The first evaluation workflow is the rollback profile. Availability of other code profiles does not make their native guarantees identical or establish customer production acceptance.
Rollback is a separate operation
The rollback input includes image and compensatesOperationId. Both enrollment and grant constrain the allowed prior image and operation relationship. The earlier operation must be committed in the same tenant, on the same full target and native UID. Its before-image must match the rollback after-image; its after-image must match the rollback baseline.
The Node does not infer safety from arbitrary rollout history. A rollback receives new authority, review where required, a new attempt and its own outcome. It may remain UNKNOWN. The original record remains intact.
Proposal identity and authority
Workload and human callers authenticate to the customer Node. Registered identity determines tenant scope. A proposal uses operation, typed target, typed input, grantRef and idempotencyKey. Raw native URLs, manifests, shell commands, arbitrary patches and caller-asserted tenant/principal fields are not supported substitutes.
The same tenant/actor key with an identical immutable request returns the existing operation. Changed input or grant under that key returns a binding conflict. A new key does not refill the root task’s one-commit capacity across grant versions. Required role, quorum, MFA and separation of duties come from policy and registered identities.
Optional expected image/version fields are assertions checked against independently read native state. They do not let the agent supply a trusted baseline. The current adapter uses captured UID and version equality tests in the native conditional mutation.
Private API surface
| Method and route | Meaning |
|---|---|
POST /v1/operations |
Persist a proposal; 202 on creation, 200 on identical replay |
GET /v1/operations |
Tenant-scoped recent operations; workloads see their own; status filtering is supported |
GET /v1/operations/:id |
Operation, approvals, attempts, observations, events and cursor |
POST /v1/operations/:id/approve |
Exact-command human authorization using current version and hashes |
POST /v1/operations/:id/reject |
Exact-command rejection/revocation where lifecycle permits |
POST /v1/operations/:id/reconcile |
Queue read-only recovery with {} |
GET /v1/operations/:id/evidence |
Export actual recorded lifecycle, observations and assurance limits |
POST /v1/grants |
Registered administrator creates a supported effect-bound grant |
POST /v1/grants/:id/revoke |
Record revocation; not cancellation of an already accepted native request |
Proposal acceptance is not completion. New operations begin as PROPOSED and can later be denied. The list endpoint returns recent records, not historical totals; inspect an older known operation directly by ID. Full cursor pagination is not part of the current build.
The existing private Node client is a convenience wrapper, not a separately published public SDK. It does not automatically retry native mutations or forward a bearer token through redirects. Preserve immutable request identity after transport uncertainty and inspect durable operation state.
State dimensions
| Dimension | Values |
|---|---|
| Lifecycle | PROPOSED, AWAITING_APPROVAL, REVALIDATING, ADMITTED, DISPATCH_RECORDED, PENDING, UNKNOWN, RESOLVED, DENIED |
| Commit | not_dispatched, committed, rejected, unknown |
| Observation | not_applicable, pending, converged, degraded, superseded, unobserved |
| Reservation | none, reserved, consumed, released |
| Integrity | unchecked, matched, mismatch |
RESOLVED does not mean success. An already matching supported no-change operation can resolve without a mutation or consumed commit unit. A committed mutation can leave a degraded rollout. A committed invariant mismatch remains an integrity incident rather than being relabeled “no effect.”
Recovery and evidence
After possible Kubernetes dispatch, recovery reads accepted native evidence. A valid response or sufficient continuous retained history can establish the original transition. A matching current value, inherited annotation, missing object or relist after a history gap cannot establish original causation alone. UNKNOWN may remain indefinitely, preserving task/resource reservations.
There is no current “mark successful,” “reset unknown” or automatic rollback endpoint. Compensation is another authorized operation. A worker lease cannot recall an in-flight request, and restoring PostgreSQL from an older snapshot does not recreate missing external history.
Evidence exports derive from stored identity/grant context, hashes, policy, review, attempt, observations and recovery events. Optional signing attributes those records to an accepted Node key. It does not prove native truth, completeness or application correctness. See recovery and security.
Validation
The verification record is dated 12 September 2026: 232 distinct Runtime tests, including 27 native Kubernetes cases and three demonstration scenarios. The native environment was disposable Kubernetes 1.35.0 with synthetic identity/MFA fixtures. PostgreSQL restart and mocked HCP tests have separate boundaries.
Customer identity/TLS, credential exclusivity, native policy, actual HCP account behavior, production acceptance and external security review remain separate validation work. The homepage replay demonstrates an image-change operation with synthetic data. It is not a customer rollback deployment.
Evaluate a single operation, or use the production-readiness checklist to examine the current native stack first.