From Execution Logs to Governance Verdicts in Ota

Most execution tooling still makes operators do too much reconstruction work.

You get:

• command output
• step logs
• maybe a receipt
• maybe a CI summary

But the hardest governance questions are usually left implicit:

• was this lane allowed or only runnable
• should this path have been refused
• was review required
• was proof expected
• did the result satisfy the declared governance bar

That is the gap Ota is closing.

The point is not to replace logs.

The point is to stop treating logs as the primary governance artifact.

Logs are still useful for detail. But governance should be emitted as structured truth:

• what Ota decided before execution
• what basis that decision used
• what evidence was expected after execution
• what evidence was actually present

That is a better operator surface, a better CI surface, and a much better agent surface.

Ota’s governance output is now moving from flat status reporting toward explicit verdict records.

For ota up --json, the shipped governance surface is:

• governance.preflight
• governance.post_execution

For selected-task preview and discovery surfaces such as ota run <task> --dry-run --json, the same phase split is exposed under:

• governance.evaluation.preflight
• governance.evaluation.post_execution

That split matters.

Preflight answers:

• is this lane allowed
• is it refused
• is it blocked
• is review required
• is a receipt or proof expected

Post-execution answers:

• did execution happen
• was it refused before execution
• was the evidence bar satisfied
• is proof missing
• is there a receipt-linked crossing record

That is stronger than asking an operator, CI job, or agent to infer all of that from prose.

The important shift is not just “more JSON.”

It is that Ota is turning governance into a first-class output surface instead of an accidental by-product of command execution.

That means a machine consumer can now read stable fields such as:

• governance.preflight.state on ota up --json
• governance.preflight.decision_basis[] on ota up --json
• governance.post_execution.state on ota up --json
• governance.post_execution.decision_basis[] on ota up --json

And on selected-task preview surfaces:

• governance.evaluation.preflight.state
• governance.evaluation.preflight.decision_basis[]
• governance.evaluation.post_execution.state
• governance.evaluation.post_execution.decision_basis[]

And, in the newer trust-refinement layer:

• governance.preflight.evidence_classes
• governance.post_execution.evidence_classes
• governance.evaluation.preflight.evidence_classes
• governance.evaluation.post_execution.evidence_classes

Those fields let downstream consumers distinguish:

• caller-asserted intent
• Ota-derived governance truth
• boundary-attested evidence such as receipt attachment state

That distinction matters because a structured field is only valuable if it is honest about what kind of truth it carries.

Here is the shipped shape from ota up --json when Ota can already distinguish preflight posture from post-execution evidence posture:

{
  "governance": {
    "preflight": {
      "state": "allowed",
      "crossing_required": false,
      "crossing_classification": "routine",
      "evidence_classes": {
        "state": "derived",
        "crossing_required": "derived",
        "crossing_classification": "derived",
        "receipt_expected": "derived",
        "proof_expected": "derived"
      },
      "receipt_expected": true,
      "proof_expected": true
    },
    "post_execution": {
      "state": "evidence_missing",
      "execution_attempted": true,
      "refusal_occurred": false,
      "decision_basis": [
        {
          "id": "evidence:receipt_present",
          "family": "evidence_gate",
          "evidence_class": "attested"
        },
        {
          "id": "receipt_status:ready",
          "family": "receipt_evidence",
          "evidence_class": "attested"
        },
        {
          "id": "evidence:proof_missing",
          "family": "evidence_gate",
          "evidence_class": "derived"
        },
        {
          "id": "crossing_record:not_required",
          "family": "crossing_evidence",
          "evidence_class": "derived"
        }
      ],
      "evidence_classes": {
        "state": "derived",
        "execution_attempted": "derived",
        "refusal_occurred": "derived",
        "crossing_record_state": "derived",
        "receipt_present": "attested",
        "proof_present": "derived"
      },
      "receipt_present": true,
      "proof_present": false
    }
  }
}

The exact field set still varies by command surface. ota up --json uses governance.preflight / governance.post_execution, while selected-task preview surfaces keep the same split under governance.evaluation.*. What is now shipped consistently is:

• preflight verdict
• cited basis
• post-execution evidence verdict
• cited evidence basis
• provenance on authoritative fields

Logs are still where you go for:

• full process output
• stack traces
• backend-specific details
• raw command detail

But logs are weak as the primary governance surface because they force reconstruction.

A governance verdict should let an operator, CI system, or agent answer questions like:

• was this refusal expected
• which policy or boundary actually blocked it
• was proof required here
• did the final state satisfy the declared bar
• is the result authoritative or only advisory

Those are not log-parsing questions.

They are governance questions.

That is why Ota should emit them directly.

This matters even more for agents than for humans.

A human can read logs and infer intent.

An agent needs a stable contract.

If an agent only sees:

• command succeeded
• command failed
• here is some text

then it still has to guess:

• whether a lane was safe
• whether it crossed a boundary
• whether it should stop
• whether the missing artifact is proof, setup, or review

That is exactly the kind of ambiguity that produces unsafe automation and noisy PRs.

A structured governance verdict is stronger because it gives the agent a machine-readable stop sign or green light.

CI also gets better when governance is structured.

Without a real verdict surface, CI usually ends up proving only:

• some workflow ran
• some job passed

That is weaker than:

• the repo’s declared lane was allowed
• the required lane actually ran
• the expected evidence bar was satisfied
• the repo did not silently drift away from its declared governance truth

That is the direction Ota is taking:

• repo contract as the source of truth
• local runner as fast feedback
• machine-readable governance verdict as the integration surface

Then CI, agents, and later harnesses can all consume the same truth.

This does not mean Ota is done the moment a JSON block exists.

A governance verdict only earns trust if:

• it is emitted where the decision is made
• it cites the real decision basis
• it distinguishes derived truth from asserted truth
• it stays reconciled with the actual execution path

That is why later trust work matters too.

The bar is not just machine-readable governance.

The bar is machine-readable governance that is authoritative enough to stop a human or agent from having to reopen the logs for the first question.

Execution logs tell you what happened.

Governance verdicts should tell you what Ota allowed, refused, required, and verified.

That is the difference between command output and execution governance.

And that is where Ota gets stronger:

• not by hiding logs
• not by narrating more prose
• but by emitting the governance truth directly