Docs / Concepts

Host

A host is the accountable boundary that exposes capabilities and enforces lifecycle, policy, and evidence behavior.

Plain English

A host is the system, service, product, process, or organization that owns what can be done.

Why it exists

Independent callers need to know who owns a capability, whether it is available, and what rules apply before invoking it.

Formal definition

A host is a protocol participant that publishes manifest metadata, accepts or rejects invocations, enforces capability lifecycle, and emits outcomes and evidence.

Concrete example

Ground the concept before the schema.

ServiceOpsHost exposes schedule_technician and query_inventory while enforcing manager approval and host-recognized entitlements.

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 publishes capabilities through a manifest.

A host validates invocation envelopes and policy before execution.

A host emits evidence that infrastructure can replay and export.

Visual model

  1. 01Host identity appears before capability details.
  2. 02Capabilities sit inside the host boundary.
  3. 03Policy and evidence are host responsibilities, not caller guesses.

Implementation notes

  • Make HostDescriptor.id stable and unique inside the trust boundary.
  • Expose unavailable capabilities as protocol state instead of transport errors.
  • Keep host health separate from individual capability lifecycle.

Common mistakes

  • Letting each caller infer host identity from a URL.
  • Returning generic 500 errors for disabled capabilities.
  • Treating audit logs as optional implementation details.

Related concepts

Keep reading through the boundary.

Host →Invocation →Policy →