Docs / Introduction

Mental model

Think in hosted abilities: actor, capability, host, policy, context, result, and evidence.

Plain English

CHP gives every useful ability a visible owner, invocation path, rule boundary, and replayable outcome.

Why it exists

A shared mental model keeps docs, manifests, diagrams, examples, and product surfaces aligned.

Formal definition

The CHP model represents capability use as an ordered relationship between actor, capability, host, policy, context, result, and evidence.

Concrete example

Ground the concept before the schema.

[Planning Agent] -> {schedule_technician} @ ServiceOpsHost | manager_approval | job_context -> Confirmed Appointment

schedule_technicianInvokable

Finds an available qualified technician and reserves a service window.

host: ServiceOpsHostpolicy: approval_requiredv1.0.0

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

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.

Actor is the requester.

Capability is the named ability.

Host owns policy, lifecycle, result, and evidence.

Visual model

  1. 01Actor chooses an ability.
  2. 02Host validates the boundary.
  3. 03Result and evidence make the outcome inspectable.

Implementation notes

  • Use the notation in examples before introducing schemas.
  • Keep policy visible before composition claims.
  • Make failure paths part of the model.

Common mistakes

  • Starting with transport instead of capability meaning.
  • Drawing diagrams that hide the host boundary.
  • Explaining composition before governance.

Related concepts

Keep reading through the boundary.