← Back to blog
Engineering note2026-09-16 11:11 UTC

V12: Effect-Bound Refusal Assurance Starts Before Execution

V12 gives Ota a bounded, typed path from a declared database change to a verified refusal before the selected execution closure starts, without mistaking that negative evidence for provider authority or successful mutation.

The problem

A repository can declare that a task changes a database, but that declaration alone is not an execution boundary. A command may select a different working directory, read different migration bytes, reach the task through a workflow hook, or execute after policy and setup have already changed state.

V12 closes a narrower and more useful gap: when Ota sees a declared database_schema_mutation, it can derive the exact selected realization and refuse it before the selected execution path begins. The result is not an assertion that a database was protected. It is evidence about one exact contract-bound lane and the controls Ota actually witnessed.

The model

V12 turns a typed database-migration declaration into several separately bound facts:

  • A canonical resource identifies the intended database namespace.
  • The effect, attachment, evidence, and realization use distinct content-addressed identities.
  • A migration manifest captures the exact selected files, bytes, working directory, invocation

origin, and application-plan inputs.

  • Policy evaluates that realization, not a broad task label or an arbitrary shell command.
  • The command-level admission is retained across ota run, ota up, proof paths, CI projection,

and sandbox capability reporting rather than reconstructed with different inputs later.

That separation matters. Two tasks can refer to the same conceptual effect while remaining distinct attachments and realizations. A declared-only command is not silently promoted into a typed, eligible realization. An unselected mode does not enter a selected-mode decision.

Refuse Before Work Starts

For a selected typed closure, Ota derives and verifies the plan before replay evaluation, authority or sandbox admission, environment rendering, setup, services, dependencies, shell dispatch, or provider contact. An explicit typed deny produces a stable refusal with execution_started: false.

This is intentionally stronger than a late runner error and intentionally weaker than a claim about the provider. Ota owns the boundary before its own selected path begins. It does not claim to have observed every child process a third-party provider might create, nor does it claim that a provider would have rejected the same operation independently.

ota up --dry-run follows the same admission model. Its blocked preview retains the selected plan and available decision evidence, but contains only the refusal action. It does not describe the lane as runnable or say that it would execute a command.

Canaries, Archives, And Doctor

An effect-refusal canary is a negative control for one exact task or workflow invocation. A pass requires an eligible typed realization, an aggregate deny, and an applicable explicit typed-deny rule. Strict fallback, a coarse refusal, an unrelated rule, an unavailable policy, an unknown canary, or an ambiguous origin cannot become a passing canary.

Operators can explicitly create a private workflow refusal archive after a typed denial. Ota later re-derives the archived contract, selected closure, migration plan, policy snapshot, decision, typed-deny basis, and pre-execution posture. Tampering with any of that context makes the archive invalid.

Doctor can promote only the exact current workflow challenge supported by a verified private archive. Adjacent task claims, stale evidence, ambiguous matches, and opaque execution paths remain unknown. The archive-derived candidate surface is also deliberately review-only: it is reconciliation-bound, has no application projection, and refuses write attempts. Negative evidence must not quietly become mutation authority.

What We Tested

The canonical pressure evidence registry records exact revisions, matrices, exercised surfaces, and limits. It is the evidence source; this article is the engineering explanation.

The bounded V12 matrices exercised selected task and workflow refusal controls on Linux and macOS, including retained-byte drift, symlink refusal, policy decision reconciliation, canary behavior, private archive history, Doctor fallback after tampering, and review-only candidate reconciliation. The final real-repository controls ran against forked Plausible and Outline revisions, while the Core controls covered the command and preview boundaries.

Those retained artifacts establish only their selected, instrumented controls. The public pressure index is generated from Core-owned records so the Site does not become a second source of truth.

What V12 Does Not Claim

V12 is provider-disabled negative evidence. It does not prove:

  • provider contact, authorization, or mutation behavior;
  • database migration success, rollback, correctness, or data integrity;
  • absence of arbitrary child processes or complete repository immutability;
  • independently administered policy authority;
  • positive execution receipts, positive assurance, or public archive-export safety; or
  • repository-wide readiness or coverage outside the selected contract closure.

Those limits are part of the design, not release-note fine print. A trustworthy execution-governance system must retain the difference between a refusal Ota witnessed and an outcome it did not.

Where To Start

V12 adds a typed, execution-disabled foundation rather than a general database executor. Start by reviewing a contract, its effect declarations, and the resulting machine-readable posture:

INSPECT TYPED EFFECT POSTUREbash
ota validateota run <task> --dry-run --jsonota up --workflow <workflow> --dry-run --jsonota doctor --json

For a contract that declares the production_schema_refusal canary on db:migrate, challenge the actual agent admission boundary:

CHALLENGE AN EFFECT REFUSALbash
ota run --agent --expect-effect-refusal production_schema_refusal --json db:migrate

A passing response includes these fields (excerpt):

EFFECT REFUSAL EVIDENCEjson
{
  "status": "passed",
  "canary": {
    "lane_kind": "task",
    "lane_target": "db:migrate",
    "actual_decision": "deny",
    "execution_started": false
  }
}

This passes only when an explicit typed rule denies that exact eligible effect realization before execution. A generic agent refusal or an unavailable policy does not satisfy the canary.

Use the contract reference, policy-pack reference, and pressure-testing index for the live specification, operator guidance, and exact retained evidence.

V12 is complete as a bounded effect-refusal assurance slice. Secret-delivery governance belongs to the separate V12.1 slice; it is not established by the refusal evidence in this article.