The scenario
An SRE agent investigates a degraded release and proposes returning one Deployment container to an explicitly permitted prior immutable image. The agent should be able to propose that operation without receiving a credential that can make arbitrary cluster changes.
This is Nikxius’s first evaluation workflow. The explicit rollback profile is implemented, but customer production validation and commercial demand remain hypotheses. The existing homepage replay demonstrates a related set_image operation, not a recorded customer rollback.
The evaluation requires an earlier committed Nikxius operation, explicit permission to restore its prior image, and an agent without an alternate Kubernetes write credential. If native evidence cannot establish the rollback’s effect, its outcome remains UNKNOWN.
Start with the existing write path
Kubernetes already supplies native authorization, admission, conditional updates and Deployment state. GitOps or protected delivery may already provide the right authority boundary. If Git owns desired state, an out-of-band patch can compete with its controller; assess a change to the authoritative source before adding another writer.
The question is whether one blocked automation still has an authority or recovery gap after those controls are composed. Nikxius should be evaluated against that baseline, not against an intentionally unsafe cluster.
Broad credentials versus a bounded proposal
Giving an agent a broad write credential leaves the scope of possible changes larger than this rollback. A narrower interface accepts only the supported operation and lets a controlled writer enforce it. The customer Node holds the native credential; the agent must lack alternate access through tokens, Secrets, shell, CI or other tools.
The Runtime does not replace Kubernetes authorization or admission. It independently reads the target, binds its exact native baseline, checks the permitted action and dispatches a conditional mutation using the protected credential.
The exact rollback contract
The operation type is kubernetes.deployment.rollback_image.v1.
| Binding | Required meaning |
|---|---|
| Cluster | The enrolled cluster origin and trust configuration |
| Namespace / Deployment / container | One registered target; not a caller-supplied manifest or arbitrary patch |
| Resource identity | The same Deployment UID as the referenced operation |
| Native version | The independently observed resource version used in the conditional baseline |
| Image | Full immutable registry/path@sha256:<64 lowercase hex> reference; no mutable tag |
| Prior operation | compensatesOperationId identifies the permitted earlier committed operation |
| Grant | Binds the registered holder to the exact target, image and prior-operation relationship |
| Review | Exact-command authorization if the frozen policy requires it |
| Proposal identity | Stable tenant/actor-scoped idempotency key; changed input under the same key is refused |
The prior operation must be committed in the same tenant, on the same full target and UID. Its before-image must equal the requested rollback image. Its after-image must equal the current before-image being reversed. Enrollment and grant both constrain the relationship.
This is not a generic kubectl rollout undo wrapper. The Runtime does not infer authority or safety merely because an image appears in rollout history. The rollback can address a degraded rollout, but remains a new operation with its own grant, attempt and outcome.
Proposal and dispatch
The following fields illustrate the private Runtime request shape. They are synthetic, not a deployable command or usable release artifact.
{
"operation": "kubernetes.deployment.rollback_image.v1",
"target": {
"cluster": "evaluation-cluster",
"namespace": "checkout",
"deployment": "checkout-api",
"container": "api"
},
"input": {
"image": "registry.example.com/checkout-api@sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
"compensatesOperationId": "01993100-0000-7000-8000-000000000001"
},
"grantRef": "01993100-0000-7000-8000-000000000002",
"idempotencyKey": "rollback-evaluation-001"
}POST /v1/operations creates a durable proposal on the customer Node. Acceptance is not completion; asynchronous processing can still deny the request. The Node checks trusted state, freezes the command and native request, applies required review, and persists possible-dispatch identity before the native call.
Kubernetes supports conditional updates to detect stale state. Its current API documentation specifies version- and type-dependent resource-version semantics; the Runtime uses its captured value as an equality precondition. No claim of success is inferred from version arithmetic. See Kubernetes API Concepts.
Failure cases worth testing
| Failure | Expected behavior or review obligation |
|---|---|
| Stale state | Refuse a baseline that no longer matches the admitted contract |
| Concurrent edit | Let native conditional semantics reject the stale mutation; do not silently rebase approval |
| Recreated Deployment | A different UID cannot inherit the old operation relationship |
| Revoked permission | Refuse newly disallowed work; do not promise recall of an already sent request |
| Lost response | Preserve possible dispatch and UNKNOWN commitment until evidence establishes more |
| Duplicate proposal | Return the existing operation for the identical key/request; refuse changed input under that key |
| Matching image after a history gap | Do not infer that this operation caused the value |
| Committed update, unhealthy rollout | Keep commitment separate from degraded observation and application health |
| Compensating rollback loses its reply | The rollback can itself remain UNKNOWN |
After possible dispatch, the current Kubernetes reconciliation path reads retained native evidence rather than blindly repeating the mutation. A valid response or sufficient continuous history can establish the original transition. Missing history can leave UNKNOWN indefinitely, with reservations retained.
What rollback does not restore
Changing a container image does not necessarily reverse a database migration, restore data, fix dependent services or establish application health. Kubernetes distinguishes desired state, rollout progress and failure conditions; application correctness requires its own checks. Read the primary Deployment documentation.
The prevention boundary also depends on trusted Node behavior, native policy and closed alternate write paths. A privileged administrator or compromised trusted component remains outside the claim. Read the security boundary.
Evaluate one workflow
Proposed scope: four weeks in one named nonproduction environment. Compare the current stack with Nikxius using the same operation and failure matrix. Include engineering setup, native-policy compatibility, operator investigation, unresolved reservations and clarity of retained evidence. Success is not simply one green rollback response.
The dated local verification record is a baseline for discussion, not customer acceptance. The recorded image-change replay shows related mechanics and explicitly preserves its original scope.
Test your rollback workflow, read the action-contract technical note, or inspect the failure taxonomy.