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.7.0
The phase optimizer adds a closed loop: observe, select an intervention, reserve resources, dispatch an approved operation, independently verify its outcome, and update allocation. It aims to increase verified reusable outcomes under a fixed resource budget. Existing phase and eligibility rules remain the evaluator.
python -m pip install "collective-capability-runtime[optimizer]==1.7.0"
For PostgreSQL workers and the authenticated API, install
collective-capability-runtime[optimizer,distributed]==1.7.0. Follow the
Phase Optimizer guide and adapt the
configuration fixture before registering
a run. Read-only planning does not dispatch providers. Real-world performance
improvement has not been established; the fixed-policy holdout report retains
negative and inconclusive results.
Agent Skill
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
| Goal | Start with | Guide |
|---|---|---|
| Create a local mission | ccr asi quickstart |
Getting Started |
| Allocate a fixed budget adaptively | ccr optimizer plan --run ... |
Phase Optimizer |
| Coordinate independent proposals | ccr workcell create |
Collective Workcells |
| Recover and complete leased work | ccr task lease |
Collective Workcells |
| Resolve a residual with independent evidence | ccr residual resolve |
Command Map |
| Run several workers | ccr server run, ccr worker run |
Distributed Runtime |
| Compare collective and baseline results | ccr experiment register |
Measurement Protocol |
| Review a possible external operation | ccr operation preflight |
Operation Gate |
| Check PIC compatibility | ccr audit pic |
PIC Interoperability |
| Audit a public release | ccr audit repo |
Release Audit |
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:
| Field | Meaning |
|---|---|
ok |
The command completed its finite validation or transition. |
accepted |
A local checker accepted the supplied evidence. It is not settlement. |
settled |
All declared settlement requirements passed. It is usually false. |
blockers / residuals |
Work that must remain visible. |
external_execution |
The command performed an external action. |
network_call_performed |
The command made a network request. |
physical_outcome_proven |
Deprecated compatibility field; always false. |
physical_outcome_verified |
A trusted signed observation passed scope and time checks. |
non_claims |
Statements the report explicitly does not assert. |
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:
| Command family | Local change |
|---|---|
asi, mission, workbench --out |
mission and report artifacts |
| `task lease | heartbeat |
| `residual assign | review |
| `workcell create | submit |
| `experiment register | ingest` |
storage migrate --apply |
additive local database migration |
provider import |
candidate evidence, residuals, and task hints |
operation approve |
parameter-bound approval artifact |
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.
Metadata
Release files for collective-capability-runtime 1.7.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| collective_capability_runtime-1.7.0.tar.gz | 327.5 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| collective_capability_runtime-1.7.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 718.2 kB
Release files / collective_capability_runtime-1.7.0.tar.gz
| Download URL | collective_capability_runtime-1.7.0.tar.gz |
|---|---|
| Size | 327.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
63a4f8f2780335b35fdb403eb83cfaca27af61538c21c14e05cbb033a03a3980
|
|
BLAKE2b-256 checksum How to use checksums |
a143b85da9f0a598232f1fbe3745b5ad0650b72ce87fe8de4e778b2539316d5f
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 6, 2026.
Transparency logRelease files / collective_capability_runtime-1.7.0-py3-none-any.whl
| Download URL | collective_capability_runtime-1.7.0-py3-none-any.whl |
|---|---|
| Size | 390.7 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
55568d95b9b6f4d68650381b21b8815c0fbd120b20a16128d4add91a4777b684
|
|
BLAKE2b-256 checksum How to use checksums |
ccdfe0993ef15c2750888807a6632f3a020a8d8deb97e37538297302b81a0c5a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 6, 2026.
Transparency log