The Architecture
Most compliance systems answer one question: what is the current state of this obligation? DDRP and CAAP answer two different questions, at two different points in the lifecycle of a professional obligation, using two architecturally isolated layers.
DDRP answers
What obligation-creating language exists, was it detectable at production, and was each obligation structurally resolved or left open?
CAAP answers
Who acted on the obligations in this artifact, when, under what authority, and against which cryptographically verified version of the record?
The Interface Contract
The interface contract is the only formal connection between the two layers. It defines the JSON schema a DDRP artifact must satisfy before CAAP will accept it. An artifact that fails validation is rejected entirely — no partial acceptance.
| Field | Purpose |
|---|---|
| artifact_schema_version | Structural compatibility. CAAP rejects unsupported versions without coercion. |
| artifact_hash | SHA-256 of canonical artifact payload. CAAP recomputes and must match. |
| document_id | Stable identifier of the source document. |
| extraction_timestamp | UTC timestamp of when the DDRP extraction occurred. |
| canon_rules_version | Version of the lexical extraction rules used. |
| obligations[] | Array of obligation objects produced by DDRP. May be empty. |
| absent_fields[] | Explicitly recorded structural elements not found. May be empty. |
Why the Separation Is Enforced
When extraction and attribution share one mutable system, a structural vulnerability emerges: the record of what obligations existed and the record of what was done about them can be retroactively aligned. The distinction between observation and interpretation collapses. The audit trail becomes a narrative document rather than an evidentiary one.
DDRP produces the record. CAAP references it by hash only. Neither can modify the other. The boundary between what was found and what was done is cryptographically enforced — not by convention, not by policy.
The Policy Connection
FedRAMP RFC-0024 (January 2026) mandates that federal cloud providers transition from human-written compliance narratives to machine-generated deterministic telemetry. The RFC explicitly prohibits generative AI outputs as compliance evidence.
The epistemological position is identical: compliance must be demonstrated by a verifiable, reproducible record, not a written assertion. The difference is scope. OSCAL applies to one domain. DDRP + CAAP applies wherever professional obligations under document require an auditable evidentiary chain.
Where the Stack Sits
Three commercial categories address portions of this problem space. None implements both layers with architectural separation.
| Property | DDRP + CAAP | CLM Platforms | GRC Platforms | FedRAMP / OSCAL |
|---|---|---|---|---|
| Deterministic obligation extraction | YES | NO (AI/ML) | NO (manual) | YES (telemetry) |
| Hash-stable immutable artifact | YES | NO | NO | PARTIAL |
| Layer separation (extraction / attribution) | YES | NO | NO | NO |
| Append-only event log (structural) | YES | NO | NO | NO |
| Authority basis required per action | YES | NO | NO | NO |
| Hash-bound action to artifact version | YES | NO | NO | PARTIAL |
| No probabilistic inference in verification | YES | NO | NO | YES (mandated) |
| Domain agnostic | YES | YES | YES | NO |
| Open non-commercial protocol | YES | NO | NO | NO |
Every commercial system in this analysis can produce an audit log. None can produce an audit log in which every entry is cryptographically bound to the specific version of the document from which obligations were deterministically extracted, with a required authority declaration per action, in a structurally append-only form. That is the gap this stack fills.
The EU AI Act Connection
Neither DDRP nor CAAP is an AI system. Neither is subject to the EU AI Act. That is the point. Organizations deploying high-risk AI systems under the Act need an accountability layer that is deterministic, human-reviewable, and not itself subject to the probabilistic failure modes the Act is designed to govern.
The stack maps directly to the Act's documentary obligations:
DDRP covers
- Article 11 — Technical documentation
- Article 12 — Record-keeping and logging
- Article 13 — Transparency and traceability
- Article 17 — Quality management systems
CAAP covers
- Article 17 — Accountability and authority chains
- Article 19 — Post-market monitoring
- Article 20 — Serious incident reporting basis
- Article 21 — Cooperation with authorities
The Documentary Accountability Substrate (DAS) is the governance framework that formalizes this mapping — introduced in the Routledge volume on agentic AI governance and published on Zenodo (DOI: 10.5281/zenodo.19369623).
Open Source
All three protocols are published as open-source repositories. Non-commercial. Freely available.