Open Protocol — Quantum Inquiry

Contextual Accountability Attribution Protocol

The layer above DDRP that proves who acted on an obligation, when, and under what authority — in an append-only, cryptographically bound event log.

Attribution Layer Append-Only Hash-Bound Authority-Declared Open Protocol

The Gap DDRP Leaves Open

DDRP produces a tamper-evident record of what obligation-creating language appeared in a document, whether it was detectable at the time of production, and whether each obligation was structurally resolved or left open. That record answers the structural question.

It does not answer the accountability question.

What DDRP proves

  • Obligation-creating language was found
  • It was detectable at time of production
  • It was structurally resolved or left open
  • The record is hash-stable and immutable

What DDRP does not prove

  • Who reviewed the obligation
  • When they acted
  • Under what authority
  • Against which version of the artifact

In regulated, legal, or organizationally consequential environments, both questions must be answered. CAAP closes the second one — without modifying, re-evaluating, or merging with DDRP.

What CAAP Is

CAAP records who acted on a DDRP artifact, when, and under what authority. It does not extract obligations. It does not interpret them. It does not re-evaluate whether the extraction was correct.

CAAP is an attribution layer. It records provenance chains, not compliance conclusions. Every event in the CAAP log requires an actor, a timestamp, an authority basis declaration, and a reference to the specific artifact hash it was taken against.

Three Defining Properties

Append-Only

Events are never modified or deleted. The log grows in one direction. Past states are permanently accessible.

Hash-Bound

Every event references the artifact_hash of the DDRP artifact it was taken against. Artifact change = new hash = new artifact identity.

Authority-Declared

Every event requires an actor field and an authority_basis field. Logging without authority declaration is structurally prohibited.

The Two-Layer Stack

DDRP and CAAP are not versions of the same system. They are adjacent layers separated by a published interface contract. DDRP produces artifacts. CAAP references them by hash only. Neither layer touches the other's internal state.

Layer B
CAAP
Attribution — append-only event log.
Every event: actor + timestamp + authority_basis + artifact_hash
No modification of past events. No deletion.
Contract
Interface Contract v1.0
Hash-bound handoff · SHA-256 only · CAAP has zero write access to DDRP · Mandatory validation before acceptance · No partial acceptance
Layer A
DDRP
Extraction — deterministic, hash-stable artifact.
Immutable once generated. Unaware of CAAP. Produces artifacts and stops.

Why the Separation Is Enforced

When extraction and attribution share one mutable system, the record of what was found and the record of what was done can be retroactively aligned. This is narrative governance — compliance demonstrated by a convincing story rather than a verifiable record.

If the layers bleed, the system collapses into narrative governance.

The DDRP / CAAP separation closes this structurally, not by policy. The boundary between what was found and what was done is cryptographically enforced.

Every commercial Contract Lifecycle Management platform and GRC system merges these layers. The result is a system that can tell you the current state of an obligation — but cannot prove, to a third-party auditor, the state at the moment of review, against which artifact version, and under whose declared authority.

What CAAP Does Not Do

  • Does not interpret obligations — interpretation belongs to the human reviewer
  • Does not re-evaluate extraction correctness — challenges to extraction are challenges to the DDRP artifact, not to CAAP
  • Does not modify obligation structure — the artifact is immutable; CAAP cannot add, remove, or change obligations
  • Does not add inferred fields — CAAP logs only what is explicitly declared by an actor
  • Does not perform lexical analysis — CAAP has no extraction function; it reads artifacts it did not produce
  • Does not provide compliance conclusions — CAAP records that actions were taken; adequacy is a determination for the reviewing authority

DDRP vs CAAP

DDRP CAAP
Core question What obligations exist in this document? Who acted on them and under what authority?
Primary output Immutable JSON artifact Append-only event log
Layer A — Extraction B — Attribution
Operates on Source documents Completed DDRP artifacts
Modifiable after generation No — immutable artifact No — append-only log

CAAP and the EU AI Act

The EU AI Act's accountability provisions — Articles 17 through 21 — require organizations deploying high-risk AI systems to maintain records of who made decisions, under what authority, and at what point in the system lifecycle. CAAP provides exactly this structure: an append-only, hash-bound event log with a required authority basis declaration per entry.

CAAP is not subject to the EU AI Act. It contains no AI. It is the accountability infrastructure that organizations subject to the Act need underneath their AI systems — a human-authored, cryptographically verifiable record of every action taken against every obligation the system created.

Open Source

CAAP, DDRP, and the Documentary Accountability Substrate are published as open-source repositories under btisler-DS on GitHub. All protocol code is non-commercial and freely available.