Concepts

Workers

A worker is any autonomous process that can execute a capability on behalf of an agent. Workers are classified by species (type/blueprint) and instance (running deployment). Before a worker can be dispatched, it must enroll with a Hall by submitting a registry record.

Worker species IDs follow a three-segment format using the wrk.* namespace: wrk.<domain>.<role>. Example: wrk.doc.summarizer. Individual deployments use a namespaced worker ID: org.acme.summarizer. Multiple worker instances can share one species.

Workers declare their capabilities, risk tier (low/medium/high/critical), required controls, privilege envelope, and blast radius dimensions. Once enrolled, the Hall can dispatch requests to them — and verify their registry records haven't been tampered with at every dispatch.

{
  "worker_id": "org.acme.summarizer",
  "worker_species_id": "wrk.doc.summarizer",
  "capabilities": ["cap.doc.summarize", "cap.doc.extract"],
  "risk_tier": "low",
  "owner": "org.acme",
  "required_controls": ["ctrl.obs.audit_log_append_only"],
  "blast_radius": { "data": 1, "network": 0, "financial": 0,
                    "time": 1, "reversibility": "reversible" },
  "artifact_hash": "sha256:a3f..."
}

Capabilities

Capabilities are the unit of work in WCP. Agents request capabilities — not workers. The Hall matches the request to an enrolled worker that can fulfill it. This decouples the caller from the implementation: workers can be swapped, upgraded, or failed over without changing client code.

Capability IDs use the format cap.<domain>.<verb> or cap.<domain>.<subdomain>.<verb>. Examples: cap.doc.summarize, cap.db.write, cap.mem.retrieve, cap.web.fetch.

Capability IDs are permanent. Once published in a WCP catalog, an ID never changes meaning and is never deleted — only tombstoned. If semantics must change, a new capability is defined. Capabilities are verbs: they describe what must be possible, not what implements it.

WCP reserves the cap.*, wrk.*, ctrl.*, pol.*, prof.*, and evt.* namespaces. Community capabilities go under x.*. Organizations can register org.<name>.* as a private namespace. The full WCP taxonomy covers 245 capability entities across 27 packs — from document processing to database operations to code execution.

Policies

Policies govern which workers can be dispatched, under what conditions, and with what controls. The policy gate evaluates every RouteInput against the active profile and the requesting worker's risk tier. Policies use the pol.* namespace; profiles use prof.*.

WCP defines three built-in profiles: prof.dev.permissive (low friction, suitable for development), prof.prod.strict (high-risk workers denied, all decisions logged), and prof.edge.isolated (strict data isolation for edge environments, no egress).

The same worker fleet runs in development chaos mode and production discipline mode by swapping profiles — no code changes required. Controls are declared by the worker and verified by the Hall before dispatch. A missing required control returns denied: true.

Blast radius is a 0–100 score summed across five dimensions: data impact, network exposure, financial impact, time cost, and reversibility. High blast radius triggers escalation or human review. WCP-Full compliance sets per-environment blast score thresholds.

# High-risk worker in prod → STEWARD_HOLD
inp = RouteInput(
    capability_id="cap.db.write",
    env="prod",
    data_label="RESTRICTED",
    tenant_risk="high",
    qos_class="P0",
    ...
)
# outcome: supervisor_required: true, supervisor_level: "gatekeeper"

Decisions

Every capability request produces a RouteDecision. The Hall receives a RouteInput, finds enrolled workers matching the requested capability, applies the policy gate, checks controls, computes blast score, and returns one of three outcomes: DISPATCH (cleared for execution), DENY (blocked with a reason code), or STEWARD_HOLD (queued for human review with a supervisor level).

Deny reason codes explain precisely why a request was blocked. Common codes: DENY_NO_WORKER (no enrolled worker has the capability), DENY_POLICY_BLOCK (risk tier exceeds policy), DENY_WORKER_TAMPERED (attestation hash mismatch), DENY_CONTROL_MISSING (required control not present), DENY_UNKNOWN_TENANT (tenant not registered as signatory).

Routing is deterministic: given identical inputs, the routing decision must be identical. Routing rules are tested against golden snapshots. Any change to routing behavior requires a new rule version. The correlation_id (UUID v4) links every RouteInput to its RouteDecision and propagates through all downstream worker calls and telemetry events.

Fail-closed is mandatory: if no routing rule matches a capability request, the decision must be denied: true. Unknown capabilities are never executed. No exceptions.

Attestation

Attestation prevents two classes of attack: supply chain tampering of worker code, and registry record falsification. When a worker enrolls, its registry record is SHA-256 hashed and the hash is stored in the record's artifact_hash field. On every dispatch, the Hall recomputes the hash and compares it to the stored value. A mismatch returns DENY_WORKER_TAMPERED.

Worker code attestation goes further: the worker's actual source file or container image is hashed at enrollment time and stored as attestation.code_hash in the registry record. At dispatch, the Hall recomputes the live hash and compares. This closes the supply chain attack where an attacker modifies a deployed worker after enrollment.

The registry record hash is computed over a canonical JSON serialization — sorted keys, no whitespace — of the record with the artifact_hash field excluded. This makes the hash deterministic across languages and environments.

import hashlib, json

def compute_hash(record: dict) -> str:
    without_hash = {k: v for k, v in record.items()
                    if k != 'artifact_hash'}
    canonical = json.dumps(without_hash, sort_keys=True,
                           separators=(',', ':'))
    return 'sha256:' + hashlib.sha256(canonical.encode()).hexdigest()

Evidence

Every RouteDecision is a record of evidence: who requested what capability, at what time, under which policy, with which controls verified, at what blast score, and what the outcome was. This evidence trail serves debugging, compliance, and forensic auditing equally well.

Every executed dispatch returns an evidence receipt containing at minimum: correlation_id, dispatched_at, worker_id, capability_id, policy_decision, controls_verified, and an artifact_hash (SHA-256 of the request payload). Every decision carries a decided_at timestamp.

Three telemetry events are mandatory on every dispatch: evt.os.task.routed, evt.os.worker.selected, and evt.os.policy.gated. The correlation ID propagates through all three events. Workers that call LLMs should emit OpenTelemetry Generative AI semantic conventions for out-of-the-box compatibility with existing OTel pipelines.

For environments with regulatory requirements, the evidence trail can be extended with Merkle tree hash chaining — each decision's hash incorporates the previous decision's hash, making any modification of historical records detectable. The principle: WCP doesn't just control what happens. It proves what happened.