Zenodo DOI: 10.5281/zenodo.21379780 - Published 2026-07-15
DKP-SPEC-001 · Defensible Knowledge Proof Protocol Specification v1.1
Defensible Knowledge Proof (DKP) - Cryptographic Proof Framework for Independently Verifiable Execution Event Validation
Version: 1.1 - Public Specification Issued by: Craig Thomas Ellrod. Author: Craig Ellrod, Founder & CEO License: Apache License 2.0 (Apache License 2.0) Document ID: DKP-SPEC-001 Status: Published Maintained by: Proof Economy™ Standards Alliance (PESA) Specification URI: proofprotocol.io
Proof Protocol™ is not a blockchain. No token. No wallet. No chain. No gas fees. Proof is anchored to the NIST Randomness Beacon. The stamp is earned, not minted.
Agents and humans do not trust agents. They trust proof.
Changelog - v1.1 - Field-level schema sections (8, 9, 15.2) moved to proprietary reference implementation, available under separate written terms - v1.0 - original release
Contents
- Section 1 - Overview
- Section 2 - The Problem DKP Solves
- Section 3 - Architecture
- Section 4 - Definitions
- Section 5 - The Five-Tier Corroboration Model
- Section 6 - Pre-Execution Commitment
- Section 7 - Attestation Architecture
- Section 8 - DKP ProofBundle™ Format
- Section 9 - Attestation Registry Entry Format
- Section 10 - Zero-Knowledge Proofs
- Section 11 - Valid Proof Event
- Section 12 - Extension Framework
- Section 13 - Proof Verifier
- Section 14 - Agentic Extension
- Section 15 - Valid Proof Stream
- Section 16 - Prior Art and Category Provenance
- Section 17 - Companion Standards
- Section 18 - Certification
Section 1 - Overview
The Defensible Knowledge Proof (DKP) Protocol is a domain-agnostic cryptographic proof framework that produces corroborated Proof Constructs - as distinguished from evidence artifacts - demonstrating that execution events occurred under pre-committed, independently verifiable conditions.
A Proof Construct is the convergence of independently witnessed execution evidence and independently attested corroboration from sources outside any single organizational trust boundary, structured such that fabrication requires the simultaneous compromise of structurally independent systems and institutional parties.
DKP is the underlying protocol for two companion standards: - Proof of Efficacy (PoE) - did the security agent work under adversarial conditions? - Proof of Performance (PoP) - did the system meet its performance specification under operational conditions?
Position on Evidence Standards
Emerging standards for tracking agentic behavior boundaries, including the Proof-of-Control Initiative, are evidence-generation frameworks: they establish what must be tracked and reported. They do not resolve the Self-Attestation Problem described below, since evidence generated within a system's own defined boundaries remains authored inside a single organizational trust boundary. DKP treats these frameworks as upstream infrastructure, not competing standards. As evidence-generation adoption grows, so does demand for the independent Attestation layer that converts evidence into a Proof Construct. Craig Thomas Ellrod participates in these working groups as a founding contributor and positions itself as the independent proof layer this and comparable standards require to satisfy legal, regulatory, and insurance evidentiary thresholds.
Section 2 - The Problem DKP Solves
Every vendor and every AI agent attests to the efficacy of its own behavior. The vendor builds the product, runs the tests, interprets the results, and authors the report. The AI agent executes the action and generates the log. The buyer or relying party receives a claim. There is no structural mechanism by which the buyer can independently verify whether that claim reflects what actually happened.
This is the Self-Attestation Problem: the party with the greatest interest in a favorable outcome is the sole author of the evidence for that outcome.
The Self-Attestation Problem is structurally worse for AI agents than for vendor products or human organizations. An AI agent can generate plausible, internally consistent, cryptographically sealable records of events that never occurred - at machine speed, without human authorship, without detectable markers of fabrication, and without any party outside the agent's trust boundary being aware that fabrication has taken place. Standard cryptographic sealing mechanisms authenticate the seal. They cannot authenticate what is underneath it.
Existing validation approaches produce evidence artifacts: records claiming that an event occurred, produced and sealed within a single organizational trust boundary, however cryptographically strong the sealing mechanism. Evidence can be fabricated. Evidence can be authored after the fact. A cryptographic hash only seals the misrepresentation.
DKP produces Proof Constructs. The distinction is structural: a Proof Construct requires the convergence of independently witnessed, independently attested records from sources that could not have been simultaneously compromised or fabricated without detection. No existing validation framework produces proof in this sense. DKP does.
Section 3 - Architecture
The DKP Protocol operates on a layered architecture:
- Proof Orchestration Layer (Arena7™) - manages proof event lifecycle
- Isolated Execution Environment (ArenaTwin) - dynamically instantiated digital twin of the target system or Agent Under Test, provisioned per proof event, destroyed upon completion
- Observation and Evidence Collection Layer - captures execution telemetry from Observation Points outside the prover system's organizational trust boundary
- Threat Intelligence Pipeline (CHOMP™ / SHRED™) - CHOMP™ ingests raw threat intelligence; SHRED™ shreds it into identifiable, actionable campaign streams
- Proof Artifact Generation and Sealing Layer - produces DKP ProofBundles and commits them to ProofRegister™/ProofChain™
- Primary Attestor Service - deployed outside the prover system's organizational trust boundary, attests every sealed ProofBundle™ at T5 completion and every Atomic Execution Unit in real time for Valid Proof Stream events
- Attestation Partner Framework - extensible registry enabling independent institutional parties to register attestations against sealed ProofBundles
Section 4 - Definitions
| Term | Definition |
|---|---|
| Atomic Execution Unit (AEU) | The indivisible unit of execution in a DKP proof event. A single discrete action - committed to before execution, executed, witnessed by an independent Observation Point, and attested by the Primary Attestor. Actor-agnostic and domain-agnostic. |
| Valid Proof Event | A sealed, attested ProofBundle™ produced from one or more Atomic Execution Units in a single campaign or proof run. Point-in-time but non-repudiable. |
| Valid Proof Stream | A continuous, live-queryable sequence of Valid Proof Events across time. Each AEU is attested in real time as it executes. |
| Attestation Stream Event | The per-AEU attestation record within a Valid Proof Stream. Generated and signed by the Primary Attestor immediately upon AEU completion. |
| Defensible Knowledge Proof (DKP) | A corroborated Proof Construct comprising: a cryptographically sealed execution evidence record produced under pre-committed, independently verifiable conditions; convergent attestation from at least one structurally independent Observation Point; a mandatory attestation from the Primary Attestor at seal time; and optionally, additional attestations from independent Attestation Partners. |
| Proof Construct | The convergence of independently witnessed execution evidence and independently attested corroboration from sources outside any single organizational trust boundary. Fabrication requires the simultaneous compromise of structurally independent systems and institutional parties. Distinguished from an evidence artifact in that evidence originates within a single trust boundary. |
| Evidence Artifact | A record claiming that an execution event occurred, produced and sealed within a single organizational trust boundary. Does not constitute a Proof Construct regardless of the strength of the sealing mechanism. |
| Valid Proof | A ProofBundle™ that satisfies all structural integrity requirements, corroboration tier conditions, temporal ordering constraints, and attestation requirements defined in Section 11. |
| Defective Proof | A ProofBundle™ that fails any single condition specified in Section 11. MUST NOT be relied upon for conformance claims, insurance submissions, or regulatory disclosure. |
| Pre-Execution Commitment | A cryptographic hash of execution parameters generated and signed before execution begins. Cannot be altered post-execution without detection. |
| External Randomness Source | A publicly verifiable, timestamped external entropy source independent of the prover system. The NIST Randomness Beacon is the reference implementation. |
| Commitment Hash | The cryptographic hash constituting the pre-execution commitment record. |
| ArenaTwin | A dynamically instantiated isolated digital twin of the target system or Agent Under Test, destroyed after proof completion. |
| Observation Point | An independent evidence capture mechanism deployed outside the prover system's organizational trust boundary. The prover cannot author, modify, or suppress evidence captured by an Observation Point. |
| Primary Attestor | A structurally independent attestation authority deployed outside the prover system's organizational trust boundary. Automatically attests every sealed DKP ProofBundle™ at T5 completion. In a base deployment, operated by Craig Thomas Ellrod |
| Attestation Partner | Any independent institutional party - including insurers, auditors, regulators, legal counsel, and certification bodies - that independently reviews a sealed DKP ProofBundle™ and registers a signed attestation in the Attestation Registry. |
| Attestation Registry | A structured component of the DKP ProofBundle™ recording attestations from the Primary Attestor and any enrolled Attestation Partners. |
| DKP ProofBundle™ | The sealed, immutable artifact constituting a Valid Proof Event. |
| ProofRegister™ | The public registry of sealed DKP ProofBundles. Publicly queryable. Contains only cryptographic hash values - no raw evidence data exposed publicly. |
| ProofVault™ | The private, offline store of corroborating evidence for each DKP tier. Access-controlled. |
| ProofChain™ | A sequential linked chain of DKP ProofBundles, each containing the seal hash of the preceding bundle. |
| ProofStamp™ | The certification mark issued upon successful completion of a DKP pipeline. |
| Proof Correlation Identifier (PCID) | A globally unique identifier for a DKP proof event. Craig Thomas Ellrod operates as the independent custodian in the PCID architecture. |
| Proof Efficacy Score (PES) | A derived metric computed from the corroboration tier, control outcome, evidence completeness, and Attestation Registry depth. |
| Control Outcome | A discrete classification of AEU execution behavior. See Section 11.3. |
| Relying Party | Any entity that consumes a ProofBundle™ as evidence and requires independent assurance of its validity without relying on prover assertions. |
| Agent Under Test (AUT) | An autonomous or semi-autonomous AI agent operating as the Prover system in a DKP proof event. See Section 14. |
| AI Agent Trust Boundary | The set of systems, principals, and infrastructure within which an AI agent operates and over which a controlling party exercises authority. See Section 14. |
| Independent AI Agent Witness | An AI agent that satisfies independence conditions IC-001 through IC-004 and therefore MAY serve as an Observation Point. See Section 14. |
| Proof Verifier | A conformant implementation of the DKP verification procedure. See Section 13. |
| Verification Report | The structured, signable output of a Proof Verifier execution. See Section 13. |
Section 5 - The Five-Tier Corroboration Model
The DKP Protocol assigns each proof event a corroboration tier based on the number and independence of evidence sources collected. The five tiers are sequential and non-skippable.
| Tier | Label | Requirement |
|---|---|---|
| T1 | ACTIVATED | Pre-execution Commitment Hash generated and anchored to External Randomness Source. |
| T2 | COMMITTED | Execution environment instantiated. Execution parameters locked and signed. |
| T3 | WITNESSED | Real-time execution telemetry captured from at least one Observation Point outside the prover system's organizational trust boundary. |
| T4 | ANALYZED | Post-execution analysis complete. Control Outcome determined for each AEU. |
| T5 | SEALED | All evidence aggregated, hashed, and cryptographically signed. ProofStamp™ issued. |
A ProofBundle™ that has not received Primary Attestor attestation is classified as a T4 artifact, not a T5 Sealed Proof Construct.
Detailed field-level evidence requirements per tier are maintained in Craig Thomas Ellrod's proprietary reference implementation.
Section 6 - Pre-Execution Commitment
The pre-execution commitment is the architectural moat of the DKP Protocol. No competitor can replicate this step without having called the shot before execution.
Prior to any execution event, the prover system generates a Commitment Hash comprising the Atomic Execution Unit set identifier, the target environment configuration hash, the expected behavioral outcome, the execution timestamp, and a value derived from the contemporaneous External Randomness Source output.
The Commitment Hash is signed and recorded before execution begins. The External Randomness Source - a publicly verifiable, timestamped entropy source independent of the prover system - ensures that the commitment cannot be fabricated retroactively. Post-hoc fabrication is structurally impossible.
This is the foundational distinction of the DKP Protocol from all prior art: BAS platforms, red team reports, compliance scanners, ZKPs, and cloud provider attestation schemes all produce evidence after the fact. DKP requires the claim to be made before the outcome is known. This property holds regardless of whether the actor is a human operator, an automated system, or an AI agent.
Section 7 - Attestation Architecture: From Evidence to Proof
The Attestation Registry is the mechanism by which a DKP ProofBundle™ transitions from a strong evidence artifact to a Proof Construct.
Primary Attestor Every DKP Protocol deployment includes a Primary Attestor service operated outside the customer's organizational trust boundary. Upon T5 completion, the proof orchestration layer automatically transmits the sealed ProofBundle™ to the Primary Attestor for independent verification and signed attestation.
For Valid Proof Stream runs, the Primary Attestor additionally signs each Attestation Stream Event in real time as each AEU completes execution.
This process is automatic, mandatory, and occurs before the ProofBundle™ is committed to ProofRegister™.
Attestation Partners Independent Attestation Partners - including insurers, auditors, regulators, and legal counsel - may register attestations against any sealed DKP ProofBundle™. Each registered attestation is appended to the Attestation Registry without modifying the sealed artifact.
Attestation status is live and queryable in real time at each partner's verification endpoint, without requiring access to or cooperation of the prover system: ATTESTED, UNDER_REVIEW, REVOKED, SUSPENDED.
Proof Strength Accumulation Each additional Attestation Partner increases proof strength - from Primary Attestor alone, up through insurer, regulatory, and legal counsel attestation. Proof strength accumulates over time. Static evidence artifacts cannot possess this property.
Section 8 - DKP ProofBundle™ Format
The field-level schema for the DKP ProofBundle™ - including commitment hash structure, evidence bundle format, corroboration tier encoding, and seal computation - is maintained as part of Craig Thomas Ellrod's proprietary reference implementation. Available to Attestation Partners and licensees under separate written terms.
Section 9 - Attestation Registry Entry Format
The field-level schema for Attestation Registry entries is maintained as part of Craig Thomas Ellrod's proprietary reference implementation. Available to Attestation Partners and licensees under separate written terms.
Section 10 - Zero-Knowledge Proofs: Where They Fall Short
Zero-Knowledge Proofs (ZKPs) are mathematically powerful. They are not a substitute for DKP.
A ZKP verifies the seal. It proves that a computation was performed correctly without revealing the inputs. It cannot tell you what happened underneath the seal.
DKP verifies what happened underneath the seal. It proves that a real-world execution event occurred - whether an adversarial technique, an AI agent action, a workflow step, or any Atomic Execution Unit - at a specific point in time, witnessed by structurally independent parties, before the outcome was known.
The distinction is structural: - A ZKP proves a mathematical statement about data. It cannot prove that an AEU was executed as committed, because execution is a real-world event, not a mathematical proposition. - A ZKP has no independent attestation layer. No structurally independent party witnesses or attests the real-world event the ZKP purports to prove. - A ZKP requires trusted setup parameters or trusted verifiers in most practical implementations, relocating rather than eliminating the trust problem. - A ZKP applied to a fabricated log - including a log fabricated by an AI agent at machine speed - produces a mathematically valid proof of a false claim. DKP's pre-execution commitment makes fabrication of the underlying record structurally infeasible before the ZKP is ever applied.
ZKP verifies the seal. DKP verifies what happened underneath it.
The DKP Protocol produces Proof Constructs rather than evidence artifacts through five structural properties: 1. The prover cannot author the Observation Point evidence - it is captured by parties outside the prover's trust boundary 2. The prover cannot author the Primary Attestor attestation - it is generated by a structurally independent party 3. The prover cannot author additional Attestation Partner attestations - each is generated independently 4. Fabricating a Proof Construct requires the simultaneous compromise of the prover system, at least one independent Observation Point, the Primary Attestor, and every enrolled Attestation Partner 5. The convergent, real-time queryability of independent attestations means fabrication cannot be retroactive
These structural properties produce a standard of proof that satisfies the convergent-testimony model used in legal, regulatory, and insurance proceedings.
Section 11 - Valid Proof Event
11.1 Definition
A Valid Proof Event is a sealed, attested ProofBundle™ produced from one or more Atomic Execution Units in a single campaign or proof run. It is the atomic proof construct of the DKP Protocol.
11.2 Conditions for a Valid Proof Event
A ProofBundle™ is a Valid Proof Event if and only if all of the following conditions are satisfied:
- C-001 - commitment_hash and randomness_source_value MUST be present, matching an independently retrievable NIST Beacon pulse.
- C-002 - The Beacon timestamp MUST precede execution start.
- C-003 - The Beacon pulse value MUST be independently retrievable from the NIST Randomness Beacon public archive.
- C-004 - A ProofBundle™ asserting T5 (SEALED) MUST carry a valid signature verified against the Primary Attestor's public key at ProofRegister™.com.
- C-005 - For any non-genesis ProofBundle™, its chain-link field MUST equal the seal hash of the immediately preceding bundle.
- C-006 - A break in the ProofChain™ at any position invalidates all subsequent ProofBundles.
- C-007 - A Valid Proof Event MUST have ATTESTED status from the Primary Attestor at time of verification.
- C-008 - Attestation status MUST be queryable by the Relying Party without prover cooperation.
11.3 control_outcome Enumeration
Values ordered from least to most active control engagement: NOT_EXECUTED, OBSERVED, LOGGED, ALERTED, DETECTED, PARTIAL, BLOCKED, EVADED, TIMEOUT, INCONCLUSIVE, ERROR.
NOT_EXECUTED and ERROR ProofBundles MUST NOT be used as Valid Proof Events for conformance claims. They are valid ProofChain™ entries for continuity and audit purposes.
11.4 Corroboration Tier Requirements
A Valid Proof Event MUST achieve at minimum T2 (COMMITTED). ProofBundles at T1 (ACTIVATED) are NOT Valid Proof Events for conformance claims, insurance submissions, or regulatory disclosure.
11.5 Verification Procedure
Non-interactive. No Prover communication required at any step. The verification procedure checks bundle integrity, pre-execution commitment validity, Primary Attestor signature, ProofChain™ integrity, evidence bundle integrity, attestation status, and corroboration tier sufficiency.
Full step-by-step verification procedure and machine-readable failure codes are maintained in Craig Thomas Ellrod's proprietary reference implementation.
11.6 Non-Repudiation Statement
A ProofBundle™ that passes all verification steps constitutes non-repudiable evidence that: an Atomic Execution Unit set was defined and committed to prior to execution using a value neither party controlled; the AEU set was executed in the configuration specified; the evidence artifacts have not been altered since sealing; a structurally independent Primary Attestor confirmed the integrity of the ProofBundle™ at the time of sealing; and the current attestation status reflects an active, unrevoked attestation. No prover assertion, verbal representation, or supplementary documentation is required. The proof speaks for itself.
11.7 Relationship to POCI Conformance Levels
| POCI Level | DKP Mapping |
|---|---|
| Level 1: Self-Declared | Structurally excluded. A Valid Proof Event requires Primary Attestor signature from a structurally independent party. Self-declaration cannot satisfy C-004. |
| Level 2: Third-Party Assessed | Satisfied at T3–T4. Point-in-time, independently witnessed assessment. Does not satisfy continuous ProofChain™ linkage (C-005, C-006). |
| Level 3: Continuously Monitored | Satisfied by Valid Proof Stream (Section 15). Per-AEU attestation in real time, live-queryable, continuously chained. |
Section 12 - Extension Framework
12.1 Purpose
The Extension Framework provides a structured mechanism for implementers, Attestation Partners, and future versions of this specification to add domain-specific, jurisdictional, or institutional fields to a ProofBundle™ without altering the core verification procedure. Extensions are sealed within the ProofBundle™ and are therefore tamper-evident.
12.2 Criticality
- CRITICAL - Proof Verifier MUST process. Unrecognized CRITICAL extension → DEFECTIVE outcome.
- INFORMATIONAL - Proof Verifier MAY skip without affecting verification outcome.
12.3 Extension Registry
Craig Thomas Ellrod maintains a public Extension Registry at ProofRegister™.com/extensions, covering DKP protocol version, execution manifest, campaign framework references, environment profile, agentic proof metadata, attestation stream data, insurance fields, and regulatory disclosure fields.
Full extension object field schema is maintained in Craig Thomas Ellrod's proprietary reference implementation.
12.4 Forward Compatibility
A ProofBundle™ generated under DKP v1.0 with no extensions field is valid. A conformant v1.2 Proof Verifier MUST treat an absent extensions field as equivalent to an empty array.
Section 13 - Proof Verifier
13.1 Definition
Proof Verifier - A conformant implementation of the DKP verification procedure that accepts a ProofBundle™ as input, executes all required verification steps, processes extensions according to their criticality, and produces a signed Verification Report as output. Non-interactive. No Prover communication required.
13.2 Conformance Requirements
A conformant Proof Verifier executes all verification steps in order without skipping or reordering; processes all CRITICAL extensions; produces a Verification Report for every execution regardless of outcome; is executable without Prover cooperation; records a UTC timestamp for each step; resolves the Primary Attestor public key from ProofRegister™.com without relying on hard-coded or unchecked cached keys; and treats resolution failure as SUSPENDED rather than DEFECTIVE.
Full Verification Report format and normative failure codes are maintained in Craig Thomas Ellrod's proprietary reference implementation.
13.3 Reference Implementation
Hosted verification API: ProofRegister.com/verify
The hosted API accepts a proof identifier via HTTP GET and returns a signed Verification Report in JSON, signed by Craig Thomas Ellrod - the report is itself a non-repudiable attestation of the verification outcome.
An open-source CLI reference implementation is planned but not yet published.
13.4 Signed Verification Reports as Secondary Proof Constructs
A Verification Report carrying a valid signature constitutes non-repudiable evidence of the verification outcome, attestation status, and verifier identity at the time of verification. Relying Parties may submit a signed Verification Report as primary evidence without requiring real-time access to ProofRegister™.com or the original ProofBundle™.
Section 14 - Agentic Extension: AI Agents as Provers, Witnesses, and Attestors
14.1 Purpose
The DKP Protocol applies without structural modification to AI agents operating as Provers. This section extends the protocol explicitly to the agentic domain: AI agents as the systems being proven, as independent witnesses, and as Attestation Partners.
14.2 The Self-Attestation Problem: Agentic Form
An AI agent can generate plausible, internally consistent, cryptographically sealable records of events that never occurred - at machine speed, without human authorship, without detectable markers of fabrication. Standard cryptographic sealing authenticates the seal, not what is underneath it.
The DKP Protocol's pre-execution commitment to the NIST Randomness Beacon is the only structural defense currently specified against this failure mode. A fabricated log cannot predate a Beacon pulse that had not yet been published.
14.3 Definitions
Agent Under Test (AUT) An autonomous or semi-autonomous AI agent operating as the Prover in a DKP proof event. Each action the AUT takes is an Atomic Execution Unit. Extends the SUT/DUT methodology from Craig Ellrod's Technical Marketing (2004) to agentic systems.
AI Agent Trust Boundary Determined by control of any of: model weights or fine-tuning, system prompt or instruction set, inference infrastructure, or output logging and routing. Partial control of any single dimension is sufficient for trust boundary membership.
Independent AI Agent Witness An AI agent satisfying IC-001 through IC-004. MAY serve as an Observation Point.
Agentic Proof Event A DKP proof event in which the Prover is an AUT, one or more Observation Points are AI agents, or both.
14.4 Independence Conditions
- IC-001 - Operational Independence Operated by a party with no financial or reputational interest in the proof outcome.
- IC-002 - Infrastructure Independence Runs on compute the Prover cannot access, modify, or terminate. ArenaTwin's network isolation is the reference implementation.
- IC-003 - Epistemic Independence No knowledge of the Prover's intended outcome before execution. NIST Beacon commitment enforces this structurally.
- IC-004 - Instructional Independence Operates under instructions authored before the proof event that the Prover cannot modify.
Failure of IC-001 or IC-002 is a permanent disqualification. Failure of IC-003 or IC-004 is remediable by resetting with a new commitment.
14.5 Role Separation
| Role | Description | Trust Boundary |
|---|---|---|
| Threat Actor | Executes adversarial AEUs against the AUT. In reference deployments: CHOMP™. | Outside Prover. |
| Agent Under Test (AUT) | The AI agent being proven. | Prover. |
| Independent AI Agent Witness | Captures real-time execution telemetry. Must satisfy IC-001–IC-004. | Outside both Prover and Threat Actor. |
| Primary Attestor | Attests sealed ProofBundle™ and Attestation Stream Events. In reference deployments: Craig Thomas Ellrod. | Outside Prover. |
14.6 Why No Existing Framework Closes This Gap
Vendor self-attestation is structurally identical to the Self-Attestation Problem. Red team reports are point-in-time and not continuously verifiable. Automated benchmarks place the Observation Point inside the Prover's trust boundary. Audit logs are generated by the agent or operator and remain subject to agentic fabrication risk. None produce a pre-committed, independently witnessed, independently attested, continuously queryable proof artifact. DKP does.
Section 15 - Valid Proof Stream
15.1 Definition
A Valid Proof Stream is a continuous, live-queryable sequence of Valid Proof Events across time. Each Atomic Execution Unit is attested in real time as it executes - not deferred to seal time. The stream is queryable during execution at ProofRegister™.com/stream/{proof_id}.
A Valid Proof Stream is composed of Valid Proof Events. A Valid Proof Event can exist without a Valid Proof Stream. A Valid Proof Stream cannot exist without Valid Proof Events as its atomic unit.
The Valid Proof Stream is the DKP Protocol's implementation of continuous attestation. It satisfies and exceeds the POCI Level 3 (Continuously Monitored) conformance requirement.
15.2 Attestation Stream Event Format
The field-level schema for Attestation Stream Events is maintained as part of Craig Thomas Ellrod's proprietary reference implementation. Available under separate written terms.
15.3 Relationship to POCI Level 3
| POCI Level 3 Requirement | Valid Proof Stream Implementation |
|---|---|
| Cryptographic evidence generated on an ongoing basis | Attestation Stream Events generated per AEU, in real time |
| Validated on an ongoing basis | Each event signed by Primary Attestor immediately upon AEU completion |
| Not assessed at a point in time | Events queryable live during execution |
| Independent validation | Primary Attestor outside Prover trust boundary; Observation Point captures evidence independently |
| Continuous integrity | Internal hash chain links every event; any tampering invalidates all subsequent events and the final seal |
No existing AI governance or attestation framework currently specifies or implements a mechanism equivalent to the DKP Valid Proof Stream. This specification and its reference implementation at ProofRegister™.com constitute deployed prior art as of 2026-07-04.
Section 16 - Prior Art and Category Provenance
Craig Ellrod has been proving system and device behavior under defined test conditions since 2004. The System Under Test (SUT) and Device Under Test (DUT) methodology - documented in Craig's book Technical Marketing - is the foundational prior art from which DKP emerges. The Agent Under Test (AUT) and Atomic Execution Unit (AEU) extend this methodology to autonomous AI agents and any domain requiring proof of execution.
- 2004: SUT/DUT test methodology developed; documented in Technical Marketing (Stratequest, 2008, ISBN 978-0982257005)
- 2004–2025: Twenty-plus years of adversarial validation practice across Cisco, Armor Defense, JupiterOne, and Cequence Security
- 2022 to 2023: Control-present versus control-absent testing committed on 18 January 2022 (surfd4wg/kali, now public), and live red-team evaluations of vendor products replacing scripted demos at the World Hacker Games (2023). Dated evidence: https://github.com/proofprotocol/PROOF-OF-EFFICACY-LINEAGE-PUBLIC
- 18 and 25 September 2025: HACKERverse® first publishes the CAE category (18 September) and the Proof Economy™ category (25 September), both captured by the Internet Archive on 6 October 2025
- March 24, 2026: Gartner releases Adversarial Exposure Validation (AEV) category - about six months after HACKERverse® first published CAE and the Proof Economy™
- July 4, 2026: DKP-SPEC-001 v1.1 published - Atomic Execution Unit (AEU), Valid Proof Event, Valid Proof Stream, Extension Framework, Proof Verifier, Agentic Extension, Continuous Attestation
Section 17 - Companion Standards
- Proof of Efficacy (PoE) v0.1 - applies DKP to adversarial security agent validation
- Proof of Performance (PoP) v0.1 - applies DKP to system performance specification verification
Both published by HACKERverse® under Apache License 2.0.
Section 18 - Certification
The DKP Protocol specification is published under Apache License 2.0 (Apache License 2.0). Any party may implement, reference, or build upon it with attribution.
Certification against DKP - the right to carry the ProofStamp™ mark - is retained by Craig Thomas Ellrod. The protocol is open. The stamp is not.
Contact
Craig Ellrod Original inventor, Proof Protocol ProofRegister™.com | proofprotocol.io
This document may be freely shared, referenced, and built upon with attribution. Certification rights are retained by Craig Thomas Ellrod.