DEV Community: Ota

Ota on dbmask: Proving a Synthetic PostgreSQL Masking Lane

Bobai Kaeto — Tue, 29 Sep 2026 12:33:25 +0000

A green command was not the acceptance condition

dbmask masks database content. The useful question for this integration was specific: could a declared task run the intended masking sequence and retain
evidence that its result matched the observed state of a disposable PostgreSQL database? A command exiting zero would not answer that on its own.

PR #37 added a reviewable ota.yaml pinned to released Ota v1.6.28 and a separate, non-blocking Ota workflow. The existing SQLite CI stayed in place. The added PostgreSQL 16 lane uses only synthetic data.

What the lane actually checks

The lane seeds two disposable databases, scans, performs a masking dry run, applies the mask, and runs strict validation. Repository-owned assertions check that the dry run preserves both databases. After apply, they check source preservation, target primary keys and account_status, and changed target full_name and email values.

The negative control restores one original synthetic sensitive value after masking. Strict validation must then refuse that row with masking_completeness. This shows the selected validator notices a deliberate violation in the exercised fixture. Ota declares and runs the selected path; dbmask's fixture and validator own the database assertions. The workflow uploads the native and
PostgreSQL lane outputs from ota-pressure/native/ and ota-pressure/postgresql/ as CI artifacts.

The released-pin fork matrix and upstream PR matrix passed the contract-to-CI drift check, the selected SQLite contributor lanes on Ubuntu, macOS, and Windows, and the synthetic PostgreSQL lane on Linux. Those checks covered PR head 9f75a339e09fa3d762094ffee2ef612f93065e41. The upstream maintainer merged the bounded integration as commit 7d8789ef4883a423ddba2f8934b95997d1aaf099 on 29 September 2026.

What this changes for Ota

The integration shows an additive, non-blocking path into an existing repository: keep established CI, add one explicit contract and one selected evidence lane, and make the proof limits reviewable.
The negative control makes the PostgreSQL result more informative than a passing command alone. This case exposed no confirmed Ota Core defect in the selected lane.

The coverage remains narrow. It does not establish production-data safety, arbitrary database state, general PostgreSQL compatibility, MySQL behavior, release readiness, or repository-wide governance. The separate date-classification fix is dbmask-owned and outside this lane. The merge confirms maintainer acceptance of this contribution; it does not establish ongoing use or endorsement.

originally posted here: https://ota.run/blog/pressure-testing-ota-on-dbmask-postgresql-5m9q

Ota v1.6.28: Secret Requirements and Linked Worktrees

Bobai Kaeto — Sat, 26 Sep 2026 22:56:08 +0000

Idea

Ota v1.6.28 begins V12.1: governed secret delivery.

Repositories already need to declare that selected work depends on credentials. The unsafe version of that declaration mixes intent with implementation: provider names, account identifiers, secret paths, environment values, and delivery scripts become repository-owned configuration. That makes the contract less portable and creates more places for sensitive operational truth to drift.

v1.6.28 establishes a narrower boundary. A contract can declare which selected tasks or workflows require an authentication credential, where a future delivery mechanism would make it available, and which propagation paths must remain denied. Ota derives that requirement from the exact selected closure and refuses before work begins while protected delivery truth is unavailable.

This release does not deliver secrets. It makes secret intent explicit without allowing a repository declaration, an ambient environment value, or an incomplete provider integration to be mistaken for delivery authority.

The release also removes practical sources of execution drift: container tasks can run from ordinary linked Git worktrees, Yarn 1 hydration has an explicit typed path, generated AGENTS.md ownership is safer, and Corepack-backed commands use the declared package manager instead of an ambient global shim.

Feature

Provider-neutral secret requirements

Contracts requiring Ota v1.6.28 or later can declare a secret_requirements catalog. The initial surface describes authentication credentials intended for a canonical process-environment destination and exact task and workflow recipients. It does not deliver those credentials.

This excerpt from the release fixture declares a requirement for its separately defined governed task without placing a credential value or secret locator in the repository:

metadata:
  ota:
    minimum_version: "1.6.28"

secret_requirements:
  provider_api_token:
    secret_class: authentication_credential
    purpose: external_api_authentication
    delivery:
      kind: process_environment
      variable: GOOGLE_API_KEY
    recipients:
      tasks: [governed]
      dependencies: deny
      hooks: deny
      services: deny
      helpers: deny
      containers: deny
      remote_execution: deny
      proof_observers: deny
      negative_controls: deny
      lifecycle_children: deny
    constraints:
      actor_mode: ci
      environment: test
      execution_mode: native
      target_platform: linux
      runtime_boundary: process
      capability: segmented_process_environment

GOOGLE_API_KEY names the process-environment destination, not a provider binding or proof that the credential exists. Every propagation edge is explicitly denied.

Validation rejects provider selectors, cloud projects, tenants, secret paths or versions, GitHub secret names, values, defaults, noncanonical recipients, and destinations already owned by compatibility environment or execution-context truth. The minimum-version floor prevents older Ota versions from silently ignoring the declaration.

Fail-closed command admission

Secret requirements participate in command-scoped admission for ota run, ota up, runtime and lifecycle proof, Doctor context, CI projection and re-evaluation, sandbox capability, and harness output.

When the selected closure has no secret requirement, admission remains not_applicable and existing behavior is unchanged. When it does, the current release refuses with secret_delivery_protected_truth_unavailable before setup, dependency hydration, workflow environment rendering, durable logs, services, proof artifacts, child creation, repository mutation, or provider contact.

For that fixture, ota run governed --native --dry-run --json refuses rather than previewing a runnable task. Selected fields from its JSON result keep the limit explicit:

{
  "ok": false,
  "code": "secret_delivery_protected_truth_unavailable",
  "preview_status": "BLOCKED",
  "execution_started": false,
  "secret_delivery_admission": {
    "status": "refused",
    "availability": "not_checked",
    "provider_contact": "not_attempted",
    "delivery": "not_attempted"
  }
}

An existing environment variable with the same name does not satisfy the governed requirement. Within Ota-selected execution, agents and CI cannot satisfy it with ambient values or repository-local secret-loading glue. Ota does not govern commands run outside its execution path.

Provider-free foundations, not delivery

Behind this refusal, Core can reconstruct the selected requirement, recipient closure, protected binding and source identities, adapter profile, and provider-free plan. The first sealed adapter
profile is bounded to GitHub Actions OIDC and Google Secret Manager on a Linux/x64 protected runner. These are internal foundations for a later transaction, not a usable provider integration: v1.6.28 makes no OIDC request, contacts no provider, and produces no secret-delivery receipt.

Linked Git worktrees now run in containers

Unix container execution now supports ordinary linked Git worktrees. Ota verifies Git pointer metadata and translates it through runner-owned, read-only mounts. The common Git directory follows the selected workspace access posture.

Malformed, aliased, or unsupported metadata is refused rather than allowing a container to start with host-only Git paths. The boundary is intentionally local: it relies on a protected per-user runner-state root and does not claim protection from a hostile concurrent process running as the same operating-system user.

This closes an important day-to-day gap for agents and maintainers who use isolated worktrees but still expect the contract's container lane to behave like the canonical repository execution path.

Typed Yarn Classic hydration

Typed Node dependency hydration now supports:

source:
  kind: node_package_manager
  manager: yarn
  yarn_release: classic
  frozen_lockfile: true

Ota renders yarn install --frozen-lockfile for Yarn 1 instead of modern Yarn's --immutable. Existing Yarn contracts retain their modern behavior, and incompatible Classic plus inline_builds declarations are rejected.

Native Corepack run fulfillment is tighter too. Structured task commands and typed Node hydration are dispatched through corepack <manager>, so an ambient global Yarn or pnpm shim cannot replace the declared package-manager version. Opaque shell bodies remain repository-owned and unchanged.

Safer generated agent guidance

ota agents --review and ota agents --write now recognize generated guidance only when it occupies one uniquely delimited managed block.

Duplicate, reversed, ambiguous, or stale markers no longer appear synchronized merely because matching text exists elsewhere in AGENTS.md. Write mode refuses ambiguous layouts without modifying the file, preserves ordinary prose containing marker text, migrates exact legacy generated-only files, and does not treat an unreadable existing file as missing.

ota tasks --use, including the canonical ota tasks --safe --use discovery lane, also renders task notes. Proof limits, external boundaries, and operational guidance are therefore visible before an agent chooses a runnable task.

Readiness and detection improvements

Rich output now shows a compact Ota Readiness success summary before publishing runtime endpoints. It names only the resolved listener, aggregate probe count, and observed attempt; detailed targets remain failure and retry diagnostics. JSON and plain output are unchanged.

The release also tightens several discovery and diagnosis paths:

Optional nested .NET marker discovery skips permission-denied descendants; requested roots and selected sources still fail closed.
source-bound candidates retain nested .sln and .csproj observations
Taskfile helpers beginning with _ or marked internal: true stay out of runnable task truth
repeated reusable GitHub Actions verification steps collapse into one readable inferred task
named Actions steps with unresolved matrix or shell expressions cannot become runnable tasks
Rust diagnosis requires comparable semantic versions; rustup-owned fulfillment still accepts stable, beta, and nightly.
CI drift detection recognizes ota run <aggregate> --agent, but not dry-run, dependency-skipping, malformed, or shell-indirected forms.

What this does not claim

v1.6.28 does not store, resolve, request, materialize, inject, or deliver secret bytes. It does not authorize execution of a secret-requiring selected closure, contact GitHub's OIDC endpoint or Google Secret Manager, or produce positive secret-delivery evidence. A declaration proves only that the repository has made its intent reviewable; a refusal proves only that Ota stopped the selected closure at the governed boundary.

Linked-worktree translation does not provide hostile same-user process isolation. A green readiness summary does not expand the underlying probe evidence. Typed hydration does not make a networked setup lane automatically agent-safe.

These limits are part of the execution contract, not caveats around it.

Docs

Use the live references for the current contract, command, and agent-guidance behavior:

Release

Ota v1.6.28 is live at
ota.run/releases/v1.6.28.

Upgrade and inspect the repository's governed execution surface:

ota upgrade --version v1.6.28
ota --version --json
ota validate
ota doctor --json
ota tasks --safe --use
ota run <task> --dry-run --json
ota up --workflow <workflow> --dry-run --json

The GitHub release contains the shipped binaries, checksums, and complete patch-level changelog.

v1.6.28 makes a strategically important distinction durable: a repository may declare that selected work needs a credential without owning the provider binding, secret locator, secret value, or delivery authority. Until protected truth can satisfy that declaration, Ota refuses before work begins and says exactly what it did not attempt.

At the same time, linked-worktree container support, explicit Yarn Classic hydration, managed agent-guidance boundaries, and tighter detection make the ordinary execution path more deterministic. The result is stronger governance at both ends: clearer intent for future protected delivery and fewer ambient assumptions in the work repositories execute today.

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

Native locally. Container in CI. One task should still mean one thing.

Adamma — Mon, 21 Sep 2026 13:29:42 +0000

Execution drift begins when each environment gets a different task definition. A developer runs one command locally, CI runs another in a container, and an AI agent has to guess which one applies.

Ota keeps one task identity while making execution differences explicit. A task can declare native, container, or configured remote modes, each with its own context, dependencies, environment, command, and runtime details.

The agent follows the selected contract path, not a guess.

Different environments are not identical. Ota makes the differences reviewable.

Ota is open source. Request a demo: demo@ota.run.

AI Agents Shouldn’t Have To Guess Which Services Must Be Running

Adamma — Wed, 16 Sep 2026 13:11:01 +0000

An agent can have the right command and dependencies, then still fail because Postgres wasn’t ready when the integration tests started.

The usual fix is another README instruction:
Start Postgres first.

That works until an AI agent, CI job, or new developer misses it.

Ota puts that prerequisite in the execution contract. A task can declare requires_services: [postgres], allowing Ota to start the declared service and check its readiness before running the task.

The dependency travels with the task instead of living in someone’s memory or a separate setup guide.

The result is a consistent, reviewable execution path for developers, CI, and AI agents.

Want to see it in practice?

Request a free demo at demo@ota.run.

Does your repository have more than one version of “how to run it”?

Adamma — Thu, 10 Sep 2026 16:22:37 +0000

Perhaps local setup, CI, containers, and AI agents all follow slightly different paths, and a green result does not always mean the same thing.

Ota is offering a free execution-readiness review for a small number of open-source projects and engineering teams.

We’ll review one selected repository, identify conflicting or incomplete execution paths, and prepare a reviewable draft integration showing:

the canonical setup and verification path;
which native, container, and CI lanes actually work;
what each result proves;
what remains unverified.

This is not a paid service or sales trial.
If this sounds familiar, message me or email adamma@ota.run.

Output Parity Is Not Input Parity: What Execution Evidence Must Bind

Bobai Kaeto — Mon, 07 Sep 2026 18:29:53 +0000

A Green Output Can Still Be Built On The Wrong Input

Software verification often begins too late.

Teams compare outputs, run smoke tests, check exit codes, and inspect whether a generated artifact looks plausible. Those checks matter. But they cannot answer a more basic question:

Did every consumer receive the same intended input?

If the answer is unknown, output parity is weak evidence.

Two programs can both complete successfully while solving different problems. One adapter may truncate precision. One wrapper may drop a flag. One generated client may normalize a field differently. One CI lane may render a template with different environment truth.

The outputs may still look reasonable. The commands may still exit zero. The smoke tests may all pass.

The parity inference is still untrustworthy.

Ota's position is direct: acceptance evidence must bind what was declared, what was delivered, where it ran, and what was observed. Output alone is not enough.

The Failure Output Tests Cannot See

A recent Claude Code issue describes a useful failure shape. Two companion tools were generated from one specification and processed a large body of work. Their outputs survived smoke testing and output-side fault checks.

But one input path had reduced numeric precision. The tools were not receiving equivalent inputs, so they were not actually evaluating the same problem.

That is not merely a testing mistake. It is an evidence-design mistake.

The verification system asked:

did both tools run?
did both produce output?
did the output survive selected checks?

It did not establish:

which canonical input each tool was meant to receive
which transformation produced each delivered representation
whether the delivered representations were semantically equivalent
whether the checks exercised the exact input path later used in real execution

Once that link is missing, output comparison begins after the divergence has already happened.

A Hash Is Useful, But A Hash Is Not The Whole Model

A digest is useful for byte identity, but incomplete.

A digest can establish the identity of bytes. It does not automatically establish:

that the bytes came from the canonical declared source
that the renderer used the intended version and configuration
that two different representations are semantically equivalent
that the consumer actually received the recorded representation
that the proof exercised the same path used by the real task

For example, a JSON fixture and a command-line argument may encode the same logical value in different forms. Their byte digests should differ. The important question is whether each form was derived correctly from the same canonical input and delivered to the intended consumer.

That requires provenance, not just hashing.

What Execution Evidence Must Bind

A trustworthy execution record needs five distinct bindings.

1. Declared intent

Which contract, task, workflow, and canonical input governed the run?

This prevents a successful command from floating free of the repository truth it was supposed to execute.

2. Delivered input

What exact representation reached each consumer?

This is stronger than recording the source file. A template, wrapper, environment projection, CLI serializer, generated SDK, or protocol adapter may change the value between source and consumer.

3. Transformation provenance

Which producer, renderer, version, configuration, and transformation path created that delivered input?

Without this, two matching outputs may only prove that the same untracked mistake happened twice.

4. Execution boundary

Which source state, worktree, runtime, platform, mode, and isolated boundary executed the consumer?

Evidence from another checkout, container, task closure, or runtime cannot silently stand in for the selected run.

5. Witnessed result

What did the runner actually observe: output identity, side effects, dependency interaction, failure behavior, or an explicitly unproved boundary?

This keeps execution success separate from proof breadth. A zero exit can establish that a command completed. It cannot, by itself, establish that the command received the correct input or produced the intended application behavior.

Why This Is Execution Governance

This is the distinction Ota is designed to make explicit. Task runners and CI scripts can carry these bindings, but they do not establish them by default.

A task runner can launch two commands.

A CI workflow can compare their output files.

A README can say both commands should use the same fixture.

Execution governance asks whether the evidence chain is complete enough to authorize acceptance:

contract intent
  -> canonical input identity
  -> transformation identity
  -> delivered input identity per consumer
  -> selected execution boundary
  -> witnessed result and explicit not-proved boundaries

If any required link is unavailable, the honest verdict is not "close enough."

It is unknown, not_proved, or refusal, depending on the declared policy.

That distinction matters for humans, CI, and AI agents. Agents are especially good at producing plausible implementations quickly. They are not a substitute for runner-authored evidence that the implementation consumed the intended truth.

What Ota Already Establishes

Ota already provides building blocks for parts of this chain:

semantic contract identity ties execution back to normalized repository truth
clean source identity can bind evidence to the exercised repository state
replay inputs stay separate from witnessed observations
expected input identities can refuse selected execution when a governed file is missing or has changed
receipts preserve runner-authored execution evidence
proof output carries explicit not_proved boundaries instead of turning a narrow green result into a repository-wide claim
promoted replay baselines remain separate from ordinary observed output

See Replay Inputs and Trusted Baselines, Execution Receipt, and Runtime Proof Evidence.

These separations are deliberate. A previously observed output must not quietly become an input assumption. A file name must not substitute for content identity. A successful task must not become
proof of behavior it never observed.

The Remaining Ota Gap

Ota does not yet provide or claim a general, first-class proof that multiple consumers received semantically equivalent delivered inputs through different transformation paths.

That is the useful next refinement exposed by this failure class.

The mature shape is not a maintainer-authored inputs_match: true. It is runner-authored evidence that records:

the canonical input identity
each consumer and delivered representation identity
the transformation or producer identity for each representation
the equivalence rule that was actually evaluated
the result and any unresolved semantic boundary

Byte equality can prove exact representations match. Semantic equivalence needs a declared, reviewable comparator appropriate to the input type. If Ota cannot verify the transformation or delivery seam, it must not promote the result beyond the evidence it has.

This should extend Ota's existing replay, artifact-lineage, and proof-evidence model. It should not become a parallel trust system or a vague "generated by AI" label. The risk is not that a tool was
AI-generated. The risk is that operational trust was granted without evidence binding its inputs, execution, and effects.

A Failing Gate Must Be A Stop

There is also a governance consequence.

If delivered-input equivalence is required for a lane, discovering that the evidence is missing or contradictory must block that lane. A warning that everyone learns to ignore is documentation, not governance.

Any exception should be explicit, scoped, attributable, and preserved as evidence. It should not silently turn an unproved input path into an accepted one.

This is the standard Ota is built around:

Declare the execution truth once. Enforce the selected boundary. Preserve evidence of what actually happened. Refuse to claim what was not proved.

Bottom Line

Output parity can be useful evidence.

It is not input parity.

Before trusting the output of generated scripts, adapters, drivers, workflows, or ordinary handwritten tools, teams need to know that each consumer received the intended input through a traceable transformation path.

That is not extra metadata around execution. It is part of the execution contract itself.

Ota's job is to make that chain machine-readable, enforceable, and honest enough that developers, CI systems, and AI agents do not have to infer trust from a green command and a plausible file.

Originally posted: https://ota.run/blog/output-parity-is-not-input-parity-what-execution-evidence-must-bind

Pressure-testing Ota on Dagger: generated SDK lineage and bounded engine truth

Bobai Kaeto — Fri, 04 Sep 2026 11:18:15 +0000

Overview

Dagger is a useful pressure repository because it already has a strong execution model. Its SDKs are generated from a shared API surface, its CLI starts a Docker-backed engine, and a generated-source change has consequences beyond the command that wrote it.

The useful Ota question is narrow: can Ota govern one generated TypeScript SDK closure from declared source inputs, through the generator, to a committed and replayable output without pretending to govern every Dagger SDK, engine operation, or release artifact?

This note records the Ota contract and pressure boundary. It is intentionally a slice proof, not a claim that Dagger is globally ready or that Ota controls Dagger's managed engine.

Why this repo mattered

Generated source is easy to under-model. A CI step can run a generator and exit green while the repository still carries stale output, or while a later consumer has never actually seen the generated files.

The selected Dagger shape is small enough to prove honestly:

one source-managed Dagger CLI;
one generator for the TypeScript SDK client;
one declared generated-source artifact;
one consumer that detects an uncommitted generated diff; and
one promoted replay consumer that checks the reviewed baseline without regenerating it.

That is enough to test lineage and replay authority without converting a selected SDK path into a claim about Dagger's complete code-generation or release system.

What the contract models

The contract pins released Ota and declares the minimum compatible version. It models the generated output as a first-class artifact:

artifacts:
  typescript-sdk-client:
    kind: generated_source
    producer: sdk:generate
    paths:
      - sdk/typescript/src/api
    inputs:
      - dagger.json
      - toolchains/typescript-sdk-dev/ts-sdk.dang
    replay:
      authority_manifest: replay/typescript-sdk-client.ota.json
      consumption: verify_unchanged

tasks:
  sdk:check-generated:
    depends_on:
      - sdk:generate
    requires_artifacts:
      - typescript-sdk-client

The producer invokes the declared Dagger release asset. The ordinary consumer depends on the producer and rejects a generated diff. The promoted consumer has no generation dependency; it must consume only the explicitly promoted authority and then verify the same output directory.

The contract assigns Ota ownership of selected tool fulfillment, contract closure, output lineage, replay admission, and receipt evidence when those stages are reached. Dagger owns the meaning of the generator, its engine lifecycle, and the module orchestration inside that engine.

What Ota pressure exposed

The first pressure path exposed a real Ota runner defect: the declared Dagger release asset was fulfilled and version-checked, but native shell execution did not preserve the managed PATH when the generator started. The contract had named the correct tool; the runner failed to carry that truth into execution.

The fix belongs in Ota, not in Dagger-specific shell glue. Native shell execution now receives the resolved managed PATH, with regression coverage for the source-managed command path.

The same pressure also sharpened the engine boundary. Dagger starts an engine through Docker and performs package and module resolution inside that managed runtime. Ota can declare and verify the Dagger CLI and Docker requirement, but it does not independently attest the engine's internal package index, module image, or all external state used by the generator. Those facts remain bounded rather than silently promoted to repository proof.

Pressure design

The pressure workflow is deliberately staged. Ota must establish contract truth and admission before the repository's generator is allowed to start; generation, receipt capture, and replay are separate intended stages rather than one undifferentiated green check. This design is not itself matrix evidence.

Intended stage	Intended evidence
Contract and discovery	`ota validate`, `ota tasks --use`, and `ota tasks --safe --use`
Admission	Generated SDK task and workflow dry-runs before execution
Generation	`sdk:generate` plus `sdk:check-generated` over the selected TypeScript API directory
Fulfillment	Dagger `v0.21.7` release-asset resolution and version probe
Receipt	Archived selected-workflow execution evidence
Replay	Explicit record, explicit promotion, promoted consumer, and no-regeneration diff check
Diagnosis	`ota doctor` on the fulfilled and promoted paths

The workflow installs Ota from the contract's released source, not from a branch or implementation revision. The generated SDK lane and promoted replay lane also remain separate: recording creates evidence, promotion selects it, and replay consumes that selection without falling back to the latest local receipt.

What the run established

The released-source pressure run
contains one Ubuntu job and concluded with failure. It is not Linux/macOS/Windows matrix evidence. The run is bound to exact Dagger revision 3ffcd68bad1a52011c3f08f390c0093a1e0b9787. Its retained GitHub job logs establish only the successful stages reached before that failure:

the repository installed Ota from its declared released source;
the contract validated without warnings;
runnable and agent-safe surfaces were inspectable;
the generated SDK task and workflow could be previewed; and
workflow preparation completed before the Dagger-managed generator started.

Execution then stopped inside Dagger's managed engine. Its package resolver could not satisfy the engine-internal protobuf-dev~32 constraint from the configured repositories. This is useful pressure evidence: the contract made the boundary visible and Ota stopped at the Dagger-managed runtime failure instead of converting a partial run into generated-source or replay proof.

The generator, receipt, promotion, and replay stages were not reached. They are therefore not claimed as exercised by this run.

What this does not prove

The selected lane does not prove:

every Dagger SDK or generated language client;
Dagger documentation generation or release artifacts;
the health, package index, module image, or internal state of the Dagger-managed engine;
production Docker policy, registry credentials, or deployment behavior;
cross-platform or repeated matrix behavior; or
repository-global correctness beyond the selected generated TypeScript SDK closure.

When exercised, promoted replay would not prove application correctness. It would prove only that the explicitly selected authority and output identity were consumed without the producer closure. This run did not reach that stage, and a future green replay lane would not remove the engine,release, or broader-repository boundaries above.

Uncovered material behavior

Contract-owned and exercised

released Ota bootstrap;
Dagger release-asset fulfillment and version checking;
contract validation and task/workflow admission; and
workflow preparation before the Dagger-managed generator started.

Contract-owned but not reached

the selected generated TypeScript SDK producer and consumer closure;
generated-output lineage and committed-diff detection;
explicit replay recording and promotion; and
promoted replay consumption without regeneration.

Repository- or runtime-owned

Dagger engine lifecycle and internal package/module resolution;
Docker daemon policy and image availability;
other SDKs, documentation, release, and deployment workflows;
GitHub triggers, permissions, credentials, runners, and artifact retention; and
Linux, macOS, Windows, and repeated-run matrix behavior.

Ota platform gaps

The earlier pressure path exposed and led to the repair of Ota's managed-PATH runner defect. The final released-source run exposed no additional Ota platform gap; it stopped at the bounded Dagger-managed engine dependency described above. If a later run shows that Ota cannot model a material Dagger boundary cleanly, that result belongs in a named widening opportunity rather than a repository-local helper or an over-broad proof claim.

A Protected Runner Is Not Approval: Pressure-Testing Ota's First Signed Authority Carrier

Bobai Kaeto — Wed, 02 Sep 2026 18:00:37 +0000

A runner label chooses a machine. It does not authorize a repository action.

GitHub Actions can route a job to a self-hosted runner. A label answers one useful question:

Which machine is eligible to receive this job?

It does not answer the question that matters for a heavier repository action:

Is this exact publish, migration, deployment, or other non-routine task authorized to run now?

Those are different boundaries. A workflow must not be able to create its own approval merely by asking for a more privileged runner.

Ota's first signed crossing-authority carrier is designed around that separation. The repository declares the governed lane. The workflow asks GitHub to schedule a protected runner. A separately managed authority source decides whether the exact lane may cross its boundary. Ota verifies that decision immediately before effects start and emits a fresh transaction record after it does.

We pressure-tested that model on a pre-provisioned Linux/x64 VPS runner. One live authorization executed and produced a retained archive. Three invalid-authority cases refused before the task ran. The result is not a general approval system. It is concrete evidence for a deliberately bounded carrier.

The flow under pressure

Repository contract selects governed lane
        |
Workflow requests a protected runner label
        |
Protected runner invokes `ota run ... --grant <id>`
        |
Ota verifies fixed authority state and exact semantic scope
        |
One fresh crossing transaction begins
        |
Selected task runs, then receipt and archive bind admission to outcome

Each layer retains its own job:

Layer	Owns	Does not own
Repository contract	Which lane requires a crossing	Trust keys, grants, bundle paths, or revocations
GitHub workflow	Scheduling, checkout, credentials, and provider policy	Authority issuance
Authority provisioner	Signed bundle, revocation, sequence state, and signing key	Repository task selection
Ota on the runner	Admission, scope verification, transaction, receipt, and archive	Issuing its own authority

That separation is the product value. GitHub still owns scheduling and platform controls. Ota adds repository-specific governance: a way to bind independently issued authority to the complete action the repository is about to execute.

What we tested

The pressure workflow verified the exact administrator-installed Ota binary against a root-owned full-commit and SHA-256 manifest before it checked authority. It then ran Ota's read-only hardening diagnostic as the unprivileged job user. Required observations had to pass: Linux/x64, non-root execution, no declared Docker host or common Docker socket, and valid fixed trust, bundle, and sequence records.

The four hosted scenarios ran against the same merged workflow revision:

Scenario	Result	What the evidence proves
Live grant	Passed	Exact-scope admission created a completed crossing transaction; the retained artifact contains the verified receipt archive and valid receipt history.
Expired grant	Passed	Dry-run and real execution refused with `crossing_grant_expired`; before/after checkout manifests matched.
Revoked grant	Passed	Dry-run and real execution refused with `crossing_grant_revoked`; before/after checkout manifests matched.
Out-of-scope grant	Passed	Dry-run and real execution refused with `crossing_grant_out_of_scope`; before/after checkout manifests matched.

The refusal cases are important. A green validate result or a rejected command alone would not establish the boundary. The pressure workflow retained typed refusal JSON, the human refusal output, and complete checkout manifests before and after both dry-run and real refusal. The selected scaffold
task never started.

What Ota verified before the live task ran

The repository contract names only an authority identifier:

governance:
  crossing_authority:
    authority_id: platform-release-authority

It does not contain the signing key, bundle location, trust-store path, or revocation state. Those live outside the checkout at fixed protected system paths:

/etc/ota/crossing-authorities.json
/var/lib/ota/crossing-authority.json
/var/lib/ota/crossing-authority-sequence.json

Before Ota admits the selected lane, the first carrier verifies the fixed authority binding and the signed bundle, then checks the grant's exact contract identity, complete selected execution scope, crossing family, classification, actor posture, expiry, revocation, and sequence/high-water state.

The scope is not a friendly task name. Changing dependencies, hooks, task effects, target platform, or execution selection changes the semantic scope identity. A standing grant for yesterday's publish lane cannot silently authorize a changed closure that happens to keep the same label.

Why the archive matters

A successful run needs more than an approval-looking log line.

For the live scenario, Ota created a fresh crossing transaction before the governed scaffold action, recorded its terminal success, and retained the receipt archive in the hosted artifact. Receipt history revalidated that archive rather than merely reporting that a file existed.

That gives a reviewer a linked chain:

declared governed lane
        -> verified signed authority and semantic scope
        -> fresh crossing transaction
        -> selected task outcome
        -> archive that re-derives the recorded scope

This is the gap Ota is intended to close. A provider can tell you that a workflow ran. Ota can preserve which repository action crossed a declared boundary, what authority admitted it, and what happened afterward.

What this does not prove

The correct claim is intentionally narrow:

The authority files were protected from the current Ota process under the observed filesystem
boundary, and Ota verified the selected crossing against them before work started.

The carrier reports this as current_process_filesystem_guarded. It does not prove:

provider-attested isolation between the job and an administrator;
absence of every possible escalation path, mount alias, metadata credential, or host-control endpoint;
a verified human, CI, or platform identity;
one-use authority or atomic broker consumption;
repository-global safety, application correctness, or prevention of raw-shell bypasses.

The runner's local inspection is diagnostic evidence. It cannot independently attest the whole provider boundary. A signed image or a protected label alone would not change that fact.

What came next

The VPS matrix closed the pressure gate for Ota's first signed-file carrier. V11.7 later added the separate broker-backed carrier, available in Ota v1.6.26 and later, and completed its bounded OSS
slice.

The completed broker path binds launcher attestation to the job, consumes a short-lived one-use work-unit lease atomically, retains terminal cleanup and archive evidence, and proves recovery on an independently administered hardened launcher. Provider attestation remains optional stronger hardening rather than a V11.7 completion requirement.

The useful and honest statement remains narrow: Ota can verify separately issued, exact-scope authority on a protected runner and produce transaction-bound evidence of execution or refusal. It does not call that provider isolation, verified human identity, raw-shell prevention, or a complete enterprise control plane.

For the operator layout and verification procedure, see the canonical Prebound Crossing Authority reference.

Originally posted here: https://ota.run/blog/a-protected-runner-is-not-an-approval-system-4q8m

Ota v1.6.27 Now Available: Effect-Bound Refusal Assurance

Bobai Kaeto — Tue, 01 Sep 2026 13:57:16 +0000

Idea

Ota v1.6.27 closes V12: effect-bound refusal assurance. It adds a deliberately narrow foundation for declaring a database-schema mutation, deriving its exact selected realization, and refusing before selected work begins. Provider execution remains disabled in this release.

The important boundary is exactness. Ota derives the selected contract attachment, resource, migration bytes, working directory, invocation origin, and, when policy is available, one command-scoped decision before its selected execution path begins. It can then report a refusal with execution_started: false rather than starting setup or rendering a workflow preview that describes the lane as runnable.

This is not a database executor, provider integration, or a claim that Ota has protected a database. It is a reviewed, machine-readable refusal boundary for one selected contract closure.

Feature

Typed effect declarations

Contracts can declare database_schema_mutation through a canonical resource binding, a typed effect definition, and an exact task attachment. Resource, consequence, attachment, evidence, and realization identities are separately content-addressed so the policy decision cannot flatten distinct sources or invocation origins into a broad task label.

Declared-only commands remain review truth, not execution authority. A command without an eligible typed realization cannot become runnable merely because it names the same conceptual effect.

Refusal before selected work

ota run, ota up, ota up --dry-run, runtime and lifecycle proof, CI checkout re-evaluation, and sandbox capability reporting share the typed-admission boundary. A selected typed denial is evaluated before Ota's selected setup, workflow environment rendering, proof artifacts, durable logs, services, dependencies, shell dispatch, or provider contact.

Blocked ota up --dry-run --json output retains the admitted non-secret application plan and available decision evidence. It contains only the refusal action, reports BLOCKED, and does not say that Ota would execute the selected command.

Explicit policy and canary evidence

Policy packs can evaluate exact typed-effect realizations with deterministic deny > warn > allow precedence. Typed lanes stay provider-disabled even when policy evaluates to allow or warn. An effect-refusal canary passes only for one eligible realization with an applicable explicit typed deny before execution starts; fallback and unrelated denials cannot turn into a passing control.

Private archive reconciliation

Operators can archive a workflow typed refusal explicitly. Ota re-derives the archived contract, selected closure, migration plan, policy snapshot, decision, typed-deny basis, and pre-execution posture before accepting it. Doctor promotes only the exact current workflow claim backed by valid private evidence; stale, task-only, ambiguous, invalid, equivalent-path, and opaque-path claims remain unknown.

ota contract effect-refusal-candidate is the first review-only bridge from that evidence back to contract authoring. Its schema-v5 candidate proposes one canary declaration as unknown, has no application projection, and remains non-writable through apply-candidate.

Detector and evidence improvements

GitHub Actions detection now retains canonical job and step working directories in source-bound task closure truth. Dynamic, noncanonical, missing, or escaping directories do not become runnable root-task claims. Named multiline verification steps remain complete ordered bodies and unresolved rather than being truncated into a promoted command.

The Core-owned pressure-evidence registry records each retained case's exact revisions, matrices, exercised surfaces, proven facts, and not_proved boundaries. The Site pressure index is generated from that registry; it is not a repository certification, endorsement, or badge wall.

Pressure and evidence

V12 retained immutable Linux and macOS controls for the exact selected boundaries, including typed run and up refusal, blocked preview construction, policy and CI re-evaluation, sandbox admission, canaries, archive history, Doctor fallback after tampering, and review-only candidate reconciliation. Final bounded real-repository matrices ran against forked Plausible and Outline revisions.

The evidence is tied to exact revisions and its limits are retained alongside the claims.

What this does not claim

v1.6.27 does not prove provider contact, authorization, or mutation behavior. It does not prove database migration success, rollback, correctness, or data integrity. It does not prove absence of arbitrary child processes, complete repository immutability, independently administered policy authority, positive execution receipts, positive assurance, public archive-export safety, or repository-wide readiness beyond the selected contract closure.

Those are not release-note caveats. They are boundaries that keep a refusal Ota witnessed distinct from an outcome it did not observe.

Docs

Use the live contract reference, policy-pack reference, andcommand reference for the current specification and operator flows. The pressure-testing index is the canonical registry for retained evidence and its limits.

Release

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

If you already use Ota, upgrade and verify:

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

The GitHub release contains the shipped binaries and checksums. Author only behavior your repository can review; a typed declaration is precise contract truth, not a reason to infer provider authority.

If you are evaluating Ota for the first time, v1.6.27 shows the standard the product is setting: a consequential repository operation can be declared precisely, evaluated against exact policy truth, and refused before selected work begins without claiming an outcome Ota did not observe.

Ota is not turning an effect declaration into execution authority. It is making the difference between declared intent, reviewed refusal, and proved outcome explicit enough for humans, CI, and agents to rely on.

Original posted here: https://ota.run/blog/ota-v1-6-27-release-essay

Pressure-testing Ota on EventCatalog: generated artifact lineage across sibling consumers

Bobai Kaeto — Fri, 28 Aug 2026 12:22:22 +0000

The finding

EventCatalog exposes a common monorepo failure mode: generated code may exist, its producer may be green, and the real downstream consumer can
still fail. Its Langium language server generates AST, grammar, module, and syntax files; a sibling VS Code extension consumes that output alongside the workspace SDK and visualiser.

The useful question is therefore not "did generation finish?" It is whether the repository can execute the complete consumer closure from declared dependency hydration through the package that needs the generated result.

The contract boundary

Ota models the generated output separately from the tasks that establish and consume it:

artifacts:
  language-server-ast:
    kind: generated_source
    producer: language-server:generate
    paths:
      - packages/language-server/src/generated/ast.ts
      - packages/language-server/src/generated/grammar.ts
      - packages/language-server/src/generated/module.ts
      - packages/language-server/syntaxes/ec.tmLanguage.json
      - packages/vscode-extension/syntaxes/ec.tmLanguage.json
    inputs:
      - packages/language-server/src/ec.langium
      - packages/language-server/langium-config.json

tasks:
  vscode-extension:build:
    depends_on:
      - language-server:generate
      - language-server:build
      - sdk:build
      - visualiser:build
    requires_artifacts:
      - language-server-ast

The setup task owns typed, frozen-lockfile pnpm hydration with the language-server package filter. That removes bespoke install shell glue without pretending the dependency path is harmless: it reaches the package registry, so the selected closure is intentionally not routine agent-safe execution. Humans and CI can run the declared verification workflow; unattended agents cannot
silently acquire that networked setup authority.

What Ota had to learn

This pressure case made two platform requirements concrete. Generated-source lineage had to remain visible at consumer admission and in execution evidence, rather than surfacing only after a build failure. And pnpm dependency hydration needed a package filter that could select a sibling package without collapsing the workspace into one opaque install-and-build command.

The resulting boundary is deliberately narrow. Ota knows which task produced the declared paths, which source inputs define that artifact, and which consumer requires it. A path merely existing is not a freshness claim, and this note does not treat it as one.

The released pressure run

Run 33167453142 passed against released Ota v1.6.26 at EventCatalog commit b593861fc84147884dcfcaf03898e490596927a0.

The native matrix ran on Ubuntu, macOS, and Windows. Each lane validated the contract, ran Doctor, listed runnable and agent-safe task surfaces, dry-ran both the consumer task and named workflow, executed the real VS Code-extension consumer closure, archived its receipt, and uploaded the resulting evidence. A separate Linux job ran ota proof runtime --workflow verify, archived the workflow receipt, and retained its proof artifact.

That is stronger than proving the generator alone: the final build consumes the generated source after Ota has resolved its producer, language-server compilation, SDK build, and visualiser build. The matrix pins the released Ota source through the contract and pins every GitHub Action revision to an immutable SHA.

Boundaries that remain

This is contract-owned and proved for one finite native language-server-to-extension build path. It does not prove the full EventCatalog workspace, every generated artifact, the semantic correctness of the generated language model, VS Code packaging or distribution, package publishing, releases, or deployment behavior.

The contract does not advertise container execution for this slice, so the three operating-system legs are native-only evidence. Package-registry availability remains an external dependency of the declared hydration lane. Those are explicit limits, not green-run implications.

Pressure-testing Ota on cloud.devenv.sh with Nix and devenv

Bobai Kaeto — Wed, 26 Aug 2026 16:32:15 +0000

Overview

cloud.devenv.sh is a useful Ota pressure case because its execution path crosses three distinct
ownership boundaries:

the host provides nix
Nix launches a pinned devenv revision
devenv owns the repository's test and up subcommands

A weak contract would flatten that into an opaque shell command. The stronger model preserves who
owns each layer and lets Ota select the repository operation without pretending to own devenv's
internal process semantics.

The immutable hosted matrix at repository revision
29c44c235795d3af3b1b7eafdaacd63a416d1f06
completed successfully on Ubuntu and macOS with released Ota v1.6.26. The result proved the
modeled boundary, but it also exposed an important limit: a green orchestrator exit is not proof
that every nested process succeeded.

Evidence snapshot

The hosted workflow run
used:

cloud.devenv.sh revision 29c44c235795d3af3b1b7eafdaacd63a416d1f06
Ota v1.6.26 source revision 08855fd1b7269abe9342dc9dd45acf4ed1885063
contract-pinned devenv launcher revision 65a7c40d185350f0e96783b3dd8d4afab3bb7034
Ubuntu binary SHA-256 3d545be8eb9701542284d28bb89fba83c77ae30c1d1157d9dd87fb83d961e05e
macOS binary SHA-256 a2448590b0fedfeaffd29535103d5209856e3b0fcb42a93d0f47256920b58a79

Both jobs validated the contract with zero errors and warnings, inspected Doctor's deterministic
fix preview, listed the public task surface, exported execution topology, and dry-ran test,
verify, dev, and the verify workflow. The contract intentionally declares no agent-safe task,
and the retained output confirmed that ota tasks --safe --json returned an empty list.

Doctor did not call the repository ready. Its retained fix preview reported verdict: risky and
agent_verdict: not_ready because .ota/state/, .ota/contracts/, .ota/receipts/, and
.ota/proof/ were not ignored by Git. The workflow intentionally accepted that advisory posture;
its green status must not be read as an agent-readiness verdict.

The Ubuntu job additionally executed the finite test task through Ota. The macOS job did not run
that real task; it proved only validation, discovery, topology, Doctor, and dry-run admission.

The contract boundary

The contract keeps launcher ownership explicit:

orchestrators:
  devenv:
    kind: devenv
    required: true
    config_files:
      - devenv.nix
    launcher:
      exe: nix
      args:
        - run
        - github:cachix/devenv/65a7c40d185350f0e96783b3dd8d4afab3bb7034#devenv
        - --

The repository's verification command remains a direct devenv subcommand:

tasks:
  test:
    command:
      exe: test
    execution:
      orchestrator:
        ref: devenv
        mode: subcommand

The long-running development path uses the same owner without being mislabeled as finite work:

tasks:
  dev:
    launch:
      kind: command
      exe: up
    execution:
      orchestrator:
        ref: devenv
        mode: subcommand

This separation gives Ota enough structure to explain and select the path while leaving devenv
responsible for the process graph it launches.

What the hosted matrix proved

The retained artifacts and logs prove that:

released Ota v1.6.26 loaded and validated the immutable contract on Ubuntu and macOS
Ota resolved nix as the host requirement and the pinned devenv invocation as orchestrator truth
task discovery preserved finite test, aggregate verify, and long-running dev as distinct lanes
Doctor preserved the repository-hygiene warning and not_ready agent verdict
all advertised native lanes admitted dry-run on both operating systems
the Ubuntu job executed ota run test --native --stream and Ota reported success after devenv returned exit code zero
the Ubuntu run stopped the devenv-managed processes before Ota emitted its successful run summary

This is execution evidence for one selected Ubuntu task. It is not runtime proof, lifecycle proof,
or evidence that every repository behavior was governed.

The green run exposed a real boundary

During the Ubuntu task, devenv logged that backend-migrate failed because
cloud.devenv.toml was missing. Other work continued, the frontend build completed, and devenv
eventually printed Tests passed :) and returned zero. Ota therefore reported the selected task as
successful.

That is faithful to the current contract: Ota invokes the selected orchestrator operation and
uses its terminal result. It does not independently reinterpret every nested devenv process log.
The matrix consequently proves that Ota executed the declared boundary, not that every internal
devenv process completed successfully.

The task also modified four tracked files:

devenv.lock
frontend/elm-srcs.nix
frontend/generated-api/.openapi-generator/VERSION
frontend/generated-api/README.md

Those mutations are part of the observed repository behavior. The run did not assert that the
worktree remained clean, so the note must not turn its green status into a non-mutation claim.

Uncovered material behavior

The pressure result classifies the remaining behavior explicitly.

Contract-owned and proved

native contract validation on Ubuntu and macOS
task, workflow, and execution-topology discovery
Doctor and Doctor fix-preview output, including the retained not_ready agent verdict
native dry-run admission for test, verify, and dev
real Ubuntu execution of the selected test task through the pinned Nix/devenv launcher

Explicitly bounded as not proved

real task execution on macOS
successful completion of every nested devenv process
lifecycle readiness and teardown assertions for dev
container and Windows execution
deployment, production readiness, and repository-global governance
a clean worktree after verification

Repo-owned outside this pressure slice

the internal devenv process graph and its terminal acceptance semantics
whether generated files should be committed, ignored, or checked for drift
the missing cloud.devenv.toml configuration expected by backend-migrate

Ota platform gap

Ota does not currently receive structured nested-process outcomes from the devenv adapter. It can
govern the selected orchestrator operation and report its exit status, but it cannot prove that all
material child processes succeeded when the orchestrator itself returns zero. A stronger future
carrier would need typed nested outcome evidence rather than log scraping.

Why this pressure case matters

The result is useful precisely because it is not a staged perfect success.

Ota correctly preserved the Nix/devenv ownership boundary and executed the selected finite lane.
The same run then showed where that evidence stops. That distinction is the product: a green outer
command should never silently expand into a claim about nested work Ota did not independently
witness.

Links

Originally Posted: https://ota.run/blog/pressure-testing-ota-on-cloud-devenv-sh-4q1n

Ota v1.6.26 Now Available: Protected Execution Foundations and Receipt History

Bobai Kaeto — Mon, 17 Aug 2026 13:29:24 +0000

Idea

v1.6.26 closes the bounded V11.7 OSS audited-crossing slice.

Prior releases built execution governance: what should run, what closure to consume, when replay is allowed, whether cleanup was witnessed. The next boundary was authority: who decides whether work executes, and how do downstream consumers verify that decision independently?

v1.6.26 addresses this through the Linux systemd protected launcher. The release does not attempt provider attestation or cross-organization trust separation. Instead, it establishes a bounded first-class path where:

the contract specifies whether execution is allowed or explicitly disabled
the launcher independently attests each boundary before Ota processes an authorization request
the crossing evidence chain becomes explicit and re-verifiable through receipt history
receipt history immutably records each decision and persists independent archives
operator-driven recovery preserves exact evidence through failures and reboots

The evidence is locally-bounded: independently administered Linux/x64 systemd production pressure proves the consumer-only positive path, while separately verified crash/reboot recovery preserves evidence through failures. Provider attestation remains open.

Feature

1. Closed the bounded V11.7 OSS audited-crossing slice

v1.6.26 completes the production-client and independently administered hardened-launcher acceptance branches.

Immutable Linux/x64 PID 1 runs 31939777636 and 31953535665 prove:

Production client with protected receipt history, one-use selected execution, and terminal cleanup
Exact archive reconciliation and administrator-driven reboot/fault recovery
Repository state unchanged, complete terminal cleanup, zero invalid protected archives

Provider attestation remains optional stronger hardening rather than an implied V11.7 requirement. Contract-authored governance.crossing_requirements is explicitly deferred to follow-on work.

2. Production protected receipt-history Core surface

ota receipt --history --source systemd_protected_launcher adds immutable receipt history anchored to the Linux systemd launcher:

ota receipt --history --source systemd_protected_launcher --json
ota receipt --history --source systemd_protected_launcher --archive-identity sha256:<hash>

The bounded manifest binds:

Admitted non-agent operator profile and live peer
Repository and catalog identities
Three content-addressed objects per entry: receipt archive, immutable contract snapshot, launcher-finalization sidecar

Core reconstructs exact bytes and applies existing semantic archive verifier. Optional --archive-identity selects one exact archive without exposing protected paths.

Local history remains default and now publishes explicit source and completeness posture in text and JSON.

Immutable Linux/x64 PID 1 run 31823037642 proves the installed production invocation client and protected-history source against exact Protocol, Core, and Launcher revisions with one valid protected archive, zero invalid archives, unchanged refusal worktrees, and no private signing material.

3. Execution-disabled systemd-launcher posture gate

The release adds bounded execution-disabled foundations through the protected launcher.

Core verifies signed V3 systemd launcher and job-principal attestation, but the launcher deliberately withholds authorization before exact scope, cgroup, child, and active-slot cleanup. The result is:

posture_admitted_before_authorization_boundary_removed typed refusal
Zero selected work, lease consumption, receipt, or archive
Exact terminal cleanup preserved

Immutable Linux/x64 PID 1 runs 31561247605 and 31389237232/31389713244 prove execution-disabled allowed, denied, stale, wrong-scope, protected-installation/runtime drift, missing-credential, and crash-recovery paths with independently re-verifiable public signed decision/relay identities.

4. Protected systemd V3 one-use lease consumption

After exact admission, the launcher atomically consumes a signed lease from the broker before spawning work:

One-use leases are consumed only once; reuse is cryptographically refused
Core binds pending transaction posture to private persistence
Launcher persists consume intent before relay and records signed response

Immutable Linux/x64 PID 1 systemd run 31631358796 proves one-use consumption, identical-lease already_consumed refusal, crash recovery, byte-identical repository state, and zero terminal slots/scopes.

5. Selected execution and receipt archives

Once the lease is consumed, Core may execute only the frozen work unit:

ota run <task> --grant <crossing_authority_id>

The launcher persists completion evidence before Core exits, verifies child reaped and scope removed, and persists launcher-owned finalization. Core then independently verifies both launcher signatures and every identity relationship.

Immutable Linux/x64 PID 1 pressure run 31664495937 proves completed, failed, interrupted, replay-refused, and crash-recovered selected execution with exact child, scope, cgroup, and active-slot cleanup.

V3 receipt archives accept only launcher-active-slot transactions. Receipt history preserves the carrier distinction and refuses to reinterpret legacy broker or signed-file carriers as V3.

6. Portable launcher finalization

v1.6.26 adds the portable protected-systemd launcher-finalization path.

New launcher-owned crossing transaction schema v3 is bound into the signed consume exchange and requires broker-archive schema v2 plus portable finalization verification. Historical transaction v2 and broker-archive v1 evidence retain original compatibility.

The launcher retains protected post-cleanup recovery state until the client acknowledges a producer-signed sidecar binding exact cleanup evidence, receipt-archive identity, and crossing transaction. Core durably publishes the exact execution receipt archive before emitting launcher completion. The root launcher reopens that private archive through the execution-principal repository descriptor, requires exact owner, content, and transaction identity, and atomically publishes the root-owned sidecar; the job principal only acknowledges it.

Signed profile bindings include CAP_DAC_OVERRIDE in the exact bounding set, solely so the root launcher can traverse private hierarchies inside its protected mount namespace.

Immutable PID 1 crash pressure and the production operator client are included in the released
bounded carrier; stronger provider-attested separation remains a follow-on boundary.

7. Honest launcher crash-recovery evidence

Live systemd finalization keeps directly observed exit and child-reaped posture; restart recovery uses signed finalization schema v2 with recovered_absent_completion_bound, verified child absence, and no claimed observed exit or reaping. Receipt history re-verifies either exact version without upgrading legacy evidence.

Immutable Linux/x64 PID 1 run 31758094819 proves the corrected portable-finalization path, one-use consumption, exact crash recovery, and valid archive history.

8. Refined active-execution admission

v1.6.26 refines native service listener conflicts around actual resource ownership:

Fixed or Ota-managed dynamic listeners: Long-running tasks bind fixed, Ota-managed dynamic, isolated, or unresolved runtime listeners across their complete execution closure, including hooks.
Native and container coexistence: Services can coexist when their projected host endpoints and effective write namespaces are disjoint.
Ancestor/descendant path conflicts: Shared write and env-materialization paths now conflict on ancestor/descendant overlap, not exact text only.
ota run <task> --host-port <port>: Directs native service execution. Container and Compose lanes remap only the host publication; direct native lanes apply the port to both canonical bind and projected host endpoint. Ota reprojects typed launch arguments and runtime environment values.
Clear conflict reporting: "Host port already in use" now names requested and active execution modes plus endpoint owner, suggests truthful --host-port <free port> rerun, and preserves existing run-summary layout with additive Reason and Host port rows.

9. Fixed interactive native task closures

The release fixes interactive native task closures so typed hydration and bootstrap phases retain Ota's canonical 🦦 loader instead of inheriting terminal ownership from a later interactive command.

On Unix, Ctrl-C now terminates Ota's complete native child process group and waits for it to settle before emitting the interrupted summary, preventing late npm output after Ota reports completion.

Native task progress loaders now show selected execution class explicitly, for example Running setup:dev (native), matching existing container and remote labels.

10. Schema embedment and version pinning

v1.6.26 removes the source checkout's absolute CARGO_MANIFEST_DIR from production schema discovery. Published JSON schemas are now embedded into the Ota binary, so installed or relocated source builds validate machine output against their exact version-matched schema set without a source checkout or compiler-path dependency.

The release also emits the full 40-character source commit from ota --version --json so protected deployment evidence can bind the installed Core binary to one exact source revision.

11. Wildcard tool-version handling

Treat wildcard (*) task tool and runtime requirements as executable-availability requirements when a present command does not expose parseable version output. Pinned requirements still fail closed when Ota cannot establish the installed version.

This keeps POSIX sh tasks portable to Debian and Ubuntu systems where dash --version exits nonzero without weakening version pins.

12. Compatibility-preserving profile support

Add compatibility-preserving support for the separated-producer ota.authority-launcher.systemd/v2 profile. V3 broker bindings and the published receipt schema require an exact registered profile-ID/identity pair. Legacy V1 evidence remains verifiable but cannot be relabelled as V2. Complete ota.authority-launcher.systemd/v3 and ota.authority-job-principal.systemd/v2 verification branches re-derive ordered launcher and job-principal observations, nested identities, protected socket source, and limited-primary-group posture from signed evidence.

Boundaries

The most important v1.6.26 behaviors are what it qualifies and refuses to imply:

execution-disabled posture proves no work runs, not that the launcher is trustworthy
protected receipt history proves exact archive binding, not system-level secret protection
launcher crash recovery preserves evidence through failures, not immunity from crashes
locally-bounded independently administered pressure proves consumer-only operation, not provider attestation or cross-organization trust
V3 receipt archives accept only launcher-active-slot transactions; legacy carriers remain in their original branches
one-use lease consumption prevents duplicate execution within a transaction; it does not prevent replay across different invocations
a successful protected execution does not prove downstream deployment or production health

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

Docs

Use the live references for protected execution, receipt history, and crossing-evidence semantics:

Release

Install or upgrade to the released version, then inspect the contract and protected-execution surface:

ota upgrade
ota --version --json
ota validate
ota doctor --json
ota tasks --safe --use

For protected execution and receipt history:

ota receipt --history --source systemd_protected_launcher --json
ota run <task> --dry-run --json
ota run <task> --grant <crossing_authority_id> --dry-run --json

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

v1.6.26 closes the bounded V11.7 OSS audited-crossing slice through locally-bounded protected-launcher foundations: not only what should run and what proof exists, but which boundaries admitted it, how launcher isolation prevented unauthorized work, and what immutable receipt archives capture each decision through recovery scenarios. Provider attestation and cross-organization trust separation remain open for follow-on work.

Pressure and Evidence

The entire protected-execution stack was shaped by production pressure on isolated Linux/x64 systems:

Installation and runtime drift: Invalid credentials and launcher-startup failures preserve zero selected work.
One-use lease consumption: Identical lease-reuse is cryptographically refused; fresh invocations require fresh authorization.
Crash recovery and restart scenarios: Launcher crash pressure and administrator-driven reboot recovery preserve exact evidence through multiple transitions.
Execution-disabled posture: Core admits the contract, but the launcher withholds authorization and emits a typed refusal with exact scope, cgroup, and child cleanup.
Receipt history and archive verification: Protected receipt history verifies exact archive, contract snapshot, and finalization sidecar identities without exposing private paths.

All evidence is immutable Linux/x64 hosted proof bound to exact Core, Launcher, and Protocol revisions. Independently administered Linux/x64 PID 1 production pressure (runs 31939777636, 31823037642, 31953535665) proves the consumer-only positive path and administrator-driven recovery branches.

Provider attestation and cross-organization trust remain open as stronger follow-on boundaries. The
independently administered launcher, portable finalization, and operator attachment surfaces are
part of the released bounded carrier.

The complete bounded V11.7 OSS slice is live. Follow-on work includes contract-authored governance.crossing_requirements, provider-attested separation, and broader multi-system authority delegation.

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