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.

In Ota v1.6.26 and later, Core provides signed authority plus a broker-backed one-use carrier. Independently administered Linux/x64 PID 1 pressure satisfies the bounded V11.7 OSS acceptance bar through the hardened-launcher alternative. Provider attestation remains optional stronger hardening; it is not implied by the systemd carrier.

The 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 explicit signed-file invocation is:

ota run publish --grant approved-publish

The signed-file 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.

The V11.7 OSS authority slice is available in Ota v1.6.26 and later. Earlier Ota releases do not include this carrier.

The first GitHub-hosted create-chrome-extension pressure proved that missing fixed authority refuses before selected work. Later independently administered Linux/x64 PID 1 pressure proved the hardened-launcher alternative, including one-use selected execution, protected history, and reboot/fault recovery.

The remaining boundaries are explicit follow-ons, not hidden V11.7 completion gates:

• provider-attested identity and image/runtime provenance for operators that require stronger provider-owned evidence than the independently administered launcher establishes
• contract-authored crossing declarations beyond the shipped derived unsafe_task and heavier_workflow families
• protected carriers for non-Linux platforms
• enterprise approval operation, centralized policy, and fleet retention
• enforcement against raw shell outside an adopted Ota execution chokepoint

Those are trust boundaries, not documentation polish.

Ota should therefore describe this as a completed bounded OSS authority carrier available in Ota v1.6.26 and later, not as provider attestation or a shipped enterprise approval control plane.

The mature model is:

• for the bounded signed-file carrier, reuse a still-live grant only while its exact scope remains valid
• for the 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
• Broker Crossing Authority
• Authority Launcher
• Authority Protocol
• Reference example