Workcells Tasks and Residuals

Workcells, Tasks, and Residuals

Why CCR does not count votes as capability

Several agents can repeat the same error, share the same source, or influence one another before independently evaluating a claim. CCR workcells therefore use staged collaboration and correlation-aware support rather than headcount or majority vote.

independent proposal -> reveal -> critique -> revision -> verification -> integration

During independent proposal, submissions remain hidden until reveal. Each submission records model, tool, and source provenance. Support from the same correlation group counts once, so repeated output from one model or one source is not mistaken for independent evidence.

Workcell example

For a source checkout, the bundled fixture demonstrates the mechanics:

uv run ccr --root .tmp/collective-runtime workcell create --template packet-distillation --name review-a --json
uv run ccr --root .tmp/collective-runtime workcell submit --workcell review-a --file examples/collective_runtime/proposal-a.json --json
uv run ccr --root .tmp/collective-runtime workcell submit --workcell review-a --file examples/collective_runtime/proposal-b.json --json
uv run ccr --root .tmp/collective-runtime workcell advance --workcell review-a --to reveal --json
uv run ccr --root .tmp/collective-runtime workcell advance --workcell review-a --to critique --json

The fixture deliberately uses a shared correlation group. It illustrates correlation discounting, not an empirical capability-improvement claim.

Claim-based integration

Integration retains each claim's supporting submissions, distinct correlation groups, evidence, dependencies, contradictions, and minority reports. An unresolved contradiction becomes a blocking residual.

Skipping directly to integration remains available for compatibility, but it creates a blocking incomplete-stage residual and reports protocol_complete=false. Agent role names, raw support count, and majority agreement never independently mark a packet checked or settled.

Leased tasks are fenced and idempotent

Task leases prevent stale workers from overwriting reclaimed work. A worker receives a monotonic fencing token and must echo the current token when heartbeating, completing, or failing a task. Completion also requires an idempotency key.

ccr task lease <task_id> --ttl 30m --agent worker.one --json
ccr task heartbeat <task_id> --agent worker.one --fencing-token <token> --json
ccr task complete <task_id> --agent worker.one --fencing-token <token> \
  --idempotency-key result.1 --summary "candidate ready" --output candidate.json --json

The task machinery prevents conflicting local state updates; it does not execute the task content automatically.

Resolving a residual

Residual resolution requires both:

1. A repair artifact.
2. A verifier JSON record whose artifact_sha256 matches that artifact and whose verifier differs from the repair agent.

Reopening a residual preserves the earlier resolution evidence. This makes the history of repair and later doubt inspectable rather than overwriting it.

Roles are constrained, not privileged

Generators can create candidate work; skeptics can create objections and residuals; verifiers can create verifier reports; integrators can import checked or provisional state; schedulers manage the queue; benchmark runners record baseline observations. No role may silently settle unresolved residuals or treat provider output as authority.

Continue to Measurement and Phase Formation for how CCR evaluates collective work, or Storage and Distributed Runtime for worker deployment.