Verify exported evidence

veriproof-verify checks an evidence-pack ZIP without calling a VeriProof API. It checks the signed file inventory, exported content, and recorded provider proof.

The supported providers are solana and azure_sql_ledger.

Before you start

You need:

an evidence-pack ZIP exported from the authorized VeriProof workflow;
the approved verifier archive for your operating system;
the supplied checksum and build provenance for that archive;
a separately trusted evidence-signing public key; and
provider access when the selected provider requires it.

Evidence packs do not contain executable files.

Run verification

Install the verifier

veriproof-verify is distributed as a standalone archive for Windows, Linux, and macOS. It runs entirely offline against an exported evidence pack and needs no VeriProof account.

If your agreement includes repository access, build the verifier from tools/Veriproof.VerifyCli.

Verify the archive checksum and build provenance before running it.

Obtain the evidence-signing public key from your deployment operator through a trusted channel. Use an ECDSA P-256 public key in PEM format.

Do not trust a key solely because it appears inside the evidence ZIP. The verifier does not need an application API key.

Check the evidence pack


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

Use JSON output for automation:


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

Supply provider access when required

Azure SQL 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"

Obtain the connection settings and trusted digest container URL from your deployment administrator, not from an untrusted evidence pack.

Record the result

Keep the verifier version, non-secret command inputs, time, status, and output with the audit workpapers. Do not record connection secrets or replace a failed result with the portal state.

Result statuses

Status	Exit code	Meaning
`verified`	0	The signature is trusted, exported files match the signed inventory, and required provider proofs verify
`mismatch`	1	At least one exported value does not match the expected integrity proof
`invalid_pack`	2	The package structure or required content is invalid
`unsupported_provider`	2	The verifier does not support the provider named by the pack
`configuration_required`	3	Provider access or required configuration is missing
`provider_unavailable`	4	The verifier could not reach or query the provider
`not_anchored`	5	The pack has no completed external proof for at least one required session
`verification_pending`	6	The transaction is waiting for a ledger block or a protected digest covering that block

verified is an integrity result. It does not determine regulatory scope, validate the truth of submitted business facts, or certify the customer system.

Troubleshooting

For configuration_required, confirm the trusted public key, provider settings, and caller permissions.
For provider_unavailable, keep the pack unchanged and retry through an approved provider endpoint.
For mismatch, stop the review and preserve the pack, verifier output, and surrounding chain-of-custody evidence.
For not_anchored, investigate the recorded submission and reconciliation state before repeating the export.
For verification_pending, check digest publication with the deployment administrator, then retry. Do not report a pending result as verified.