← Back to blog
Release essay2026-07-17 10:54 UTC

Ota v1.6.24 Now Available: Runtime Proof, Replay Trust, and Typed Execution

Ota v1.6.24 strengthens runtime proof with transaction-bound seam evidence and negative controls, adds replay-grade input provenance, and expands typed image, hydration, runtime, and artifact ownership.

Ota v1.6.24 runtime proof, replay trust, and typed execution governance

Idea

v1.6.24 is an execution-evidence release.

The pressure behind it was a trust problem: a green command is useful, but it does not automatically prove that a declared dependency shaped the result, that the same material inputs can be replayed, or that a new run still represents the same operational truth.

Ota now draws those boundaries more sharply.

This release strengthens three connected questions:

  • did the selected runtime start and become ready?
  • did the proof actually exercise the declared dependency seam?
  • can a later run identify and replay the material inputs that shaped the original execution?

It also moves more setup and runtime behavior from shell convention into typed contract ownership, so the evidence has stronger declared truth beneath it.

Feature

v1.6.24 strengthens six connected parts of Ota's execution-governance model.

1. Runtime proof now distinguishes readiness, exercise, and causality

Runtime proof should not overstate what a green lane established.

v1.6.24 adds a stronger evidence ladder for declared dependency seams:

  • reachable means the selected path reached the dependency boundary
  • exercised requires transaction-bound evidence that the dependency participated in the current run
  • fault_tested requires a separate, same-obligation negative control that fails for the declared missing-effect reason

For marker-bound seams, Ota now creates an opaque transaction marker for the producer path and requires the observer to recover it from the dependency. A clean observer exit is not enough. The evidence has to match the current transaction and declared obligation.

Negative controls are strict too. An unrelated timeout, setup failure, crash, or generic non-zero exit cannot promote a seam to fault_tested. The control must be valid, bound to the same obligation, and classified as the expected obligation failure or missing effect.

The resulting proof can remain honestly qualified:

QUALIFIED PROOFjson
{
  "ok": true,
  "proof_verdict": "passed_with_unproven_boundaries",
  "dependency_evidence": [
    {
      "dependency_id": "service:postgres",
      "level": "fault_tested"
    }
  ],
  "not_proved": [
    {
      "kind": "dependency_output_shaping_not_proved"
    }
  ]
}

That distinction matters. Ota can prove that a declared PostgreSQL seam was causally exercised without pretending that PostgreSQL shaped every application output or that one narrow proof covered the whole repository.

2. Replay became execution-authored instead of reconstructed later

v1.6.24 adds first-class replay against archived execution truth:

REPLAYbash
ota up --workflow verify --replay-baseline latest --json

The replay surface reports one of three explicit outcomes:

  • replay_verified
  • replay_failed
  • replay_unavailable

Ota compares the selected workflow, backend, provider, remote target, and lifecycle against the archived baseline before treating it as comparable execution. It also classifies last-known-good evidence as verified, stale, or unavailable rather than silently treating any old green receipt as current proof.

Receipts now retain more of the material input identity needed for honest replay and diagnosis, including clean Git state, policy rulesets, environment-source identity, lockfiles, Node runtime identity, immutable Compose image identity, and dependency-hydration provenance where available.

The evidence model also keeps inputs separate from witnessed output. Declared replay inputs belong under replay_inputs; observed query behavior belongs under witnessed_observations.query_traces. That lets later comparisons distinguish changed inputs from changed runtime behavior instead of mixing both into one evidence list.

3. Dependency provenance became more explicit

Dependency hydration is not fully described by the package-manager verb alone.

This release widens typed hydration with source posture:

  • uv hydration can declare a default index, ordered additional indexes, and offline intent
  • .NET restore records runner-resolved NuGet feed identity when it can establish it
  • pnpm workspace hydration can declare a first-class filter

The trust rule remains conservative. If Ota cannot recover authoritative feed identity, the evidence narrows the diagnosis; it does not become a false hermeticity claim.

This gives receipts and replay a better answer to a common drift question: not only which package manager ran, but which declared or resolved dependency source shaped the run.

4. More execution truth moved into typed contract ownership

v1.6.24 removes more reasons to hide important repo behavior in opaque shell commands.

The release adds or widens:

  • action.kind: build_container_image for typed image file, context, tag, and provider ownership
  • generated artifact lineage through declared producers, outputs, inputs, and consumer requirements
  • task-level only_on platform constraints
  • launch.runtime_projection adapters for Uvicorn and Next.js
  • closure-aware execution modes for tasks and aggregates
  • aggregate dry-run governance derived from the actual dependency closure

Execution-mode admission is stricter as well. If a task does not advertise a requested mode, Ota refuses it instead of quietly selecting a different execution path.

Together, these changes strengthen the relationship between declared contract truth, the selected runtime path, and the evidence Ota emits afterward.

5. Task discovery and execution now agree more closely

Humans and agents need to see the same callable surface that the runner will enforce.

Task discovery now reports closure-aware run guidance, including:

  • human execution commands
  • agent execution commands
  • agent policy posture
  • machine-readable use.modes[]

Ota also tightened CI verification recovery and governance reconciliation so merge-gate output can explain the required verification lanes, the cited inputs behind the decision, and the decision basis instead of publishing a verdict with weak provenance.

The result is a cleaner path from discovery to execution: task listings, dry-run governance, runtime admission, and receipts are less likely to describe competing truths.

6. Runtime cleanup and interruption became safer

Some of the most important trust work in this release is deliberately unglamorous.

v1.6.24 improves runtime correctness around interruption and cleanup:

  • Ctrl+C is classified consistently as an interrupted execution with exit code 130
  • signal forwarding targets the selected child process tree without killing the invoking shell
  • interrupt state is scoped to the active execution epoch
  • native command services publish clearer readiness and endpoint truth
  • runtime proof starts and stops only proof-owned Compose dependencies
  • services that were already running before proof are preserved
  • container proof cleanup follows the selected effective execution mode

This matters because evidence is only trustworthy when the runner also owns failure, interruption, and cleanup boundaries correctly.

Pressure-tested on real repositories

The release was shaped through real repository pressure rather than fixtures alone.

  • Athena API forced marker-bound PostgreSQL seam proof, same-obligation controls, and typed production image ownership.
  • Bedrock pressured replay inputs, presentation and comparator profiles, and witnessed query traces.
  • Lead Quorum pressured uv source posture, runtime projection, and image-build ownership.
  • Kylrix pressured Next.js runtime projection and truthful native/container mode admission.

Those repos exposed the places where a structurally valid contract could still produce evidence that was too broad, too weakly attributed, or too dependent on shell convention. The fixes in v1.6.24 are the product response to that pressure.

Docs

Use the live references for the shipped surface:

The published schemas and public examples have also been updated for replay inputs, witnessed query traces, dependency evidence, seam observations, negative controls, and explicit not_proved boundaries.

Release

v1.6.24 is live here: https://ota.run/releases/v1.6.24

Upgrade and verify the selected repo path:

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

v1.6.24 moves Ota further from “the command passed” toward the stronger question: what did this execution actually prove, which inputs shaped it, and what remains unproved?