Docs / Concepts

Adapter

An adapter maps an existing system into a CHP capability contract without forcing that system to become CHP-native.

Plain English

An adapter is the bridge from something you already have to a hosted capability interface.

Why it exists

Most useful capabilities already live inside products, services, databases, scripts, and workflows that need a stable protocol boundary.

Formal definition

An adapter translates an existing provider or runtime surface into CHP manifest, invocation, outcome, policy, and evidence semantics.

Concrete example

Ground the concept before the schema.

A ServiceOps adapter can map an internal dispatch API into schedule_technician while preserving CHP policy and outcome rules.

create_project_updateDiscoverable

Finds an available qualified technician and reserves a service window.

host: ProjectOpsAdapterpolicy: team_memberv1.0.0

Invocation trace

  1. 01 Actor

    Delivery Agent

  2. 02 Capability

    create_project_update

  3. 03 Host

    ProjectOpsAdapter

  4. 04 Policy

    team_member

  5. 05 Context

    project_context

  6. 06 Result

    Project Update

adapter-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.

Adapters sit behind or beside hosts depending on ownership.

Adapters should not erase lifecycle, permission, or version metadata.

Adapters make conformance possible for existing systems.

Visual model

  1. 01Existing system remains behind the adapter bridge.
  2. 02Adapter publishes a capability-shaped contract.
  3. 03CHP callers invoke the host boundary, not the private implementation.

Implementation notes

  • Map provider errors into structured CHP outcomes.
  • Keep provider credentials and policy enforcement server-side.
  • Document which provider semantics are not portable.

Common mistakes

  • Exposing provider-specific payloads as the public contract.
  • Treating adapter availability as identical to provider availability.
  • Skipping conformance because the underlying provider already has tests.

Related concepts

Keep reading through the boundary.

Host →Invocation →Policy →