Providers and PIC Interoperability

Providers and PIC Interoperability

Providers contribute evidence, not authority

CCR can plan, execute, or import provider routes under explicit contracts. A provider report can add verifier evidence, residuals, candidate-only reasons, phase gaps, bottlenecks, and task hints. It does not silently promote a packet or settle a mission.

Provider-imported safe_commands are suggestions to inspect under operator control. They are never executed automatically.

PIC is optional

Percolation Inversion Compiler (PIC) is an optional finite checker and planning provider. Its absence is represented as a provider-missing residual, not as an internal CCR crash.

python -m pip install percolation-inversion-compiler
ccr provider health --provider pic --json
ccr audit pic --pic-root <PIC_ROOT> --json
ccr provider plan --provider pic --action verify_packet --packet <packet_id> --json

CCR owns task leasing, role separation, blackboard events, packet-state management, residual preservation, local graphs, baseline comparison, and local phase-certificate-candidate assembly. PIC supplies packet-level checks, ECPT/BIT/TRC/SQOT/ALT diagnostics, and PIC-native phase planning or certificate candidates. CCR does not reimplement PIC's certificate logic.

The non-settlement boundary

The following distinctions are deliberate:

PIC accepted             != CCR settled
PIC settled              != CCR settled
provider plan            != provider execution
safe command             != authority
execution available      != executed
candidate path           != settled capability

PIC/PIC-TS reports remain evidence-only after import. They do not grant authority, dispatch a provider, prove a physical outcome, or turn settled=false into a CCR settlement.

Typical route

ccr task next --role generator --json
ccr task lease <task_id> --ttl 30m --agent <agent_id> --json
ccr packet submit --file packet.json --json
ccr verify --provider pic --packet <packet_id> --profile development --json
ccr integrate --report reports/pic/<report>.json --json
ccr phase form --profile development --json

The verifier stage may be planned without execution. An execution-capable provider command requires an explicit operator request, required configuration, relevant policy gates, and --execute where supported.

How imported fields are handled

Provider/PIC field	CCR treatment
accepted or workflow_usable	Evidence attached to the existing packet status; import does not promote it.
settled	Settlement-candidate evidence; CCR still applies its own promotion, phase, baseline, lineage, risk, and residual gates.
candidate_only_reasons	Preserved as nonblocking residuals; they add no positive phase contribution.
settled_blockers, missing_obligations, cannot_promote_because	Preserved as blocking residuals.
safe_commands	Retained as tasks or open hints, never executed by import.
Phase bottlenecks	Used as deterministic scheduling input, not as a capability claim.

Other integration boundaries

MCP descriptor inspection, A2A handoff preflight, provider conformance, provider registry validation, operation replay, and observation verification are evidence-review or metadata-validation surfaces. They are not dispatch, authority, or proof of a physical outcome.

For the operation boundary itself, see Operations and Authority.