Docs / Reference
Manifest fields
Manifest fields declare host identity, protocol compatibility, capability metadata, lifecycle, permission, and policy before invocation.
Plain English
A manifest is the first thing a caller should inspect before trusting a hosted capability.
Why it exists
Without a stable manifest shape, independent callers discover incompatibility, unavailable capabilities, or missing subject requirements too late.
Formal definition
A CHP manifest is a HostDescriptor: the host-published declaration of protocol version, host identity, capability descriptors, maturity, evidence behavior, and policy metadata.
Concrete example
Ground the concept before the schema.
ServiceOpsHost declares schedule_technician version 1.0.0 with service:dispatch permission and approval_required policy.
{ "id": "service-ops-host", "version": "0.1.0", "protocol_version": "0.1", "kind": "service", "capabilities": [{ "id": "schedule_technician", "version": "1.0.0", "description": "Finds an available qualified technician and reserves a service window.", "status": "experimental", "modes": ["sync"], "emits": ["execution_started", "execution_completed", "execution_denied"], "policy": { "risk_tier": "high", "auth_required": true, "approval_required": true, "allowed_actors": ["agent://planning-assistant"] }, "metadata": { "required_permissions": ["service:dispatch"], "lifecycle": "invokable" } }], "evidence": { "store": "local-append-only", "append_only": true }}Developer reference
Manifest field reference
These fields are the minimum interoperable discovery surface for a host capability.
Stable host identity used in evidence, telemetry, and trust decisions.
Host implementation version, separate from capability and protocol versions.
CHP protocol version; v0.1 uses 0.1.
Host implementation kind such as local, service, cli, device, or mcp-wrapper.
Stable capability identifier selected by callers before invocation.
Capability contract version for compatibility checks.
Capability maturity status; deprecated is the standardized retirement signal.
Supported invocation modes that callers may request.
Evidence event types the capability can emit.
Structured policy metadata for risk tier, auth, approval, data classification, and allowed actors.
Extension area for host-specific lifecycle or entitlement labels that are still enforced through protocol outcomes.
Whether the host declares append-only evidence storage.
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.
Reference pages turn protocol concepts into implementation checks.
Field names, outcome codes, and conformance cases should stay stable across hosts.
Examples should map every field back to capability, host, policy, context, or evidence.
Visual model
- 01Read the field or code before implementation.
- 02Map it into manifest, invocation, outcome, or evidence behavior.
- 03Add route, conformance, or unit coverage for each failure-sensitive field.
Implementation notes
- Prefer explicit protocol fields over framework-specific inference.
- Treat absent required fields as malformed protocol input.
- Keep examples close to the failure cases they are meant to prevent.
Common mistakes
- Letting transport status codes carry protocol meaning alone.
- Hiding required protocol state in logs or application glue.
- Testing only successful invocations.
Related concepts