Why Heavier Repository Execution Needs Audited Boundary Crossings

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.

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.

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.

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.

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 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.

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?

• Audited Execution Boundary Crossings
• Safe Agent Execution and Refusal
• Execution Receipt
• Execution Governance Loop
• Prebound Crossing Authority
• Preview example