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:
-
reachablemeans the selected path reached the dependency boundary -
exercisedrequires transaction-bound evidence that the dependency participated in the current run -
fault_testedrequires 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:
{
"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:
ota up --workflow verify --replay-baseline latest --json
The replay surface reports one of three explicit outcomes:
replay_verifiedreplay_failedreplay_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:
-
uvhydration can declare a default index, ordered additional indexes, and offline intent -
.NET restorerecords 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_imagefor typed image file, context, tag, and provider ownership - generated artifact lineage through declared producers, outputs, inputs, and consumer requirements
- task-level
only_onplatform constraints -
launch.runtime_projectionadapters 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
uvsource 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:
- Get started: Install Ota
- Proof semantics: Runtime Proof Evidence
- Execution evidence: Execution Receipt
- Contract fields: Contract Reference
- Command behavior: Command Reference
- Machine output: JSON Output Reference
- Governance architecture: Execution Governance Loop
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:
ota upgrade
ota --version
ota validate
ota doctor --json
ota tasks --safe --use
ota run <task> --dry-run --json
ota 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?
Originally posted here: https://ota.run/blog/ota-v1-6-24-release-essay
Top comments (0)