Docs / Reference
Glossary
Canonical terms for capability, host, adapter, registry, invocation, policy, context, evidence, replay, and composition.
Plain English
The glossary keeps CHP language stable across docs, examples, manifests, and product surfaces.
Why it exists
A protocol surface becomes harder to implement when core terms drift between marketing, docs, code, and tests.
Formal definition
The glossary is the governed vocabulary for CHP concepts and their relationships.
Concrete example
Ground the concept before the schema.
Capability means a named hosted ability, not merely an endpoint, plugin, or function.
Finds an available qualified technician and reserves a service window.
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.
Glossary terms should link to concept pages.
Examples should use glossary terms consistently.
Terminology changes should update docs, pages, and component examples together.
Visual model
- 01Capability is what can be done.
- 02Host owns where and how it is done.
- 03Invocation is the governed request to do it.
Implementation notes
- Define terms before first use on long-form docs pages.
- Prefer hosted capability over generic tool when discussing CHP.
- Update route labels and examples when glossary terms change.
Common mistakes
- Using capability, tool, function, and endpoint interchangeably.
- Calling logs evidence without protocol fields.
- Treating context as a loose prompt string.
Related concepts