Capabilities

A capability is a stable, permanent identifier for something that must be possible. It is a verb — not a noun. It describes what must happen, not what implements it.

cap.<domain>[.<subdomain>].<verb>

Examples from the WCP catalog:

cap.doc.summarize
cap.doc.pdf.extract
cap.mem.retrieve
cap.mem.embed
cap.web.fetch
cap.research.register
cap.notify.send
cap.db.write
cap.ml.infer
cap.ops.approve

Why Request by Capability, Not by Worker Name

Most AI agent systems hardcode tool calls. The agent requests call_summarizer_v2() and the system dispatches summarizer_v2. This creates tight coupling: the caller knows the worker name, the worker location, and implicitly the implementation details.

WCP breaks this coupling. The agent requests cap.doc.summarize. The Hall decides which enrolled worker implements that capability, applies governance, and dispatches. The caller never names the worker directly.

This separation produces three concrete benefits:

Workers can be swapped without changing client code. Replace org.acme.summarizer with org.acme.summarizer-v2 or a third-party implementation — the agent’s request does not change.

Multiple implementations can coexist. A high-QoS request (P0) can be routed to a fast, expensive worker while a background request (P3) goes to a slower, cheaper one — both implement cap.doc.summarize and both are governed by the same policy.

Policy is attached to the capability, not the worker. When the routing rule for cap.db.write requires STEWARD_HOLD in production, that governance applies regardless of which worker species implements the write. The policy travels with the capability ID.

Capability ID Format Rules

Segments:   2 to 4 dot-separated segments
Characters: lowercase a-z, digits 0-9, hyphens (-) only
Separator:  dot (.)
Forbidden:  underscores, uppercase, spaces, unicode
Max length: 64 characters total

Valid:

cap.doc.summarize
cap.doc.pdf.extract
cap.mem.retrieve

Invalid:

cap.Doc.Summarize         (uppercase)
cap.doc.pdf_extract       (underscore)
cap.doc.pdf.native.extract  (5 segments — too deep)

Capability IDs Are Permanent

Once a capability ID is published in the WCP catalog, it is permanent. Its core meaning never changes. It is never removed — only tombstoned with a deprecated status and a superseded_by pointer.

{
  "id": "cap.doc.ocr.basic",
  "status": "deprecated",
  "superseded_by": "cap.doc.ocr",
  "deprecated_catalog": "2.0.0",
  "sunset_catalog": "4.0.0"
}

Namespace Ownership

WCP uses a strict namespace ownership model. Different prefixes signal different stability guarantees:

Prefix	Owner	Stability
`cap.*`	WCP catalog	Permanent once published
`wrk.*`	WCP catalog	Permanent once published
`ctrl.*`	WCP catalog	Permanent once published
`pol.*`	WCP catalog	Permanent once published
`prof.*`	WCP catalog	Permanent once published
`evt.*`	WCP catalog	Permanent once published
`x.*`	Community / experimental	No stability guarantee
`org.<name>.*`	Organization-private	Owner’s discretion

No entity outside the WCP catalog maintainers may publish IDs in the reserved namespaces (cap.*, wrk.*, ctrl.*, pol.*, prof.*, evt.*).

Community Namespace (`x.*`)

Free accounts get one x.* namespace. Register at pyhall.dev with your GitHub account to claim it. Convention: x.<your-domain>.<verb>. There is no stability guarantee — IDs in x.* are experimental and may be redefined.

x.acme.custom-analysis
x.mylab.experimental-embed

Organization Namespace (`org.<name>.*`)

Register your namespace at pyhall.dev to claim it. Org namespaces are private and cannot conflict with WCP catalog IDs or other organizations’ namespaces.

org.acme.summarize-with-citations
org.fafolab.research-ingest

Taxonomy at a Glance

The WCP catalog contains 245 entities across 48 worker species domains, organized by domain prefix. A few representative domains:

Domain prefix	What it covers
`cap.doc.*`	Document processing: summarize, extract, chunk, hash, OCR
`cap.mem.*`	Memory operations: retrieve, embed, store, search
`cap.web.*`	Web operations: fetch, scrape, search
`cap.db.*`	Database operations: read, write, migrate
`cap.ml.*`	ML operations: infer, embed, eval, fine-tune
`cap.notify.*`	Notification: send, queue, escalate
`cap.obs.*`	Observability: log, trace, alert
`cap.ops.*`	Operations: approve, deploy, rollback
`cap.research.*`	Research operations: register, index, cite

See Capability Catalog for the full table.

How Enrollment Links Capabilities to Workers

When a worker enrolls, it declares the capabilities it implements in its registry record:

{
  "worker_id": "org.acme.summarizer",
  "worker_species_id": "wrk.doc.summarizer",
  "capabilities": ["cap.doc.summarize"]
}

When an agent requests cap.doc.summarize, the Hall routes locally against its prefetch cache — no registry call on the hot path. It applies routing rules, controls verification, and policy gate evaluation to select the best available worker species. The prefetch cache is refreshed from the registry every 60 seconds in the background. The agent only knows the capability ID — the Hall handles the rest.