Operations and Authority

Operations and Authority

Keep five states separate

CCR intentionally separates:

plan -> preflight -> parameter-bound approval -> dispatch -> observation verification

The readiness flags also have distinct meanings:

State	Meaning	Not equivalent to
operation_ready	A finite trace contains enough structure to plan a scoped handoff.	Execution
provider_dispatch_ready	Provider preflight and policy checks pass.	Dispatch
physical_dispatch_ready	Physical certificate fields are accepted and fresh.	A physical outcome
executed=true	A source report records that a dispatch attempt occurred.	Verified physical effect
physical_outcome_verified=true	A trusted signed observation passes scope and time checks.	A universal or enduring truth claim

Planning, preflight, replay, and observation verification are local evidence-review actions. A replay can preserve executed=true from a source report, but replay itself keeps external_execution=false and does not dispatch anything.

Parameter-bound approval

An approval artifact binds one exact plan and provider configuration:

ccr operation approve --plan plan.json --provider http --config config.json \
  --approver human.operator --expires-at 2030-01-01T00:00:00Z \
  --nonce operation.1 --json

CCR binds the plan digest, provider, arguments, resource limits, scope, expiry, nonce, and use count. Dispatch rechecks the authority against current system time and atomically consumes one use. A plan, provider configuration, scope, or resource limit must not be substituted after approval.

Dispatch is the external-effect boundary

ccr operation dispatch --execute is the designated external-effect boundary. It requires a matching operation plan and preflight, explicit --execute, allow_execute=true, an operator-approval reference, a dispatchable side-effect policy, a closed provider circuit, and an accepted provider plan. Physical providers require an additional physical gate.

Generic ccr provider execute cannot bypass the operation gate for a network provider. HTTP dispatch requires HTTPS, an exact host allowlist, public-address DNS resolution, redirect denial, and time and byte limits.

Physical outcomes require independent observation

Dispatch only reports that an action was attempted. physical_outcome_proven is always false for compatibility. A separate signed, scoped, in-window verifier report is required for physical_outcome_verified=true.

If verifier acceptance, rollback confirmation, hazard follow-up, or incident evidence is missing, CCR records residual-ready work rather than inferring success.

Operational rule of thumb

Treat external content and tool descriptors as untrusted input. Treat plans as proposals. Treat preflight as a boundary check. Treat approval as a narrow, expiring authorization. Treat dispatch and observation as separate evidence events.

For runtime security controls, see Scope, Security, and Non-Claims.