Docs / Concepts

Capability

A capability is the named unit of work that CHP makes discoverable, governable, invokable, and auditable.

Plain English

A capability is something a person, agent, product, service, process, or organization can do through a host.

Why it exists

Callers need to understand the ability they are using before they bind a workflow, policy, or agent plan to it.

Formal definition

A capability is a stable, versioned, invokable unit exposed by a host with declared metadata, policy, lifecycle, inputs, outputs, and evidence behavior.

Concrete example

Ground the concept before the schema.

schedule_technician is a capability because it names a specific hosted ability, declares policy, and returns a concrete result.

schedule_technicianInvokable

Finds an available qualified technician and reserves a service window.

host: ServiceOpsHostpolicy: approval_requiredv1.0.0

Policy boundary

Approval required

manager_approval

A manager must approve technician scheduling before the host returns a confirmed appointment.

Invocation trace

  1. 01 Actor

    Planning Agent

  2. 02 Capability

    schedule_technician

  3. 03 Host

    ServiceOpsHost

  4. 04 Policy

    manager_approval

  5. 05 Context

    job_context

  6. 06 Result

    Confirmed Appointment

manifest.json
json
{  "id": "service-ops-host",  "version": "0.1.0",  "protocol_version": "0.1",  "kind": "service",  "capabilities": [{    "id": "schedule_technician",    "version": "1.0.0",    "description": "Finds an available qualified technician and reserves a service window.",    "status": "experimental",    "modes": ["sync"],    "emits": ["execution_started", "execution_completed", "execution_denied"],    "policy": {      "risk_tier": "high",      "auth_required": true,      "approval_required": true,      "allowed_actors": ["agent://planning-assistant"]    },    "metadata": {      "required_permissions": ["service:dispatch"],      "lifecycle": "invokable"    }  }],  "evidence": {    "store": "local-append-only",    "append_only": true  }}

Relationships

Where this sits in the protocol.

Each concept should explain its neighbors so implementation teams can preserve the boundary across manifests, invocation, evidence, and tests.

A host owns the capability lifecycle and manifest entry.

A registry or manifest makes the capability discoverable before invocation.

Policy determines whether the capability may execute for a caller.

Visual model

  1. 01Caller discovers schedule_technician.
  2. 02Host validates the requested version and policy.
  3. 03Invocation produces Confirmed Appointment or a structured denial.

Implementation notes

  • Use stable capability IDs that describe the ability, not the transport endpoint.
  • Publish version and availability before callers invoke the capability.
  • Return structured outcomes for unavailable, denied, and failed executions.

Common mistakes

  • Treating a raw function name as the public protocol contract.
  • Hiding lifecycle or permission state until after the invocation starts.
  • Changing payload semantics without changing the capability version.

Related concepts

Keep reading through the boundary.

Host →Invocation →Policy →