UNKNOWN is not FAILURE
A request can time out after the native system commits the change. Treating that timeout as a known failure can cause a duplicate or conflicting effect. A successful request acknowledgment can also precede a degraded rollout.
Nikxius retains these distinctions in the operation lifecycle. Recovery asks what available native evidence establishes. If it cannot establish the original effect, the Runtime keeps the outcome unknown.
Three kinds of recovery
| Kind | Question | Current Runtime boundary |
|---|---|---|
| Process recovery | Can the worker continue after a crash? | Durable operation, grant, approval, attempt and observation state survives in PostgreSQL |
| Outcome reconciliation | What did the original native request do? | Read accepted native evidence; preserve UNKNOWN if evidence is insufficient |
| Compensation | What new operation should address a known effect? | A separate authorized action with its own preconditions and outcome |
Restarting a worker is not proof that a remote mutation failed. A rollback is not deletion of the previous operation. These distinctions keep local process state from being mistaken for external truth.
What can establish the original effect
For the current Kubernetes path, a valid native response or sufficient retained continuous native history can establish the original committed transition. Current matching state alone may show convergence without showing which operation caused it.
A history gap matters. Kubernetes documents finite watch history and relisting when an old version is unavailable. Relisting restores the current view; it cannot recreate a missing historical transition. Read the original Kubernetes API documentation for the native semantics.
The Runtime’s read-only reconciliation can leave an outcome unresolved indefinitely. It keeps the relevant task/resource reservation rather than assuming that missing evidence means no effect. The current API has no “mark successful” or “reset unknown” endpoint.
Retry rules are native-system rules
The general rule is not “never retry.” The writer’s documented contract determines whether repeating a request preserves one logical effect. Stripe’s error-handling documentation describes safe same-key network retries and indeterminate server-error outcomes. Temporal’s Activity documentation recommends idempotent external work.
Nikxius’s current Kubernetes contract is narrower: after possible dispatch, reconciliation reads rather than blindly repeating the mutation. Retrying the original proposal identity returns the durable operation; it is different from issuing another native PATCH.
When commitment is known but recovery is not
An image change can be committed while the Deployment is degraded. That does not refund consumed task capacity or turn the mutation into “not dispatched.” Diagnosis belongs to the resource owner. A compensating rollback requires new authority and can itself fail or remain unknown.
A native admission component that changes an inspected invariant can produce a committed integrity incident. The record must retain that effect instead of presenting the invalid transition as prevented.
The operator’s obligation
For an unresolved operation, preserve its identity, exact command, native target, attempt, last observations and watch-continuity evidence. Restore authorized read access where possible. Escalate through the customer’s incident process if history cannot establish the result.
Emergency access should not rewrite the original record. New work can change the system while the earlier effect remains unattributed. Backup restoration likewise cannot safely erase remembered external effects and start the same grants again.
These are current documented behaviors and deployment assumptions, not guarantees of application recovery. See the technical contract, security boundary and dated local verification record.
Test recovery against your native stack
Use one nonproduction workflow and exercise a lost response, worker restart, duplicate proposal, native-history gap and degraded rollout after commitment. Compare unresolved-state handling and operator work with existing workflows and runbooks.
Evaluate one operation, or read When AI Gets Write Access for the underlying research and competitive context.