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 bounded V11.7 OSS authority surface is available in Ota v1.6.26 and later. Earlier Ota releases do not include this carrier.

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

Completion means the reviewed OSS carrier and evidence boundary are implemented and pressure-proven. It does not mean Ota operates an enterprise approval service or establishes every provider and host-isolation property.

• the independently administered hardened-launcher and reboot/fault-recovery branches satisfy the V11.7 acceptance bar
• provider attestation remains optional stronger hardening and is not implied by the systemd launcher profile
• contract-authored crossing declarations remain follow-on authoring work; current crossing-required truth is derived from the shipped unsafe-task and heavier-workflow families
• non-Linux protected carriers, enterprise approval operation, and raw-shell governance outside an adopted Ota chokepoint remain outside this bounded slice

• 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