1. Purpose

This document provides a comprehensive walkthrough of a completed DDRP v0.2 execution, showing how a deterministic run is initiated, isolated, executed, and recorded. It combines step-by-step UI guidance with structural analysis of the resulting artifacts.

This walkthrough documents execution behavior and structural outputs only. It does not interpret results, assess compliance, or make legal, policy, or correctness claims.

2. Licensing & Use

Software License: DDRP is released under Creative Commons Attribution-NonCommercial 4.0 International CC BY-NC 4.0.

Walkthrough Content License: This walkthrough document and included screenshots are provided under the same license unless otherwise stated.

Permitted Use: Inspection, evaluation, testing, academic review, regulatory examination, and adaptation of the protocol pattern consistent with the license terms.

Prohibited Use: No claims of legal compliance, regulatory approval, or correctness may be made based solely on this walkthrough or the artifacts shown herein.

3. Critical Disclaimers

3.1 Evidentiary & Interpretation Disclaimer

• This walkthrough documents execution behavior only.
• DDRP does not perform legal interpretation, policy analysis, or compliance determination.
• Detected operators and instantiated obligations represent structural signals derived deterministically from canonical text.
• Obligation statuses (e.g., OPEN, SATISFIED) reflect structural completeness, not legal validity, enforceability, or intent.
• Any conclusions drawn from these artifacts are the responsibility of the downstream analyst or authority.

3.2 Determinism & Integrity Statement

All inputs, outputs, and artifacts shown in this walkthrough are bound to a single isolated run via cryptographic hashes and transaction records. Re-execution against the same canonical input and pattern set will produce byte-identical results.

4. UI Walkthrough

This section shows a single, completed DDRP v0.2 run from initialization through artifact generation. Each figure corresponds to a visible stage in the UI and reflects what the system displays at that point in execution.

4.1 Run Initialization and Isolation

Figure 1 shows the UI immediately after a new run is started. A unique Run ID is generated and displayed, and the interface transitions from an idle state to an active, isolated execution context. All subsequent inputs and outputs in the walkthrough are bound to this run.

Run ID: 2f5da1c2-18b4-4c47-a173-88bc43054e4a

4.2 Protocol Self-Test

Figure 2 shows the protocol self-test being executed to verify that the DDRP runtime and pattern set are loaded correctly. All checks complete successfully, confirming the system is in a valid state before document analysis begins.

Self-Test Results:

• Timestamp: 2026-01-01T00:49:04.327Z
• Deterministic: TRUE (128 exact): PASS
• Pattern Count: 49
• Canon Rule Count: 7
• Catch Task Count: 2 (catch)
• Operators Detected: 3
• Overall: PASS

4.3 Known Test Inputs

Known test inputs are fixed, predefined test documents whose structure and expected outcomes are already understood in advance. They exist for one reason only: to verify that the protocol behaves deterministically before it is applied to an unknown document.

By running DDRP against known inputs (Semantic A, Semantic B, and the remaining test cases), you confirm that the same operators and obligations are detected every time, without drift, inference, or interpretation. This establishes a stable baseline so that any ambiguity or gaps found later can be attributed to the source document—not to the system.

Figure 3 — Known Semantic A:

Input text: "Users must submit identification within 30 days."

Figure 4 — Known Semantic B:

Input text: "Identification must be provided by users no later than thirty days."

4.4 Input Panel and Canonical PDF Extraction

Figure 5 shows the document input panel after the California-2025-AB853-Introduced.pdf has been loaded and successfully extracted into canonical text for deterministic review.

Extraction Details:

• File: California-2025-AB853-Introduced.pdf
• Pages: 2
• Extraction: Success
• PDF Hash (SHA-256): ba168f481ab42700
• Canonical Hash (SHA-256): 7f65326b008d823b
• Canon Rules Applied: 7

The upper panel displays the active run's input state, indicating that the document has been loaded and is bound to the run before analysis is executed. The lower panel shows the PDF extraction result, including page count, extraction status, cryptographic hashes, applied canon rules, and the read-only canonicalized text.

This view exists to make the exact analysis substrate explicit. It shows precisely what text will be reviewed by the protocol and provides verifiable evidence that extraction succeeded and that the text has not been interpreted, altered, or enriched prior to deterministic processing.

4.5 Run Summary and Structural Status

Figure 6 shows the run summary generated after deterministic review, presenting the structural resolution state of detected obligations and the integrity of the execution.

Summary Structure:

The summary consolidates the results of the completed run into four panels: Input (basic document characteristics), Signals Detected (operators and obligations count), Structural Profile (distribution of operator types), and Continuity (cryptographic hashes and deterministic confirmation).

This view exists to provide a high-level structural assessment of the run without interpreting meaning or evaluating compliance. It allows the reader to see, at a glance, whether obligations were structurally resolvable and whether the execution artifacts are complete and auditable.

4.6 Detailed Results and Export Artifacts

Figure 7 shows the detailed results of the completed deterministic review, including detected operators, instantiated obligations, and available export artifacts.

Interface Components:

The upper table lists all operators detected in the document, each tied to a specific pattern ID and character range in the canonical text. The middle table shows the obligations instantiated from those operators, along with their resolution status and the specific structural fields that are present or missing. The lower section provides export controls for the generated artifacts, including operator detections, obligations, bundled outputs, and the transaction record.

This view exists to allow direct inspection and verification of how obligations were derived from textual signals and to provide access to the immutable artifacts produced by the run. No interpretation or remediation is performed at this stage; the interface exposes structure and evidence only.

5. Structural Review of Results

This section provides a structured review of what the run demonstrates, what was detected, and how the resulting artifacts should be read, without interpreting legal meaning or assessing compliance.

5.1 Execution Integrity and Continuity

The demonstration run is bound by a single transaction record that establishes execution identity and continuity:

• A unique transaction identifier links the run to its inputs and outputs
• The input document is recorded with format, length, and cryptographic hash
• Output artifacts (operator detections and obligations) are similarly hashed
• The transaction chain begins from a zeroed previous hash, indicating a genesis run
• An explicit disclaimer states that the record documents execution continuity only

Together, these elements establish that the run is auditable, isolated, and reproducible.

5.2 Operator Detection Overview

The operator detection artifact records the raw structural signals extracted deterministically from the canonicalized text.

5.2.1 Requirement Operators (REQ)

The following requirement operators were detected:

• "shall" — detected three times
• "shall not" — detected once

Each detection is recorded with:

• Operator type
• Pattern identifier
• Matched text
• Exact character start and end offsets
• Metadata indicating requirement strength and negation status

These detections serve as obligation triggers, not as interpretations of meaning.

5.2.2 Scope Operators (SCOPE)

A single scope-bounding operator was detected: "Except as"

This operator introduces conditional or bounding logic and is treated as a distinct structural signal.

5.2.3 Universal Quantifiers (UNIV)

Multiple universal quantifiers were detected, including:

• "no"
• "all"
• "any"
• "only"

These operators contribute to obligation breadth and constraint structure but do not, by themselves, resolve obligations.

5.2.4 Anchors (ANCHOR)

Anchor operators were detected, including:

• URL references
• "pursuant to" phrases
• Literal citation placeholders

Anchors provide structural linkage and provenance signals within the document.

5.3 Obligations Instantiated

From the detected operators, DDRP instantiated five obligations:

5.3.1 Requirement Applicability Obligations

Four obligations of type REQ_APPLICABILITY were instantiated, each triggered by a detected requirement operator.

For each of these obligations:

• The required structural fields are "who" and "what"
• These fields were not deterministically present in the extracted signal set
• As a result, all four obligations remain in OPEN status

5.3.2 Scope Bounding Obligation

One obligation of type SCOPE_BOUNDING was instantiated from the detected "Except as" operator.

• The required field ("scope") was present
• The obligation is marked SATISFIED
• Evidence links directly back to the triggering scope operator and its character range

This demonstrates successful deterministic resolution where required structure is present.

5.4 Structural Field Propagation

Although the four requirement obligations remain OPEN, the run demonstrates limited field propagation:

• The detected scope signal is recorded as evidence for multiple requirement obligations
• This shows that structural signals can be reused across obligations without asserting semantic resolution

The system exposes partial structure while preserving uncertainty where required fields are missing.

5.5 Status Summary

The final obligation status distribution for this run is:

• SATISFIED: 1
• OPEN: 4
• CONTRADICTED: 0
• AMBIGUOUS: 0

This distribution reflects the structural characteristics of the source document as processed deterministically.

6. What This Run Demonstrates

This demonstration run shows that DDRP:

• Reliably detects obligation-triggering language
• Separates scope bounding from requirement applicability
• Instantiates obligations only when structural criteria are met
• Refuses to infer or complete missing fields
• Preserves uncertainty explicitly through OPEN obligation states
• Produces complete, auditable artifacts bound to a single execution

7. What This Run Does Not Claim

This run does not:

• Interpret legal meaning or intent
• Assess regulatory compliance
• Determine enforceability or correctness
• Resolve obligations beyond deterministic structure
• Substitute for legal, policy, or human analysis

8. Why This Document Is a Suitable Demonstration Case

The source document (California-2025-AB853-Introduced.pdf) contains realistic regulatory features:

• Hard requirements ("shall", "shall not")
• Scope carve-outs
• Universal quantifiers
• Cross-references and anchors

This combination produces a non-trivial but traceable signal surface, making it well-suited for illustrating DDRP's design principles and execution boundaries without overloading the reader.

9. Exported Artifacts

At the conclusion of a run, DDRP produces three structured JSON artifacts. Together, these files constitute the complete, auditable record of execution.

9.1 Operators JSON

This file lists every operator detected in the canonical text. Each entry records the operator type, matched text, pattern identifier, and exact character range. It represents the raw, deterministic signal surface extracted from the document, without aggregation or interpretation.

File: ddrp-v0.2.0-operators-6abbeca0-c2dfd6e8-2026-02-01T00-49-56-490Z.json

Structure:

• Version: 0.1.0
• Pattern count: 49
• Matches: Array of 24 detected operators
• Input hash: 6abbeca0 (links to source document)

9.2 Obligations JSON

This file records the obligations instantiated from detected operators. For each obligation, it specifies the obligation type, required structural fields, which fields are present or missing, and the resulting status. It documents how textual signals resolve—or fail to resolve—into structurally complete obligations.

File: ddrp-v0.2.0-obligations-6abbeca0-c2dfd6e8-2026-02-01T00-49-58-803Z.json

Structure:

• Version: 0.1.0
• Obligation count: 5
• Obligations: Array of 5 obligation records
• Status summary: SATISFIED: 1, OPEN: 4, CONTRADICTED: 0, AMBIGUOUS: 0

9.3 Transaction Record JSON

This file records execution continuity and integrity. It includes run identifiers, timestamps, input and output hashes, environment metadata, and hash chaining. The transaction record does not assert correctness or compliance; it exists to prove that the run occurred as recorded and that the exported artifacts are bound to that execution.

File: ddrp-v0.2.0-transaction-6abbeca0-c2dfd6e8-2026-02-01T00-50-01-027Z.json

Key Fields:

• DDRP version: 0.2.0
• Transaction ID: 4f4d87a0-07c7-4f15-8a#-06034f675c59
• Timestamp: 2026-02-01T00:49:02.100Z (UTC)
• Input hash: 6abbeca0
• Detection hash: de7387d60e82c5c6
• Obligations hash: 9ae2638f35243ded
• Transaction hash: e26e39a7889d7eb7
• Previous transaction hash: 0000000000000000 (genesis run)
• Disclaimer: This record documents execution continuity only

10. Conclusion

This combined walkthrough has demonstrated a complete DDRP v0.2 execution from initialization through structural analysis. The walkthrough has shown:

• How deterministic runs are initialized and isolated
• How known test inputs validate protocol behavior
• How canonical text extraction preserves document integrity
• How operators are detected and obligations instantiated
• How structural completeness is assessed without interpretation
• How artifacts provide complete, auditable execution records

The protocol's refusal to infer missing structure, its preservation of uncertainty through OPEN states, and its production of cryptographically-bound artifacts establish DDRP as a deterministic tool for structural document analysis.