Skip to content
kadubon edited this page Aug 25, 2026 · 2 revisions

Collective Capability Runtime

Collective Capability Runtime (CCR) is a JSON-first, residual-preserving runtime for coordinating work across AI agents. It records tasks, capability packets, evidence, disagreements, verifier reports, and unresolved work so that collaboration remains inspectable rather than becoming a count of repeated answers.

CCR does not run an LLM, claim real artificial superintelligence, or turn a provider report into authority. It provides local and distributed coordination primitives that an agent, tool, or human can use to produce and review structured work.

The central principle

More agents, more text, more packets, or more agreement do not automatically create verified progress. CCR treats a result as useful only within a declared scope, with preserved provenance, verification, resource constraints, and unresolved obligations.

raw input -> candidate packet -> checked evidence -> integration -> settlement only if all declared gates pass
                              |                                  |
                              +---- residuals remain visible -----+

settled=false is therefore an expected diagnostic state, not a crash. It means that the declared settlement requirements have not all been discharged.

What CCR is and is not

CCR provides CCR does not provide
Local-first JSON artifacts, schemas, task leasing, residual ledgers, workcells, and verifier-report routing An LLM, autonomous web crawling, or arbitrary shell execution
Protocol-relative measurement of verified capability formation under matched resources A proof of real ASI, consciousness, model self-rewrite, or model-weight updates
Optional provider integration, including PIC-compatible evidence routes Automatic authority, automatic execution of safe_commands, or settlement from provider output
A parameter-bound operation gate for explicitly requested external effects Proof that a physical outcome occurred merely because a dispatch was attempted

Suggested reading order

  1. Getting Started - Create and inspect a local mission safely.
  2. Core Concepts and Status - Learn the distinction between a packet, task, residual, acceptance, and settlement.
  3. Missions and Local State - Understand the local runtime lifecycle and write boundaries.
  4. Workcells, Tasks, and Residuals - Coordinate independent work without treating consensus as proof.
  5. Measurement and Phase Formation - Evaluate a collective system against a resource-matched baseline.
  6. Providers and PIC Interoperability - Use external verifier reports without granting them settlement authority.

A safe first workflow

Use a dedicated runtime directory so generated artifacts do not mix with source files:

python -m pip install collective-capability-runtime
ccr --root ccr-runtime asi quickstart --profile development --json
ccr --root ccr-runtime mission next --mission mission:quickstart --compact --json
ccr --root ccr-runtime workbench report --mission mission:quickstart --format markdown --out CCR_WORKBENCH.md
ccr --root ccr-runtime residual market --mission mission:quickstart --json

These commands create or inspect local artifacts. They do not call a provider or network endpoint. Read the generated workbench, then choose a blocking residual or a verifier task rather than assuming that the mission is settled.

Key distinctions

Field or state Meaning
ok The command completed its finite validation or transition.
accepted A local checker accepted supplied evidence; this is not settlement.
settled All declared settlement requirements passed; this is usually false.
residuals / blockers Unresolved work that must remain visible.
external_execution The command performed an external action.
physical_outcome_verified A trusted signed observation passed its scope and time checks.

Where to go next

See References and Traceability for the implementation documents behind this wiki.

Clone this wiki locally