Why ok: true Is Not Enough for AI Agent Execution

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.

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.

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.

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

1. Require ok: true for the selected execution.
2. Confirm proof_scope matches the task or workflow it intended to prove.
3. Read proof_verdict; do not translate every green execution into an unqualified proof pass.
4. Inspect not_proved[] for a boundary relevant to the next action.
5. 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.

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.

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.

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.

• Runtime Proof Evidence
• Execution Receipt
• JSON Output Reference
• Execution Governance Loop
• Ota v1.6.24