The Compliance Problem
If a compliance review cannot be reconstructed, it cannot be defended. An auditor, a regulator, or a counterparty asking you to prove that an obligation was reviewed will not accept a description of your process. They need a record — tamper-evident, reproducible, tied to the specific version of the document you reviewed.
Three questions determine whether that record exists:
DDRP is the protocol that produces verifiable, auditable answers to all three.
What DDRP Is
DDRP extracts obligation-creating structure from text and renders it into an auditable, repeatable record.
Same document.
Same rules.
Same output.
That constraint is not a feature. It is the point.
DDRP operates on documents as structured artifacts, not as sources of meaning to be inferred. It identifies explicit linguistic operators — requirements, scope delimiters, definitions, universals, exclusions, temporal anchors — and instantiates them into obligations only when the text supports doing so.
Each obligation is evaluated against a fixed schema:
Who / What / When / Where / Why / How
If a field is absent, DDRP does not infer it. The absence is recorded as absence.
DDRP does not:
- interpret meaning
- judge compliance
- estimate risk
- score confidence
- predict outcomes
- explain decisions after the fact
The Design Constraint
DDRP trades linguistic coverage for inspectability. Every instance of a defined term is captured with 100% precision. Every gap in the dictionary is a known unknown — not a hidden failure.
Deterministic — Used
- Fixed lexical rules
- 100% precision on defined terms
- Inspectable and repeatable
- Fail mode: gaps in dictionary
- Gaps are known and auditable
Probabilistic — Not Used
- Statistical inference
- Variable output
- Black-box reasoning
- Fail mode: hallucination
- Gaps are hidden
The RFC 2119 standard (MUST, SHALL, SHOULD, MAY) provides the default obligation vocabulary. Custom dictionaries extend coverage to domain-specific terms.
How DDRP Works
Four sequential stages, each producing an auditable output:
1 — Ingestion & Layout Zoning
Coordinate-aware extraction. Physical structure preserved. Obligation location recorded. Same input always produces same canonical text.
2 — Lexical Extraction
Artifact scanned for obligation-creating terms. No inference. A term is present or absent. Exact character offsets recorded.
3 — Structural Resolution Tracking
Each obligation logged as open. Resolved only when a fulfillment token exists in the responsive artifact. Unresolved obligations remain flagged.
4 — Audit Trail Generation
Output: search token + coordinates + artifact hash + timestamp + resolution status. Immutable. Any post-hoc modification is detectable. Reruns are byte-identical under the same inputs and rules.
See DDRP in Action
A live pipeline demonstration runs DDRP and CAAP against real governing documents — including a California AI statute and a simulated AI-assisted employment assessment scenario. The demo shows what the D → A → L pipeline produces and what it enforces. In the HR simulation, users operate the CAAP ledger directly and encounter an obligation the system cannot attribute, because the governing document never assigned it.
The system prompts sent to the extraction layer are visible verbatim inside the demo. The raw JSON returned before rendering is inspectable. Every simulated attribution event is labeled as such at the card level.
Does this require AI?
No. DDRP is a deterministic lexical extraction protocol — pattern matching against a defined obligation dictionary. The v0.1 reference implementation uses 49 lexical patterns run by a regex engine. No language model involved. CAAP requires no AI in any configuration: it is an append-only recordkeeping protocol. A database and a SHA-256 library are sufficient.
The demo uses Claude AI to execute the DDRP extraction rules because it allows the pipeline to be demonstrated without shipping a full rule-based parser. A production implementation would replace this with a deterministic lexical engine. The demo is a proof of function — it shows what the pipeline produces, not how it must be implemented.
The full source code for this demo is available for inspection on GitHub. To request access contact bruce@quantuminquiry.org.
DDRP and CAAP
DDRP answers the structural question: what does this document obligate, and was each obligation resolved? It produces an immutable artifact and stops.
The accountability question — who acted on these obligations, when, and under what authority — is answered by CAAP, a separate protocol layer that references DDRP artifacts by hash only. Neither layer modifies the other.
DDRP and the EU AI Act
DDRP is not an AI system. It uses no machine learning, no statistical inference, and no probabilistic models. That means the EU AI Act does not regulate it — and that is precisely what makes it valuable to organizations that the Act does regulate.
The Act requires high-risk AI systems to maintain logs, produce traceable decisions, and support post-market monitoring under Articles 11, 12, 13, and 17–21. Those provisions specify what must exist. They leave open the documentary method by which authoritative text becomes a stable operational obligation and subsequent action remains reviewable under adversarial conditions.
DDRP closes that gap:
Article 12 — Logging
DDRP produces hash-stable, timestamped extraction records. Every run is byte-identical and tamper-evident.
Article 13 — Transparency
Obligations are identified by lexical rule, not inference. The record is human-readable and fully inspectable.
Article 17 — Quality Management
Same document, same rules, same output. Reproducibility is structural, not procedural.
CAAP extends this to the accountability layer: who acted on each obligation, when, and under what authority — in an append-only log that cannot be retroactively altered.
Open Source
DDRP, CAAP, and the Documentary Accountability Substrate are published as open-source repositories under the btisler-DS GitHub account. All protocol code is non-commercial and freely available.