VeritasChain Standards Organization (VSO)

Posted on Jan 13

AI Needs a Flight Recorder: Introducing VAP, an Open Framework for Verifiable AI Decision Trails

#vap #ai #security #opensource

The $1 Trillion Question

On May 6, 2010, the Dow Jones Industrial Average dropped nearly 1,000 points in minutes. Over $1 trillion in market value evaporated—then partially recovered—in what became known as the "Flash Crash."

The cause? Algorithmic trading systems interacting in unexpected ways.

The aftermath? Years of investigation, contradictory explanations, and a lingering question: What actually happened inside those algorithms?

Fast forward to 2025. AI systems now manage not just trades, but medical diagnoses, autonomous vehicles, content moderation, and government benefits. The potential for catastrophic failure has grown exponentially. Yet our ability to answer "what happened inside the AI?" has barely improved.

This is why we built VAP.

The Accountability Gap

When a human makes a consequential decision, we can ask them why. When an AI makes one, we get... logs. Maybe. If they exist. If they haven't been tampered with. If someone thought to record them.

Consider these scenarios:

Finance: An algorithmic trading system executes a series of trades that triggers a market disruption. Regulators ask for the decision trail. The firm provides logs—but how do regulators know those logs are complete? That they haven't been edited? That they represent what actually happened?

Healthcare: An AI diagnostic system recommends against treatment for a patient who later dies. The hospital claims the AI flagged the case for human review. The family's lawyers claim it didn't. There's no way to prove either side.

Content Moderation: A platform claims it blocked AI-generated harmful content. Victims claim the content was generated and distributed. The platform produces logs showing rejection events. But can anyone verify those logs existed before the controversy?

The common thread: We're asked to trust logs that can be fabricated, modified, or selectively presented.

This isn't a technical limitation—it's a design failure. We have decades of cryptographic research on tamper-evident logging. Certificate Transparency has proven that append-only, publicly verifiable logs work at scale. Yet AI systems operate in an accountability vacuum.

Introducing VAP: Verifiable AI Provenance Framework

VAP (Verifiable AI Provenance Framework) is an open, vendor-neutral framework that defines minimum requirements for cryptographically verifiable AI decision trails.

The core principle is simple: Verify, Don't Trust.

VAP doesn't restrict what AI systems can do. It standardizes how they prove what they did.

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│     VAP (Verifiable AI Provenance Framework)                    │
│     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━                    │
│     Cross-domain meta-framework                                 │
│     Defines common minimum requirements                         │
│                                                                 │
│                          │                                      │
│                          │ publishes profiles                   │
│                          ▼                                      │
│                                                                 │
│     ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐            │
│     │   VCP   │ │   CAP   │ │   DVP   │ │   MAP   │  ...       │
│     │Finance  │ │Content  │ │Automotive│ │Medical │            │
│     └─────────┘ └─────────┘ └─────────┘ └─────────┘            │
│                                                                 │
│     Domain-specific protocol implementations                    │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

VAP defines the "what"—common requirements for verifiable AI provenance.
Domain-specific Profiles define the "how"—implementations tailored to finance, healthcare, automotive, and other high-risk domains.

The Four-Layer Architecture

Every VAP-compliant system implements four layers:

┌────────────────────────────────────────────────┐
│  Layer 4: Verification Layer                   │
│  Merkle Tree / External Anchoring              │
├────────────────────────────────────────────────┤
│  Layer 3: Integrity Layer                      │
│  Hash Chain / Digital Signatures               │
├────────────────────────────────────────────────┤
│  Layer 2: Provenance Layer                     │
│  Actor / Input / Context / Action / Outcome    │
├────────────────────────────────────────────────┤
│  Layer 1: Identity Layer                       │
│  UUID v7 / Timestamps / Issuer Identity        │
└────────────────────────────────────────────────┘

Layer 1: Identity

Every event gets a globally unique identifier (UUID v7), a high-precision timestamp, and cryptographic binding to its issuer.

{
  "event_id": "019400a2-7c8b-7def-8000-0123456789ab",
  "timestamp_ns": 1736762400000000000,
  "issuer_id": "VSO-ALGO-001"
}

UUID v7 embeds the timestamp, making identifiers inherently sortable while maintaining uniqueness guarantees.

Layer 2: Provenance

This is the "who did what with what information" layer. For AI systems, this captures:

Actor: Which model/algorithm/human made the decision
Input: What data was available at decision time
Context: Active parameters, constraints, environment state
Action: The decision or recommendation made
Outcome: What actually happened as a result

{
  "provenance": {
    "actor": {
      "type": "AI_MODEL",
      "identifier": "trading-algo-v2.3.1",
      "model_hash": "sha256:a1b2c3..."
    },
    "input": {
      "sources": ["market_feed_A", "risk_params_v4"],
      "hash": "sha256:d4e5f6..."
    },
    "action": {
      "type": "ORDER_SIGNAL",
      "decision": {"symbol": "AAPL", "side": "BUY", "qty": "100"},
      "confidence": "0.87"
    }
  }
}

Layer 3: Integrity

Each event includes a cryptographic hash of the previous event, forming an append-only chain. Any modification to historical events breaks the chain—and the break is mathematically detectable.

{
  "integrity": {
    "prev_hash": "sha256:9f8e7d6c5b4a...",
    "event_hash": "sha256:1a2b3c4d5e6f...",
    "signature": "ed25519:...",
    "signer_id": "VSO-SIGNER-001"
  }
}

The hash chain provides tamper evidence—you can detect if something changed. The digital signature provides non-repudiation—you can prove who created the record.

Layer 4: Verification

Individual hash chains prove internal consistency, but a malicious operator could maintain multiple conflicting chains. The verification layer solves this through external anchoring.

Periodically, the system computes a Merkle tree root of recent events and publishes it to an external, append-only transparency log. This creates a public commitment that can't be retroactively altered.

Internal Events          Merkle Tree           External Anchor
     │                       │                       │
  ┌──┴──┐                   ┌┴┐                     │
  │ E1  │──────────────────►│ │                     │
  │ E2  │──────────────────►│R│────────────────────►│ Transparency
  │ E3  │──────────────────►│O│                     │ Log
  │ E4  │──────────────────►│O│                     │
  └─────┘                   │T│                     │
                            └─┘                     │

This architecture mirrors Certificate Transparency (RFC 6962), proven at scale across the entire HTTPS ecosystem.

Domain Profiles: One Framework, Many Applications

VAP's scope is deliberately strict: domains where system failures can cause irreversible harm to human life, social infrastructure, or democratic institutions.

Each domain gets a specialized Profile that extends the core framework:

Profile	Domain	Risk Category	Status
VCP	Finance & Trading	Market Stability	v1.1 Released
CAP	Content / Creative	IP Rights, Misinformation	v0.2 Draft
DVP	Automotive	Physical Safety	Planned
MAP	Medical	Patient Safety	Planned
PAP	Public Sector	Democratic Integrity	Planned

VCP: VeritasChain Protocol (Finance)

VCP is the first production-ready VAP profile, targeting algorithmic trading systems. It defines:

Event types: INIT, SIG (signal), ORD (order), EXE (execution), CXL (cancel), etc.
Nanosecond timestamp precision for high-frequency trading
Integration patterns for FIX Protocol and common trading platforms
GDPR-compliant crypto-shredding for data deletion

{
  "vcp_version": "1.1",
  "event_type": "ORD",
  "trading": {
    "symbol": "EURUSD",
    "side": "BUY",
    "order_type": "LIMIT",
    "price": "1.08542",
    "quantity": "100000",
    "time_in_force": "GTC"
  }
}

VCP has been submitted to IETF as draft-kamimura-scitt-vcp, positioning it within the emerging Supply Chain Integrity, Transparency, and Trust (SCITT) architecture.

CAP: Content/Creative AI Profile

CAP addresses the AI content generation accountability crisis—exemplified by recent incidents where platforms claimed to have blocked harmful AI generations but couldn't prove it.

CAP introduces the concept of Negative Proof: the ability to cryptographically demonstrate that specific content was NOT generated, not just that it WAS blocked.

Key event types include:

INGEST: Recording what training data was used
GEN: Capturing generation requests and outputs
BLOCK: Logging content moderation decisions
EXPORT: Tracking where generated content was sent

Regulatory Alignment

VAP isn't designed in a vacuum. It's built to support compliance with emerging AI regulations:

EU AI Act (August 2026)

Article 12 requires high-risk AI systems to have logging capabilities that enable:

Traceability of AI decisions
Identification of risks
Post-market monitoring

VAP's four-layer architecture directly maps to these requirements.

MiFID II/III (RTS 25)

European algorithmic trading regulations require:

Sequenced record-keeping of all orders
Clock synchronization to UTC
5+ year retention

VCP provides cryptographic guarantees exceeding these requirements.

GDPR Compliance

The "right to erasure" seems incompatible with immutable audit trails. VAP solves this through crypto-shredding: personal data is encrypted, and deleting the encryption key renders it mathematically unrecoverable while preserving the hash chain's integrity.

Before Key Destruction:
  Encrypted Data + Key → Decryptable

After Key Destruction:
  Encrypted Data + [KEY DESTROYED] → Mathematically Unrecoverable
  Hash Chain → Still Verifiable ✓

Why Open Standards Matter

We deliberately chose to release VAP as an open specification under CC BY 4.0, not as a commercial product. Here's why:

1. Trust requires transparency

A proprietary audit system is a contradiction. If you can't verify the verifier, you've just moved the trust problem, not solved it.

2. Adoption requires neutrality

Regulators won't mandate a single vendor's solution. Industry won't adopt a competitor's proprietary format. Open standards can become infrastructure.

3. Security requires scrutiny

Cryptographic systems must be publicly analyzed to be trusted. Security through obscurity is security through wishful thinking.

4. Interoperability requires coordination

AI systems don't exist in isolation. A trading algorithm connects to exchanges, brokers, risk systems, and regulators. Each needs to verify the same audit trail.

The Sidecar Pattern: Non-Invasive Integration

One concern we hear: "We can't modify our production trading systems to add logging."

VAP addresses this through the Sidecar Pattern—a parallel process that observes events without modifying the core system:

┌─────────────────────────────────────────────────┐
│            Existing Trading System               │
│                 (Unmodified)                     │
└──────────────────────┬──────────────────────────┘
                       │ Events (read-only)
                       ▼
┌──────────────────────────────────────────────────┐
│              VAP Sidecar Process                  │
│  Event Capture → Chain Builder → Merkle Anchor   │
└──────────────────────────────────────────────────┘

The sidecar:

Receives events via message queue, log files, or API
Builds the hash chain and signatures
Handles Merkle tree construction and external anchoring
Exposes verification APIs for auditors

Zero changes to your core system. Full cryptographic auditability.

Getting Started

Read the Specification

The complete VAP Framework Specification is available at:

📁 github.com/veritaschain/vap-spec

Choose Your Profile

Finance/Trading: VCP Specification
Content/Creative AI: CAP Specification
Other Domains: Open an issue to discuss new profiles

Assess Your Current State

The VAP-AT (AI Auditability Testing) program provides a 10-criterion benchmark for evaluating your system's auditability:

Third-Party Verifiability
Tamper Evidence
Sequence Fixation
Decision Provenance
Responsibility Boundaries
Audit Submission Readiness
Retention & Durability
Timestamp Reliability
Cryptographic Strength
Cryptographic Agility

Each criterion is scored 0-2, giving a maximum score of 20.

Contribute

VAP is developed by the VeritasChain Standards Organization (VSO), a vendor-neutral standards body. We welcome:

Specification improvements: Open a PR with clarifications or corrections
New profile proposals: Use our profile proposal template
Implementation feedback: Share your integration experiences
Regulatory input: Help us align with jurisdiction-specific requirements

What VAP Is NOT

To be clear about scope:

❌ VAP is not a blockchain. It uses cryptographic techniques from blockchain (hash chains, Merkle trees), but doesn't require distributed consensus or cryptocurrency.

❌ VAP is not a SaaS product. It's a specification. Anyone can implement it.

❌ VAP is not a certification authority. VSO publishes standards; we don't certify or endorse specific implementations.

❌ VAP is not a regulation. It's infrastructure that helps comply with regulations.

❌ VAP is not AI safety. It doesn't make AI systems safer—it makes their behavior auditable. These are complementary, not substitutes.

The Road Ahead

IETF Standardization

VCP has been submitted to the IETF SCITT Working Group. Our goal is to position VAP profiles as domain-specific implementations of the broader SCITT transparency architecture.

Post-Quantum Readiness

VAP mandates Crypto Agility—the ability to migrate cryptographic algorithms without breaking existing records. We're already planning the transition path from Ed25519 to post-quantum signatures (DILITHIUM2) as NIST PQC standards mature.

Expanding Profiles

Medical AI (MAP) and Autonomous Vehicles (DVP) profiles are in early planning. If you work in these domains and want to contribute, reach out.

Closing Thoughts

The AI accountability problem isn't going away. As systems become more capable, the stakes only grow. We can wait for the next Flash Crash—or the first autonomous vehicle pile-up, or the first AI-assisted medical catastrophe—and then scramble to figure out what happened.

Or we can build the infrastructure now.

VAP isn't the only possible answer. But it's an answer that's:

Open: Anyone can implement, audit, or improve it
Practical: Sidecar integration works with existing systems
Proven: Built on cryptographic primitives with decades of analysis
Aligned: Designed for emerging regulatory requirements

The aviation industry learned, after too many crashes, that flight recorders save lives. Not by preventing accidents, but by ensuring we learn from them.

AI needs a flight recorder.

VAP is that recorder.

DEV Community