Why ok: true Is Not Enough for AI Agent Execution

#aiagents #runtimeproof #governance #executionsafety

A successful command is not broad authorization

ok: true answers one useful question:

Did the selected Ota execution complete successfully?

It does not answer:

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

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

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

Read the proof carrier, not one field

Run the declared workflow through Ota's proof boundary:

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

A successful but bounded result can look like this:

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

These fields are intentionally different:

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

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

Why a qualified pass is not a failure

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

It does not automatically prove:

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

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

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

What an agent should do next

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

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

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

The verdict is derived, not narrated

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

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

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

What this does not solve

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

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

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

The operational rule

For humans, agents, and CI:

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

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