Prove why an automated claim decision went the way it did.

Denial is a first-class outcome in CHP — which makes insurance one of the closest fits for the protocol. This page shows how it would work with today’s primitives; the production audit layer is what we build with a design partner.

Read the essay: “Proving why a claim was denied” →

The pain

Models and agents increasingly approve, deny, and price claims. When a decision is challenged — by a policyholder, an adjuster, or a regulator — you need to show not just the outcome, but why it happened and that it was allowed to happen. Logs scattered across services are not a defensible answer.

The trigger

A complaint, an audit, or a market-conduct exam asks: “Show us how this automated decision was made, and prove the record hasn’t changed.” Today that reconstruction is slow, manual, and contestable.

Who owns it

Claims and underwriting operations leaders, paired with compliance and legal — the people accountable when an automated decision has to stand up to scrutiny.

What CHP would do

Every decision crosses a capability boundary that emits a structured outcome — approved, denied, or referred — with a stable reason code, the deciding subject, and a tamper-evident evidence id, all replayable by case. A denial is a first-class, explainable record, not an inference from logs.

The demonstrated record

A decision, with its reason attached.

This is the actual shape of a CHP outcome: the decision, an explicit denial reason and code, the correlation that ties it to the case, and the evidence ids that back it. It is the record an adjuster, a policyholder, and a regulator can all replay.

Demonstrated, not yet shipped: the decision and denial primitives exist today. Hosted retention and regulator-shaped audit export are what we build with a design partner.

decision outcome — with reason

json

{
  "invocation_id": "inv_session_abc_001",
  "capability_id": "schedule_technician",
  "capability_version": "1.0.0",
  "correlation": { "correlation_id": "session-abc" },
  "outcome": "denied",
  "success": false,
  "data": null,
  "error": null,
  "denial": {
    "code": "entitlement_denied",
    "message": "service:dispatch is required",
    "retryable": false
  },
  "evidence_ids": ["evt_8f3a1c"],
  "started_at": null,
  "completed_at": "2026-06-16T15:14:22.104Z"
}

Building automated claims decisions?

Bring a real approve/deny flow. We’ll map it onto the protocol and build the retention and audit export your compliance function needs, together.

Build it with us