-
Notifications
You must be signed in to change notification settings - Fork 4
CHAP vs application‐specific approval logs
A custom approval log can record a button click. CHAP standardises the meaning, provenance and evidence of the decision so it can move across frameworks, tools and organisations.
CHAP does not make an application-specific approval log impossible or obsolete. A well-designed custom system can record any field CHAP records, use signatures, build a hash chain and enforce detailed policy.
The difference is standardisation. With a custom log, every consumer must learn your event names, identity rules, task model, override representation and integrity mechanism. With CHAP, those concepts have a shared wire format and method catalogue. The value grows when more than one application, framework, team or organisation must understand the same human-agent decision.
| Question | Application-specific log | CHAP |
|---|---|---|
| Event vocabulary | Chosen by one product team | Shared protocol methods such as review.request and decide.override
|
| Scope | Usually one application or workflow | Workspaces spanning humans, agents and services |
| Human modification | Often stored as a final value or free-text note | Structured diff, rationale, tags and intent classification |
| Identity | Product account or internal principal | Typed participants with explicit workspace membership and policy |
| Evidence integrity | Whatever the product implements | Signed envelopes and a hash-linked evidence model |
| Portability | Requires a custom export and interpretation layer | Common JSON-RPC wire, schemas and conformance material |
| Framework integration | Rebuilt per framework | Reusable bridges can map framework checkpoints into CHAP decisions |
| Operational freedom | Maximum product-specific flexibility | Constrained by protocol semantics and profiles |
| Adoption cost | Low for a single narrow flow | Integration cost, with returns increasing across boundaries |
Most approval systems begin with a table resembling this:
| timestamp | user_id | item_id | action |
|---|---|---|---|
| 10:42:18 | 4821 | draft-991 | approved |
That table answers who clicked what and when. It may be entirely adequate for product analytics or basic operations. It does not necessarily answer:
- Which agent and model version produced the proposal?
- Which artefact version did the reviewer see?
- Was approval within the reviewer's authority?
- Did the reviewer accept the output unchanged?
- If it changed, what was the patch and why?
- Did the reviewer preserve the agent's intent or substitute a different judgement?
- Which tool calls, external agents or source records supported the proposal?
- Can another system verify that the history was not silently rewritten?
Teams can add these fields. The result is often a capable but private protocol embedded in a database schema. CHAP makes that protocol explicit and reusable.
decide.approve, decide.reject and decide.override distinguish outcomes that are often collapsed into a Boolean. abstain.declare and escalate.raise represent two important cases that many approval tables treat as errors or comments.
A decision is meaningful only relative to what was proposed. CHAP links the review request, artefact and decision. An override can carry a JSON Patch style diff, a rationale, tags and whether the original intent was preserved.
CHAP uses a workspace as the unit of accountable work. Humans, agents, services and groups become typed participants subject to membership and policy, instead of anonymous actors behind a generic application event.
Every signed message extends the evidence chain. audit.read and verification operations make the chain a first-class protocol surface rather than an implementation detail of one product's logging stack.
An MCP tool call or A2A exchange can be cited without copying the external protocol traffic into CHAP. The approval evidence can remain coherent even when work crosses several systems.
A custom approval log may be the right answer when:
- The workflow is narrow and unlikely to leave one product.
- Existing event infrastructure already satisfies the required evidence model.
- Millisecond-level operational telemetry matters more than portable decision semantics.
- CHAP's participant, workspace or artefact model would add complexity without a real consumer.
- The system must remain compatible with an established sector schema that already governs the exchange.
Standards have a cost. Do not adopt CHAP merely to replace a four-column table with a larger four-column table.
The case strengthens when:
- Several agent frameworks need to produce equivalent decision records.
- Review happens outside the application that generated the proposal.
- A customer, partner or auditor must interpret the evidence independently.
- Overrides are intended to become structured improvement data.
- The organisation wants to change vendors without rewriting the meaning of its history.
- A protocol adapter must connect MCP tools, A2A peers and human review.
Do not begin by deleting operational logs. They still serve debugging, performance, billing and incident response.
- Identify the accountability boundary: the proposal, reviewer, decision and resulting action.
- Map application actors to CHAP participants.
- Map the business object to a CHAP task and artefact.
- Emit
review.requestwhen the proposal becomes reviewable. - Emit approve, reject or override when the reviewer responds.
- Store the CHAP evidence identifier in the existing operational event.
- Test export and verification from a separate process or implementation.
- Add abstention, escalation, handoff and stronger identity only where the workflow needs them.
This creates a narrow accountability spine while preserving the application's richer telemetry.
Dual writing can create disagreement between a product's approved=true field and a CHAP decision. Define which record is authoritative for the accountable outcome and make the other an index or projection.
Also define failure behaviour. If the business action succeeds but the CHAP envelope fails, the system needs a reconciliation path. If the CHAP decision is accepted but the external action fails, record the failed execution separately. Approval and execution are related facts, not the same fact.
- Why AI audit logs do not capture human judgement
- From human override to learning signal
- What CHAP proves, and does not prove, for AI governance
- CHAP specification
- CHAP core specification
- CHAP relationship to other standards
- CHAP practical scenarios
If your application already has an approval log, star CHAP and share a redacted event shape in Discussions. It is one of the best tests of whether the protocol vocabulary is complete.
Last reviewed: 25 August 2026.