Audited Execution Boundary Crossings

Ota's released governance and receipt surfaces distinguish routine execution from a heavier selected lane that requires an audited crossing.

The runner derives crossing posture from the selected execution truth and keeps the crossing record separate from ordinary success or refusal.

• crossing_required says whether the selected path leaves the routine boundary
• crossing_classification distinguishes the released routine and escalated postures
• the crossing record is runner-authored execution evidence and can carry reason and bounded actor context
• a crossing record is never reusable authority for another run
• receipts and governance output keep crossing evidence linked to the selected execution instead of burying it in logs

• agent mode refuses unsafe closures; a grant must never bypass that boundary
• audited crossing is for allowed-but-heavier non-agent execution, not a loophole for unsafe agent execution
• routine tasks should not require ceremonial approval records
• heavier publish, migration, deployment, external-effect, or black-box lanes need explicit evidence when they cross the declared default boundary

The signed grant carrier described below is active work on the 1.6.26-implementation branch. It is not a released or complete authority surface.

Do not publish repository-owned keys or bundles as a workaround; that would let the caller self-issue authority.

• the repository names only an authority identity
• trust keys, signed bundle location, revocation state, sequence state, and clock high-water evidence must stay outside caller-controlled repo state
• on Linux, the provisioner installs only the fixed trust-store binding at /etc/ota/crossing-authorities.json; that binding identifies separately protected bundle and sequence state, normally under /var/lib/ota/
• the signed-file carrier is filesystem-guarded only against the current Ota process; the Unix broker carrier separately verifies challenge-bound launcher attestation and atomically consumes one exact lease for run/up
• a grant must bind exact contract identity, semantic selected closure, crossing family/classification, actor posture, mode, lifecycle, platform, effects, and a bounded validity window
• missing, stale, revoked, rolled-back, or out-of-scope authority must refuse before selected-lane side effects
• real admitted execution must create a fresh runner-owned crossing transaction; dry-run and refusal must not mint a crossing record

governance:  crossing_authority:    authority_id: platform-release-authority

ota run publish --grant approved-publish

Until those gates close, this page is an evolving design and implementation reference, not a claim that Ota has shipped reusable enterprise approval authority.

• hosted pressure for the broker-backed one-use carrier
• one terminal broker transaction across complete runtime/lifecycle proof invocation and cleanup sets
• stronger provider/launcher-attested separation beyond the protocol claims Ota currently verifies
• broader platform-specific protected-system authority support

• reuse a live grant only when its exact scope and liveness still hold; never reuse the crossing record
• mint a fresh boundary-authored crossing record for every execution
• keep principal, authorizer, and runner context separate when the evidence can support them
• expire grants by bounded work or short lifetime rather than open-ended standing authority
• treat an externally managed approval system as an authority source, not as evidence that a previous run succeeded