Governance · Lesson 03 of 03
What Ota can enforce vs what requires a chokepoint
Ota enforces within its execution scope. Anything outside — provider policy, shell orchestration, external systems — requires an adopted chokepoint to be enforceable.
Learning objectives
- List three things Ota can enforce natively
- List three things that require an external chokepoint
- Explain why provider and authority boundaries matter for governance
Prerequisites
Ota can enforce only where execution enters an adopted Ota or provider chokepoint. A contract is canonical policy truth, but a process with unrestricted raw-shell access can route around a CLI it is not required to use.
Three enforcement points
Local Ota execution provides fast admission feedback. Mandatory CI checks decide merge acceptance. Agent harnesses or sandboxes constrain runtime capabilities. The same contract can inform all three without claiming that one surface controls the others automatically.
ota run --agent --json deployCanonical terminology
Evidence boundary for this lesson
Establishes
- The worked examples establish the lesson's canonical Ota distinctions for its stated scope.
Does not establish
- Reading the lesson does not validate a repository, execute its tasks, or establish organizational acceptance.
Knowledge check
Can ota.yaml stop an unrestricted process from invoking raw shell?
No. The contract becomes non-optional only where execution, CI, or an agent harness adopts an enforcing Ota-aware chokepoint.