Docs / Reference

Notation reference

CHP notation shows actor, capability, host, policy, context, and result in one readable protocol sentence.

Plain English

Notation is the shorthand for explaining a capability invocation before showing JSON.

Why it exists

Readable notation lets product, security, engineering, and operations review the same boundary.

Formal definition

[Actor] -> {capability} @ Host | policy | context -> Result

Concrete example

Ground the concept before the schema.

[Planning Agent] -> {schedule_technician} @ ServiceOpsHost | manager_approval | job_context -> 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

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 maps to invocation subject identity.

Capability and host map to manifest metadata.

Policy, context, and result map to invocation and outcome semantics.

Visual model

  1. 01[Actor]
  2. 02{capability} @ Host
  3. 03policy | context -> Result

Implementation notes

  • Use notation at the start of concept pages.
  • Keep capability IDs in code form.
  • Do not use notation as a replacement for schemas.

Common mistakes

  • Leaving out policy.
  • Treating host as optional.
  • Using a vague result like done.

Related concepts

Keep reading through the boundary.