Waymo‘s robotaxis are completing more than 400,000 rides a week across ten U.S. cities. Every single journey involves thousands of perception, path planning, and control decisions. So here’s a question worth asking: if a regulator, an insurer, or a plaintiff’s counsel asked you to reconstruct any one of those decisions, what tamper-evident record exists to do it?
For most AV systems right now, the honest answer is nothing that an independent party could verify. That’s the accountability gap at the heart of robotaxi deployment, and it is closing fast.
EU AI Act Article 12 enforcement begins August 2026. UNECE WP.29 global technical regulations are in active development. At SAE Level 3 and above, liability shifts from driver to manufacturer — and without a tamper-evident audit trail, a manufacturer has no defensible record that the AI behaved as documented when something goes wrong.
The Driving Vehicle Protocol (DVP), part of the VeritasChain Standards Organization‘s VAP (Verifiable AI Provenance) Framework, is the open standard designed to fill this gap. Think of it as an AI flight recorder for autonomous vehicles: a standardised, cryptographically verifiable record of what the system decided and when, without exposing proprietary algorithms.
Defensible audit posture is the term we’ll use throughout: the state where your team can produce cryptographically verifiable evidence of AI decision behaviour in response to any regulatory inquiry, incident investigation, or litigation. This article covers the technical foundations, the regulatory mapping, and what to ask before signing any AV procurement contract.
Why Has Deployment Outpaced the Audit Infrastructure Autonomous Systems Need?
AVs generate terabytes of data per hour — LiDAR point clouds, camera feeds, radar returns — but there is no standardised, tamper-evident record of what the AI decided and why. Each manufacturer uses their own logging format, stored in a vendor-controlled silo with no standardised interface and no independent third-party verifiability. Call it “trust us” logging.
In January 2026, the NTSB opened an investigation into incidents where Waymo robotaxis drove past school buses in Austin and Atlanta. NHTSA separately launched an investigation after a Waymo robotaxi struck a child near a Santa Monica elementary school. In each case, investigators had no choice but to depend on vendor-supplied data — with no independent way to verify those logs hadn’t been modified after the fact.
XAI techniques like LIME and SHAP can explain model reasoning but they provide no tamper-evidence and no legal standing. EU AI Act Article 12 requires verifiable records of decisions, not explanations of them. That distinction matters when you’re in front of a regulator or a plaintiff’s counsel.
For a detailed account of what these audit gaps looked like in practice during real incidents, it’s worth reading the full breakdown.
How Did Aviation Solve This Problem — and What Does ED-112A Tell Us?
Aviation had the same problem. Before ED-112A and TSO-C124 codified flight data recorder and cockpit voice recorder requirements, post-crash investigations faced the same challenge: vendor-supplied logs with no independent tamper-evidence. The resolution required regulatory mandates — specific, enforceable requirements for what must be captured, for how long, and in what format.
DVP brings that same discipline to AVs. It defines a standardised minimal audit interface that all AV systems must expose, without requiring disclosure of proprietary algorithms. Both domains have a liability transfer moment — take-off for aviation, ADS engagement for AVs — and both require post-incident causal chain reconstruction. Both reached the same inflection point: voluntary manufacturer logging produced an accountability gap that only standardised requirements could close.
The EU AI Act August 2026 deadline and UNECE WP.29 GTR development are that inflection point for AVs.
What Is the Driving Vehicle Protocol (DVP) and How Does It Work?
DVP is an open standard from the VeritasChain Standards Organization (VSO) for tamper-evident audit logging of AI decision sequences in autonomous vehicles. It’s published at github.com/veritaschain/vap-spec under CC BY 4.0 — no licensing fees. VSO sets the rules; it doesn’t perform audits. Think W3C.
DVP is the automotive profile of the VAP (Verifiable AI Provenance) Framework. VCP — the finance profile — is already deployed in production financial systems and submitted to IETF SCITT as draft-kamimura-scitt-vcp. DVP follows the same architectural pattern.
The central design decision is what DVP calls the “audit zone vs. competition zone” principle. DVP standardises only the minimal audit interface — a five-field Common Header in every event record. Everything else — sensor fusion algorithms, neural network architectures, path planning implementations — stays proprietary, undisclosed, outside DVP’s scope entirely.
The DVP Common Header is five fields per event:
EventID— UUID v7 (time-ordered)Timestamp— ISO 8601VehicleID— vehicle identifierEventType— from the DVP Event Types Registryprev_hash— SHA-256 hash of the previous event (the chain link)
The DVP Event Types Registry defines a taxonomy in four categories:
- Perception: PRC_OBJ, PRC_LAN, PRC_SGN, PRC_LOW (low confidence)
- Planning: PLN_PTH, PLN_MNV, PLN_RTE
- Control: CTL_ACC, CTL_BRK, CTL_STR, CTL_EMG (emergency stop)
- System: SYS_MOD, SYS_TOR (takeover request), SYS_FLB (fallback), SYS_ODD (ODD boundary)
This is a standardised minimum. Vendors add domain-specific types in the payload’s competition zone.
How Do Hash Chains Create Tamper-Evidence Without Blockchain Overhead?
A hash chain is a cryptographic mechanism where each recorded event contains the SHA-256 hash of the previous event. The result is an append-only, tamper-detectable sequence where log integrity is a mathematical property of the data structure — not a policy enforced by an administrator.
Hashes are computed using JCS (RFC 8785) canonicalisation, which ensures reliability regardless of key ordering or whitespace. Each event contains prev_hash — the SHA-256 of the prior event. Each event is also signed with the vehicle’s Ed25519 private key for per-event non-repudiation.
Change a single field in event 1,000 and the chain integrity check fails for every event from 1,001 onward. Any party with access to the log can detect this — no vendor cooperation required.
A hash chain is not a blockchain. No distributed consensus, no mining, no infrastructure overhead. The legal consequence is straightforward: without a hash chain, a plaintiff’s counsel can argue vendor logs were modified after an incident. With a hash chain, modification is mathematically detectable by anyone with access to the log.
How Does Merkle Tree Anchoring Make Periodic Verification Practical at Scale?
An AV at highway speeds generates thousands of DVP events per minute. Anchoring every event externally would be prohibitively expensive.
Merkle tree anchoring solves this: batch the event hashes into a tree structure following RFC 6962, combine hashes upward until a single root remains, then submit only the 32-byte root to an external endpoint — a timestamp authority, notary service, or regulator-operated verification node — at intervals of every 10 minutes or at trip end.
To verify a specific event later, an auditor needs three things: the event record, the Merkle proof path (a small set of sibling hashes), and the anchored root. Recompute the root and check it matches. No other events required, no vendor involvement required.
More frequent anchoring narrows the tamper window but increases costs — calibrate against your regulatory obligations. The VSO Regulator-Operated Verification PoC demonstrated this running on a regulator’s own infrastructure across ten jurisdictions including the EU, UK, US, Japan, and Singapore. Regulators are actively building their own verification infrastructure.
What Are ODD Boundary Events and Why Are They the Most Critical Logging Category?
The Operational Design Domain (ODD) is the defined set of conditions within which an ADS is certified to operate safely: geography, weather, road type, speed range, time of day. The ODD boundary is not just a technical parameter — it’s the legal boundary that determines whether manufacturer liability is engaged.
When an incident occurs at L3+, the central question is: was the ADS within its certified ODD at the moment of the incident? Without a tamper-evident ODD boundary record, a plaintiff’s legal team can argue it wasn’t — and there’s no independent evidence to rebut them.
DVP’s SYS_ODD event type logs whenever a vehicle approaches or crosses its certified ODD boundary. A concrete sequence looks like this:
- Vehicle approaches fog-reduced visibility (LiDAR degraded below threshold)
SYS_ODDlogged — GPS coordinates, timestamp, boundary condition code- Conditions require fallback —
SYS_FLBlogged - Takeover required —
SYS_TORlogged with response timing
The hash chain preserves this sequence with tamper-evidence. The Merkle anchor establishes it was committed externally before any incident. In post-incident reconstruction, this answers the question that matters most: what did the system know, and when did it know it?
PRC_LOW (PERCEPTION_CONFIDENCE_LOW) is the complementary event — logged whenever sensor fusion confidence drops below threshold. Together, SYS_ODD and PRC_LOW cover the moments of greatest liability exposure: boundary conditions and perception failures.
ISO 21448/SOTIF establishes safety frameworks for perception insufficiency but lacks standardised audit trail specifications. DVP fills that gap: SYS_ODD and PRC_LOW are the implementation of what SOTIF requires but doesn’t specify.
For more context on why the Level 2 vs Level 4 distinction changes who is legally responsible for logging, the liability classification framework sets the full picture.
How Does DVP Map to EU AI Act Article 12, UNECE WP.29, and ISO 21448/SOTIF?
EU AI Act enforcement begins August 2, 2026. Autonomous vehicles are classified as high-risk AI under Annex III — and if you’re procuring or integrating AV technology now, your first production deployment is already within the compliance window. Non-compliance penalties reach €35 million or 7% of global annual turnover.
Article 12(3) requires: automatic logging of decision events; timestamping; recording of operation duration; logging of input data characteristics; and a reference database of model versions. Article 19 sets a minimum six-month retention period.
DVP satisfies each of these requirements. The sidecar integration pattern with hash chain covers automatic event logging. ISO 8601 timestamps are in every Common Header. SYS_ODD handles the ODD boundary documentation that WP.29 explicitly requires. The event taxonomy plus hash chain provides scenario reconstruction. And Merkle tree anchoring delivers the third-party verifiability implied by conformity assessment.
Article 12 does not yet explicitly require cryptographic integrity — but the pattern from MiFID II, SOX, and GDPR is consistent: principles-based text becomes prescriptive audit practice within a few years. VCP already satisfies MiFID II RTS 25. Cryptographically verifiable AI audit trails are already regulatory reality in finance.
DVP-compliant logging is a precondition for EU AI Act conformity assessment — necessary but not sufficient. But if you can’t produce DVP-compliant logs, you haven’t cleared the first bar. This connects directly to the broader autonomy accountability challenge enterprise teams need to understand before procuring or integrating any AV system.
DVP Open Standard vs Proprietary Vendor Logging — What Do Enterprises Gain?
Proprietary vendor logging has genuine advantages. Deep integration with the vendor’s perception stack. Engineers who can interpret the logs. No additional integration effort on day one. Acknowledging this makes the open standard case more credible, not less.
What proprietary logging can’t deliver is independent third-party auditability, regulatory portability, or an audit trail that survives vendor transitions. DVP’s “audit zone vs. competition zone” separation means adoption requires no proprietary disclosure. Here’s how the two approaches compare:
Log portability: DVP logs are publicly specified and processable without vendor software. Proprietary logs are vendor-dependent.
Third-party auditability: DVP Merkle proofs are verifiable by any party with the proof path. Proprietary logs require vendor cooperation.
Regulatory recognition: DVP maps to Article 12 and WP.29 with documented specificity. Proprietary formats need custom mapping per jurisdiction.
Tamper-evidence: DVP uses hash chain plus Ed25519 signatures. Proprietary logging relies on “we have access controls.”
Vendor independence at L3+: With DVP, you hold independently verifiable logs. With proprietary logging, you depend on the vendor at the liability moment.
Initial integration effort: DVP’s sidecar pattern has minimal overhead. Proprietary logging is lower effort on day one.
If a vendor is acquired, goes insolvent, or terminates a contract, an enterprise with proprietary logs faces loss of access to records needed for compliance or litigation — plus dependence on a vendor whose interests no longer align with yours. DVP’s open format and independently verifiable Merkle proofs eliminate that dependency.
Understanding how liability classification determines audit requirements clarifies why the enterprise — not just the AV vendor — needs its own independently verifiable record.
What to Ask When Evaluating AV Vendors for Audit Posture and DVP Compliance
This is a procurement due diligence function, not a post-deployment activity. Once a contract is signed with inadequate logging provisions, you inherit the vendor’s audit posture — which may not be defensible.
Five questions to ask before contract signature:
1. Log format standardisation: Is the audit trail in a standardised, publicly documented format (DVP-compliant or equivalent), or proprietary? Can you export raw logs an independent auditor can process without vendor software?
2. Tamper-evidence mechanism: Is log integrity cryptographically enforced — hash chain with per-event digital signatures — or policy-based? Ask for the technical specification. “We don’t modify logs” is not a tamper-evidence mechanism.
3. Independent verifiability: Can a regulator or auditor verify the integrity of a specific log record without vendor access or vendor-provided tools? Any process that requires the vendor to authenticate logs is not independent verification.
4. ODD boundary event logging: Does the logging architecture explicitly capture ODD boundary events — including approach to boundaries, not just violations? The vendor should be able to show you what a SYS_ODD equivalent event record looks like.
5. Retention policy and chain of custody: Who has custody of the logs? What happens if the vendor is acquired, goes insolvent, or terminates your contract? The enterprise should own exported logs in a portable format with retention aligned with EU AI Act Article 19 (minimum six months).
Development teams implementing DVP will find integration guidance at github.com/veritaschain/vap-spec. The focus here is enterprise procurement posture.
Frequently Asked Questions
Where can I find the DVP specification?
DVP is published at github.com/veritaschain/vap-spec under CC BY 4.0 — no licensing fees. The full specification including the Common Header schema, Event Types Registry, and Merkle anchoring guidance is freely available.
Does DVP require a blockchain?
No. DVP uses a hash chain — no distributed consensus, no mining, no blockchain infrastructure. A blockchain is a distributed consensus mechanism; a hash chain is a cryptographic sequencing property applicable to any append-only log. Tamper-evidence is enforced locally; Merkle anchoring provides external verifiability without blockchain.
Which autonomous vehicle vendors currently support DVP?
DVP is in specification phase as of April 2026 — VSO has not published vendor adoption commitments. Treat DVP compliance as a contractual requirement in new integrations. The “audit zone vs. competition zone” design means vendors need not expose proprietary systems to adopt DVP.
What is SOTIF and why does it matter for AV logging?
ISO 21448 / SOTIF addresses functional insufficiencies in sensors and algorithms — failures from system limitations, not component defects. SOTIF establishes safety frameworks but lacks standardised audit trail specifications. DVP fills this gap: SYS_ODD and PRC_LOW directly address the logging that SOTIF implies but does not specify.
What is the VAP Framework and how does DVP relate to it?
VAP (Verifiable AI Provenance) is a cross-domain meta-framework from VSO. DVP is the automotive profile; VCP is the finance profile (IETF SCITT submitted); MAP covers medical AI; EIP covers energy infrastructure. VAP’s Shared Assurance Core — hash chain, Merkle anchoring, Ed25519 signatures, JCS canonicalisation — is shared across all profiles.
What is the difference between XAI and DVP/VAP?
XAI answers “why did the model decide this?” using techniques like LIME, SHAP, or attention maps. DVP/VAP answers “did this decision actually happen and can you cryptographically prove it?” EU AI Act Article 12 requires verifiable records of AI decisions, not explanations. XAI alone does not satisfy Article 12.
What does EU AI Act Article 12 require from AV operators?
Article 12 requires high-risk AI operators to: automatically log all decision events; timestamp every event; record operation duration; log input data characteristics; and maintain a model version reference. Article 19 sets a minimum six-month retention period. Enforcement begins August 2, 2026; penalties reach €35 million or 7% of global turnover. In litigation, absent Article 12-compliant logs can be characterised as evidence destruction.
What is Merkle tree anchoring and how does a regulator verify logs?
Each leaf node is a hash of an individual event; intermediate nodes are hashes of child nodes; the root is a 32-byte hash committing to the full batch. DVP submits the root to an external endpoint periodically. To verify a single event, an auditor needs only the event record, the Merkle proof path, and the anchored root — no vendor access required. The VSO Regulator-Operated PoC demonstrated this across ten jurisdictions.
What happens to audit logs if an AV vendor is acquired or goes insolvent?
Proprietary formats create vendor custody risk: acquisition, insolvency, or contract termination can cut off enterprise access to logs needed for compliance or litigation. DVP’s open standard format eliminates this. Enterprise contracts should specify DVP-compliant log export, enterprise ownership of log files, and retention aligned with EU AI Act and UNECE WP.29 obligations.
Is “defensible audit posture” a product or a capability?
It is an organisational capability — the state where an enterprise can produce cryptographically verifiable evidence of AI decision behaviour in response to any regulatory inquiry, incident investigation, or litigation. DVP provides the technical foundation; the enterprise adds the policy, retention, and operational readiness layers.
The broader context for all of this is the accountability challenge that enterprise teams need to understand across the full scope of autonomous systems deployment. DVP addresses the logging layer. The enterprise team needs to address the full stack: governance, retention, chain of custody, and the contractual provisions that ensure those capabilities survive vendor transitions. Defensible audit posture is the state of readiness you hope you never need to demonstrate — and that you cannot build retroactively after an incident occurs.
