Implementers
Adopt CHP from the side of the boundary you own.
CHP is useful whether you expose capabilities, call them, compose them into applications, or operate the infrastructure that validates and observes them.
Capability host implementer
Expose a reliable capability surface that independent agents can trust.
Start with a manifest, stable capability IDs, lifecycle state, and structured invocation outcomes.
Host quickstart →Agent or framework author
Call capabilities without hardcoding every provider, tool shape, or failure mode.
Use discovery and invocation semantics to handle availability, subject policy, host timeout behavior, and denials.
Protocol surface →Application developer
Move high-value actions behind governed boundaries while preserving product workflow control.
Route actions through hosts, attach correlation IDs, and replay evidence for user-visible operations.
Quickstart →Infrastructure provider
Build validation, policy, observability, and managed trust services around a portable protocol.
Validate host descriptors, enforce policy checks, stitch evidence, and run conformance checks.
Conformance →Readiness checklist
What a credible implementation should prove.
The protocol boundary is only useful if independent callers can understand what is available, why a request failed, and where the evidence for a decision lives.
Capability IDs and versions are stable.
Manifest validation runs before publication.
Unavailable capabilities fail predictably.
Entitlement denials are structured.
Invocations carry correlation context.
Evidence can be replayed by correlation ID.
Malformed input tests exist.
Conformance gaps are documented.
Adoption paths
Adopt the protocol one boundary at a time.
CHP is useful as a local host, a remote invocation boundary, a manifest contract, or a conformance target for infrastructure.
01
Implement a host
Wrap local functions or managed services behind CHP manifests and invocation handlers.
Implementer paths →02
Call a host
Use the local or remote client shape to invoke capabilities and replay evidence by correlation ID.
Protocol surface →03
Validate the surface
Treat manifests, unknown hosts, unavailable capabilities, and malformed requests as protocol concerns.
Read the spec →04
Run conformance
Use tests and protocol checks to prove independent implementations behave consistently.
Conformance model →Adoption status
Early, open, and built for independent implementations.
Public protocol surfaces earn trust by being explicit about maturity. CHP is ready for experimentation, reference implementations, and conformance-driven feedback.
Open source
Apache-2.0 reference implementation, schemas, docs, and examples are public in GitHub.
Early protocol
The implementation is alpha; the current spec document is v0.1 and the package is v0.7.0.
Conformance-oriented
The site and repo now make malformed input, lifecycle failures, version mismatch, and authorization denials explicit test concerns.
Start with one governed boundary.
Implement a local reference host, serve it over HTTP, then add manifest validation, permission checks, and conformance coverage as the surface becomes public.