Verify exported evidence

veriproof-verify checks an evidence pack without calling the VeriProof API. Follow verifier installation and key verification to obtain the tool and a separately trusted evidence-signing public key.

Each tenant selects Solana or Azure SQL Database Ledger when it is created. The verifier reads that provider from the exported integrity record; it does not choose or change the tenant’s provider. Local VeriProof tenants use Solana on devnet.

Verify the archive checksum and supplied build provenance before running it.


veriproof-verify --pack evidence-pack.zip --trusted-evidence-public-key evidence-signing-public.pem

Use --json for automation.

Where to get a pack

Administrators with private-data export access: open the application, then Compliance → Evidence and activity → Records. Use the session row’s Download signed evidence ZIP action to include its committed source revision.
Compliance officers: open Compliance → Evidence → Audit Engagements, select the engagement, and download its audit completion package.
Invited auditors: open the verification guide on the read-only Home page for the assigned engagement.

The evidence package includes proof data, verification instructions, and chronology.pdf, a readable timeline built from the package’s own files. The PDF is in the signed file inventory, so the verifier checks it with everything else and notes when it matches. The package does not include an executable; obtain the verifier separately through the approved delivery path.

Bulk record exports contain session metadata. Their review supplements can verify independently, but omitted session revisions return source_revision_not_included for the overall package.

Solana

The verifier recomputes exported content hashes and the session’s Merkle inclusion path, retrieves the recorded finalized transaction, checks its successful execution metadata, and matches the canonical memo envelope. When the package declares scoped review coverage, the transaction memo must also match the domain-separated supplemental commitment.

Azure SQL Database Ledger


az login
veriproof-verify --pack evidence-pack.zip \
  --trusted-evidence-public-key evidence-signing-public.pem \
  --azure-sql-connection "$VERIPROOF_LEDGER_CONNECTION" \
  --azure-sql-digest-storage "$VERIPROOF_LEDGER_DIGEST_STORAGE"

The verifier uses DefaultAzureCredential, checks the exact session or supplemental anchor row, and asks Azure SQL Database to verify the ledger against protected digest storage. Local PostgreSQL is a development simulation and is never reported as Azure SQL Ledger verification.

For a user-assigned Azure identity, pass its client ID as a UUID. The option applies to both session anchors and scoped review supplements and keeps the existing DefaultAzureCredential flow:


veriproof-verify --pack evidence-pack.zip \
  --trusted-evidence-public-key evidence-signing-public.pem \
  --azure-sql-connection "$VERIPROOF_LEDGER_CONNECTION" \
  --azure-sql-digest-storage "$VERIPROOF_LEDGER_DIGEST_STORAGE" \
  --azure-sql-managed-identity-client-id "$AZURE_CLIENT_ID"

Obtain the trusted digest container URL from your deployment administrator. Do not copy it from an untrusted evidence pack. The verifier checks that an uploaded digest covers the session’s ledger transaction. A missing digest returns a waiting result.

Scoped review records

Packages can declare independent coverage for the selected review records. The signed verification-scope.json names the scoped proof sidecars. Each sidecar is stored at review-records/{application-guid}/anchor-proof.json and binds the tenant, application, selected sessions, recorded-through cutoff, and exact bytes for:

cases.json
continuation-events.json
execution-acknowledgments.json
audit.csv
control-references.json
control-reference-unavailable.json

The verifier recomputes this domain-separated commitment, checks the signed inventory and review-records/export-scope.json, then verifies the matching provider receipt. A valid ZIP signature does not provide an independent anchor for these records. An execution acknowledgment records an acknowledgment; it does not confirm the application’s outcome.

Results

verified means the signature is trusted, exported files match the signed inventory, and required session and declared scoped review provider proofs verify. It does not establish that submitted business facts are true or certify compliance.

Treat mismatch as a failed integrity check. Other results identify missing configuration, an unavailable provider, an invalid pack, or incomplete proof. Use the result status table to decide whether to correct settings, investigate, or wait for a ledger digest.