Ota v1.6.25 Now Available: Governed CI, Trusted Replay, and Lifecycle Proof

Idea

v1.6.25 is an execution-authority release.

Ota already gave repositories one contract for setup, readiness, tasks, workflows, and agent
boundaries. The next problem was harder: how should a consumer decide whether the resulting green
run deserves trust?

A contract can be internally valid while making a claim that available evidence does not support.
A CI workflow can be green while executing a different closure from the one the contract governs.
A generated baseline can be present while nobody can prove who recorded it, which version was
reviewed, or whether replay was allowed to rewrite it. A service can become ready while teardown
remains unobserved.

v1.6.25 addresses those gaps by making authority more explicit:

• CI lanes are deterministic projections of contract truth, not another hand-maintained execution source.
• prerequisite freshness is derived from runner-witnessed provenance, not a maintainer-authored cold: true label.
• replay consumes an explicitly promoted baseline identity, never whichever recording happens to be newest.
• lifecycle proof owns startup, readiness, assertion, and finalization as one bounded transaction.
• safety and proof claims remain qualified when the available evidence is incomplete.

The result is not “more green.” It is a stronger account of what made the run green, which
authority admitted it, and where the proof stops.

Feature

1. CI can now be projected from the contract

v1.6.25 introduces a provider-neutral CI projection:

ota ci projection \
  --workflow verify \
  --mode container \
  --target-os linux \
  --json

The projection binds the selected workflow, effective execution mode, target operating system,
bootstrap truth, toolchain ownership, governance decision, proof requirements, and stable merge
check identities.

GitHub Actions is the first adapter:

ota ci github render --workflow verify --mode container --target-os linux
ota ci github check --workflow verify --mode container --target-os linux
ota ci github sync --workflow verify --mode container --target-os linux

All three commands use the same canonical renderer. check detects drift. sync writes only the
Ota-owned reusable workflow and refuses unowned or unsafe paths.

The ownership boundary is deliberate. Ota owns the governed verification lane. The provider-owned
caller keeps triggers, permissions, environments, scheduling, deployment, and platform policy.
This avoids replacing two manually maintained sources of execution truth with fragile
bidirectional synchronization.

Generated lanes also preserve execution semantics:

• finite verification runs the selected task closure, not readiness-only ota up
• runtime-proof lanes execute through one authoritative proof wrapper instead of running twice
• native toolchains are projected from contract truth
• container-owned toolchains stay inside the declared image
• impossible mode or target-OS combinations are refused before rendering

The provider-neutral model is the product surface. GitHub is an adapter, not the architecture.

2. Agent refusal can be tested at the real chokepoint

Safety metadata is useful only if the runner still enforces it.

Repositories can now declare refusal canaries for tasks and workflows that must remain unavailable
to agents:

agent:
  refusal_canaries:
    - task: publish
    - workflow: release

The canary uses the ordinary runner admission path:

ota run --agent --expect-refusal publish
ota up --agent --expect-refusal --workflow release

It succeeds only when Ota observes the expected safety-boundary refusal before work starts. An
admitted target fails the canary. A refusal at the wrong governance boundary does not silently
stand in for the safety control being tested.

Managed CI projects each canary as its own provider check with a stable merge-check identity. That
turns “this lane is unsafe for agents” from static metadata into a negative control on the actual
runner chokepoint.

3. Doctor separates declaration, evidence, and policy

ota doctor --json now carries contract-claim assurance without pretending that Ota can infer
missing intent.

For agent-safety and proof-breadth claims, the output keeps four truths separate:

• what the maintainer declared
• what closure the runner derives and enforces
• whether observable evidence is supported, contradicted, or unknown
• what policy decides to do with that assurance

unknown is important. A structurally valid contract is not independently proven merely because
nothing contradicted it.

Archived runtime proof can support a bounded proof claim only when its contract snapshot, source
identity, selected scope, execution mode, and replay posture match the current lane. Stale,
scope-mismatched, or absent evidence stays unknown.

This is also why execution success and proof breadth remain separate. ok: true means the selected
execution/readiness operation succeeded. Consumers must read proof_verdict and not_proved[]
before deciding what the artifact established.

4. Freshness is now runner-authored provenance

“It worked in a fresh environment” is a useful claim, but only when the runner can show which
prerequisites were absent, created, reused, and later asserted.

Runtime proof now carries an execution-boundary evidence graph for supported prerequisite classes.
The graph binds precondition observations, producer events, assertion observations, identities,
scope, and ordering to the current execution.

Ota derives two independent results:

• target_freshness, such as cold_start_verified, persistent_state_reused, or unknown
• derivation_posture, such as fully_derived, cache_assisted, inherited_immutable, or unknown

That separation matters. A clean node_modules target rebuilt with a reused download cache can be
cold for runtime state while still being cache-assisted. A pre-existing virtual environment with
a matching identity is verified reused, not cold.

The first carriers are intentionally narrow:

• native virtual environments
• native frozen pnpm hydration
• compatible finite ephemeral-container dependency closures

Ota does not generalize those observations into whole-machine freshness. Uninstrumented services,
databases, volumes, provider-managed state, and unsupported package-manager layouts remain
unknown.

5. Generated baselines have an explicit authority chain

v1.6.25 adds first-class record, promote, and replay authority for generated baselines:

ota baseline record --artifact answer-key
ota baseline promote \
  --artifact answer-key \
  --attestation .ota/recordings/answer-key.json

The authority chain is explicit:

producer run
  -> recorded attestation
  -> explicit promotion
  -> immutable selected authority
  -> bounded replay

Recording binds the producer receipt, semantic contract identity, source state, execution-boundary
graph, and complete canonical output manifest. Promotion selects one named attestation
atomically. Replay consumes only the promoted identity; it never selects “latest” and never
rewrites authority.

Strict read_only replay uses a runner-owned snapshot outside the writable worktree and projects
it across the full ephemeral-container consumer closure. Native and other non-strict lanes can use
verify_unchanged, which detects mutation after execution without falsely claiming that writes
were structurally prevented.

Portable manifests name scm_review as an external trust root. Ota verifies the selected manifest
and content identities, but it does not claim to have verified repository review, reviewer
identity, or signer provenance. That delivery-system authority remains outside Ota.

Replay-input pins are stronger too. Authors can optionally declare an immutable expected identity:

replay_inputs:
  - id: frozen_store
    kind: static_file
    path: data/store.db
    expected_identity: sha256:4d8c...

Ota computes the observed identity before execution and refuses missing or mismatched pins before
setup, hydration, service ownership, or task startup. Expected and observed identities remain in
machine-readable refusal evidence.

6. Lifecycle proof owns finalization, not just readiness

ota proof lifecycle adds a bounded transaction for manager-owned service closures:

ota proof lifecycle --workflow integration --json --archive

The transaction orders:

1. prerequisite execution
2. initial-state observation
3. cleanup-lease acquisition
4. service startup
5. readiness
6. an optional finite assertion
7. reverse-order teardown
8. terminal finalization observation

Ota leases only services it can prove were inactive before startup. It does not claim ownership of
pre-existing services. Cleanup runs after acquired ownership on success, failure, or interruption,
and isolated container boundaries are complete only after the engine confirms that the exact
session is absent.

Lifecycle archives bind the semantic contract snapshot, source identity, selected workflow and
service closure, execution scope, target OS, boundary identity, transaction records, and qualified
verdict. Archive verification re-derives service selection and teardown authority from the
snapshot instead of trusting archive-authored labels.

The boundary remains narrow: lifecycle proof can establish the selected startup/readiness/assertion
and finalization transaction. It does not prove broader application output, repository completion,
deployment safety, or provider policy.

7. Typed execution keeps replacing shell ownership

The release also closes several practical gaps uncovered while pressure-testing the larger trust
model:

• command.interaction: auto | forbidden | required makes human TTY ownership explicit while keeping agent and non-TTY execution noninteractive
• native Corepack activation prevents ambient Yarn or pnpm shims from bypassing declared versions
• GitHub projection supports contract-owned Python/uv, Node/Corepack, Ruby, Go, and .NET toolchains
• typed local-project Python hydration preserves editable posture, extras, groups, source, manifest, and lock identities
• selected Ruby container lanes can fulfill the declared Bundler version before hydration
• effects.network_kind: service_readiness distinguishes finite local probes from live integration tests

These changes are not independent conveniences. They remove shell and ambient-state ambiguity from
the execution paths that now produce stronger proof.

Boundaries

The most important v1.6.25 behavior is what it refuses to imply:

• a successful command does not prove the wider repository
• a supported contract claim does not prove the absence of hidden risk
• a cold verified target does not prove whole-machine or provider-state freshness
• a recovered seam marker does not prove that the dependency shaped broader application output
• a lifecycle pass does not prove deployment or production health
• a promoted baseline relies on the declared external review authority
• a provider adapter does not transfer triggers, permissions, secrets, environments, or deployment policy into Ota

Those are not disclaimers around the product. They are part of the product contract.

Pressure

The release was shaped by real repositories with different failure boundaries:

• Kylrix and Outline pressured managed native/container CI projection and Corepack ownership.
• OrchardCore and nopCommerce pressured typed .NET projection without transferring deployment policy into Ota.
• Lead Quorum and Dograh pressured native Python fulfillment and local-project hydration.
• EventCatalog pressured portable generated-baseline authority and detached replay consumers.
• Bedrock pressured the separation between declared replay inputs and witnessed model behavior.
• Caddy and Open WebUI pressured lifecycle ownership across isolated and Compose-backed managers.
• Athena API pressured bounded dependency proof and typed Ruby/Bundler execution.

The useful outcome was not that every repository became globally governed. Each pressure pass
either moved material behavior into the contract, carried a machine-readable not_proved
boundary, kept provider-owned behavior outside Ota, or exposed a named platform gap.

Docs

Use the live references for exact authoring and machine-consumer semantics:

• Install Ota
• Command Reference
• Contract Reference
• Execution Receipt
• Runtime Proof Evidence
• JSON Output Reference

Release

Install or upgrade to the released version, then inspect the contract-owned surface before running
it:

ota upgrade
ota --version
ota validate
ota doctor --json
ota tasks --safe --use
ota run <task> --dry-run --json

For the new proof and CI surfaces:

ota ci projection --workflow verify --mode native --target-os linux --json
ota proof runtime --workflow verify --json --archive
ota proof lifecycle --workflow integration --json --archive

The canonical release and complete patch-level changelog are available at
ota.run/releases/v1.6.25.

v1.6.25 moves Ota from declared execution governance toward evidence-bound execution authority:
not only what should run, but which closure ran, what state it relied on, who selected the replay
truth, which cleanup Ota owned, and what the resulting green artifact still did not prove.

Originally posted here: https://ota.run/blog/ota-v1-6-25-release-essay