One operation. One environment. A dated decision.
An automation is ready to do something useful, but its write authority or failure model is blocking release. The Nikxius design-partner evaluation tests whether one exact Kubernetes rollback can cross that boundary with less custom control and recovery work.
Proposed paid evaluation: one supported operation in one named nonproduction environment, for up to four weeks. Establish the acceptance contract and current-stack baseline before installation. The outcome is a documented decision to continue, expand under a separate agreement, or use the native stack.
This is for a platform engineering team with an active automation, an accountable technical owner and a real deployment decision. Interest in agents alone is not enough. The first conversation should identify the operation, current writer, unresolved problem and decision date.
Read the evaluation guide
Read the guide online — start here for architecture, security, installation, the rollback workflow, acceptance tests, native-stack comparison and the proposed commercial scope. All 11 documents are readable in your browser, with a contents menu and a separate PDF for each section.
For offline reading, download the complete guide · PDF, 20 pages.
The optional ZIP document bundle · 3.5 MB also contains offline HTML, editable documents, configuration examples and dated validation references. Runtime source is supplied separately for an agreed evaluation; the download contains no Runtime credentials.
The proposed scope and fees are discussion materials. Reading or downloading the guide does not create an agreement or authorize production use.
The operation we start with
An agent proposes returning one Kubernetes Deployment container to an explicitly permitted prior immutable image. Nikxius receives that proposal through its private Runtime API. The agent does not receive the Runtime’s Kubernetes write credential.
The rollback must reference an earlier committed Nikxius operation on the same tenant, target and native Deployment UID. Its before-and-after images must reverse that earlier change. Enrollment and grant both bind the prior-image relationship. A fresh evaluation therefore establishes the earlier operation before enabling its rollback.
The rollback gets a new root task, grant, operation identity and exact-action review where the policy requires it. The source operation and its consumed authority remain in history. Kubernetes revision history alone does not supply this authorization.
Read the Kubernetes rollback contract for the precise request and its limits. A committed image change does not restore databases, reverse every dependency change or establish application health.
What gets installed and what it can access
The evaluation uses a customer-controlled Nikxius Runtime and PostgreSQL inside the agreed environment. Configuration enrolls one target, permitted images, the prior operation, identity mappings and review policy. Changes to this reviewed enrollment currently take effect through configuration and restart.
| Component | Responsibility |
|---|---|
| Customer identity provider | Authenticate registered workload and human identities; provide the accepted token and MFA context |
| Agent or automation | Propose the exact supported operation with a stable idempotency key |
| Nikxius Runtime | Bind authority and native state, retain dispatch identity, perform the conditional mutation and reconcile available evidence |
| PostgreSQL | Retain operation, grant, approval, attempt and observation state across Runtime restarts |
| Kubernetes | Enforce native authorization and admission; perform the conditional update; supply resource state and controller observations |
| Customer platform team | Own credentials, deployment configuration, competing controllers, monitoring, application checks and emergency access |
The Runtime needs its own credential for named-resource read, watch and patch access to the enrolled Deployment. Kubernetes RBAC limits resources and verbs; the trusted adapter limits the patch fields. The agent must lack equivalent writes through other tokens, Secrets, shell, CI or tools, and must not be able to take over the Runtime.
The website does not connect to your cluster. Evaluation does not require a Nikxius-hosted execution service, cluster-admin access for the agent, payment access or access to arbitrary business records. Installation still needs an authorized customer administrator, database provisioning, secret handling and a reviewed network/TLS path. Credentials stay in the customer’s approved mechanism; do not email them to Nikxius.
See the Runtime architecture and security boundary. Customer identity integration, credential exclusivity and operational acceptance must be verified in the evaluation environment.
How this fits your existing stack
Keep existing IdP, RBAC, admission controls, protected delivery and observability. If GitOps owns the desired state, first establish whether the correct operation is a change to Git. An out-of-band Runtime patch must not compete with an authoritative controller.
Before installing, document the strongest current implementation using identity, Kubernetes RBAC/admission, GitOps or CI/CD, native API semantics, workflow retries, approvals and retained evidence. Nikxius is worth evaluating only if an important execution or recovery deficiency remains.
Both implementations face the same target, permissions, failure scenarios and acceptance criteria. Measure setup and maintenance effort, customer configuration, investigation time, retry decisions, unresolved outcomes and operational burden. Count custom engineering and support time separately from reusable software.
If your native stack satisfies the complete contract economically, use it. A working demo is not evidence that another execution component is necessary.
What happens when execution becomes uncertain
| Scenario | Required evaluation result |
|---|---|
| Changed target or image | Existing authority and approval cannot authorize the changed action |
| Expired or revoked grant | Refuse a later dispatch claim; do not claim recall of a request already admitted for dispatch |
| Stale state or concurrent edit | Refuse the stale baseline; do not silently rebase the reviewed operation |
| Identical duplicate | Preserve the operation identity; reject changed content under the same key |
| Crash around dispatch | Retain the original attempt and distinguish unclaimed work from possibly dispatched work |
| Lost native response | Preserve UNKNOWN; do not blindly repeat the mutation |
| Missing causal history | Keep uncertainty and the applicable reservation rather than infer success from the current image |
| Accepted change with unhealthy application | Keep native commitment, rollout observation and application health separate |
| Direct agent write | Demonstrate that the scoped agent cannot bypass the agreed boundary |
Reconciliation inspects retained authoritative evidence. It may establish the original transition, or the outcome may remain UNKNOWN indefinitely. A current matching image alone is insufficient. Emergency customer action must follow the agreed break-glass process and preserve the original record.
Execution evidence can be exported. Optional Node signing attributes retained records under the documented key trust model; it does not prove business correctness or make missing observations complete.
What has been exercised
On 15 September 2026, an internal fresh-install evaluation on disposable Kubernetes v1.35.0 and PostgreSQL exercised the actual rollback, process termination and restart, recovery after a lost response, retained UNKNOWN and evidence export. Across the repository’s scoped runs, 485 distinct tests passed. The kit’s validation summary records the test boundaries and counting method.
These results establish local behavior under the documented fixtures. Customer identity integration, independent customer installation, application health and production admission remain unvalidated. Native component tests establish overlap with the current stack; they do not establish a measured customer operating advantage.
The four-week plan
| Stage | Customer and Nikxius work | Decision or evidence |
|---|---|---|
| Scope and baseline | Name the operation, owner, nonproduction environment, native writer and decision date; complete architecture/security review | Agreed boundary, current-stack implementation and acceptance criteria |
| Install and operate | Install Runtime and PostgreSQL, connect identity, enroll the source/rollback relationship and perform exact-action review | A customer engineer can follow the documented workflow; record actual installation effort |
| Exercise failures | Run both implementations through the same denial, concurrency, crash, lost-response and recovery cases | Reproducible results, retained evidence and explicit unresolved conditions |
| Decide | Compare technical outcomes, customer operating effort and commercial fit | Continue under agreed terms, scope a justified next operation, or stop |
The proposed limit is four weeks from the agreed start. Dates and work depend on customer access and review. We do not claim a measured installation time or independent customer operation before those results exist.
The customer provides a platform owner, a participating engineer, security review, the existing-control baseline and authorized access to the evaluation environment. Nikxius provides scoped installation/integration support, the acceptance package, failure investigation and the written result. Name support owners, availability and escalation responsibilities in the agreement; this is not an implied production SLA.
What success and exit mean
Technical success means the agreed contract holds in the customer’s environment, the engineer can operate it, the failure results are inspectable, and the comparison shows a worthwhile advantage after accounting for added work. Commercial success requires an actual buying decision. Passing tests alone does not establish either recurring demand or a production authorization.
At the end, record one of three decisions: pursue a production/annual agreement after its separate admission review; authorize a specific additional evaluation; or stop and retain the native stack. There is no automatic renewal or production continuation implied by this page. Agree evidence export, retention, credential revocation and uninstall responsibilities before starting.
Fees, payment milestones, scope, access, support, acceptance and exit terms require a separate written agreement. The current offer is a pricing hypothesis, not a claim of market-validated value or guaranteed results.
Bring one blocked operation
Describe the change your automation needs to make, the current write path, the unresolved authority or recovery problem, and the person/date for the deployment decision. Keep the first message descriptive; no credentials, customer records or private production manifests are needed.
Discuss one rollback evaluation
Opening this link opens your email app. Nothing is sent by this website and an enquiry creates no commitment. You can also use the contact page.
For the wider engineering rationale, read When AI Gets Write Access. Research motivates this test; customer evidence determines whether the product deserves to continue.