Related OSS

Related OSS

PIC has a companion open-source project:

Collective Capability Runtime, or CCR, is an agent-native Python runtime for coordinating distributed AI-agent work into reusable, verifiable, residual-preserving capability artifacts.

Short Version

Use PIC when you need to check agent output, preserve proof obligations, export schemas, run Phase Ecology Lab diagnostics, or create protocol-relative certificate candidates.

Use CCR when you need a local runtime that coordinates many agents through task leasing, blackboard memory, packet distillation, provider imports, residual tracking, phase formation, and release audits.

The two projects are complementary. CCR does not replace PIC. PIC output does not automatically settle CCR.

v0.6.0 makes the handoff explicit: PIC can emit ccr.task.v0.1 and ccr.residual.v0.1 JSONL, while CCR remains responsible for import policy, leases, provider authority, witness checks, and settlement.

PIC Owns

• packet-level checks;
• verifier routing;
• proof obligations;
• residual ledgers;
• JSON schemas for PIC records;
• Phase Ecology Lab diagnostics;
• ECPT, BIT, TRC, SQOT, and ALT diagnostic surfaces;
• CCR task and residual JSONL emission;
• TRC trace normalization and operation-readiness checks;
• protocol-relative certificate candidates.

CCR Owns

• multi-agent task queues;
• task leases and role separation;
• blackboard events;
• packet distillation;
• local packet status;
• residual preservation across runtime steps;
• provider plan, execute, and import orchestration;
• SQLite indexing of JSON artifacts;
• phase formation over local CCR packet state;
• repository and release audits.

Interoperation Boundary

CCR can call or import PIC-compatible reports as provider evidence. That is useful for packet checks, phase diagnostics, task creation, and residual preservation.

The safety rule stays strict:

• PIC accepted=true is not CCR settlement.
• PIC settled=true is provider evidence, not automatic CCR final settlement.
• PIC operation_ready=true is a trace-readiness record, not provider execution.
• PIC-emitted constraints.allowed_commands=[] means no command is authorized by the handoff record.
• PIC safe_commands are task hints, not authority to execute.
• Candidate-only packet volume is diagnostic, not progress.
• Residuals must stay visible in both systems.

Common Workflow

agents create candidate work
-> CCR stores tasks, packets, leases, and blackboard events
-> PIC checks candidate packets or phase reports
-> PIC emits CCR task or residual JSONL when handoff is needed
-> CCR imports normalized provider reports
-> residuals and task hints are preserved
-> humans or agents resolve the next explicit checks

Safety Boundary

Neither PIC nor CCR proves real ASI, physical truth, oracle truth, legal authority, or policy success.

Neither project grants automatic shell execution, repository mutation, package installation, network access, credential use, model-weight change, or self-rewrite.

Links

• CCR repository: kadubon/collective-capability-runtime
• PIC repository: kadubon/percolation-inversion-compiler
• CCR-PIC interoperability document: INTEROP_PIC.md