Skip to Content
Getting StartedHow VeriProof Works

How VeriProof Works

This page walks through the complete lifecycle of a compliance record: from the moment your AI application makes a decision, through ingest and governance processing, to a tamper-proof blockchain anchor on Solana.

The data flow in four stages

Your AI app
    │
    │  OTel spans
    ▼
VeriProof SDK  ──── X-API-Key ──▶  Ingest API
                                       │
                                   Validate & classify
                                       │
                                   Governance engine
                                   (alerts, scoring)
                                       │
                              ┌────────┴────────┐
                              │                 │
                        Tenant DB          Merkle batch
                        (PostgreSQL)            │
                                          Solana Anchor
                                          (CMT leaf)

Stage 1 — Instrumentation

Your application produces OpenTelemetry spans as it executes AI workflows. The VeriProof SDK is configured once at startup as the OTel TracerProvider. From that point, any span created by your code — or by a framework adapter — is intercepted.

The SDK enriches spans with governance-specific attributes:

  • veriproof.session.intent — what the AI was asked to do
  • veriproof.decision.type and veriproof.decision.confidence_score
  • veriproof.guardrail.action — whether guardrails passed, blocked, or escalated
  • veriproof.human_oversight.type — recorded evidence of human review events
  • veriproof.grounding.status — whether the response was grounded in retrieved context

Content capture (prompt and response text) is disabled by default and must be explicitly opted into, giving you precise control over what data leaves your environment.

Stage 2 — Ingest

Completed spans are batched and sent to the VeriProof Ingest API at POST /v1/ingest/otlp. Each batch carries a SHA-256 Merkle root computed over all leaf hashes in the batch — a structural checksum the server validates on receipt.

Batch payload
├── span[0]: JSON hash  ─┐
├── span[1]: JSON hash   ├── SHA-256 Merkle root (sent in payload header)
└── span[n]: JSON hash  ─┘

The API authenticates requests using your X-API-Key header. Keys are scoped to a single application and environment (sandbox or production) and are stored encrypted in Azure Key Vault.

Multi-tenant isolation: Your data is stored in a PostgreSQL row-level security (RLS) partition keyed to your Customer ID. The ingest endpoint sets the RLS context on every database connection — cross-tenant reads are structurally impossible, not just access-controlled.

Stage 3 — Governance processing

After a compliance record is stored, the governance engine runs synchronously:

  1. Alert evaluation — Checks the record against your configured alert rules (anomaly thresholds, keyword patterns, risk level triggers). Matching rules generate notifications via email or webhook.
  2. Governance scoring — Computes a session-level governance score from the aggregate of guardrail outcomes, grounding quality, and human oversight ratios. This score feeds the Compliance Center dashboard and trend charts.
  3. Compliance classification — Tags sessions with applicable compliance frameworks (EU AI Act risk tier, NIST AI RMF category) based on the application’s configuration.

Stage 4 — Blockchain anchoring

Compliance records are not individually anchored — that would be prohibitively expensive. Instead, VeriProof uses a batching strategy with Solana’s Concurrent Merkle Trees (CMT):

  1. Records accumulate in a notary outbox as they arrive.
  2. The notary worker reads the outbox on a configurable schedule (default: every 30 seconds in production).
  3. All leaf hashes in the batch are combined into a single Merkle root.
  4. That root is written as a leaf to a Solana CMT on the Solana mainnet .
  5. The resulting transaction signature is stored alongside the original records.

Each CMT tree holds up to 1 million leaves (tree depth 20). A single anchoring transaction costs approximately $0.000035 regardless of how many records it covers — the batch amortizes cost across all records anchored in that round.

                    Solana CMT
                   ┌──────────┐
                   │  Root    │
                   │          │
           ┌───────┴───┐  ┌───┴───────┐
           │  Branch   │  │  Branch   │
           └──┬──┬──┬──┘  └──┬──┬──┬──┘
              ▲  ▲  ▲        ▲  ▲  ▲
           Merkle roots from each anchoring batch

What this means for an audit: To verify that a compliance record has not been altered, an auditor can:

  1. Retrieve the record from VeriProof and recompute its leaf hash.
  2. Obtain the Merkle proof path from the CMT.
  3. Reconstruct the root and compare against the value on-chain.

This verification requires only a Solana RPC endpoint — no dependency on VeriProof’s infrastructure. If VeriProof were unavailable tomorrow, every previously anchored record would still be independently verifiable.

The compliance record structure

Each session in VeriProof maps to one or more traces, which decompose into:

LayerDescription
SessionTop-level unit. One per “transaction” — a loan decision, a support conversation, a triage episode. Has an intent, a risk level, an outcome.
StepsOrdered operations within the session: retrieval, LLM generations, tool calls, agent handoffs. Each step has typed tags.
Governance eventsTyped events overlaid on steps: guardrail triggers, human oversight checkpoints, content safety signals.
Decision contextThe structured record of what was decided, why, with what confidence, and from what options.
Outcome feedback(Optional) Post-hoc linkage of real-world results to the original session. Supports model performance analysis and post-decision audits.

Data residency and privacy

By default, metadata (session IDs, step names, governance attributes) is captured. Content — prompt text and model responses — is not captured unless you explicitly enable it with enable_content_capture: True.

For EU customers, data is stored in Azure’s West Europe region by default. Enterprise Federated deployments can pin storage to a customer-owned Azure tenant in any Azure geography.

Next steps

Last updated on
What is VeriProof?5-Minute Quickstart