The vocabulary of the capability boundary.

The atomic thing a system can do — schedule_technician, transfer_funds, approve_discount, read_file. In CHP a capability is declared with a stable id, a version, an input schema, and the policy it requires, before anyone calls it. Capabilities are what the protocol governs and proves.

The moment an invocation stops being a decision and becomes a real effect on the world. It is the same line regardless of who initiated it — a person, an agent, or a product — which is why it is the right place to declare, govern, and prove what happens. Governance lives at the boundary, not in the model.

A host can be a person approving something, a business process, a device, an application, or another vendor’s agent framework. The host declares its capabilities, enforces policy at the boundary, and emits evidence. CHP is host-agnostic by design — that breadth is why it is a protocol rather than a feature.

Carried in an InvocationEnvelope with the capability id, the inputs, the subject making the call, and a correlation that ties it to everything else in the session. Every invocation produces an outcome — success, denial, or unavailable — and an evidence event, every time.

Each invocation emits an ExecutionEvidence event: a stable action id, the host, the correlation, an explicit outcome, and a hash linking it to the prior event. Evidence is designed to outlive the system that produced it — portable and verifiable on its own terms, which is what makes it trustworthy to a skeptic.

Each evidence event includes a hash of the previous one, so the records form a chain. Alter or remove any record and the chain breaks visibly. This is, almost literally, chain of custody — the property defensibility and audit actually require, and the reason CHP’s evidence is more than a log.

A shared correlation runs through every invocation in a session, matter, or workflow — even across multiple hosts. It is what lets a distributed process reconstruct as a single ordered trace instead of being inferred from scattered logs.

When a policy or entitlement check fails at the boundary, CHP denies the action and records why — an explicit reason code, the deciding subject, and an evidence id — rather than swallowing it as an exception. “Why was this denied?” becomes a query, not a reconstruction.

Because every action shares a correlation and is recorded as the same kind of event, the whole sequence — what an agent touched, what a person decided, in what order — can be replayed from the evidence store. Replay is how “show me what happened” is answered.

CHP ships a conformance suite so independent hosts can demonstrate they declare, govern, and prove capabilities correctly. Conformance is what makes the protocol trustworthy across vendors — a record means the same thing no matter who produced it.

The CapabilityDescriptor carries a capability’s id, version, description, input schema, and governance metadata — who may invoke it, under what policy, and whether it emits evidence. It is the unit behind both the catalog and capabilities.txt.

Adapters turn external systems — SaaS APIs, databases, devices — into declared, governed capabilities, so an action through them is recorded the same way as any other. The open adapter ecosystem is what the capabilities catalog draws from.

A discovery sibling to robots.txt and llms.txt: a crawlable, static declaration of the capabilities a host exposes, pointing to an MCP, HTTP, or CHP endpoint for the actual call. Discovery and invocation are different jobs — capabilities.txt does discovery.