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

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.

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 linuxota ci github check --workflow verify --mode container --target-os linuxota 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 publishota 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-keyota 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.

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

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

ota upgradeota --versionota validateota doctor --jsonota tasks --safe --useota run <task> --dry-run --json

For the new proof and CI surfaces:

ota ci projection --workflow verify --mode native --target-os linux --jsonota proof runtime --workflow verify --json --archiveota 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.