← Runtime integrity sprint
Deployment reportFailure-inclusive recordDEPLOYED_HEALTHY

RC2 deployment record

A release-engineering account of the rollbacks, missing production conditions, deterministic canaries, interpreter mismatch, and final process-start diagnosis that led to a healthy atomic deployment.

Why release engineering became part of correctness

The validated candidate initially existed only in a dirty development tree containing unrelated work. The installer also upgraded a live virtual environment in place. Neither could establish which bytes were tested, packaged, loaded, or available for rollback. The release process moved to clean worktrees, exact-scope commits, immutable tags, wheel and installed-file hashes, release-specific environments, atomic systemd drop-ins, maintenance ingress, and executable-only rollback.

Clean commitvalidated scope only
→
Wheelhash + RECORD
→
Immutable environmentinstalled hashes
→
Atomic switchdrain + snapshot + drop-in
→
Canarydeterministic machine facts

What the release attempts taught us

StageObserved failureCorrection
Pre-RCValidated bytes mixed with unrelated dirty-tree work; live venv mutated in place.Isolated commit/tag, immutable environment, source→wheel→installation attribution.
RC1Model-selected smoke tests chose the wrong tools; a compressed stale answer passed; recovery amplified latency to hundreds of seconds.Production-history fixture, bounded directional reuse check, deterministic authenticated canary hooks.
RC2.1Background exit was durable, but output emptiness was not reconstructably typed; maintenance producer coverage and mutation-cause prose needed proof.empty|nonempty|unknown plus bytes, producer matrix, fail-closed maintenance, cause-compatible prose.
RC2.2The validated venv’s Python symlink resolved to the host interpreter, so copying it could not preserve the reviewed Python 3.14.6 identity.New release validated explicitly on the production-compatible Python 3.14.4 runtime.
RC2.3/2.4Cancellation erased a failed tool outcome; deterministic failure canary still entered long model recovery.Job-scoped action preservation through cancellation and fail-fast infrastructure assertions.
RC2.5Background canary proved its lifecycle, then unnecessary model/reviewer recovery made it appear failed and slow.Canaries terminate as soon as their durable acceptance facts exist.
Final blockerBackground child could not start.Diagnosed and removed a canary-only inaccessible working-directory override.

The final process-start failure

Exact cause: the deterministic canary created a privileged-account-owned workspace with mode 0700, then supplied that path as the service child’s working directory. The unprivileged service process could not traverse it, and process creation raised PermissionError [Errno 13].

The executable itself was valid. Python subprocess behavior, /usr/bin/true, journal paths, systemd restrictions, and the normal workbench path were not the cause. Ordinary background jobs inherit the service working directory. The fix removed only the canary-specific cwd override and added a regression reproducing inaccessible workspace behavior.

Deterministic canaries

Deployment canaries became infrastructure assertions rather than miniature conversations. Mutation ends when the expected adapter failure and zero writes are durable. Background ends when process settlement, exit code, output state/bytes, and journal reconstruction are durable. Stance ends after authoritative lookup and a before/after mutation check. Recall ends when typed retrieval state is established. Journal provenance ends when required receipts and linkage exist. Model prose or reviewer approval is required only when prose or review is the object being tested.

Background~0.129 sexited, exit 0, empty, 0 bytes, reconstructed, valid chain.
Mutation~0.076 sExpected literal/source validation failure, zero remote writes.
Recovery calls0No model, reviewer, or permission activity in deterministic canaries.

Atomic deployment boundary

  1. Freeze and verify. Commit, tree, tag, wheel, RECORD, module hashes, interpreter, manifests.
  2. Close and drain. Durable maintenance allows only the authenticated canary while ordinary producers remain pending or safely rejected.
  3. Snapshot. SQLite online backup, PostgreSQL state, workbench chains, stance rows, configuration, and previous executable identity.
  4. Switch one service. Stop only the agent, atomically replace its drop-in, reload systemd, and start from the immutable environment.
  5. Verify loaded bytes. Process command, interpreter, installed hashes, schema, dependencies, maintenance readback.
  6. Canary and compare. Exercise deterministic paths and compare event, journal, workbench, stance, and outbox integrity.
  7. Reopen gradually. Explicitly disable maintenance, limited traffic, progressive ramp, elevated monitoring.

Rollback changes the executable release only. Databases are not restored unless corruption is proven, preserving valid state created around the switch.

Final RC2.6 identity

Tagkairo-validated-20260822-rc2.6
Commit55bb7bc2a1a93178877d0040d7513ecf9dfe218a
Tree54876853032b5df6e5ff3730bf5f9d5e061b8f0b
Wheel SHA-256867a6dced39c94ade1fd3091d184782a0c730d15ab88d43bcfdb48bec6ad753b
Manifest SHA-256cd628c1f67eb816df20962ce28546ba4d386beea4a30408fcff7b771a02e967b
Database schema16; no migration
Final stateDEPLOYED_HEALTHY

SQLite integrity was ok, stance state did not change because of deployment or smoke inspection, and normal traffic reopened successfully.

Post-sprint patch

A later two-file RC2.7 successor corrected ordinary continuing-topic projection without reopening the sprint architecture. It was packaged from RC2.6, passed the directly affected tests and installed-wheel smoke, deployed through the same maintenance/snapshot/atomic-switch mechanism, and passed live service, storage, and recall checks. RC2.6 remains the release that closed the engineering sprint described here.

What deployment success does not mean

It does not mean every optional canary is a scientific test of model quality, that no future defect exists, or that Kairo must take any particular philosophical position. Deployment acceptance concerned loaded identity, storage integrity, core foreground operation, typed lifecycle truth, retrieval-state truth, and preserved self-authorship.