Permission model
Capability registration, standing permission, and exact approval are separate. Conflating them would create accidental authority.
1. Capability registration
A versioned manifest describes what an application/skill may request. Registration is owner/admin-only in the canonical registry and grants zero authority.
2. Standing policy
Standing policy returns only ALLOW, REQUIRE_APPROVAL, or DENY. User-facing “Ask” means REQUIRE_APPROVAL; it is not a fourth runtime authority state.
At equal specificity, conflict resolves DENY > REQUIRE_APPROVAL > ALLOW. Absence of an applicable configured rule/default is DENY.
3. Exact approval
When policy returns REQUIRE_APPROVAL, an owner approval binds one exact canonical request. Approval creation itself does not execute the effect. Current policy is re-evaluated before dispatch; a current deny still wins.
First-use capability / permission discovery
Unknown actions, resource scopes, unsupported capability versions, materially new argument shapes, or valid registered requests with no configured standing permission fail closed. The current effect is terminally denied, no execution lease or adapter mutation occurs, and bounded owner-reviewable permission work may be created or aggregated.
Owner choices in governed Pi
| Choice | Effect |
|---|---|
| Allow once | Configures REQUIRE_APPROVAL for the bound scope, creates a fresh continuation request, then requires an exact one-time approval before a separate resume can execute. |
| Always allow | Creates a scoped standing allow rule for future matching requests. |
| Ask every time | Creates standing REQUIRE_APPROVAL; each matching request needs an exact owner approval. |
| Deny once | Closes only the exact continuation and creates no standing policy. |
| Always deny | Creates a scoped standing deny rule. |
Cancellation is non-authorizing. Owner-choice input does not bypass capability validation, emergency pause, deny precedence, current-policy re-evaluation, exact approval binding, leases, sandboxing, or idempotency.
Restart / continuation behavior
Continuation state is durable, non-authoritative workflow metadata. Restart can recover blocked state, but it cannot dispatch automatically. A continuation may submit at most one fresh request derived from immutable captured intent; that request receives the full current authority evaluation.