Architecture components
Use this page to identify the component responsible for a workflow or record. For exact services, settings, and versions, check the release runbook and deployed Azure resources.
Customer application
The application starts governed sessions, sends decision facts, uses policy results, stores its workflow state, and records outcomes.
A policy denial does not terminate the process. The application must prevent denied dispatch or release.
VeriProof SDK
The SDK provides language-specific session, policy, review, outcome, and telemetry helpers. Framework adapters vary in what they observe or govern.
The SDK uses the configured central VeriProof endpoint. An entitled application can also route ordinary governance calls through a local Edge Gateway. The central endpoint remains configured for validated handoffs requested by the gateway.
The SDK does not write directly to a customer database or Key Vault.
Ingest and runtime APIs
The APIs authenticate the calling application and validate its requests. Depending on the route, they store accepted records, evaluate configured policy, or return workflow results.
Exact routes and availability depend on the selected release. Use the generated API catalog as a route inventory, then check the endpoint contract for permissions and schemas.
Customer portal services
Customer services own application setup, policy work, reviews, evidence, settings, and role-aware views. Background workers update derived records and assigned work.
Some portal views update after ingest rather than immediately. Compare identifiers and recorded timestamps when a newly accepted record is not yet visible.
MCP server and CLI
The MCP server exposes role-aware customer operations through the same application services used by the portal. The CLI supports deployment discovery, user sign-in, application and key work, session export, diagnostics, and verifier launch.
Portal permissions and scope still apply. Using MCP or the CLI does not grant broader access.
Data stores
PostgreSQL stores customer and operational records. Azure storage supports selected queues and artifacts. Azure SQL Database can also serve as the configured ledger proof provider.
The target deployment determines the exact databases, storage accounts, encryption configuration, backup policy, and retention behavior.
Portals
The customer and staff portals are separate applications with distinct authorization boundaries. The public website and docs site do not share customer data access.
Proof provider
A deployment selects Solana or Azure SQL Ledger.
- Solana produces a public transaction reference.
- Azure SQL Ledger uses ledger tables and protected database digests.
The public verifier checks an exported evidence pack against the selected provider. Verification access depends on that provider; it does not require a VeriProof application key.
Monitoring
Azure Monitor and Application Insights can collect operational telemetry. Logs must exclude credentials, protected evidence, and captured content unless an approved diagnostic process requires it.