How VeriProof works
An application sends facts for a policy check, acts on the result, and reports what happened. VeriProof connects that decision with its evidence and any required human review.
Your application remains responsible for calling VeriProof and using the returned result. VeriProof does not control an application that has not integrated these checks.
Follow a governed action
Your application starts a governed session
Use the core SDK for your language. Add a framework adapter only when it matches the operation you need to observe or govern.
The SDK can record OpenTelemetry spans and VeriProof governance attributes. Prompt and response content is not captured unless your application enables content capture.
Your application checks selected actions
For a governed action, your application sends the decision facts to the configured VeriProof endpoint. The policy result can allow, warn, transform, deny, or require review.
A denial does not terminate the application process. Your integration must prevent the denied action or output from continuing.
VeriProof records the submitted evidence
The ingest service authenticates the application, validates the submitted telemetry, and records accepted session data. Background workflows then update the related governance, compliance, alert, and work views.
Dashboard and work-list updates may arrive after the ingest request completes. Check the session status and use the returned identifiers to find the related records.
A reviewer responds when policy requires review
VeriProof routes the review request to an authorized reviewer and records the response. Your application must keep its workflow state in a protected store, verify the callback, and recheck current policy before resuming protected work.
Your application remains responsible for its business process. VeriProof supplies the review record and the supported procedure for continuing after review.
Your application records the outcome
The application reports what happened after the governed action. This connects the policy decision and review history to the business result without claiming that VeriProof produced the result.
The deployment records integrity evidence
Each deployment selects its supported proof provider. Solana records a public proof reference. Azure SQL Ledger uses append-only ledger tables and separately protected database digests.
Proof submission can remain pending or fail. Review the recorded provider, status, timestamps, and verification material before making an integrity claim.
What VeriProof records
| Record | Purpose | Responsibility |
|---|---|---|
| Session and steps | Connect the application workflow, model calls, tools, and handoffs | The application and SDK submit accurate context |
| Policy evaluations | Record the facts checked, policy version, result, and reason | The application uses the result before dispatch or release |
| Human review | Record routing, reviewer response, and continuation state | The application stores workflow state and resumes safely |
| Outcomes | Connect later business results to the governed session | The application reports the outcome |
| Integrity metadata | Identify hashes, provider status, and proof references | Operators monitor submission and retain required exports |
Framework instrumentation does not automatically control every model call, tool side effect, stream, or handoff. Check the adapter capability matrix before relying on an adapter for enforcement.