System-of-record verification for AI agents.
Trust the system the business trusts, not the agent's own report. Pruvz verifies each high-impact agent action by independently reading the systems of record where the outcome actually lives, read-only, and it never lets an agent's claim decide a verification result.
Every organization already has an answer to "where would we look if this were disputed": the billing platform for a refund, the CRM for an account change, the claims system for a claim decision. System-of-record verification takes that existing source of truth and makes it the grader of the agent's work, instead of accepting the agent's logs as the record. It is the structural answer to the question every buyer in this category should ask: who grades the work, and do they have a stake in the grade?
Which system counts as the record.
The test is simple: if the outcome were disputed, which system's answer would prevail? That is the system verification must read.
Refunds and billing changes
The billing or payment platform. If a dispute reaches finance, this is the system whose answer prevails, so it is the system verification must read.
Account and subscription changes
The CRM. The agent's confirmation message is not the record; the customer's account state is.
Claims, tickets, and approvals
The claims platform, the ticketing system, the approval workflow: systems of record such as these are where the outcome legally and operationally lives.
Never the agent's own database
Logs, caches, and agent state record what the agent believes it did. A record the agent writes cannot verify the agent's work.
Independence, enforced by the data model.
In Pruvz, independence is not a policy statement; it is how the evidence is built. Every observation carries a server-assigned trust level based on its source: what an agent or external caller reports is recorded as a claim, and what the verification worker reads directly from a system of record is independent evidence. External callers cannot create independent or derived evidence at all, and only the verification worker assigns final verification results. So a claim can never masquerade as proof, no matter who submits it, and every entry lands on an ordered, append-only trail where later facts are appended after the original ones, never over them.
The trust-level taxonomy, shown in a real packetSeparation you can hand to a security review.
The agent executes with its credentials; verification reads with different ones, read-only, in the production deployment model. The verification worker runs off the agent's critical path, reads the systems of record inside a defined window with retries, and classifies each action into exactly one terminal business fact. The security and data architecture page documents the trust boundaries, the verification lifecycle, and what happens to results when a source system changes after finality. The packet schema and validator are public, so the record format itself is inspectable.
Common questions.
Why can't the agent's logs serve as verification?
Because they are the agent's own account of its work. Logs, traces, and tool-call results record what the agent attempted and what an API answered at that moment, and every one of them is written from the agent's side of the boundary. Verification requires a source the agent cannot influence: the system the business itself treats as the record of the outcome, read independently after the action. That is the difference between an audit trail that reconstructs what the agent did and evidence that proves what actually happened.
Does Pruvz write to my systems of record?
No. Verification read-back is read-only by construction: the verification worker holds credentials that can query the systems of record but cannot modify them, and in the production deployment model the execution and verification credentials are separate. A verification retry repeats the read, never the business action. Pruvz records and verifies; it does not execute, correct, approve, or block anything in your systems.
What if the system of record is temporarily unreachable?
The action stays verification-pending. Pruvz reads inside a defined verification window with retries and backoff, and an unreadable source is recorded as unreadable rather than treated as a failed business outcome. If retries are exhausted, the action is classified as verification failed, a technical outcome that is explicitly distinct from an outcome mismatch, and it is surfaced for attention rather than silently dropped.
Which systems of record does Pruvz read today?
In the current product demo, the verification worker independently reads a billing system and a CRM system, and the demo shows the full read-back live. Production connectors to live systems of record, such as Stripe and HubSpot, will be selected and developed with the founding design partners; the verification engine and evidence model are designed for systems of record such as CRM, billing, ERP, and ticketing.
Watch the read-back happen.
The recorded demo shows the verification worker reading the billing and CRM systems of record after a live agent acts: one run confirms the outcome, one catches an agent report the records do not support. The founding design-partner program is open for 3-5 teams that want this verification running against their own systems of record.