Collective Capability Runtime

Collective Capability Runtime (CCR) is a JSON-first runtime for coordinating work across AI agents. It keeps tasks, evidence, disagreements, verification, and remaining work visible so that several agents can build reusable capability without treating repeated answers or raw agent count as proof.

CCR does not run an LLM. Agents and tools use its CLI, JSON schemas, SQLite or PostgreSQL state, and optional HTTP API to exchange auditable work.

New in v1.9.0

An opt-in native companion path admits pinned ALT reuse, VEK verification work and CPCF first-action proposals through CCR's existing reservation, lease and signed-result controls. CAIT reconciles original source accounting and can change later eligible work without duplicating credit. This is a finite synthetic profile; native forecasts are not observed capacity or execution authority. See Native interchange and qualification and publication.

Verified growth (v1.8 compatibility)

An explicit opt-in growth policy adds evidence-bound service accounting, receiver-qualified reuse, and bounded verification-aware allocation. The v1 optimizer and its existing behavior remain available unchanged.

python -m pip install "collective-capability-runtime[optimizer]==1.8.0"
ccr optimizer growth-example --json

The offline example executes a synthetic workcell/task/evidence/reuse loop, freezes the policy and compares both arms without contacting providers. Read Verified Growth, Interchange, and Release Validation for the finite domain, scientific boundaries and actual publication status. Existing configurations continue to use the legacy Phase Optimizer.

Agent Skill

Native companion commands, exact supported contracts, synthetic examples and authority boundaries are documented in Native interchange.

This repository includes an Agent Skills-compatible workflow at .agents/skills/collective-capability-runtime/SKILL.md. Compatible agents can discover it from this repository, or copy it to a supported user skills directory such as ~/.agents/skills/collective-capability-runtime/. The canonical implementation remains this repository.

Vision And Measurement

CCR supports protocol-relative ASI-proxy phase formation. In ordinary terms, this means improving the rate at which a bounded team produces checked, reusable results under declared authority and resource limits.

Progress is measured against a resource-matched baseline. Relevant measures include time to checked status, residual half-life, verification yield, effective independent contributors, error correlation, and communication or verification cost. More agents or more candidate text alone do not count as progress.

This protocol-relative state is not real ASI. CCR does not claim consciousness, model-weight updates, legal authority, or a physical outcome merely because a report was accepted.

Install

Published package:

python -m pip install collective-capability-runtime
ccr agent explain --json

Repository checkout:

uv sync --all-extras
uv run ccr agent explain --json

Optional PostgreSQL, API, authentication, and worker support:

python -m pip install "collective-capability-runtime[distributed]"

Optional telemetry:

python -m pip install "collective-capability-runtime[telemetry]"

PIC is an optional finite checker and planning provider:

python -m pip install percolation-inversion-compiler
ccr provider health --provider pic --json

Five-Minute Start

These commands work after installation. They create a local mission and a human-readable workbench without calling a provider or network endpoint:

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

Read CCR_WORKBENCH.md, then select a blocking residual or verification task. settled=false is a normal report state: it means required work remains.

For a source-checkout example of independent proposals and a resource-matched experiment, follow examples/collective_runtime/README.md.

Choose A Workflow

Phase Optimization

CCR can now close the loop from intervention selection and resource reservation to independent verification and adaptive allocation. The optimizer supports SQLite, PostgreSQL workers, and approval-bound HTTP dispatch. Training costs count against the candidate evaluation budget, and holdout evidence is kept separate from policy learning. See Phase Optimizer.

Core Concepts

• Task: a unit of work with dependencies, role, lease, heartbeat, and fencing token.
• Capability packet: a candidate or checked result with scope, evidence, provenance, and residual references.
• Residual: explicit unresolved work. Resolution requires a repair artifact and independent verifier evidence.
• Workcell: independent proposal, reveal, critique, revision, verification, and integration stages. Correlated sources count once.
• Mission: a target, baseline, packets, tasks, residuals, and reports under one declared scope.
• Experiment: a preregistered comparison with a task manifest, evaluator, resource envelope, seed, and outcome schema.
• Operation approval: a time-limited authorization bound to a plan, provider, arguments, resources, scope, nonce, and use count.

Important Output Fields

CCR emits deterministic JSON where possible. Inspect these fields before choosing the next action:

Unknown measurements remain unknown. CCR does not replace missing reuse, hazard, queue, cost, or verifier values with favorable defaults.

State And External Effects

Local inspection, schema validation, planning, and reporting do not perform external effects. The following commands intentionally mutate local runtime state:

ccr operation dispatch --execute is the external-effect boundary. Network providers require HTTPS, an exact host allowlist, public-address DNS checks, redirect denial, byte/time limits, a current preflight, and an unexpired bound approval. Physical or irreversible operations require distinct approvers, rollback and hazard controls, and independent verification.

Generic ccr provider execute cannot bypass this operation gate. Imported safe_commands are task hints and are never run automatically.

Storage Profiles

SQLite is the default profile for one machine. Connections close after each operation, state changes use immediate transactions, and task leases use monotonic fencing tokens.

PostgreSQL 16+ is the distributed authoritative store. Workers claim tasks with FOR UPDATE SKIP LOCKED, use database time, heartbeat leases, and commit idempotently. Delivery is at least once; CCR does not claim exactly-once execution. JSON files are content-addressed exports in this profile.

ccr --root ccr-runtime storage doctor --json
ccr --root ccr-runtime storage migrate --json
ccr --root ccr-runtime storage reconcile --json

Documentation

• Documentation Index: task-oriented navigation
• Getting Started: shortest local workflow
• Command Map: commands, writes, and authority needs
• Collective Workcells: independent proposals and residual-preserving integration
• Distributed Runtime: PostgreSQL, OIDC + DPoP API, and workers
• Measurement Protocol: resource-matched experiments
• Operation Gate: approval, dispatch, and observation boundaries
• Security Audit Checklist: NIST AI RMF and OWASP agent controls
• PIC Interoperability: PIC 1.0 compatibility and non-settlement boundary
• Security Policy: threat model and disclosure process

Search terms: collective intelligence runtime, multi-agent coordination, distributed AI agents, PostgreSQL task queue, capability packet, residual ledger, independent verification, ASI-proxy measurement, PIC interoperability, OIDC DPoP agent API, operation approval, and provenance.

Public Release Audit

Run the complete local gate before creating a tag or GitHub release:

uv sync --all-extras
uv run ruff format --check .
uv run ruff check .
uv run mypy src
uv run python -m compileall -q src tests
uv run pytest
uv run python scripts/check_schema_registry.py
uv run ccr audit repo --json
uv run ccr audit pic --pic-root <PIC_ROOT> --json
uv build
uv run ccr audit release --dist dist --json
uvx twine check dist/*

<PIC_ROOT> is a trusted local checkout of kadubon/percolation-inversion-compiler. These audit commands do not push, tag, publish, dispatch providers, or prove a physical outcome.

Compatibility

The v1 CLI and JSON interfaces remain compatible. New fields are additive. The safety exception is deliberate: side-effecting provider execution must use the TRC operation approval and dispatch path. The Python API remains semi-stable; CLI commands and registered JSON schemas are the public contract.