DEV Community: Ota

Pressure-testing Ota on Grafana: bounded Go proof and a staged Compose slice

Bobai Kato — Wed, 05 Aug 2026 17:37:56 +0000

Overview

Grafana is a large mixed repository. Its upstream CI spans sharded backend and frontend tests,
multiple databases, end-to-end paths, release builds, and a Tilt-owned development environment.

That makes it a useful pressure target precisely because a plausible-looking single verify
command would be dishonest.

The Ota 1.6.25 contract owns two specific surfaces:

a Go package build path rooted at ./pkg/...;
a separately declared Compose dependency slice for PostgreSQL, Prometheus, Loki, and Tempo.

Everything else remains outside the claim.

The Contract

The backend proof is intentionally narrow. Ota hydrates Go modules, then runs the named package
build rather than guessing at Grafana's full sharded test matrix:

tasks:
  setup:
    prepare:
      kind: dependency_hydration
      medium: package_dependencies
      source:
        kind: go_modules

  build:backend:pkg:
    command:
      exe: go
      args: [build, ./pkg/...]
    depends_on: [setup]

workflows:
  proof:backend:pkg:
    setup:
      task: setup
    run:
      task: build:backend:pkg

The Go range is also honest about the claimed lane:

>=1.26.3 <1.27, not an artificial patch pin;
native and ephemeral-container modes for the package build;
no claim that this range proves every Grafana build or test path.

The named lane matters. build:backend:pkg says what it owns. A generic build or verify
would blur frontend, release, and backend truth in a repository where those are different paths.

The Compose Boundary

The development workflow is equally bounded. Grafana's frontend-service environment uses more than
the four observability dependencies in this contract, including application and proxy behavior
owned by Tilt. Ota therefore models only the selected Compose services:

tasks:
  devenv:observability:up:
    compose:
      kind: up
      services: [postgres, prometheus, loki, tempo]
    effects:
      network: true
      network_kind: container_image_hydration

Ota captures the Compose adapter inputs, starts only that selection, inspects it with a separate
safe status task, archives a receipt, and stops it again. This is not a claim that Grafana itself,
its frontend, its proxy, or its Tilt orchestration became ready.

Released Install Truth

The pressure matrix consumes the Ota version declared in the contract:

metadata:
  ota:
    minimum_version: "1.6.25"

agent:
  bootstrap:
    ota:
      source:
        kind: version
        version: v1.6.25

The GitHub workflow installs via ota-run/setup with source: contract, checks that the installed
binary is exactly v1.6.25, and retains the version record, topology, receipts, and proof output
for seven days on every result. The workflow actions themselves are pinned to immutable revisions.

What The Matrix Covers

The v1.6.25 requalification matrix covers:

contract validation, Doctor, task discovery, safe-task discovery, workflow discovery, and execution-topology export on Ubuntu, macOS, and Windows;
native task and workflow dry-runs across that matrix;
container task and workflow dry-runs on Ubuntu;
real native and ephemeral-container execution of the selected Go build on Ubuntu;
real start, safe status inspection, archived receipt, receipt diff, and stop for the selected observability Compose dependencies on Ubuntu.

The released-v1.6.25 requalification is green: Grafana matrix run
30965322618. All three legs
recorded ota v1.6.25 at source commit a3e9f98f3. The Ubuntu evidence also retains the Compose
receipt and its unchanged baseline comparison, including the selected image digests. That comparison
is witness-only: it does not execute a replay or establish hermeticity.

What It Does Not Prove

This is selected-lane evidence, not a Grafana-wide readiness verdict. It does not prove:

Grafana's sharded backend unit, integration, frontend, E2E, or release workflows;
application readiness, user-visible dashboards, API correctness, or migration behavior;
the Tilt-managed frontend-service application, proxy, or lifecycle;
Docker Desktop behavior on macOS or Windows;
registry availability, external services, or host capacity beyond each selected execution.

The material uncovered behavior is therefore explicitly repo-owned or unproved, not silently
absorbed into a green label.

Why Heavier Repository Execution Needs Audited Boundary Crossings

Bobai Kato — Mon, 03 Aug 2026 12:03:38 +0000

Safe by default is only half the execution-governance problem

A repository needs a routine execution lane.

That lane should cover the work developers, CI systems, and AI agents perform repeatedly:

lint
test
bounded verification
local readiness checks
finite generated-output checks

But serious repositories also have heavier lanes:

publish a package
run a migration
deploy an environment
modify external state
execute a destructive recovery
call a black-box production dependency

Pretending those lanes should never run is not governance.

Treating them like routine verification is not governance either.

Ota's position is that leaving the default-safe lane should become an explicit, auditable execution
event.

That event is a boundary crossing.

A crossing is not the same as a refusal

Agent safety and audited crossings solve different problems.

Agent mode answers:

Is this complete task or workflow closure safe for an agent to execute?

If the answer is no, Ota refuses it before selected work begins.

Audited crossing answers:

This heavier non-agent lane may be allowed, but what boundary was crossed, why was it crossed, and
what execution evidence belongs to that decision?

A grant must never turn an agent-unsafe lane into an agent-safe one. Crossing is not a bypass around
safe-task enforcement.

It is a separate governance path for allowed-but-non-routine non-agent execution.

What Ota publishes today

Ota's released governance and receipt surfaces can distinguish routine execution from a selected
lane that requires a crossing.

The important fields are:

crossing_required
crossing_classification
runner-authored crossing evidence linked to the selected execution

For example, current governance JSON can make the boundary visible before execution:

{
  "crossing_required": true,
  "crossing_classification": "escalated",
  "crossing_boundary_family": "unsafe_task"
}

That is a governance decision, not approval and not evidence that the task ran. Agent-mode safety
still decides whether the selected closure is callable by an agent.

The released classification distinguishes routine posture from escalated posture. Ota does not
publish an exceptional machine classification today.

The crossing record belongs to one execution. It is evidence that the boundary was crossed. It is
not reusable approval authority for the next run.

That separation matters:

authority answers whether this execution may cross
the crossing record says what actually crossed
the receipt links the decision to execution outcome

Reusing a crossing record as authority would let yesterday's evidence authorize tomorrow's work.
Ota rejects that model.

The stronger authority carrier is implemented but still in development

On the 1.6.26-implementation branch, Core implements the first preview signed-authority carrier.
V11.7 remains partial because that carrier has not completed its live-grant pressure bar and the
separate one-use broker carrier remains planned.

The preview contract names an independently managed authority:

governance:
  crossing_authority:
    authority_id: platform-release-authority

The repository does not carry the trust key, signed bundle path, revocation state, or sequence
state.

That is deliberate. If the caller can edit both the lane and the authority that approves it, the
approval is self-issued.

The preview invocation is:

ota run publish --grant approved-publish

The current preview admission binds the grant to:

the exact semantic contract identity
the complete selected task or workflow closure
the crossing family and classification
bounded actor posture
mode, lifecycle, target platform, and declared effects
a short validity window
current signed revocation and sequence truth

A missing, stale, revoked, rolled-back, or out-of-scope grant must refuse before the selected lane
starts.

Real admitted execution must create a fresh runner-owned crossing transaction before selected-lane
mutation and finalize that transaction on success, failure, interruption, or recoverable
abandonment. Dry-run and refusal must not mint a crossing record.

The first carrier is deliberately bounded as current_process_filesystem_guarded. It verifies a
fixed system trust binding, signed bundle, revocation state, and sequence state protected from the
current unprivileged Ota process. It does not prove provider-attested privilege separation or a
verified human, CI, or platform identity.

What is not complete yet

This signed authority surface is implemented in Core, but it is not released or complete.

GitHub-hosted create-chrome-extension pressure
already proves that missing fixed authority refuses before selected work. That is useful fail-closed
evidence, but it does not prove that a live grant is protected from the job that consumes it.

The remaining gates include:

valid, expired, revoked, and out-of-scope live-grant pressure on a pre-provisioned hardened non-root runner
a broker-backed, atomically consumed one-use work-unit lifetime
independently authenticated per-use transaction state beyond same-user local reconciliation
broader protected-system authority support across platforms

Those are trust boundaries, not documentation polish.

Until they close, Ota should describe the grant carrier as active development, not as shipped
enterprise approval infrastructure.

The durable design rule

The mature model is:

for the bounded signed-file carrier, reuse a still-live grant only while its exact scope remains valid
for the planned broker carrier, issue and atomically consume one lease for one exact crossing
never reuse the crossing record
mint fresh runner-authored crossing evidence for every execution
recheck grant liveness at the boundary
keep principal, authorizer, and runner context separate
refuse when Ota cannot verify the authority it would need to make the stronger claim

That keeps routine work cheap and makes non-routine execution explicit without turning every command
into approval ceremony.

It also gives reviewers a better artifact than a log line saying someone ran deploy.

Why this matters for Ota

Execution governance cannot stop at "allowed" and "denied."

Real repositories need a third answer:

allowed only through an explicit, attributable, bounded crossing

Ota already makes the crossing visible. The active authority work is about making admission
trustworthy without letting the repository or caller approve itself.

That is the difference between recording that a risky command ran and governing how it was allowed
to run.

Where does your repository record that distinction today: a workflow approval, a ticket, a CI log,
or nowhere?

References

Originally posted here: https://ota.run/blog/why-heavier-repository-execution-needs-audited-boundary-crossings

One Contract, Multiple Enforcement Points for Safe AI Agent Execution

Bobai Kato — Thu, 30 Jul 2026 16:20:35 +0000

Overview

A lot of AI agent safety discussion still stops too early.

People talk about:

prompts
instructions
guardrails
whether the agent "knows better"

Those things matter, but they are not where the real control lives.

If an agent can ignore the instructions, pick the wrong execution path, skip the real verification
lane, or claim success without independent evidence, then the repo does not have enforcement.

It has suggestions.

That is why the stronger shape is not "better prompting."

It is:

one declared contract
multiple enforcement points
no second hand-maintained execution policy

Ota provides the declared repo contract and local execution boundary. CI projection and runtime
providers can consume that truth, but they do not become competing execution contracts. A provider
still owns its triggers, credentials, runner selection, deployment policy, and branch-protection
settings. Ota owns the contract-derived execution lane, its admission, and the evidence it can
honestly emit about that lane.

The Local Runner Is Useful. It Is Not The Final Teeth.

A local runner is valuable because it gives fast feedback.

It can tell an agent:

this task is safe
this workflow is not callable
this path is blocked
this repo is not ready

That is already much stronger than a plain instruction file.

But a local runner is still optional.

If one team uses the contract-aware runner and another team points a different agent at the same
repo, local enforcement alone does not scale. The same is true if someone simply bypasses the
preferred agent flow and uses a different tool.

That makes the local runner the fast-feedback layer, not the final teeth.

Its job is:

early refusal
early visibility
local proof and receipts
safer routine execution before review

That is important. It is just not the last enforcement boundary.

The Real Teeth Live At Mandatory Chokepoints

The durable version is when an organization makes contract-owned lanes mandatory at the places
people cannot opt out of.

That means:

Ota projects the declared CI verification lane
branch policy makes that check required at merge time
an identified runtime provider applies the compatible capability and sandbox controls at execution time

Those chokepoints do not care which agent was used.

They do not care which local runner someone prefers.

They sit at the points the organization already relies on to keep human changes and automated
changes inside the same review and execution boundary.

So the stronger stack is:

ota.yaml as the declared spec
local runner enforcement for immediate feedback
contract-owned CI checks, made mandatory by provider branch policy
runtime capability boundaries, only where the selected provider can apply and attest them

That is the difference between repo guidance and repo governance.

Why CI Comes First

If you want to move higher in the stack, CI is the first practical enforcement point that can be
made mandatory.

Why?

Because the merge gate already exists.

Most teams already have:

CI runs
required checks
branch protection
some notion of mergeability

Once provider branch policy requires the contract-owned check, CI becomes the first non-optional
place where repo truth can become enforcement instead of convention.

What CI should answer is not:

did a random workflow happen to pass

It should answer:

did the repo's declared merge-relevant verification lanes pass
is the required proof present
did the execution path stay inside contract-owned governance truth

A green required CI check should mean:

this change is merge-compliant with the repo contract.

That is a much stronger statement than:

someone ran something and the job happened to go green.

A Green Check Is Not A Runtime Boundary

CI is the right first gate, but it is not the whole answer.

CI can tell you:

whether the declared merge checks passed
whether the required evidence exists
whether the contract and CI wiring agree

CI cannot tell you:

what an agent will try at runtime
whether the harness still exposes undeclared actions
whether the execution boundary is actually constrained
whether the agent can still reach external effects you did not intend

That is why the second mandatory enforcement point matters:

sandbox and capability policy

The repo contract should not only describe what is mergeable.

It should also be consumable by the runtime boundary.

But a declaration is not enforcement by itself. If the selected runtime provider cannot apply and
attest a declared control, Ota must refuse that lane rather than print a stronger claim than the
provider earned. This is why capability-aware admission matters: the contract declares the
boundary; the runner verifies that the chosen provider can actually hold it.

That means a harness or sandbox should be able to enforce things like:

this task is callable in agent mode
this task is not callable in agent mode
this path is writable
this path is protected
this execution lane implies external effects
this execution lane requires review

That is the runtime-side equivalent of required checks.

One Contract, Not Three Policies

The biggest failure to avoid is not just weak enforcement.

It is split-brain enforcement.

If:

the local runner has one understanding of safe execution
CI has another
the sandbox has a third

then the repo is back to drift.

The mature model is:

one contract
multiple enforcement consumers
no duplicated Ota execution policy

That means:

the contract is the source of truth
the local runner consumes it for fast feedback
CI consumes it for a contract-owned merge check
the harness or sandbox consumes it for compatible runtime capability boundaries

Provider configuration still retains provider-owned truth: triggers, permissions, runners,
credentials, deployment environments, and the branch policy that makes a check mandatory. The
point is not to erase those boundaries. It is to stop duplicating Ota-owned bootstrap,
verification, admission, and proof truth across them.

What This Means For AI Agent Governance

This is where repo governance gets more serious than AGENTS.md.

An instruction file can say:

be careful
run tests
avoid dangerous commands
ask before touching infrastructure

That is useful.

But it is still prose.

What scales is when the repo can declare:

which lanes are safe
which verification path is merge-relevant
which evidence is required
which tasks are callable in agent mode
which effects require review

Then the rest of the stack can enforce that declared truth.

That is how a repo contract stops being a suggestion and starts becoming infrastructure.

The Stronger Direction

The most durable shape is not:

"everyone uses the same runner"

It is:

one repo contract
local enforcement for speed
CI checks made required by provider merge policy
runtime capability boundaries where a provider can enforce and attest them

That is the real higher-stack version of execution governance.

It does not depend on trusting agent behavior.

It depends on making repo truth explicit enough that the mandatory chokepoints already sitting in
the stack can consume it, and on refusing when a selected enforcement point cannot hold the
declared boundary.

If you want the deeper boundary between instructions and governed execution, read:

Originally posted here: https://ota.run/blog/one-contract-multiple-enforcement-points-for-safe-ai-agent-execution

Pressure-testing Ota on Hasura: raw Kubernetes manifests and honest kubectl proof

Bobai Kato — Tue, 28 Jul 2026 11:46:24 +0000

Overview

Hasura exposed a useful execution-governance boundary:
raw Kubernetes manifests without Helm or Compose owning the operational path.

That sounds simple. It is also easy to overclaim.

kubectl can parse and render a manifest locally without contacting a cluster. A Kubernetes API
can accept those objects without proving that Hasura became ready. A green command can therefore
mean at least three different things:

the manifests were interpreted locally;
a cluster accepted the declared resources;
the application started and became usable.

This pressure test asked whether Ota could govern the first two claims while refusing to imply the
third. The contract now installs released Ota v1.6.24 directly, so the version used by humans,
agents, and CI is contract truth rather than workflow-local bootstrap glue.

The pressure slice

The work stayed deliberately scoped to
install-manifests/kubernetes.
That directory contains the raw Hasura deployment and service manifests used by this test.

The Ota contract owns:

released Ota v1.6.24 bootstrap identity;
cross-platform kubectl acquisition;
non-mutating local manifest tasks;
explicit cluster-mutating apply tasks;
a safe verification workflow;
a separate deployment workflow;
task and workflow dry-run coverage;
the task and workflow truth consumed by the three-OS pressure matrix.

It did not attempt to govern all of Hasura or turn this narrow infrastructure directory into an
application-readiness contract.

What the contract says

Ota owns its own bootstrap identity

The pressure contract does not ask CI to choose an implementation branch or duplicate installer
commands. It pins the released version through the contract:

agent:
  bootstrap:
    ota:
      source:
        kind: version
        version: v1.6.24

The GitHub workflow uses ota-run/setup with source: contract, so the workflow consumes this
identity instead of becoming another source of Ota version truth.

Ota owns the tool

The contract does not hide kubectl installation in a shell preamble:

tools:
  kubectl:
    version: "*"
    acquisition:
      provider: apt
      package: kubectl
    platforms:
      macos:
        acquisition:
          provider: brew
          package: kubernetes-cli
      windows:
        acquisition:
          provider: winget
          package: Kubernetes.kubectl

That gives humans, CI, and agents the same declared tool requirement instead of three separate
installation conventions.

Local verification is non-mutating

The safe verification lane uses kubectl annotate --local. It asks kubectl to load and emit the
object without contacting a Kubernetes API:

k8s:preview:deployment:
  command:
    exe: kubectl
    args:
      - annotate
      - --local
      - -f
      - deployment.yaml
      - ota.run/preview=true
      - -o
      - yaml

The aggregate keeps both manifests in one canonical verification path:

verify:
  description: Render the focused raw Kubernetes manifest set without mutating the cluster
  aggregate:
    tasks:
      - k8s:preview:deployment
      - k8s:preview:service

This proves that the installed kubectl can interpret and render the selected manifests. It does
not prove server-side admission, policy compatibility, resource creation, or application
readiness.

Cluster mutation is not agent-safe verification

The apply tasks declare their external effect instead of disguising deployment as another check:

k8s:apply:service:
  command:
    exe: kubectl
    args:
      - apply
      - -f
      - svc.yaml
  effects:
    external_state:
      - kubernetes

Those tasks are intentionally excluded from agent.safe_tasks. The workflow layer also gives
verification and deployment different operational meanings:

workflows:
  default: verify

verify:
  intent: ci_verification
  run:
    task: verify

deploy:
  intent: deployment
  run:
    task: k8s:cluster:proof

Ota is not merely storing two commands. It is declaring which path is routine verification and
which path mutates an external system.

The proof ladder

The pressure design keeps three distinct proof levels:

Level	Evidence required	Current `v1.6.24` result
Local manifest interpretation	Real `kubectl annotate --local` execution for both manifests	Proved locally on macOS
Kubernetes API and resource acceptance	Real `kubectl apply` followed by `kubectl get` in an ephemeral `kind` cluster	Hosted Ubuntu reproof pending
Hasura application readiness	Pod readiness, database connectivity, service reachability, and application behavior	Not proved

This distinction is the main engineering result. A created Deployment and Service are stronger
evidence than local YAML handling, but they are still not proof that Hasura became ready.

Current Ota 1.6.24 evidence

The upgraded contract was exercised with released Ota v1.6.24, commit c1ab23a58.

The current local proof covers:

ota validate;
ota doctor;
ota tasks --use;
ota tasks --safe --use;
ota run verify --dry-run --json;
ota up --workflow verify --dry-run --json;
real ota run verify --native --agent;
both real kubectl annotate --local tasks.

ota doctor reported the repository slice ready with no findings. The task and workflow previews
were runnable, and the real safe verification closure completed successfully.

The pressure workflow is prepared to repeat contract discovery and dry-run coverage on Ubuntu,
macOS, and Windows, with real kind cluster apply-and-observe proof on Ubuntu. That hosted matrix
must pass against the upgraded contract before this draft is published as cross-platform
v1.6.24 evidence.

Matrix design

The matrix is asymmetric by design. It does not pretend that every operating system owns a
Kubernetes runtime:

Lane	Contract and discovery gates	Dry-run coverage	Real execution	Honest boundary
Ubuntu	Validate, Doctor, task inventory, safe-task inventory, workflow inventory, execution topology	`verify`, cluster proof, and both workflows	Local manifest verification plus apply-and-observe against an ephemeral `kind` cluster	Kubernetes resource acceptance, not Hasura readiness
macOS	Validate, Doctor, task inventory, safe-task inventory, workflow inventory, execution topology	`verify`, cluster proof, and both workflows	No hosted cluster execution	Contract and admission compatibility only
Windows	Validate, Doctor, task inventory, safe-task inventory, workflow inventory, execution topology	`verify`, cluster proof, and both workflows	No hosted cluster execution	Contract and admission compatibility only

The Ubuntu lane creates the kind cluster in GitHub Actions, outside the Ota contract. Ota then
owns the declared kubectl task and workflow execution inside that provider-owned boundary. This
keeps cluster provisioning truth separate from manifest execution truth.

The refreshed matrix acceptance bar is:

ota-run/setup installs the contract-pinned v1.6.24 release.
ota --version confirms the installed release before any contract claim is evaluated.
ota doctor passes without a tolerated blocked state.
The safe verify closure executes through the real agent boundary.
Successful JSON, topology, and execution-receipt evidence is retained for every lane.
Ubuntu proves resource apply and observation without promoting that result to application readiness.

Explicit boundaries

The pressure result remains narrow:

Contract-owned and currently proved with v1.6.24: Ota bootstrap identity, kubectl acquisition shape, task/workflow selection, safe-task separation, local validation and discovery, dry-run admission, and real local manifest execution on macOS.
Contract-owned and awaiting hosted reproof: Ubuntu kind resource apply/observation and the Ubuntu, macOS, and Windows matrix.
Repo-owned and outside this slice: editing deployment.yaml with the real database URL.
Not proved: Hasura pod readiness, database connectivity, service reachability, application behavior, production-cluster policy, RBAC, storage, ingress, load balancers, and rollback.
Not governed by this contract: creation and teardown of the CI kind cluster, which remained GitHub workflow infrastructure.
Not repo-global: no result here should be read as proof of the wider Hasura repository.

What Hasura taught Ota

Raw manifests do not need a giant abstraction. They need precise ownership and honest evidence.

Ota adds value here by keeping four truths together:

how the required tool is acquired;
which command path is safe verification;
which path mutates Kubernetes;
what each successful lane actually proved.

The important outcome is not that Ota can run kubectl. Any shell can do that. The outcome is that
humans, CI, and agents receive the same governed execution path without being told that local
rendering, cluster acceptance, and application readiness are interchangeable.

Originally posted here: https://ota.run/blog/pressure-testing-ota-on-hasura-raw-kubernetes-manifests-and-honest-kubectl-proof-4m2h

mise Resolves Tools. Ota Governs Repository Acceptance.

Bobai Kato — Mon, 27 Jul 2026 12:25:30 +0000

Overview

mise is one of the cleanest ways to make a repository's tool environment explicit.

It can tell contributors, CI, and agents which runtime versions and command environment a project expects.

That matters.

But a resolved environment is not the same thing as accepted repository execution.

mise helps answer:

Which tools and versions should this repo use?

Ota answers a different question:

Is the selected repo path ready, safe, canonical, and verified?

Those two layers work well together because they solve different parts of the same operational problem.

For modern repositories, especially ones touched by AI agents, that distinction matters. The failure is not always "wrong Node version" or "missing Python". Many repo failures happen after the right tools are already present.

The repo still needs to declare setup, task truth, readiness, verification, agent safety, runtime mode, and proof boundaries.

That is Ota's layer.

What mise Is Good At

mise is good at environment and tool resolution.

It gives a repo a compact way to declare things like:

which Node version should be used
which Python, Go, Ruby, or other tools matter
which tool versions should be installed or activated
which command environment should be entered
which repo-owned task aliases should exist

That is valuable for contributors and agents because it reduces host guesswork.

Without a tool manager, a new contributor may have the wrong runtime, a stale global binary, or an old package manager sitting on PATH.

With mise, the repo can make more of that explicit.

That is a strong foundation.

Where Environment Resolution Stops

The problem starts when teams treat environment resolution as repository acceptance.

They are not the same thing.

The right tools can be installed and the repo can still be ambiguous about:

which setup path is canonical
whether dependencies have been hydrated
whether services are required
whether test, check, ci, or verify is the accepted lane
whether local and CI execution agree
whether a task is safe for an agent
whether a green command proves a narrow slice or the full repo

mise can help run commands in the right environment. It does not, by itself, decide which command should count as the repo's acceptance path.

That is not a weakness in mise. It is a layer boundary.

Repository Acceptance Is A Different Contract

Repository acceptance means the repo can answer:

what must exist before work begins
how prerequisites are materialized
which task or workflow is canonical
which runtime mode is selected
what readiness means
what proof was produced
what was explicitly not proved
what an AI agent is allowed to run

That is why Ota uses ota.yaml.

The contract is not just a list of commands. It is an operating model for the repo.

Ota can declare:

toolchains
setup and dependency hydration
tasks and workflows
native and container modes
services and readiness checks
safe tasks for agents
protected and writable paths
proof and receipt output
CI drift and governance findings

That gives the repo a shared acceptance surface for humans, CI, and agents.

The Strongest Shape: mise For Tools, Ota For Acceptance

The mature pattern is not "Ota instead of mise."

It is:

mise owns tool and environment resolution where the repo uses it.
Ota owns repository readiness, canonical tasks, execution boundaries, and acceptance proof.

That lets each layer do its real job.

If a repo already uses mise.toml, Ota should not flatten that truth into vague shell glue. The contract should preserve that mise is the environment authority, then model what the repo does inside that environment.

For example:

orchestrators:
  mise:
    kind: mise
    required: true
    config_files: [mise.toml]
    activation:
      trust: true
    prepare:
      install: true

toolchains:
  node:
    version: "22"
    fulfillment:
      source: mise
      mode: run

tasks:
  verify:
    description: Run the accepted verification lane
    command:
      exe: pnpm
      args:
        - test
    execution:
      orchestrator:
        ref: mise
        mode: exec
    safe_for_agent: true

Here mise owns tool activation and the runner invokes pnpm test through mise exec. Ota still owns the selected verification lane and its agent-admission posture. The point is not that every repo should use this exact shape; it is that the environment authority remains explicit instead of being hidden in shell glue.

Why This Matters For AI Agents

AI agents are bad at unspoken repository assumptions.

They can read many files, but reading more does not create authority.

If the repo has:

a mise.toml
a README command
a package script
a CI workflow
an AGENTS.md instruction
a local shell wrapper

the agent still has to decide which signal is authoritative.

That is where Ota helps. It can detect and surface repo evidence, but the Ota contract reference gives the final declared path:

run ota doctor to inspect readiness
run ota tasks --use to see canonical usage
run ota up to prepare the selected path
run ota run verify --agent when the task is admitted for agents

The agent does not have to infer from scattered signals. It follows the repo contract.

Safe Environment Resolution Is Not Safe Execution

There is a safety distinction here too.

A correctly resolved environment does not make every command safe.

An agent inside the right mise environment can still run:

a destructive migration
a publish command
a broad cleanup script
a task that mutates external state
a verification lane that assumes secrets or live services

Tool correctness is not execution permission.

Ota's agent boundary exists because safe execution needs more than the right runtime. It needs a declared safe surface and a runner that can enforce it.

That is why Ota separates:

human command usage
agent-admitted command usage
safe task closure
effects and protected paths
proof and refusal output

mise can make the environment correct. Ota's contract declares what the selected path may claim as safe, ready, and proved; Ota evaluates that claim and carries its explicit proof boundaries.

How Ota Uses mise Evidence

When Ota sees mise.toml, it does not treat it as random configuration.

It treats supported tool declarations as repo-owned evidence with provenance.

That evidence can help answer:

which toolchains are expected
which versions are pinned or ranged
whether the contract's declared runtime differs from the repo-owned tool source
whether a declared task is explicitly mediated by mise
whether supported CI and contract evidence disagree

But Ota should stay honest.

mise.toml is strong evidence for environment resolution. It is not complete evidence for repository acceptance.

That means Ota should preserve provenance:

mise evidence can support toolchain truth and reveal runtime drift
the contract still owns selected setup, tasks, workflows, and proof
a task runs through mise only when its contract declares the mise orchestrator
doctor surfaces conflicts Ota can establish from supported repo-owned sources
unsupported or ambiguous claims should remain visible instead of inferred away

That is the difference between helpful detection and overconfident automation.

What This Looks Like In Practice

In a serious repo, the flow should feel boring:

ota doctor
ota tasks --use
ota up
ota run verify

If the contract declares mise as the selected task orchestrator, Ota invokes the task through
mise on that path.

If the host runtime differs from a high-confidence mise.toml declaration, doctor can name that
drift. It does not silently convert a host mismatch into acceptance: the selected task must still
run and produce its declared evidence.

Where Ota can recover both CI and toolchain evidence, it can surface a supported conflict rather
than asking an operator to reconstruct it from a later failing build.

If a task only works because a developer already has a warmed environment, Ota should not call that accepted readiness.

The goal is not more YAML for its own sake. The goal is fewer hidden assumptions.

The Clear Boundary

The clean distinction is:

mise resolves the environment.
Ota governs repository acceptance.

That means mise can be a strong input to Ota, but it should not be forced to carry all execution meaning.

Do not overload an environment manager with:

agent safety
proof breadth
readiness semantics
CI drift governance
protected path policy
runtime receipts

Those are Ota concerns.

The repo needs both layers when it wants both reliable environments and trustworthy execution.

Read the Ota command reference for the doctor, preparation,
and execution surfaces that apply the contract.

When To Use Ota With mise

Use mise when the repo needs strong tool and environment resolution.

Use Ota when the repo needs to make that environment operationally useful:

accepted setup
canonical tasks
safe agent lanes
verification after changes
local and CI alignment
machine-readable proof
bounded claims about what passed and what did not

For AI-agent work, that combination is stronger than either layer alone.

mise gets the agent into the declared environment. Ota tells it which lane is admitted, what that
lane must prove, and where the claim ends. Environment resolution is necessary; repository
acceptance is the bar.

Originally posted here: https://ota.run/blog/mise-resolves-tools-ota-governs-repository-acceptance

AI Agent Contracts Cannot Define Repository Acceptance

Bobai Kato — Sat, 25 Jul 2026 17:00:13 +0000

The Missing Half Of An Agent Contract

Most agent contracts answer an important question:

How should an agent change this repository?

They can protect sensitive directories, ask for smaller diffs, require a handoff, and tell an
agent when to stop and ask a human.

But a repository has a second question:

What must happen before this change counts as accepted?

That is not a writing-style question. It is an execution question: the setup path, the selected
services, the canonical verification lane, the execution mode, and the evidence a green result
actually carries.

An agent contract can guide edits. It cannot, by itself, define repository acceptance.

The Failure Mode

Consider an agent contract that says:

- Do not edit generated clients.
- Keep migrations small and explain them.
- Run tests before handoff.
- Ask before changing infrastructure.

Those are good contribution rules. They do not answer whether “run tests” means pnpm test, a
service-backed workflow, a container lane, or CI's actual verification closure. They do not say
whether dependencies are materialized, a database is ready, or a zero exit proves more than one
narrow check.

The dangerous outcome is a plausible handoff: the agent followed the instructions, ran a command,
and reported success. Nobody can tell whether it used the accepted path.

Ota Defines The Acceptance Path

Ota gives that operational truth a machine-readable home in ota.yaml:

tasks:
  setup:
    prepare:
      kind: dependency_hydration
      medium: package_dependencies
      source:
        kind: node_package_manager
        manager: pnpm
        mode: install
        frozen_lockfile: true

  verify:
    command:
      exe: pnpm
      args: [test]
    depends_on: [setup]
    safe_for_agent: true

agent:
  safe_tasks: [verify]
  verify_after_changes: [verify]

That is not an instruction to “remember to install dependencies.” It declares one accepted setup
and verification path that Ota can inspect, dry-run, execute, and record.

An agent can discover the declared surface, then execute it through the enforced lane:

ota doctor
ota tasks --safe --use
ota run verify --agent

The important distinction is that --agent asks Ota to resolve the selected task closure before
anything starts. If the requested task, dependency, or workflow path is outside the effective safe
surface, Ota refuses it and emits a structured result rather than relying on the agent to obey
prose.

The Boundary Is Real, But Scoped

Ota does not claim to sandbox every process an agent could launch. An agent with unrestricted shell
access can still bypass Ota by not using it.

The enforcement point is the Ota runner boundary: ota run <task> --agent and, for an
agent-admitted workflow, ota up --workflow <name> --agent. That gives developers and CI fast,
inspectable execution control now. A stronger organization-wide boundary comes when CI gates and
agent harnesses consume the same contract truth.

That honesty matters. A declared safe task is useful; a runner that refuses an unsafe closure is
stronger; an org-level harness or merge gate that requires the same result is stronger again.

Two Contracts, Two Jobs

Use an agent contract for contribution behavior:

editing and review rules
sensitive files and escalation
coding conventions and handoff expectations

Use Ota for repository acceptance:

dependency hydration and setup order
services, readiness, tasks, and workflows
native or container execution selection
agent-admitted execution paths
receipts, proof boundaries, and CI drift checks

Neither replaces the other. A repository with only agent guidance still asks the agent to infer
how the software runs. A repository with only Ota can still need human collaboration rules.

The durable model is simple: let the agent contract govern edits, and let Ota govern whether the
repository was prepared, verified, and evidenced through an accepted path.

Originally posted here: https://ota.run/blog/ai-agent-contracts-cannot-define-repository-acceptance

Testing the Proof System: Negative Controls and Dependency Evidence in Ota

Bobai Kato — Fri, 24 Jul 2026 14:37:52 +0000

A green call does not prove the dependency mattered

A service can be reachable without being exercised. An application can call a dependency without
proving the dependency shaped the tested obligation. A control can fail for an unrelated reason.

Flatten those outcomes into one green or red status and a proof system will eventually claim more
than it observed.

Ota 1.6.24 separates three levels:

reachable: the selected path reached a declared dependency boundary;
exercised: a finite observer recovered evidence produced through that dependency in the current proof transaction;
fault_tested: a separate control proved the same obligation failed for the declared missing-effect reason.

Each level answers a different question. None may be inferred from a command label or exit code.

The contract names the seam and the control

The runtime workflow declares the positive observation and the negative control independently:

workflows:
  app-proof:
    run:
      task: app
    readiness:
      surfaces: [app]
    proof:
      seam_observations:
        - id: postgres-marker
          dependency: postgres
          producer_task: proof:marker-produce
          task: proof:marker-observe
          marker_env: OTA_PROOF_DEPENDENCY_MARKER
      negative_controls:
        - id: postgres-unavailable
          dependency: postgres
          obligation: postgres-marker
          task: proof:postgres-unavailable
          intervention:
            kind: dependency_endpoint_override
          expected_failure: dependency_unavailable

Run the ordinary proof first. Select the control explicitly when the causal claim is required:

ota proof runtime --workflow app-proof --json --archive
ota proof runtime --workflow app-proof \
  --negative-control postgres-unavailable \
  --json --archive

Ota does not silently inject failure into every runtime check. Negative controls are separate proof
runs because they answer a stronger question and may mutate or disrupt the selected dependency.

`exercised` requires current-transaction evidence

The do-nothing observer is the first adversary.

If an observer can exit zero without reading evidence from the dependency, it has not proved the
seam was exercised. If it can reuse a value from yesterday's run, it has not proved this execution
used the seam.

For marker-bound observations, Ota creates an opaque marker and gives it only to the declared
producer. The observer receives the transaction context but not the marker. It must recover the
marker through the dependency and write the runner-owned attestation.

Ota verifies the observation identity, transaction identity, marker, and evidence digest before it
emits level: exercised. The transient marker is then removed. A clean observer exit, guessed
value, stale record, or caller-side trace cannot earn that level.

`fault_tested` requires the right red

The negative control has its own adversary: an unrelated failure.

A broken setup step, timeout, DNS failure, crash, or generic non-zero exit may turn the lane red. It
does not prove that removing PostgreSQL invalidated the same obligation that passed in the green
run.

Ota promotes the seam only when the canonical control record is:

bound to the same proof transaction and obligation;
run under the declared intervention;
classified as expected_missing_effect;
backed by a matching failure-attestation digest;
emitted with status: validated and outcome: expected_obligation_failed.

The dependency record carries only a derived projection of that canonical control. This prevents a
nested object from becoming a second, weaker authority.

{
  "dependency_evidence": [
    {
      "dependency_id": "service:postgres",
      "proof_obligation_id": "postgres-marker",
      "level": "fault_tested",
      "observation": {
        "origin": "round_trip_effect",
        "evidence_class": "attested"
      },
      "negative_control": {
        "status": "validated",
        "same_obligation": true,
        "failure_mode": "expected_missing_effect",
        "failure_attestation_digest": "sha256:..."
      }
    }
  ]
}

If Ota cannot validate that chain, the control remains invalid or unrun. An unclassified red
never upgrades evidence to fault_tested.

Strong seam proof is still bounded proof

A PostgreSQL marker round trip can establish that the selected obligation depended on PostgreSQL.
It cannot establish that PostgreSQL shaped every response, migration, query result, or user-visible
output in the repository.

Ota therefore retains the obligation-scoped boundary:

{
  "proof_verdict": "passed_with_unproven_boundaries",
  "not_proved": [
    {
      "kind": "dependency_output_shaping_not_proved",
      "proof_obligation_id": "postgres-marker"
    }
  ]
}

This is not a caveat hidden in prose. It travels with the artifact so CI and agents cannot honestly
turn one controlled seam into repo-global proof.

Athena API supplied the real pressure

athena-api forced this model through a Rails and
PostgreSQL runtime rather than a synthetic fixture. Its released Ota 1.6.24 matrix
run #29572074325 proved native and
container lanes while keeping Windows intentionally static. The later PostgreSQL pressure retained
dependency_output_shaping_not_proved even after the marker-bound seam and matching control became
stronger.

Read the full engineering note: Pressure-testing Ota on athena-api.

The design rule

Proof must be able to fail its own strongest claim.

Reachability proves contact. Transaction-bound observation proves the selected seam was exercised.
A validated same-obligation control proves the dependency was necessary for that obligation. Ota
keeps those claims separate because automation becomes dangerous when evidence levels collapse into
one optimistic green.

References

Originally published here: https://ota.run/blog/testing-the-proof-system-negative-controls-and-dependency-evidence

Ota 1.6.24: Replayable Proof for Real Repository Execution

Bobai Kato — Wed, 22 Jul 2026 20:49:31 +0000

A rerun is not automatically a replay

Running the same command twice does not prove that the same execution happened twice.

The contract may have changed. A lockfile may have moved. CI may have selected another backend. A
live API may have returned different state. Even a green result can describe a different operational
world.

Ota 1.6.24 takes a strict position: replay is a comparison against an archived execution witness,
not a synonym for rerun.

The selected workflow, backend, provider, lifecycle, contract snapshot, and captured inputs must be
comparable before Ota will call the result verified.

The command starts from an archived witness

Archive the original execution receipt, then select it as the replay baseline:

ota up --workflow verify --json
ota receipt --json --archive
ota up --workflow verify --replay-baseline latest --json

The replay result is explicit:

replay_verified: the selected scope reconciled with the baseline;
replay_failed: comparable execution produced material drift or failure;
replay_unavailable: Ota could not make an honest comparison.

replay_unavailable is not a weak error message. It is a trust boundary. A baseline from another
workflow, backend, provider, remote target, or lifecycle must not be promoted to last-known-good
evidence for the selected lane.

Declare inputs separately from observed behavior

Ota contracts can name the repo-owned artifacts that define a replay lane:

tasks:
  gate:
    replay_inputs:
      - id: recorded_sql
        kind: static_file
        path: data/fixture.jsonl
      - id: frozen_store
        kind: static_file
        path: data/store.db
      - id: runtime-presentation
        kind: presentation_profile
        path: replay/presentation-profile.yaml
      - id: equivalence
        kind: comparator_profile
        path: replay/comparator-profile.yaml
    witnessed_observations:
      query_traces:
        - id: recorded_queries
          path: evidence/query-trace.jsonl

These are not interchangeable fields.

replay_inputs[] records what the selected lane consumed before execution.
witnessed_observations.query_traces[] records behavior observed from an execution.

If observed SQL is silently treated as a current-run input, the replay can confirm itself. Ota
keeps the evidence linked but separate so a later comparison can distinguish changed inputs from
changed behavior.

In 1.6.24, Ota captures the observed SHA-256 identity of each declared replay input. That tells a
later replay exactly which bytes the original lane used and exposes identity drift between receipts.
It does not let the 1.6.24 contract declare an expected digest that blocks the very first execution.
That distinction matters: observed identity is execution evidence, not a maintainer-authored pin.

What a verified replay actually says

A verified replay says that Ota reconciled the selected execution scope and the named evidence it
knows how to compare. It does not automatically mean the lane was hermetic.

Matching static inputs remain scoped evidence. Undeclared environment state, live services, remote
APIs, clocks, randomness, and other ambient inputs can still matter. Ota therefore reports replay
posture and hermeticity separately instead of turning one matching hash into a repo-wide claim.

The machine consumer should inspect:

{
  "replay": {
    "posture": "replay_verified",
    "hermeticity": "partly_ambient",
    "baseline": {
      "last_known_good": "replay_verified"
    }
  }
}

The exact payload contains more scope and comparison detail. The important point is that
replay_verified and partly_ambient can both be true. One describes the comparison Ota completed;
the other prevents that result from claiming the rest of the world was frozen.

Bedrock made the distinction concrete

Bedrock, created by Vinicius Pereira, is a natural-language
to SQL stability harness. Its deterministic lane consumes a recorded SQL fixture, a frozen SQLite
store, and a defended baseline. The SQL records also contain useful witnessed query behavior.

That repo forced the product question: should historical model output become a replay input, or
remain witnessed evidence?

Ota keeps both roles explicit. The released-version pressure matrix passed native Ubuntu, macOS,
Windows, and the container replay lane in
run #29572073749. That matrix proves
the bounded offline replay path. It does not prove Bedrock's live model-recording lane or a live
database.

Read the full engineering note: Pressure-testing Ota on Bedrock: query identity as replay
evidence.

The operational rule

Use replay when you need to answer:

Did this selected execution still hold against the archived contract, scope, and named inputs?

Do not use it to imply:

Nothing outside this receipt could have affected the result.

That distinction is why Ota archives execution evidence, preserves semantic contract identity, and
publishes unavailable or partly ambient outcomes instead of manufacturing certainty.

References

Originally posted here: https://ota.run/blog/ota-v1-6-24-replayable-proof-for-real-repository-execution

Why ok: true Is Not Enough for AI Agent Execution

Bobai Kato — Tue, 21 Jul 2026 12:26:17 +0000

A successful command is not broad authorization

ok: true answers one useful question:

Did the selected Ota execution complete successfully?

It does not answer:

Did this lane prove every dependency mattered?
Did it cover every workflow in the repository?
Did it exercise a live external integration?
Is an agent now authorized to publish, deploy, or migrate?

Humans often carry those distinctions in context. Automated systems usually do not. If the only
machine signal is a Boolean, a narrow green result will eventually be consumed as a broader claim.

Ota 1.6.24 keeps execution success, proof breadth, and remaining uncertainty separate.

Read the proof carrier, not one field

Run the declared workflow through Ota's proof boundary:

ota proof runtime --workflow app --json --archive

A successful but bounded result can look like this:

{
  "ok": true,
  "phase": "readiness",
  "proof_verdict": "passed_with_unproven_boundaries",
  "proof_scope": {
    "kind": "runtime_path",
    "proof_class": "slice_proof",
    "workflow": "app",
    "task": "serve"
  },
  "not_proved": [
    {
      "kind": "broader_repo_completion_not_proved",
      "relative_to": "runtime_path"
    }
  ]
}

These fields are intentionally different:

ok reports selected execution success;
phase says where that result was established;
proof_verdict reports the derived proof posture;
proof_scope names the lane the artifact can speak for;
not_proved[] carries material boundaries that remain outside the claim.

An agent that reads only ok is not consuming the Ota proof contract correctly.

Why a qualified pass is not a failure

Suppose Ota starts an API and verifies its declared HTTP listener. That is useful runtime evidence.
It may prove the selected service became ready on the declared path.

It does not automatically prove:

a neighbouring release workflow;
a live payment or model API;
production data behavior;
a database's complete output-shaping role;
repository-wide completion.

Returning ok: false would discard the real success. Returning an unqualified pass would overstate
it. passed_with_unproven_boundaries preserves both truths.

The boundary is part of the result, not an apology after it.

What an agent should do next

An agent or CI integration should evaluate the result in this order:

Require ok: true for the selected execution.
Confirm proof_scope matches the task or workflow it intended to prove.
Read proof_verdict; do not translate every green execution into an unqualified proof pass.
Inspect not_proved[] for a boundary relevant to the next action.
Apply policy before crossing into a heavier lane such as deployment, migration, publishing, or live external effects.

That last step matters. Proof and authorization are related, but they are not the same object. A
runtime receipt can establish what happened. It should not silently grant permission for a more
dangerous task.

The verdict is derived, not narrated

Ota derives the terminal proof verdict at the decision boundary. A materially bounded proof cannot
serialize as an unqualified pass merely because an output formatter prefers a simpler status.

The same principle applies to dependency evidence. Caller-side activity, dependency readiness,
transaction-bound exercise, and negative-control causality retain different evidence levels. A
consumer does not get to upgrade them by ignoring the accompanying boundary.

That is the practical difference between execution logs and governance evidence: the artifact
carries enough structure for another system to refuse an over-broad interpretation.

What this does not solve

Ota cannot stop a general-purpose agent from bypassing Ota and invoking an arbitrary shell directly.
The repository contract is the specification; enforcement must also exist at the callable runner,
sandbox, CI, or merge-gate chokepoint.

Within Ota, agent mode restricts execution to the declared safe closure. Outside Ota, a harness must
expose Ota's governed lanes instead of handing the agent an unrestricted shell and hoping it behaves.

That boundary is important because ok: true is evidence, not a universal capability token.

The operational rule

For humans, agents, and CI:

Treat ok as execution status. Treat proof_verdict, proof_scope, and not_proved as the
authority on what that success established.

This makes a green result more useful, not less. It can safely drive automation because its limits
are available to the same machine that reads its success.

References

Originally posted here: https://ota.run/blog/why-ok-true-is-not-enough-for-ai-agent-execution

Pressure-testing Ota on Open WebUI: proof cleanup ownership, bootstrap truth, and native vs Compose runtime boundaries

Bobai Kato — Mon, 20 Jul 2026 18:43:02 +0000

Overview

Open WebUI exposed a real Ota lifecycle boundary.

This was not mainly a parsing or contract-shape repo. The contract was already strong enough to model:

source-checkout verification
packaged native runtime through uv run open-webui serve
frontend development runtime
default Docker Compose runtime

What the repo exposed was operational truth after proof:

a successful native proof still left a host workload alive
the first cleanup fix then widened too far and treated a Compose-owned runtime as the same class of host workload

That made Open WebUI a valuable pressure repo.

It forced Ota to get more precise about cleanup ownership instead of treating all successful runtime proof as one generic teardown problem.

The current pressure contract pins released Ota v1.6.24. Its latest green matrix run proves
the release surface at the exact contract and workflow revision linked below.

What Open WebUI exposed in Ota

This repo exposed four meaningful weaknesses.

1. proof success was weaker than it looked

The first issue was not that runtime proof failed.

It was that runtime proof succeeded and still left the native workload alive afterward.

In this repo, the packaged native workflow launches:

serve:native:
  launch:
    kind: command
    exe: uv
    args:
      - run
      - open-webui
      - serve
      - --host
      - 0.0.0.0
      - --port
      - "8080"

Ota proved that workflow, but the launched process tree was still alive after proof completed.

In GitHub Actions, that surfaced through setup-uv post-job cleanup, which blocked while the uv cache was still in use.

That was an Ota gap.

If proof succeeds but leaves behind repo-owned runtime state that later breaks CI cleanup, the proof surface is still incomplete.

2. native service cleanup widened past its real ownership boundary

The first core fix made Ota clean selected native service workloads after successful proof.

That was directionally correct, but Open WebUI immediately exposed the next boundary.

The Docker workflow uses a native task shape to launch Compose:

compose:up:
  launch:
    kind: command
    exe: docker
    args:
      - compose
      - up

That is a native command surface, but it is not the same kind of ownership as a host-managed runtime like uv run open-webui serve.

The first cleanup widening treated it as if Ota should reclaim the resulting listener directly like a host workload. That was too broad.

This repo made the distinction unavoidable:

host-owned native process workload
adapter-owned Compose runtime

Those are not the same cleanup family.

3. contract-owned CI bootstrap truth still matters

The workflow was already using ota-run/setup with contract mode, which is the right direction.

The contract bootstrap truth also had to stay aligned so the setup surface consumed the same install story the repo intended to publish.

That was not the original runtime bug, but it was still real governance drift.

A pressure repo should not say one thing in ota.yaml and effectively rely on another in CI.

4. mixed-runtime repos punish vague lifecycle ownership

Open WebUI combines several legitimate paths:

Python ownership through uv
Node ownership for frontend/build work
a packaged native runtime
a frontend-only runtime
a Docker Compose runtime

That combination matters because it punishes sloppy lifecycle assumptions quickly.

If Ota collapses all of that into “run a process and then stop something later,” the product boundary is still too weak.

What had to be fixed in Ota core

Open WebUI led to three real Ota fixes.

proof success-path cleanup for host-owned native workloads

Ota's proof teardown was tightened so it no longer stops only the outer ota up process.

It now also cleans selected native host service workloads that Ota actually owns for the chosen workflow.

That closes the gap where proof succeeded but left the packaged native runtime process tree alive after completion.

cleanup narrowing for Compose-owned runtime lanes

The first cleanup fix exposed a second Ota boundary, and that also had to be corrected.

Ota now skips that host-workload cleanup path for Compose-owned native service tasks such as docker compose up.

That matters because Compose runtime cleanup belongs to adapter-owned repo cleanup surfaces, not to host-process workload reclamation.

Without that distinction, Ota was overreaching past the lifecycle it actually owned.

proof cleanup now respects workflow-owned active execution scope

The last failure was subtler.

Docker proof itself was healthy, but teardown still failed because cleanup hit Ota's active execution registry and treated the proved compose:up service task as an unrelated blocker.

That was also an Ota gap.

The selected workflow had launched that runtime, proved it, and was now trying to clean up its own owned execution surface.

Ota now scopes workflow cleanup to the active execution ownership actually selected by the proof lane.

That keeps ordinary ota clean strict while allowing proof teardown to reclaim the workflow-owned execution it just created.

What changed in the contract

The final contract is stronger because it uses cleaner contract-owned truth in the same places where the product now got stronger.

The packaged native workflow stays explicit:

native:
  intent: local_development
  prepare:
    task: setup:env
  setup:
    task: setup
  run:
    task: serve:native
  readiness:
    surfaces:
      - native-web
  exposes:
    - surface: native-web

The Docker workflow stays separate instead of pretending it is the same runtime family:

docker:
  intent: packaged_runtime
  run:
    task: compose:up
  readiness:
    surfaces:
      - docker-web
  exposes:
    - surface: docker-web

That separation matters because the repo is not publishing one runtime claim.

It is publishing at least two different runtime claims with different lifecycle owners.

The contract bootstrap truth was also aligned so CI, humans, and agents all read the same Ota install intent from the repo contract.

The branch carries a 1.6.24 contract floor and structured bootstrap source, so CI, humans,
and agents use the same released Ota surface.

What the matrix now proves

The matrix does more than parse the contract, but each OS lane has an explicit scope.

All three lanes run ota validate, capture ota doctor, show task and workflow usage, inspect
execution topology, and dry-run the verify task and native workflow. They also dry-run the
finite backend-format and frontend-test tasks.

Ubuntu is the proof lane. It additionally runs the full frontend verification aggregate, the
finite backend-format and frontend-test tasks, then proves both the packaged native runtime and
the Docker Compose runtime. It also dry-runs the Docker workflow before executing its proof lane.

macOS and Windows are deliberately audit-only: they do not claim task execution, native runtime
proof, Compose proof, or Docker-workflow coverage. That is an explicit matrix boundary, not an
implicit gap hidden behind a green OS label.

The contract also models the frontend development runtime and the Playwright-enabled Compose
overlay. Neither is runtime-proved by this matrix. GPU and API-exposure overlays remain outside the
declared pressure scope. Those are modeled paths, not evidence that every Open WebUI runtime family
has been proved.

The green v1.6.24 matrix run
proved the tightened lifecycle boundaries on Ubuntu:

the native proof succeeded and cleaned up its host-owned runtime
the Docker Compose proof succeeded and tore down without tripping over its own active execution record
the contract-owned bootstrap, real verification tasks, and runtime-proof lanes agreed

Why this repo mattered

Open WebUI mattered because it is exactly the kind of repo that exposes whether a readiness system really understands lifecycle ownership.

It is not enough to support:

Python
Node
a native service task
a Compose runtime task

The product also has to know which cleanup responsibility belongs to which path.

This repo forced Ota to answer that cleanly:

proof success should not leave host-owned native workloads behind
Compose-owned runtimes should not be reclaimed as if they were the same class of host process

That is not cosmetic polish.

That is operational trust.

If Ota says a runtime path was proved, it should also leave the repo and CI environment in a truthful post-proof state.

Remaining boundary

The pressure pass also exposed a separate dependency-hydration limitation. Open WebUI's committed
uv.lock was stale, and a normal project uv sync can rewrite it before an unrelated verification
task inspects the working tree. The contract avoids that mutation for the upstream Ruff formatting
gate by using an isolated uvx tool bootstrap.

That is a truthful contract choice, not a complete Ota solution. Ota still needs a typed uv
frozen-lockfile posture for dependency hydration so a contract can require uv to refuse stale lock
state before execution rather than relying on task-specific avoidance. This remains an Ota product
gap; it was not hidden to make the matrix green.

Pressure-testing Ota on Kylrix: Next.js runtime projection and dual-mode contributor proof

Bobai Kato — Sat, 18 Jul 2026 15:36:41 +0000

Overview

Kylrix is a large Next.js workspace with two materially different local stories:

a contributor path backed by SQLite
a self-hosted Compose topology with Appwrite and supporting services

That distinction made it a useful Ota pressure target. A contract that treated both paths as one
generic “run the app” command would either hide the contributor truth or overclaim the self-hosted
one.

The useful outcome was not more shell automation. It was a narrower contributor contract and an
honest production-topology boundary.

The contributor path needed one source of listener truth

The contributor runtime is a Next.js service on port 3005. Before this pressure pass, a contract
author had to duplicate that bind truth in two places:

Next.js launch flags
the listener used for readiness and projected URLs

That duplication drifts easily. The stronger Ota shape is to keep the listener canonical and project
known server flags from it:

surfaces:
  contributor:web:
    kind: http
    port: 3005
    path: /

tasks:
  dev:
    launch:
      kind: command
      exe: pnpm
      args: [exec, next, dev, --turbopack]
      runtime_projection:
        listener: contributor:web
        adapter: nextjs

Ota derives the supported Next.js bind flags from the declared listener. Readiness and the rendered
external URL now describe the same runtime truth as the process command.

Native and container verification should not fight over state

Kylrix also needed a real dual-mode contributor path. The finite verification workflow runs the
same SQLite-backed test, lint, and build tasks on the host or in Ota's pinned Node container.

The important detail is attachment isolation:

execution:
  backends:
    container:
      image: node@sha256:a25c9934ff6382cd4f08b6bc26c82bf4ea69b1e6f8dabfb2ead457374127c365
  contexts:
    contributor:container:
      backend: container
      lifecycle: persistent
      attachments:
        isolated_paths: [node_modules, .next, .pnpm-store]

That makes the mode boundary operational instead of cosmetic. Container verification does not reuse
or corrupt native dependency and build state, while both lanes still execute the same declared
verification closure.

The self-hosted topology is governed, but bounded

Kylrix's full self-hosted stack is not a second contributor runtime. It uses Compose to build and
launch Kylrix, Appwrite, MariaDB, Redis, and Caddy. Ota owns the interpolation env file, Compose
file selection, image build, lifecycle, and readiness surface:

selfhost:up:
  launch:
    kind: compose
    action: up
    detach: true
  runtime:
    kind: service
    surfaces: [selfhost:web]

The contract does not claim that it has provisioned Appwrite credentials, completed the interactive
setup wizard, or proved application-level self-hosted behavior. Those steps require operator
credentials and are explicitly outside this workflow.

That boundary is as important as the Compose ownership. A green lifecycle proof should not be read
as a green product deployment.

What the matrix proves

The Kylrix Ota matrix proves the narrow contributor surface across native and container lanes:

contract validation, doctor, and task discovery
safe-agent task and workflow previews
real SQLite-backed test, lint, and build verification
native and container workflow receipts
native and container runtime proof for the Next.js contributor service

The self-hosted Compose workflow is modeled and dry-run covered, but not matrix-executed. It remains
deliberately outside the contributor proof claim because its Appwrite provisioning is operator-owned.

The released v1.6.24 pressure run is #29572073845.

Why this repo mattered

Kylrix reinforced two Ota design rules:

listener truth should be declared once and projected into supported launch adapters
native, container, and self-hosted paths must be governed as distinct execution realities, not flattened into one optimistic “works locally” claim

The result is a contract that helps contributors start with the finite SQLite path, gives Ota a
truthful container equivalent, and keeps the heavier Appwrite topology visible without pretending it
has been fully proved.

Pressure-testing Ota on lead-quorum: native Python truth, repo-local fulfillment, and runtime bind projection

Bobai Kato — Fri, 17 Jul 2026 12:51:03 +0000

Overview

lead-quorum was a strong pilot repo because it was small enough to reason about and real enough to fail honestly.

It has:

repo-local Python environment ownership
pinned dependency installation
env bootstrap from example truth
a deterministic local test surface
live external verification
a local web runtime
a distributed demo path
a Docker build lane

That is exactly the kind of repo where a contract can look clean while still hiding real setup and execution drift.

Why this repo mattered

The useful pressure here was not “can Ota run one Python command.”

The useful pressure was whether Ota could stay truthful when the repo itself owns:

the .venv
the dependency install lane
the local executable path
the runtime listener truth

If Ota probes or fulfills those in the wrong order, the contract is not trustworthy even if the repo itself is valid.

That is what made lead-quorum valuable.

What the contract now models

The final contract is explicit about the repo’s real setup split.

Setup is not one opaque shell step. It is three different ownership surfaces:

copy .env from .env.example only if missing
create the repo-local virtual environment
hydrate dependencies through typed uv requirements-file installation

That looks like this in the contract:

setup:
  aggregate:
    tasks:
      - setup:env
      - setup:venv
      - setup:deps

setup:env:
  action:
    kind: copy_if_missing
    from: .env.example
    to: .env

setup:venv:
  action:
    kind: ensure_virtualenv
    path: .venv
    python: "3.12"

setup:deps:
  prepare:
    kind: dependency_hydration
    medium: package_dependencies
    source:
      kind: uv
      cwd: .
      mode: pip_requirements
      requirements_file: requirements.txt

The contract also keeps verification and external-runtime claims separate:

verify for deterministic local validation
live for Gemini-backed end-to-end testing
app for the local web service
distributed for the A2A demo path

That matters because a working local scoring test and a live distributed runtime are not the same readiness claim.

What lead-quorum exposed in Ota

This repo exposed three real Ota gaps.

1. native repo-local fulfillment and probing were ordered incorrectly

Older Ota could still probe repo-local Python executables too early.

That is the wrong trust order for a repo that creates its own .venv as part of setup. If the repo-local interpreter path is declared as:

exe: .venv/bin/python

then Ota has to materialize the dependency/setup closure before treating that path as a fulfilled runtime command.

Otherwise a valid contract can fail just because Ota asked the question too early.

That is exactly what this repo exposed.

2. native Python candidate selection was too weak

lead-quorum also exposed a narrower but important gap in typed Python hydration.

When Ota selected a local Python candidate for setup and hydration, it could still choose the wrong host interpreter path instead of the repo’s intended environment. In practice that meant a dependency like cryptography could start building against the wrong target environment instead of the repo-owned Python lane.

That is not a repo bug. That is a readiness engine selecting the wrong execution truth.

3. runtime bind truth was duplicated between launch args and runtime listeners

The local web service made a third weakness obvious.

Before widening, the contract still had to repeat bind truth in two places:

command-line runtime args such as --host and --port
the declared runtime listener surface

That duplication is fragile.

The stronger product shape is for the runtime listener to stay canonical and for Ota to project the supported bind flags for known servers. lead-quorum became the first real repo to pressure that widening cleanly.

What changed in Ota

lead-quorum drove platform fixes, not repo-local workarounds.

native repo-local fulfillment now respects setup materialization order

Ota now runs the selected setup closure before probing repo-local backend/runtime commands that depend on that materialized state.

That closes the gap where a repo could declare a truthful .venv/bin/python lane and still fail because Ota evaluated it before the repo-local environment existed.

Python candidate selection is now stricter and more truthful

Ota also now prefers version-matching Python candidates before falling back to weaker generic host candidates.

That makes typed Python hydration much less likely to drift onto the wrong interpreter family when the contract has already declared the intended Python lane.

runtime listener truth can now project bind args

This repo also helped widen Ota’s runtime-to-launch projection.

The local web service can now declare listener truth once and let Ota project supported bind args for a known adapter:

launch:
  kind: command
  exe: .venv/bin/uvicorn
  args:
    - web.app:app
  runtime_projection:
    listener: web
    adapter: uvicorn

That is a cleaner long-term shape than duplicating --host and --port in every Python service contract.

What the matrix now proves

The released v1.6.24 pressure matrix on Ota's fork is green across Ubuntu, macOS, Windows, and
a Dockerfile-owned Ubuntu container lane. Ubuntu and macOS execute the native deterministic and
runtime-proof lanes. Windows is intentionally audit-only in this matrix: it validates the contract
and discovers the task surface, but does not execute native tasks or runtime proof.

That matters because this repo’s truth is not only “tests pass on one machine.” The matrix proves:

ota validate
ota doctor
ota tasks --use
ota tasks --safe --use
task dry-run coverage for setup, deterministic test, live test, distributed demo, and Docker build lanes
workflow dry-run coverage for verify, app, live, and distributed
real setup
real deterministic test
real verify workflow proof
real local app workflow proof
real docker:build
real verify:container workflow against the repository Dockerfile image
contract-modeled and dry-run-covered live external and distributed workflows; their real matrix execution is conditional on GOOGLE_API_KEY and was skipped in this released-version run

That is a much stronger outcome than “the contract parses.”

Why this repo was a good pilot

lead-quorum did exactly what a first pilot should do.

It did not mainly expose repo noise. It exposed trust gaps in Ota itself:

setup before probe
correct interpreter selection
one canonical runtime bind truth

Those are real product boundaries.

That is why this repo was worth pressure-testing.

It also reinforced an important standard for future pilots:

a receipt or contract is only useful if it stays aligned with the actual decision and execution path, not just with what the repo intended in prose.

lead-quorum is created and maintained by Vinicius Pereira. The
Ota integration is proposed upstream; the forked matrix below is pre-merge pressure evidence, not
evidence from the canonical repository.

DEV Community: Ota

Pressure-testing Ota on Grafana: bounded Go proof and a staged Compose slice

Overview

The Contract

The Compose Boundary

Released Install Truth

What The Matrix Covers

What It Does Not Prove

Links

Why Heavier Repository Execution Needs Audited Boundary Crossings

Safe by default is only half the execution-governance problem

A crossing is not the same as a refusal

What Ota publishes today

The stronger authority carrier is implemented but still in development

What is not complete yet

The durable design rule

Why this matters for Ota

References

One Contract, Multiple Enforcement Points for Safe AI Agent Execution

Overview

The Local Runner Is Useful. It Is Not The Final Teeth.

The Real Teeth Live At Mandatory Chokepoints

Why CI Comes First

A Green Check Is Not A Runtime Boundary

One Contract, Not Three Policies

What This Means For AI Agent Governance

The Stronger Direction

Pressure-testing Ota on Hasura: raw Kubernetes manifests and honest kubectl proof

Overview

The pressure slice

What the contract says

Ota owns its own bootstrap identity

Ota owns the tool

Local verification is non-mutating

Cluster mutation is not agent-safe verification

The proof ladder

Current Ota 1.6.24 evidence

Matrix design

Explicit boundaries

What Hasura taught Ota

mise Resolves Tools. Ota Governs Repository Acceptance.

Overview

What mise Is Good At

Where Environment Resolution Stops

Repository Acceptance Is A Different Contract

The Strongest Shape: mise For Tools, Ota For Acceptance

Why This Matters For AI Agents

Safe Environment Resolution Is Not Safe Execution

How Ota Uses mise Evidence

What This Looks Like In Practice

The Clear Boundary

When To Use Ota With mise

AI Agent Contracts Cannot Define Repository Acceptance

The Missing Half Of An Agent Contract

The Failure Mode

Ota Defines The Acceptance Path

The Boundary Is Real, But Scoped

Two Contracts, Two Jobs

Testing the Proof System: Negative Controls and Dependency Evidence in Ota

A green call does not prove the dependency mattered

The contract names the seam and the control

exercised requires current-transaction evidence

fault_tested requires the right red

Strong seam proof is still bounded proof

Athena API supplied the real pressure

The design rule

References

Ota 1.6.24: Replayable Proof for Real Repository Execution

A rerun is not automatically a replay

The command starts from an archived witness

Declare inputs separately from observed behavior

What a verified replay actually says

Bedrock made the distinction concrete

The operational rule

References

Why ok: true Is Not Enough for AI Agent Execution

A successful command is not broad authorization

Read the proof carrier, not one field

Why a qualified pass is not a failure

What an agent should do next

`exercised` requires current-transaction evidence

`fault_tested` requires the right red