Core Concepts and Status

Core Concepts and Status

The basic objects

Object	Purpose
Task	A unit of work with dependencies, a role, a lease, heartbeats, and a fencing token.
Capability packet	A candidate or checked result with scope, evidence, provenance, and residual references.
Residual	Explicit unresolved work, doubt, missing evidence, or a failed gate.
Workcell	A staged process for independent proposals, critique, revision, verification, and integration.
Mission	A declared target, baseline, authority envelope, packets, tasks, residuals, and reports under one scope.
Experiment	A preregistered comparison with an evaluation design, resource envelope, seed, and outcome schema.
Operation approval	A time-limited authorization bound to an exact plan, provider, arguments, resources, scope, nonce, and use count.

CCR keeps these objects separate so that evidence does not become authority, a task does not become a result, and an unresolved obligation does not disappear because other work succeeded.

Status is a lattice, not a single success bit

CCR supports statuses including raw, proposed, candidate, checked, provisional, speculative, settled, rejected, quarantined, deprecated, and expired.

A typical promotion path is:

raw -> candidate -> checked -> settled

Each step has additional requirements:

Transition	Required conditions in the runtime contract
Raw to candidate	Schema validity and declared scope.
Candidate to checked	At least one required verifier accepts and residuals remain preserved.
Checked to settled	No blocking residuals, target satisfaction, closed lineage, risk within envelope, and integration-policy success.
Any status to quarantined	Critical hazard, authority bypass, malformed provenance, invalid hash, or unsafe execution request.

The exact promotion policy is part of the declared runtime contract. A successful command or a provider's accepted=true alone is insufficient for settlement.

Acceptance, settlement, and physical evidence

Claim	What it means	What it does not mean
ok=true	A finite command completed successfully.	The mission is correct, settled, or externally executed.
accepted=true	A checker accepted the supplied evidence.	All CCR gates passed.
settled=true	All declared settlement requirements passed.	A physical result is automatically proven.
provider_dispatch_ready=true	Provider preflight and policy checks passed.	A dispatch occurred.
physical_dispatch_ready=true	Physical certificate fields were accepted and fresh.	A physical outcome occurred.
physical_outcome_verified=true	A trusted signed observation passed scope and time checks.	General truth beyond that verified scope.

The deprecated compatibility field physical_outcome_proven is always false. This is intentional: no report should silently claim physical proof without the separate observation-verification path.

Residuals are first-class scientific information

Residuals preserve missing evidence, uncertainty, constraints, contradictions, and blocked work. CCR does not replace unknown measurements with favorable defaults and does not allow residuals to be silently discarded during integration.

A residual is not necessarily a failure of the runtime. It is a machine-readable statement of what remains to be repaired, verified, bounded, or explicitly left unresolved.

For the lifecycle of these objects, continue to Missions and Local State and Workcells, Tasks, and Residuals.