Architecture overview

Use this overview to agree on where VeriProof runs, which data it receives, and who operates each part. The application remains responsible for its business actions; VeriProof provides policy results, review workflows, and recorded evidence.

The operating model determines ownership of the Azure subscription and its controls. In either model, the SDK calls a VeriProof endpoint rather than writing directly to a database.

Supported operating models

Model	Azure boundary	Operating owner
Managed SaaS	VeriProof-managed Azure environment	VeriProof
Customer-managed Azure	Customer Azure subscription and approved network	Customer, with agreed VeriProof support

The internal deployment setting for Customer-managed Azure can use the value Hybrid. This value does not mean that only hashes leave the customer environment.

Main trust boundaries

The customer application calls the SDK and uses policy results.Application boundary Follow submitted records through authentication, storage, and customer views.Service boundary Identity provider access and VeriProof membership remain separate controls.Identity boundary Solana or Azure SQL Ledger supplies provider-specific integrity evidence.Proof boundary

Architecture decisions

Record the decision and responsible owner for each area:

applications, SDKs, callbacks, agent tools, and administrators in scope;
identity providers, workload identities, roles, and privileged access;
ingress, egress, private connectivity, DNS, certificates, and service dependencies;
captured fields, regions, stores, retention, deletion, backup, restore, and exports;
proof provider, public-data boundary, verifier access, monitoring, and reconciliation; and
deployment, incident, upgrade, vulnerability, and support owners.

Architecture diagrams describe intended boundaries. Validate the deployed resources, identities, routes, data stores, and proof provider before approving an environment.