Evidence is not telemetry

A fair pushback from any team with a mature stack: we already have OpenTelemetry — traces, spans, logs, the works. Why would what our agents do need a separate record? It's the right question, and the answer isn't "OTel is bad." It's that telemetry and evidence are built for different jobs, and one was never trying to be the other.

What telemetry is for

OpenTelemetry exists to help you understand a running system. Traces show how a request flowed; spans show where time went; logs and metrics show health. It's an extraordinary tool for debugging latency, finding a bad deploy, and watching a fleet. To do that job well, it makes choices that are exactly right for observability and exactly wrong for proof:

• It's sampled. You don't keep every span — you keep enough to see the shape. Defensible records can't be sampled; the action you'll be asked about is the one that got dropped.
• It's mutable and ops-owned. Spans are enriched, redacted, and aged out at the platform's discretion. That's good hygiene and bad provenance — a record you can edit is a record an adversary can question.
• It has no notion of a denial or an approval. A span can record that a call failed. It has no concept of an action refused at the boundary before it ran, or a human approving one — the outcomes governance actually turns on.

None of that is a flaw. It's telemetry being telemetry.

What evidence is for

CHP evidence exists to be defended — by a security reviewer, an auditor, opposing counsel, a regulator. That job demands the opposite choices:

• Mandatory, not sampled. Every attempt at the capability boundary emits a started/completed/failed/denied event. Completeness is the point.
• Tamper-evident, not mutable. Events are SHA256 hash-chained; altering or dropping one breaks the chain visibly. Integrity is a property of the record, not a promise from the platform.
• Decision-aware. Denials and approvals are first-class outcomes, with reason and subject — because "what was it not allowed to do, and who signed off" is the question that matters.
• Replayable by correlation. One id reconstructs the whole causal execution across tools, agents, and systems — not a sampled trace, the actual ordered sequence.

The second is what unblocks shipping an agent into consequential work.

They compose — you don't rip anything out

This isn't migrate-off-OTel. CHP sits at the capability boundary and OpenTelemetry sits across your whole system, and they meet cleanly: map CHP correlation ids to trace ids, and emit OTel spans or events from CHP evidence. Your dashboards keep working; your traces get richer; and you gain the one record OTel was never built to be — the complete, tamper-evident, decision-aware account of what crossed the boundary.

Keep OpenTelemetry for understanding your system. Add CHP for proving what your agents did. Where CHP sits among observability, gateways, workflow engines, and event streams is laid out in the landscape comparison — or see how evidence beats logs on the same point.