Design-partner evaluation guide

What we install

A customer-controlled Runtime Node, PostgreSQL and a narrowly scoped Kubernetes identity in one nonproduction environment. The agent proposes; the Node holds the mutation credential. Your IdP, RBAC/admission, GitOps, monitoring and emergency procedures remain.

A broad agent credential can permit writes outside the task. Nikxius requires that the agent cannot reach an equivalent writer or the Node’s credential. We review that boundary together.

What we test

1. Bind exact target, permitted image, authority and current native state.
2. Reject changed actions, stale state and unauthorized retries.
3. Persist dispatch; retain UNKNOWN after a missing response.
4. Restart, reconcile without blind replay, and export evidence.
5. Have your engineer compare the same contract with your native stack.

What we need

A platform owner, security reviewer, disposable target, approved identity/secrets, PostgreSQL and your current execution path. The local fixture needs Node 22+, Docker, kind and kubectl; real customer identity integration is a separate check.

No model key, payment credential, public Runtime endpoint or unrelated production access is required. Support access is agreed explicitly.

The decision

After the proposed four weeks: customer-operated acceptance, measured native comparison and a continuation or exit decision. A committed patch is not application health; UNKNOWN may remain unresolved. This kit grants no production authorization.

The product hypothesis

A customer-controlled Runtime binds authority to an exact operation and independently read native state. It freezes the command, enforces review, records dispatch before I/O and retains outcomes and unresolved obligations. Kubernetes and your IdP remain authoritative.

The first scope is one nonproduction Deployment rollback to a permitted prior image, bound to an earlier committed operation on the same native resource.

Four weeks to a decision

• Week 1: agree workflow, owner, native alternative and decision criteria.
• Week 2: install identity, credentials and the bounded operator path.
• Week 3: compare the same stale-state, lost-response and restart cases.
• Week 4: customer engineer runs acceptance; record costs and decision.

Proposed fee: US$15,000, split equally at signing and agreed acceptance. This is unvalidated pricing; written scope defines responsibilities, milestones and legal terms.

What establishes value

Value means a meaningful deficiency closed or lower control/recovery burden. Measure installation, custom engineering, operation and support separately. Founder assistance is not customer independence.

Local tests do not establish customer compatibility, production security or willingness to pay. Those are evaluation questions. A committed resource change is not proof of application health.

Use the native stack if it meets the contract economically. Continue with Nikxius only for a repeatable advantage. Production authorization and annual terms are separate decisions.

Control flow

The workload submits a typed request, grant reference and stable idempotency key. The server derives tenant and principal from registered issuer/subject mappings. It independently reads Kubernetes, checks enrollment and authority, and freezes the target, effect, policy and native UID/resourceVersion. Required human review binds exact command/dispatch hashes and the current operation version.

Before sending a protected mutation, PostgreSQL records admission, reservation and dispatch identity. The Node constructs a conditional native patch. It accepts no arbitrary URL, YAML, shell command or caller-supplied patch. A lost response does not authorize another mutation.

The Node records the persisted native response or retained causal history. Read-only reconciliation can resolve an unknown commitment only with sufficient evidence. A current GET showing the expected image is insufficient on its own.

Read each state dimension

RESOLVED does not mean success. committed does not mean healthy. A committed invariant mismatch remains an incident with consumed authority.

Integration boundary

The first deployment uses one Node plus PostgreSQL. API and worker may run together. Browser sessions are process-local; the initial evaluation is not a claim of multi-replica availability. PostgreSQL and Kubernetes share no transaction. Worker leases protect local ownership, while the native conditional request protects its frozen baseline.

A GitOps controller that owns the field must be part of the design. Do not create a second uncoordinated writer. If the customer’s approved GitOps path already meets the contract, that path is the comparator to beat.

Source: docs/runtime/API.md, OPERATIONS.md, DEPLOYMENT.md, RECOVERY.md; docs/security/TRUST_BOUNDARIES.md in the evaluation checkout. No hosted Nikxius control plane is required for this Runtime path.

Identity and credentials

Customer IdP token acquisition is integrated externally. The browser’s token handoff is not a full SSO redirect/PKCE client. Identity mappings load at startup; reviewed changes require restart. Task-grant revocation is durable and does not require restart.

Least privilege must include bypass review

Scope the Node to the named resource and required reads/watch/patch. Kubernetes RBAC cannot restrict a patch to one image field; trusted adapter code supplies that restriction. Native admission constraints may add protection and must be tested with the actual controller/admission composition.

The agent must not read Secrets, mint the Node’s token, exec into privileged pods, assume another role, invoke an equivalent CI writer or use host access to escape the boundary. The local tests probe named routes. They do not prove that every customer bypass path is absent.

Failure, revocation and break-glass

Missing mandatory authority, policy, approval or durable admission prevents new protected dispatch. That does not recall a request already admitted or stop every delayed sender. Native UID/version/field tests remain necessary. A missing response stays UNKNOWN; no timer converts it to failure.

A Node restart preserves durable operation state in PostgreSQL and ends browser sessions. An old database restore can forget native effects; reconcile the restore gap before reopening writes. Missing native history may leave an outcome unresolved indefinitely.

Customer emergency access remains separately governed. Record the operator, reason, time and native evidence when using it. Never use break-glass to rewrite the original operation as successful, cancelled or nonexistent. The Runtime has no “mark successful” or “reset unknown” endpoint.

Data, evidence and operational responsibility

Operation inputs, identities, decisions, attempts and projected observations stay in the customer’s Node/database. There is no required Nikxius-hosted telemetry or model-provider dependency in this path. Support access and export sharing require explicit scope. Customer infrastructure provides encryption at rest, backups, network controls and retention decisions; their configuration is not established by local tests.

Exports contain supported lifecycle records and stated limits. A signature establishes integrity and attribution under the configured key; it does not establish business correctness, uncompromised execution or independent Kubernetes truth. No automated destructive retention job is supplied; unresolved attempts and consumed identities must not be purged to clear a queue.

No SOC 2, ISO 27001, external penetration test, production SLA, incident-response staffing or customer production acceptance is claimed. Security review is part of the nonproduction evaluation; production needs separate admission.

Source: docs/security/THREAT_MODEL.md, CREDENTIAL_MODEL.md, TRUST_BOUNDARIES.md, FAILURE_SEMANTICS.md; docs/runtime/DEPLOYMENT.md and RECOVERY.md.

Local prerequisites

Node 22+, npm, running Docker, kind and kubectl; network access to obtain dependencies and pinned sample images. No production cluster, cloud account or LLM key is needed. The helper uses an isolated kubeconfig and named disposable kind cluster, not your current production context.

Run from the repository root. Start with the clean-checkout commands:

npm ci
npm run build

Continue with the quickstart’s design-partner evaluation section: isolated Docker database, kind cluster, local migration URL, generated fixture identities and protected environment file. Docker Compose is not required. Supply the migration credential only to setup, then unset it; the Runtime uses its generated restricted login. Setup changes disposable resources; never run it against production.

After setup, run the exact acceptance command:

export NIKXIUS_RUNTIME_DEMO_DIR=.tmp/design-partner-eval
node --env-file=.tmp/design-partner-eval/runtime.env \
  scripts/design-partner-acceptance.mjs \
  .tmp/design-partner-eval/runtime-config.json

Complete the customer path

For operator inspection, serve runtime-rollback-config.json as shown in the quickstart and open http://127.0.0.1:8789/operations. The fixture’s historical payments and production-us-east labels are synthetic; no production resources are involved. Native conformance suites reset shared fixtures, so run them before final acceptance.

The older public demo uses set_image; its fixture reset is not a Runtime rollback. Keep the new run record with its source revision. The acceptance section summarizes the dated internal validation and its limits. The optional document bundle includes the redacted validation record; generated credentials remain private.

Customer nonproduction installation

Follow docs/runtime/DEPLOYMENT.md for image build, migration/init-tenants, registered IdP subjects/audiences, HTTPS origin, mounted rotating credential, reviewed RBAC and Node configuration. The example manifests do not provision IdP, PostgreSQL, ingress, backups or a registry. Customer identity token acquisition and native controller/admission ownership need explicit review.

The 15 September clean-source internal run reached acceptance in 20 minutes 25 seconds, including native tests and interleaved author work. Tools were already installed and download caches were warm. The acceptance runner itself took 2 minutes 16 seconds. These are elapsed internal observations, not hands-on customer installation time. Record prerequisites, downloads and assistance in your run. Under 60 minutes remains an unvalidated customer target. The optional document bundle includes the evaluation-validation summary with exact timings and limits.

If any step fails, preserve the exact command/version and redacted error. Do not bypass identity, TLS, least privilege or persistence to finish a demonstration. For UNKNOWN, use docs/runtime/RECOVERY.md; never mint a new key simply to retry a possibly executed mutation.

Bind the relationship

kubernetes.deployment.rollback_image.v1 requires an explicitly authorized immutable image and compensatesOperationId. The earlier operation must be committed in the same tenant, for the same native target/UID, with the appropriate reversed before/after images. An arbitrary old registry digest is not sufficient.

The contract binds the registered cluster, namespace, Deployment, container, native UID/version, image, earlier operation, grant, review policy and stable idempotency key. Customer enrollment must permit the relationship. Use actual observed values; the following is a shape, not an executable grant:

{
  "operation": "kubernetes.deployment.rollback_image.v1",
  "target": {
    "cluster": "evaluation",
    "namespace": "evaluation",
    "deployment": "sample-api",
    "container": "api"
  },
  "input": {
    "image": "registry.example.com/sample@sha256:<prior-digest>",
    "compensatesOperationId": "<earlier-committed-operation>"
  },
  "grantRef": "<sponsor-issued-grant>",
  "idempotencyKey": "<stable-task-specific-key>"
}

Illustrative tokens above must be replaced from the local runner’s actual record. The customer receives a runnable generated example, not these placeholders as an install step.

Review, execute, recover

The Runtime independently reads current state and freezes the exact command. Required approval binds current hashes/version, not “allow a rollback sometime.” Before dispatch it revalidates authority and state, persists attempt identity and constructs a conditional patch.

If the native response establishes the intended mutation, record committed. Observe rollout separately. If the response is lost, retain UNKNOWN and the reservation; read-only reconciliation must establish the original causal transition. A current matching image or inherited annotation alone cannot establish attribution.

Failure cases to see in the evaluation

A rollback may itself fail or remain UNKNOWN. If GitOps owns the image field, use its approved write path or select another valid evaluation target. Source: docs/runtime/OPERATIONS.md, API.md, RECOVERY.md and the acceptance runner supplied with the source checkout.

Required cases

The 15 September fresh local rollback run passed ten automated assertions across A–I; J remains NOT_OBSERVED. Real Kubernetes 1.35.0 and PostgreSQL were used with synthetic identity/MFA. An actual SIGKILL preserved the original attempt; response-loss recovery retained one adapter PATCH invocation. A separate crash after the durable claim but before I/O preserved UNKNOWN with no replay. These counters are not packet capture or application-effect proof.

The dated evaluation-validation summary in the optional document bundle records 485 distinct repository tests across scoped runs, without double-counting repeated browser tests. The actual PostgreSQL restart test used a typed native-provider double; the native rollback/SIGKILL exercise is separate. Detailed original A01–A28 mapping remains in docs/runtime/ACCEPTANCE.md; these lettered scenarios do not renumber it. Neither run proves customer installation, IdP compatibility or application health.

Run and record

Use the quickstart and customer acceptance runner against disposable resources first. Preserve an earlier committed image operation, then exercise the separately granted rollback. Stop concurrent demo/worker processes when required by the runner; native suites share fixtures and run serially.

For every case record: expected result, actual commit/observation, operation/attempt IDs, grant/command binding, original request key, native observation source, injected fault, repeated-write count, evidence path, operator minutes, assistance and limitations. Fault injection after native I/O is not a claim that every physical network partition was reproduced.

For J, hand a clean environment and the kit to an engineer who did not author the implementation. Count interventions and failed commands. Verify that the engineer can explain why a timeout may remain UNKNOWN and why a new request key is not a safe retry strategy.

Acceptance and purchase are separate

Correct UNKNOWN behavior can pass a test and still impose unacceptable operating cost. Record pass/fail/blocked per case, compare native-stack burden and make a separate continuation decision. Agree the contractual milestone before work; this template creates no automatic acceptance or invoice obligation.

Assemble the real alternative

If GitOps owns the field, assess the source-of-truth change and resulting controller effect. A direct patch demonstration cannot claim equivalence merely because both eventually show the same image. Record differences in the declared operation and attribution boundary.

Test identical questions

Can old approval authorize changed bytes? What prevents stale-state mutation? What survives a crash? Who determines whether retry is safe after a timeout? What evidence establishes the original effect? Can an agent bypass the path? What remains unresolved after an unhealthy rollout?

Apply acceptance cases A–J to both approaches, documenting cases that are not semantically comparable. Preserve errors and unresolved outcomes. Native capability that meets a case is a pass, not something to discount because it lives across several tools.

Measure effort honestly

Time both from the same start condition. Separate founder implementation, customer configuration, custom engineering and recurring operation. Publish neither invented savings nor a composite score that hides an unacceptable failure. The checkout’s docs/design-partner/NATIVE_STACK_COMPARISON.md contains the reproducible comparator and run-evidence references; customer-specific savings and superiority remain unmeasured until the customer baseline is run.

Decide

The 15 September local native reference passed six component checks, including native authorization/admission, conditional writes, revocation and response-loss recovery from retained history. Its single-process file journal is not a complete distributed workflow, GitOps or customer-identity composition. The result demonstrates useful native capability; it does not establish the cheaper complete customer path. The optional document bundle includes the native comparison reference and its result.json for the exact scope.

Choose the native stack if it meets the contract economically. Continue with Nikxius only when the customer records a concrete advantage, accepts its additional operational component and identifies a production decision and budget owner. If the path cannot be made mandatory, the initial boundary is not established.

Scope and commercial structure

One kubernetes.deployment.rollback_image.v1 operation family: one enrolled Deployment container in one named nonproduction environment, restoring an explicitly permitted immutable prior image tied to an earlier committed operation. Establishing the controlled prior image operation is part of the test fixture, not a license for general cluster mutation.

Annual scope and price are separate. The proposed credit is not a cash refund, automatic renewal or obligation to purchase. Access delays and scope changes require a recorded schedule decision; no unlimited extension or engineering is implied.

Delivery and responsibilities

Nikxius, led by Nikhil Sood, supplies installation/integration assistance, the agreed test procedure, documented findings and operator handover. Support channel, working hours, escalation owner and response expectations are recorded in the order; 24/7 coverage and an SLA are not included by implication.

The customer supplies a platform owner, technical operator, security reviewer, approved nonproduction environment, identity/secret/database setup, current-stack configuration and operational evidence. Secrets remain in approved channels. The customer retains change authority, backups and emergency responsibility.

Acceptance and end state

Before signing, name the milestone owner, ten-case acceptance contract, evidence and any measured improvement threshold. An honest unresolved outcome can be technically correct; it must still be operationally acceptable. Disputed/unmet criteria, remedies and termination follow the signed agreement, not assumptions in this offer.

Close with one dated choice: annual/production scoping, additional bounded evaluation, native stack sufficient, or no continuation. Production access, new operations, bespoke integrations, compliance certification and public customer references require separate approval. No endorsement or right to publish customer data is implied.

Contracting identity, authorized signatories, license, confidentiality, data handling, IP, liability, tax, termination and governing law remain to be confirmed through appropriate legal review. This scope supersedes the older image-change starting offer for new evaluations while retaining its proposed price and credit structure.

Why not use RBAC and admission?

Use them. They are part of the baseline and the Nikxius deployment. RBAC constrains the credential’s resource/verbs; native admission can constrain writes. Evaluate whether the composed stack also binds the exact task, native baseline, durable attempt, unresolved outcome and operator recovery economically. Nikxius has no automatic claim to win.

Does this replace GitOps, Temporal or the IdP?

No. Existing identity, workflow and authoritative writer ownership remain. The current typed adapter calls the registered Kubernetes API; it is not a generic GitOps or Temporal integration. A competing controller must be reconciled in the design, not ignored during the demo.

Is this a published SDK or hosted service?

The Node client is exported by the private control-plane workspace. Runtime source is private and UNLICENSED without agreed evaluation terms. Execution requires no Nikxius SaaS control plane. The public website is not a customer execution endpoint.

Can the agent still bypass it?

Yes, if it retains another equivalent writer or access to the Node’s credential. Review direct permissions, secrets, token creation, exec, CI/tools and host paths. Local denial tests establish the tested paths, not every possible customer route.

What if the response is lost?

The attempt may have executed. Preserve UNKNOWN and the original identity; use read-only reconciliation. Do not issue another mutation simply because a timeout occurred. Sufficient retained native history can establish the original transition; current matching state alone cannot.

Can UNKNOWN stay forever?

Yes. Missing or compacted history can prevent resolution. The task/resource reservation remains. Customer operational ownership and separately governed emergency access must handle that obligation. A UI acknowledgement does not manufacture evidence.

Is execution exactly once?

There is no universal exactly-once claim. Nikxius preserves request/attempt identity, avoids blind replay and uses native preconditions. PostgreSQL and Kubernetes are separate systems; delayed requests and missing history remain explicit limits.

Does revocation cancel an action?

It blocks later checked admission/dispatch claims. It does not retract a native request already accepted or guarantee every delayed sender has stopped. The exact native conditional request is a separate guard.

Does a signature prove a correct outcome?

It can establish integrity and Node-key attribution of the retained record. It does not establish business correctness, independent native truth or a complete record where history was lost. Unsigned source-qualified exports remain possible.

What proves that the application recovered?

Application-specific health checks owned by the customer. A committed Deployment spec change and controller rollout observation are distinct from application health. The rollback is itself a new consequential operation and can fail or remain unknown.

Is it production-ready or independently certified?

Local conformance and this proposed nonproduction evaluation do not establish production acceptance, external penetration testing or certifications. Customer IdP, native policy, backups, retention, support and security review must be validated for the intended environment.

Technical gate

The customer engineer can install the agreed composition, establish exact authority, run the supported rollback, observe failure, preserve UNKNOWN, reconcile using native evidence and export the lifecycle. Cases A–J have explicit pass/fail/blocked evidence and limitations. No bypass is found within the agreed review scope. Founder interventions and unresolved security issues are counted.

A correctly retained UNKNOWN may satisfy a failure-semantics test. It does not by itself establish acceptable day-to-day operations. Define who investigates unresolved effects, available history, acceptable investigation time and escalation before acceptance.

Economic and operating gate

Compare the same contract with the actual native alternative. Measure customer installation/configuration, custom engineering, support and incident/recovery effort separately. Agree a useful improvement threshold with the owner instead of imposing an invented percentage. Include ongoing Node/database upgrades, credential rotation, backups, monitoring and retention.

Recurring software value requires substantially reusable contracts. If each customer needs different engineering and continual founder operation, record the result as services-heavy rather than calling it self-service software.

Four closeout outcomes

The acceptance installment uses the previously agreed contract milestone. Purchase, payment, technical acceptance and permission to change production are separate records. A technical pass with no willingness to pay remains an unproven commercial thesis.

Close access and retain the truth

Export the agreed redacted result and lifecycle evidence. Revoke evaluation grants and remove temporary identities/credentials through customer procedures. Stop/delete only explicitly agreed evaluation resources after retaining required evidence; do not silently destroy unresolved obligations. Record remaining UNKNOWN operations and transfer ownership before shutdown.

Document next operation requests as evidence, not automatic roadmap promises. Broader implementation should normally follow repeated demand from independent companies with the same missing requirement and a budget owner, unless a paying customer explicitly funds a bounded bespoke scope.

The closeout records the completion date, customer decision, reasons, assistance hours and data/access disposition. That date anchors any agreed 90-day annual-credit period. Neither public reference rights nor customer endorsement is included by default.

The optional ZIP document bundle contains the same 11 PDFs, offline HTML, editable documents, configuration examples and redacted validation references. Runtime source is supplied separately under agreed evaluation terms. Reading or downloading this material creates no agreement and grants no production authorization.

Return to the evaluation overview or contact Nikxius to discuss one blocked operation.