DEV Community: Bobai Kato

Pressure-testing Ota on Flagr: native and container Go verification with honest boundaries

Bobai Kato — Fri, 14 Aug 2026 23:06:06 +0000

Overview

Flagr is a useful test of whether Ota can keep a real service repository legible. It has a portable Go verification path, a local SQLite-backed API, a six-instance Docker Compose integration topology, four database services, and a locally tagged integration image. Those are different execution truths. One green test command should not flatten them into one readiness or deployment claim.

The pressure contract pins released Ota v1.6.25, separates deterministic verification from runtime and integration work, and gives the Compose topology a runner-owned lifecycle proof.
It also removes Windows from the selected verification surface rather than carrying an audit-only lane that could be mistaken for execution support.

Why this repo mattered

Flagr combines several patterns that show up in mature service repositories:

a finite Go verification lane;
a long-running local service with a declared HTTP surface;
an integration topology that needs an image build, Compose startup, readiness, test execution, and teardown; and
CI that needs to distinguish a safe verification lane from deliberately external-state-mutating integration work.

The pressure question was not merely whether go test could pass. It was whether the contract could own hydration, execution mode, runtime readiness, image construction, service dependencies, failure cleanup, and agent refusal without hiding the important transitions in CI shell.

What the contract models

The deterministic lane uses typed Go module hydration in native and container contexts. Linux and macOS own the native verification path; Linux also owns the container path through golang:1.26-bookworm. The selected Go closure is intentionally unavailable on Windows.

The integration image is not a raw docker build string:

integration:image:
  description: Build the locally tagged image consumed by the six-node Compose integration topology
  category: build
  action:
    kind: build_container_image
    file: integration_tests/Dockerfile-Integration-Test
    context: .
    tag: flagr_integration_tests

The workflow split stays explicit:

verify is deterministic Go package verification;
local owns the SQLite-backed API runtime;
integration owns the image, Compose topology, readiness, integration suite, benchmark, and explicit teardown;
integration:lifecycle gives Ota ownership of service start, assertion, teardown, and archive evidence;
integration:lifecycle:failure-control intentionally fails the real assertion and verifies that teardown still completes; and
agent refusal canaries exercise the real boundary around the unsafe image task and integration workflow.

The lifecycle model includes the Flagr services and their MySQL and PostgreSQL dependencies. Each managed service declares manager_inactive as its teardown assertion. Readiness failure is not accepted as proof that a service stopped; the Compose manager must report the terminal state.

What Flagr exposed in Ota

Flagr exposes several real Ota boundaries without needing repository-specific workarounds.

Aggregate verification needed to remain visible as executable closure support in task discovery.
Doctor also had to stop probing repo-owned commands before their producer task had created them.
Those are ordering and discovery problems in the runner, not defects in a Go repository.

The CI pressure exposed another distinction: a finite workflow cannot stop after a readiness-oriented ota up. Ota's provider-neutral CI projection distinguishes a finite task closure from a service-runtime path. The finite lane executes its selected task; runtime proof owns
its own execution path.

That is why the image build matters. Ota owns the action, Dockerfile, context, local tag, and evidence surface. Flagr still owns what the image means and how its integration system behaves.

The lifecycle lane closes the remaining shell-shaped gap. Starting Compose, probing six Flagr endpoints, running an assertion, and calling down in a final CI step showed that readiness was proved but transaction-owned cleanup was not. Ota's managed lifecycle surface now acquires cleanup authority before start, runs the declared assertion, finalizes each managed service, and archives the bounded result. The failure control matters because successful cleanup alone would not prove that the same finalization path survives an assertion failure.

Matrix design

The released matrix is deliberately split by evidence type:

Lane	Platform and mode	Evidence
Managed `verify` projection	Linux native	Contract validation, Doctor, safe discovery, dry-run admission, real verification, receipt archive, and two refusal canaries
Managed `verify` projection	macOS native	The same finite verification and refusal boundary on the second supported host OS
Managed `verify` projection	Linux container	The same selected verification closure inside the contract-owned Go image
Native runtime proof	Ubuntu and macOS	Bounded execution of the SQLite-backed local API and its declared health surface
Container runtime and integration	Ubuntu	Container runtime proof plus the six-instance Compose suite, benchmark, receipt, and explicit teardown
Managed lifecycle pressure	Ubuntu	Successful lifecycle archive plus an assertion-failure control that must still finalize every transaction-owned service
Contract-to-CI drift	Ubuntu	The first-party Action checks that CI consumes contract-owned bootstrap and verification truth

The contract and generated workflows bind bootstrap to released v1.6.25. All three supported managed projections are generated from the final contract, and their human-owned caller bindings are checked against the same projection identities before hosted execution.

The complete hosted governance matrix is green in
run 31834610141 at commit 58f5263a. It executed Linux and macOS native verification, Linux container verification, both refusal canaries in every generated lane, native runtime proof on Ubuntu and macOS, container runtime proof, the Compose integration suite and benchmark, explicit teardown, and the contract-to-CI drift gate.

The managed lifecycle lane is independently green in
run 31834610099. The successful transaction acquired ownership for and finalized ten services, passed the real integration assertion, and observed every declared teardown state. Its separate failure control sent the same assertion to an unreachable endpoint, recorded the expected non-zero outcome, and still completed finalization for all ten services.

That lifecycle result is deliberately passed_with_unproven_boundaries, not a bare pass. The four
database services do not declare readiness or another manager-backed start-state observer, so service_started_state_not_proved remains attached to each database obligation. Application output and broader repository completion also remain explicitly unproved.

The distinction between the lanes is part of the result. A refusal canary is not a successful integration run; it proves that the real runner still rejects that path in agent mode. Runtime readiness is not lifecycle finalization. Lifecycle finalization is not application correctness or production deployment evidence.

Doctor stayed honest

The released contract validates with no errors, but Doctor intentionally retains two classes of warning:

the agent-safe verification closure performs declared Go dependency hydration over the network; and
the lifecycle closure mutates Docker, MySQL, and PostgreSQL external state.

Those warnings are not noise to remove. They tell an operator that repository write boundaries do not govern registries, the Docker engine, or database state. The managed verification lanes remain
agent-admitted because the network effect is typed as dependency hydration. The integration and lifecycle lanes remain outside agent-safe admission.

Uncovered material behavior

The pressure result is bounded as follows:

Contract-owned and exercised

typed Go module hydration for the selected native and container verification modes;
deterministic Go package verification on Linux, macOS, and Linux container execution;
SQLite-backed local API runtime and HTTP readiness;
the locally tagged integration-image build;
the selected six-instance Compose integration suite and benchmark;
successful and assertion-failure lifecycle finalization; and
agent refusal canaries plus contract-to-CI drift detection.

Explicitly outside this proof

the UI build, browser E2E lane, actionlint job, dependency-freshness policy, and broader upstream benchmark surface remain repo-owned CI behavior outside this selected Ota pressure contract;
GitHub triggers, permissions, credentials, runner policy, and artifact retention remain provider-owned;
release publication to GHCR, multi-architecture release images, and production deployment remain outside Ota's selected execution scope; and
external production services, production data, and deployment credentials were neither selected nor proved.

Ota platform gaps

This pressure lane exercises shipped Ota surfaces without adding a repo-local workaround. Any hosted failure must be classified before editing: contract defect, upstream Flagr behavior, provider failure, or a new Ota platform gap. A green matrix does not erase the explicit boundaries above.

What this did not prove

The matrix does not prove Windows execution. The contract prevents that over-read by excluding the selected verification tasks from Windows rather than publishing a non-executing audit lane.

The selected integration topology is real local proof, but it is not evidence that every deployment environment has the same topology or that production operations are governed by this contract. The lifecycle archive proves only the selected Compose transaction and its declared teardown assertions. It does not prove Flagr's application outputs, repository-wide correctness, or external
provider policy. It also does not promote the four database services to observed started state; their command execution and terminal manager state are evidenced, while their start-state obligations remain bounded as not_proved.

Hosted result

The hosted governance and lifecycle matrices are green on the same pressure commit and install Ota from the contract's released v1.6.25 source. Local validation also passed Doctor, discovery,
native and container dry-run admission, real native and container verification, refusal canaries, managed projection checks, and workflow linting. The hosted runs, not that local result, are the
publication evidence.

Test What Your AI Agents Must Not Do

Bobai Kato — Wed, 12 Aug 2026 14:19:58 +0000

A Guardrail Without A Negative Test Is Still An Assumption

Most AI agent governance starts with the positive path.

A repository tells an agent which task it may run. The agent invokes that task. The test suite
passes. CI goes green.

That proves one useful thing: the allowed path still works.

It does not prove that the forbidden path is still forbidden.

A stale allowlist, an incomplete dependency closure, a runner regression, or a hand-maintained CI
condition can quietly widen what an agent is able to execute. Every positive check may remain green
while the safety boundary has stopped doing its job.

This is why agent guardrails need negative tests.

Ota calls those tests refusal canaries.

They are available in Ota v1.6.25, and they reflect a deliberate product position:

Agent safety should be executable contract truth, not a promise that the model will remember to
behave.

Ota uses the same ota.yaml contract to define the safe task surface, evaluate the complete
selected closure, refuse unsafe execution, emit machine-readable evidence, and project the canary
into CI. There is no separate shell rule for the negative test to drift away from.

That is the difference between documenting a guardrail and operating one.

What A Refusal Canary Tests

A refusal canary names a task or workflow that must remain outside the repository's agent-safe
execution boundary.

For example, a repository may allow agents to run verification while reserving publishing for a
human-controlled path:

agent:
  safe_tasks:
    - verify
  refusal_canaries:
    - task: publish
    - workflow: release

tasks:
  verify:
    command:
      exe: pnpm
      args: [test]
    safe_for_agent: true

  publish:
    command:
      exe: pnpm
      args: [publish]
    safe_for_agent: false

workflows:
  release:
    intent: release
    run:
      task: publish

The positive check proves that the allowed lane remains callable:

ota run verify --agent

The refusal canary tests the opposite boundary:

ota run publish --agent --expect-refusal
ota up --workflow release --agent --expect-refusal

These commands do not run the unsafe task and then inspect its exit code. Ota exercises the same
agent admission boundary used by ordinary execution and requires refusal before the selected task,
its dependencies, or the workflow closure starts.

That distinction matters. The canary tests the execution boundary, not the behavior of a dangerous
command after it has already begun.

Expected Refusal Becomes A Passing Test

An ordinary agent refusal is a blocked execution result. That is the correct behavior for a direct
attempt to run an unsafe task, but it is inconvenient as a CI assertion because the shell sees a
non-zero exit.

--expect-refusal gives that result explicit negative-control semantics:

refused_as_expected means the declared agent-safety boundary refused the selected target before execution and the canary passes;
refusal_not_observed means the target was admitted, so the canary fails; and
wrong_refusal_boundary means execution was blocked for another reason, so the canary still fails.

The third state prevents an important false positive.

Suppose publish accidentally becomes agent-safe, but an unrelated organization policy still
denies the command. A weak negative test would see "something failed" and call the guardrail
healthy. Ota does not. The canary passes only when the safety boundary it was created to test is
the boundary that refused the lane.

For machine consumers, the same result is available as structured JSON:

ota run publish --agent --expect-refusal --json

The output carries the canary target, the runner-authored refusal record, whether execution
started, and the associated blocked receipt when refusal was observed. The agent does not
self-report that it behaved safely.

This is where Ota is intentionally more opinionated than a task runner. A task runner answers,
"Can I invoke this command?" Ota also asks, "Should this actor be admitted to this complete
execution closure, and what evidence should exist when the answer is no?"

Why This Must Run Through The Real Runner

It is easy to imitate a refusal canary with shell logic:

if [ "$AGENT_MODE" = "true" ]; then
  exit 1
fi

That only proves the shell condition still exists.

It does not prove that Ota's selected task closure, safety declaration, dependency expansion, and
execution admission agree. It can also drift independently from local execution, turning CI into a
second policy system.

A useful refusal canary has to pass through the same chokepoint as the real action. Otherwise the
test and the boundary can fail independently while both appear green.

Ota therefore derives the refusal from current contract truth at execution time. Authors declare
which task or workflow is the canary; they do not author the reason that should make it pass.

Put Refusal Canaries In CI

Local refusal gives agents and developers fast feedback. CI turns the same boundary into a
repository-level control.

A mature governance lane should test both directions:

At least one meaningful safe verification path is admitted and completes.
Each material unsafe path selected as a canary is refused by the agent boundary.

Ota's provider-neutral CI projection includes each declared refusal canary. The GitHub adapter
emits each one as its own provider check with a stable merge-check identity. That lets a repository
make the negative control merge-required instead of hiding several boundaries inside one opaque
script step.

This is stronger than one broad "agent safety" job. If the publish canary fails while verification
still passes, the provider shows exactly which execution boundary widened.

Branch protection remains provider-owned. Ota can generate and identify the GitHub check, but the
repository's GitHub policy must make it required if the organization wants a non-optional merge
gate. Future provider adapters must preserve the same ownership boundary rather than pretending
Ota controls provider policy.

What Refusal Canaries Prove

A passing refusal canary proves a narrow and valuable claim:

At this contract snapshot and runner boundary, the selected task or workflow was refused for the
expected agent-safety reason before execution started.

It does not prove:

that every dangerous repository action has been declared;
that the maintainer classified every task correctly;
that raw shell execution outside Ota is impossible;
that CI branch protection requires the canary check;
that runtime filesystem, network, credential, or provider controls were enforced; or
that the repository is globally safe for autonomous operation.

Those are different obligations.

Contract-claim assurance can evaluate whether observable repository evidence supports a declared
safety claim. Sandbox and capability providers can enforce runtime controls. CI policy can make
checks mandatory. Refusal canaries test whether one declared runner boundary still refuses what it
is supposed to refuse.

Keeping those claims separate is what makes the result trustworthy.

Turn Incidents Into Permanent Negative Tests

A refusal canary protects a boundary the repository has already identified. It cannot protect an
omitted path merely because that path reaches a similar outcome.

If publish is refused, Ota has proved that the selected publish closure was refused. It has not
proved that another task, migration, helper script, or raw shell command cannot reach the same
external effect. Presenting task-level refusal as effect-level protection would turn a precise
negative test into a broader claim the evidence does not support.

The practical operating model is a ratchet: when an incident or review exposes another material
execution path, add that real task or workflow as a permanent canary. The incident should improve
the executable governance suite, not remain only in a retrospective document.

Ota's current refusal canaries are task- and workflow-bound. Effect-level assurance across
equivalent execution paths is a separate, planned governance boundary; it is not something this
feature claims to provide today. Until that boundary is implemented and pressure-tested, canary
coverage should remain explicit about which declared lanes it exercises and which equivalent paths
remain unproved.

Choosing Useful Canaries

Do not turn every non-agent-safe helper into a canary. Choose actions whose accidental admission
would materially weaken the repository's governance story.

Good candidates include:

package publishing and release workflows;
production deployment;
destructive database operations;
credentialed external mutations;
infrastructure apply or teardown tasks; and
expensive or metered execution that should require a different authority path.

The canary should name the real contract task or workflow. Do not create a fake unsafe command
whose only purpose is to be refused; that proves the fixture, not the material repository boundary.

Also keep the positive lane. A system that refuses everything is not safely governed execution. It
is unavailable software. The useful result is selective admission: routine work remains easy, and
materially different work remains outside the agent-safe closure.

Try It In Your Repository

The fastest way to understand refusal canaries is to make one fail deliberately on a temporary
branch.

First, install Ota, then inspect the repository before changing its
contract:

ota doctor
ota tasks --use
ota tasks --safe --use

Add one real unsafe task or workflow to agent.refusal_canaries. Choose publishing, deployment,
infrastructure mutation, or another material lane that already exists in the repository. Then
validate both directions:

ota validate
ota run verify --agent
ota run publish --agent --expect-refusal --json

Now temporarily make publish agent-safe. The positive verification lane can remain green, but the
refusal canary changes to refusal_not_observed and exits non-zero. That is the failure shape the
feature exists to expose: the repository still works, but its agent execution boundary has widened.

When the local contract is correct, inspect the provider-neutral CI projection:

ota ci projection \
  --workflow verify \
  --mode native \
  --target-os linux \
  --json

For GitHub Actions, Ota can render the governed reusable workflow from that projection:

ota ci github render \
  --workflow verify \
  --mode native \
  --target-os linux

The repository keeps ownership of triggers, permissions, secrets, runners, environments, and
branch protection. Ota owns the contract-derived execution and refusal checks. That boundary lets
teams adopt Ota without replacing their CI provider or creating another hand-maintained workflow
language.

The Larger Point

AI governance cannot stop at telling agents what they may do.

It also needs tests for what they must not be allowed to execute.

Positive tests prove that an allowed path still works. Refusal canaries prove that a selected
forbidden path still stops at the runner boundary. Together they turn an agent allowlist from
static metadata into executable governance.

That is the standard Ota is building toward: boundaries that are declared once, exercised through
the real chokepoint, and retained as evidence rather than trusted as prose.

If your repository already tells agents what they may run, the next useful question is simple:

Which one unsafe action would you want CI to prove they still cannot run?

Go Deeper

Originally posted here: https://ota.run/blog/test-what-your-ai-agents-must-not-do

Pressure-testing Ota on nopCommerce: managed .NET verification across native and container CI

Bobai Kato — Tue, 11 Aug 2026 11:34:53 +0000

The question

nopCommerce is a useful test of where Ota should
stop owning CI. Its .NET repository has substantial provider-owned workflow and deployment policy;
Ota should not turn that into a second CI language. The pressure question was narrower: can Ota own
a restore-and-build verification lane while GitHub retains triggers, runners, permissions,
environments, and release policy?

The setup task expresses restore as typed dependency hydration, then the workflow runs a finite
aggregate verification task:

setup:
  prepare:
    kind: dependency_hydration
    medium: package_dependencies
    source:
      kind: dotnet_restore
      cwd: src/Tests/Nop.Tests

verify:
  aggregate:
    tasks:
      - build

workflows:
  verify:
    setup:
      task: setup
    run:
      task: verify

The pressure result

The contract declares native and container execution for the same workflow. Ota projects each into
an Ota-owned reusable workflow, binds it to a target OS and projection identity, and asks the
human-owned GitHub caller to supply that identity. The caller is an adapter, not a second authority.

Moving the contract from the old implementation branch to released v1.6.25 changed both
projection identities. The old caller refused immediately. That was the useful failure: it made
stale governance YAML visible before any verification task ran. We regenerated the native and
container projections with the released Ota binary, updated the caller bindings, and re-ran them.

The result is two linked release-backed proofs at commit
409bcc073d:
the contract matrix installed
Ota v1.6.25, executed restore and build on native and container Linux, and dry-ran the selected
surface on macOS and Windows. The managed governance run
verified both regenerated identities before executing the finite task and archiving its receipt.

This is the ownership split Ota needs: the contract owns restore, verification, admission, mode,
and projection identity; GitHub retains its provider policy. Neither side has to duplicate the
other's truth.

Why the refusal matters

Bootstrap truth is execution truth. Changing an Ota source from an implementation branch to a
release changes the engine that interprets the contract, so it must change the projected lane's
identity too. Treating that as a cosmetic edit would let a caller keep asserting governance that it
was no longer able to reproduce.

The initial refusal made the mismatch actionable: no task ran, the expected identity was reported,
and ota ci github sync could regenerate the Ota-owned files from the same release that CI would
install. That is a better failure mode than a hand-maintained workflow silently drifting until a
toolchain or execution change reveals it later.

Why the split is practical

This is not an argument that all GitHub workflow YAML should disappear. nopCommerce still needs
provider-owned decisions that are specific to the repository: when to run, which runner to use,
what credentials are available, and how releases are protected. Those are not contract defaults.

What Ota can own without overreaching is the governed lane inside that caller: the selected
workflow, its toolchain fulfillment, native or container mode, agent admission, and the stable
check identity branch protection can require. That leaves a small human-owned adapter instead of
two independently authored execution plans.

Boundary

This is a restore-and-build baseline, not full nopCommerce proof. The modeled test task was
admitted and dry-run but not executed. Database-backed behavior, frontend workflows, runtime
readiness, Windows execution, and deployment remain outside the claim. The container image uses a
tag rather than a digest, so the container result is run-specific execution evidence, not immutable
image provenance.

Pressure-testing Ota on Azure SDK for .NET: typed NuGet hydration across ephemeral containers

Bobai Kato — Mon, 10 Aug 2026 14:29:16 +0000

Overview

Azure SDK for .NET is a large multi-service repository. Its contributor, test, API-compatibility,
code-generation, live-resource, and release paths are not one runnable surface.

The Ota contract therefore owns one useful contributor slice and names it plainly:

restore the dependencies for sdk/core/Azure.Core through the repository's NuGet.Config;
build that library with --no-restore;
execute the same sequence in native mode and in a fresh .NET SDK container.

That is enough to pressure a real boundary without pretending that a green build means the Azure
SDK repository, its services, or its releases are ready.

The Contract

The repository owns package-source policy. Ota owns the typed restore operation that consumes it:

tasks:
  setup:
    prepare:
      kind: dependency_hydration
      medium: package_dependencies
      source:
        kind: dotnet_restore
        cwd: sdk/core/Azure.Core/src
        config_file: ../../../../NuGet.Config

The later build is deliberately no-restore:

tasks:
  build:
    depends_on: [setup]
    command:
      exe: dotnet
      args: [build, --no-restore, --framework, net10.0]
      cwd: sdk/core/Azure.Core/src

This makes the boundary testable. If restore state does not reach the build, --no-restore fails
instead of silently going back to the network.

Ephemeral Container Cache Ownership

The selected container context is ephemeral, so restore and build do not share a long-lived
container. The contract declares the NuGet cache as Ota-managed attachment state:

execution:
  contexts:
    dotnet:container:
      backend: container
      lifecycle: ephemeral
      container:
        image: mcr.microsoft.com/dotnet/sdk:10.0.103
      attachments:
        isolated_paths:
          - .nuget/packages

Ota derives NUGET_PACKAGES for the selected context and carries that cache across the restore and
later no-restore build containers. The repo does not need to duplicate a host cache path or a
Docker volume name in a helper script.

Azure SDK exposed two Ota corrections while this was pressure-tested:

command tasks must mount the contract root, then apply command.cwd inside it, because restore writes shared intermediates under the repository artifacts/ tree;
typed dotnet_restore must carry the resolved NuGet package cache into later ephemeral tasks, not merely report that restore exited successfully.

Those are runner ownership fixes. They are not Azure-specific workflow glue.

.NET Version Truth

The contract follows global.json, which requests 10.0.103 with rollForward: feature:

toolchains:
  dotnet:
    version: ">=10.0.103, <10.1.0"

That admits valid servicing releases in the same feature band. An exact patch equality would turn
the repository's declared roll-forward policy into a false readiness failure.

Released Matrix

The requalification matrix installs Ota from the contract as released v1.6.25, verifies the
binary version before any Ota command runs, and pins all GitHub Actions by immutable revision.

The released four-lane matrix
is green. Every lane recorded ota v1.6.25 (source, commit a3e9f98f3) before running Ota.

It covers:

validate, Doctor, task/workflow discovery, and safe/unsafe task-surface discovery;
task and workflow dry-runs on Ubuntu, macOS, Windows, and Ubuntu container mode;
real restore, no-restore build, and declared workflow execution in each advertised mode;
retained version, diagnosis, contract snapshot, and archived workflow receipt artifacts on every result.

The receipts agree on one contract snapshot:
sha256:f7a96703141dc4e6cbb9626e0f893f4692d781db48113ac639c18770d972134b.
The Ubuntu container receipt records dotnet:container with ephemeral lifecycle; the other three
receipts record the native context. A historical matrix that installed an implementation branch is
not evidence for this release claim.

What It Does Not Prove

This is selected-lane evidence only. It does not prove:

every Azure SDK client library, test suite, API-compatibility check, generator, or release build;
Azure credentials, live-resource tests, external package-feed availability, or service behavior;
application correctness, package publication, or repository-wide readiness;
container execution on macOS or Windows, where those lanes exercise native contract execution;
hermetic replay or a contract-pinned expected identity for the SDK image tag.

The last point is an intentional limitation to keep visible: this contract records the configured
SDK image tag, not an immutable image digest. A mutable tag is not a maintainer-declared immutable
input, so this is not a claim of a pinned container base.

Why This Matters

The useful result is not that Ota can invoke dotnet restore.

It is that the contract declares dependency intent once, while the runner owns the workspace and
cache continuity needed to make a later no-restore build meaningful across fresh containers. The
result remains narrow, inspectable, and honest about the much larger Azure SDK surface it does not
govern.

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

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

Bobai Kato — Wed, 29 Jul 2026 19:40:13 +0000

Idea

v1.6.25 is an execution-authority release.

Ota already gave repositories one contract for setup, readiness, tasks, workflows, and agent
boundaries. The next problem was harder: how should a consumer decide whether the resulting green
run deserves trust?

A contract can be internally valid while making a claim that available evidence does not support.
A CI workflow can be green while executing a different closure from the one the contract governs.
A generated baseline can be present while nobody can prove who recorded it, which version was
reviewed, or whether replay was allowed to rewrite it. A service can become ready while teardown
remains unobserved.

v1.6.25 addresses those gaps by making authority more explicit:

CI lanes are deterministic projections of contract truth, not another hand-maintained execution source.
prerequisite freshness is derived from runner-witnessed provenance, not a maintainer-authored cold: true label.
replay consumes an explicitly promoted baseline identity, never whichever recording happens to be newest.
lifecycle proof owns startup, readiness, assertion, and finalization as one bounded transaction.
safety and proof claims remain qualified when the available evidence is incomplete.

The result is not “more green.” It is a stronger account of what made the run green, which
authority admitted it, and where the proof stops.

Feature

1. CI can now be projected from the contract

v1.6.25 introduces a provider-neutral CI projection:

ota ci projection \
  --workflow verify \
  --mode container \
  --target-os linux \
  --json

The projection binds the selected workflow, effective execution mode, target operating system,
bootstrap truth, toolchain ownership, governance decision, proof requirements, and stable merge
check identities.

GitHub Actions is the first adapter:

ota ci github render --workflow verify --mode container --target-os linux
ota ci github check --workflow verify --mode container --target-os linux
ota ci github sync --workflow verify --mode container --target-os linux

All three commands use the same canonical renderer. check detects drift. sync writes only the
Ota-owned reusable workflow and refuses unowned or unsafe paths.

The ownership boundary is deliberate. Ota owns the governed verification lane. The provider-owned
caller keeps triggers, permissions, environments, scheduling, deployment, and platform policy.
This avoids replacing two manually maintained sources of execution truth with fragile
bidirectional synchronization.

Generated lanes also preserve execution semantics:

finite verification runs the selected task closure, not readiness-only ota up
runtime-proof lanes execute through one authoritative proof wrapper instead of running twice
native toolchains are projected from contract truth
container-owned toolchains stay inside the declared image
impossible mode or target-OS combinations are refused before rendering

The provider-neutral model is the product surface. GitHub is an adapter, not the architecture.

2. Agent refusal can be tested at the real chokepoint

Safety metadata is useful only if the runner still enforces it.

Repositories can now declare refusal canaries for tasks and workflows that must remain unavailable
to agents:

agent:
  refusal_canaries:
    - task: publish
    - workflow: release

The canary uses the ordinary runner admission path:

ota run --agent --expect-refusal publish
ota up --agent --expect-refusal --workflow release

It succeeds only when Ota observes the expected safety-boundary refusal before work starts. An
admitted target fails the canary. A refusal at the wrong governance boundary does not silently
stand in for the safety control being tested.

Managed CI projects each canary as its own provider check with a stable merge-check identity. That
turns “this lane is unsafe for agents” from static metadata into a negative control on the actual
runner chokepoint.

3. Doctor separates declaration, evidence, and policy

ota doctor --json now carries contract-claim assurance without pretending that Ota can infer
missing intent.

For agent-safety and proof-breadth claims, the output keeps four truths separate:

what the maintainer declared
what closure the runner derives and enforces
whether observable evidence is supported, contradicted, or unknown
what policy decides to do with that assurance

unknown is important. A structurally valid contract is not independently proven merely because
nothing contradicted it.

Archived runtime proof can support a bounded proof claim only when its contract snapshot, source
identity, selected scope, execution mode, and replay posture match the current lane. Stale,
scope-mismatched, or absent evidence stays unknown.

This is also why execution success and proof breadth remain separate. ok: true means the selected
execution/readiness operation succeeded. Consumers must read proof_verdict and not_proved[]
before deciding what the artifact established.

4. Freshness is now runner-authored provenance

“It worked in a fresh environment” is a useful claim, but only when the runner can show which
prerequisites were absent, created, reused, and later asserted.

Runtime proof now carries an execution-boundary evidence graph for supported prerequisite classes.
The graph binds precondition observations, producer events, assertion observations, identities,
scope, and ordering to the current execution.

Ota derives two independent results:

target_freshness, such as cold_start_verified, persistent_state_reused, or unknown
derivation_posture, such as fully_derived, cache_assisted, inherited_immutable, or unknown

That separation matters. A clean node_modules target rebuilt with a reused download cache can be
cold for runtime state while still being cache-assisted. A pre-existing virtual environment with
a matching identity is verified reused, not cold.

The first carriers are intentionally narrow:

native virtual environments
native frozen pnpm hydration
compatible finite ephemeral-container dependency closures

Ota does not generalize those observations into whole-machine freshness. Uninstrumented services,
databases, volumes, provider-managed state, and unsupported package-manager layouts remain
unknown.

5. Generated baselines have an explicit authority chain

v1.6.25 adds first-class record, promote, and replay authority for generated baselines:

ota baseline record --artifact answer-key
ota baseline promote \
  --artifact answer-key \
  --attestation .ota/recordings/answer-key.json

The authority chain is explicit:

producer run
  -> recorded attestation
  -> explicit promotion
  -> immutable selected authority
  -> bounded replay

Recording binds the producer receipt, semantic contract identity, source state, execution-boundary
graph, and complete canonical output manifest. Promotion selects one named attestation
atomically. Replay consumes only the promoted identity; it never selects “latest” and never
rewrites authority.

Strict read_only replay uses a runner-owned snapshot outside the writable worktree and projects
it across the full ephemeral-container consumer closure. Native and other non-strict lanes can use
verify_unchanged, which detects mutation after execution without falsely claiming that writes
were structurally prevented.

Portable manifests name scm_review as an external trust root. Ota verifies the selected manifest
and content identities, but it does not claim to have verified repository review, reviewer
identity, or signer provenance. That delivery-system authority remains outside Ota.

Replay-input pins are stronger too. Authors can optionally declare an immutable expected identity:

replay_inputs:
  - id: frozen_store
    kind: static_file
    path: data/store.db
    expected_identity: sha256:4d8c...

Ota computes the observed identity before execution and refuses missing or mismatched pins before
setup, hydration, service ownership, or task startup. Expected and observed identities remain in
machine-readable refusal evidence.

6. Lifecycle proof owns finalization, not just readiness

ota proof lifecycle adds a bounded transaction for manager-owned service closures:

ota proof lifecycle --workflow integration --json --archive

The transaction orders:

prerequisite execution
initial-state observation
cleanup-lease acquisition
service startup
readiness
an optional finite assertion
reverse-order teardown
terminal finalization observation

Ota leases only services it can prove were inactive before startup. It does not claim ownership of
pre-existing services. Cleanup runs after acquired ownership on success, failure, or interruption,
and isolated container boundaries are complete only after the engine confirms that the exact
session is absent.

Lifecycle archives bind the semantic contract snapshot, source identity, selected workflow and
service closure, execution scope, target OS, boundary identity, transaction records, and qualified
verdict. Archive verification re-derives service selection and teardown authority from the
snapshot instead of trusting archive-authored labels.

The boundary remains narrow: lifecycle proof can establish the selected startup/readiness/assertion
and finalization transaction. It does not prove broader application output, repository completion,
deployment safety, or provider policy.

7. Typed execution keeps replacing shell ownership

The release also closes several practical gaps uncovered while pressure-testing the larger trust
model:

command.interaction: auto | forbidden | required makes human TTY ownership explicit while keeping agent and non-TTY execution noninteractive
native Corepack activation prevents ambient Yarn or pnpm shims from bypassing declared versions
GitHub projection supports contract-owned Python/uv, Node/Corepack, Ruby, Go, and .NET toolchains
typed local-project Python hydration preserves editable posture, extras, groups, source, manifest, and lock identities
selected Ruby container lanes can fulfill the declared Bundler version before hydration
effects.network_kind: service_readiness distinguishes finite local probes from live integration tests

These changes are not independent conveniences. They remove shell and ambient-state ambiguity from
the execution paths that now produce stronger proof.

Boundaries

The most important v1.6.25 behavior is what it refuses to imply:

a successful command does not prove the wider repository
a supported contract claim does not prove the absence of hidden risk
a cold verified target does not prove whole-machine or provider-state freshness
a recovered seam marker does not prove that the dependency shaped broader application output
a lifecycle pass does not prove deployment or production health
a promoted baseline relies on the declared external review authority
a provider adapter does not transfer triggers, permissions, secrets, environments, or deployment policy into Ota

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

Pressure

The release was shaped by real repositories with different failure boundaries:

Kylrix and Outline pressured managed native/container CI projection and Corepack ownership.
OrchardCore and nopCommerce pressured typed .NET projection without transferring deployment policy into Ota.
Lead Quorum and Dograh pressured native Python fulfillment and local-project hydration.
EventCatalog pressured portable generated-baseline authority and detached replay consumers.
Bedrock pressured the separation between declared replay inputs and witnessed model behavior.
Caddy and Open WebUI pressured lifecycle ownership across isolated and Compose-backed managers.
Athena API pressured bounded dependency proof and typed Ruby/Bundler execution.

The useful outcome was not that every repository became globally governed. Each pressure pass
either moved material behavior into the contract, carried a machine-readable not_proved
boundary, kept provider-owned behavior outside Ota, or exposed a named platform gap.

Docs

Use the live references for exact authoring and machine-consumer semantics:

Release

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

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

For the new proof and CI surfaces:

ota ci projection --workflow verify --mode native --target-os linux --json
ota proof runtime --workflow verify --json --archive
ota proof lifecycle --workflow integration --json --archive

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

v1.6.25 moves Ota from declared execution governance toward evidence-bound execution authority:
not only what should run, but which closure ran, what state it relied on, who selected the replay
truth, which cleanup Ota owned, and what the resulting green artifact still did not prove.

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

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

DEV Community: Bobai Kato

Pressure-testing Ota on Flagr: native and container Go verification with honest boundaries

Overview

Why this repo mattered

What the contract models

What Flagr exposed in Ota

Matrix design

Doctor stayed honest

Uncovered material behavior

Contract-owned and exercised

Explicitly outside this proof

Ota platform gaps

What this did not prove

Hosted result

Links

Test What Your AI Agents Must Not Do

A Guardrail Without A Negative Test Is Still An Assumption

What A Refusal Canary Tests

Expected Refusal Becomes A Passing Test

Why This Must Run Through The Real Runner

Put Refusal Canaries In CI

What Refusal Canaries Prove

Turn Incidents Into Permanent Negative Tests

Choosing Useful Canaries

Try It In Your Repository

The Larger Point

Go Deeper

Pressure-testing Ota on nopCommerce: managed .NET verification across native and container CI

The question

The pressure result

Why the refusal matters

Why the split is practical

Boundary

Links

Pressure-testing Ota on Azure SDK for .NET: typed NuGet hydration across ephemeral containers

Overview

The Contract

Ephemeral Container Cache Ownership

.NET Version Truth

Released Matrix

What It Does Not Prove

Why This Matters

Links

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

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

Idea

Feature

1. CI can now be projected from the contract

2. Agent refusal can be tested at the real chokepoint

3. Doctor separates declaration, evidence, and policy

4. Freshness is now runner-authored provenance

5. Generated baselines have an explicit authority chain

6. Lifecycle proof owns finalization, not just readiness

7. Typed execution keeps replacing shell ownership

Boundaries

`exercised` requires current-transaction evidence

`fault_tested` requires the right red