Docs / Comparisons
CHP vs service mesh
Service meshes center service-to-service traffic. CHP centers capability-level meaning, policy, invocation outcomes, and evidence.
Plain English
A service mesh can route packets between services; CHP explains what ability was requested and how the host governed it.
Why it exists
Capability callers need semantic outcomes and evidence, not only network-level reliability and traffic policy.
Formal definition
CHP operates at the capability contract layer, above transport routing, and standardizes discoverability, invocation safety, and audit semantics.
Concrete example
Ground the concept before the schema.
A mesh may route to ServiceOpsHost; CHP tells the caller whether schedule_technician is invokable and why a denial occurred.
Finds an available qualified technician and reserves a service window.
Category contrast
CHP vs service mesh: what changes
CHP can complement adjacent systems, but it centers a different protocol boundary.
Compared to
Service mesh
They center
Service-to-service traffic, routing, retries, identity, and network observability.
CHP centers
Capability identity, host lifecycle, policy decision, structured outcome, evidence, and replay.
Use service mesh for traffic control and service infrastructure.
Use CHP for capability-level contracts and outcomes.
Connect both through shared correlation and telemetry export.
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.
Service mesh can support host transport and observability.
CHP provides capability semantics above traffic management.
Evidence can be exported into infrastructure telemetry.
Visual model
- 01Mesh handles network path.
- 02Host handles capability policy.
- 03CHP outcome explains protocol result.
Implementation notes
- Do not rely on mesh routing policy as capability authorization.
- Export CHP evidence alongside infrastructure telemetry.
- Preserve capability IDs in logs and traces.
Common mistakes
- Assuming service identity equals capability permission.
- Treating retries as capability lifecycle logic.
- Losing capability-level correlation in network traces.
Related concepts