One refund, verified end to end. Inspect the captured packet.
This page publishes a real Public Evidence Packet exported from the Pruvz product demo: a refund an AI agent executed, independently verified in the billing and CRM systems of record, with every step on an ordered evidence trail.
Not a mockup and not a hand-authored scenario: the packet was mechanically composed from the two product API responses captured for one real demo run, with their action and evidence fields unedited. Download it, validate it against the public schema on your own machine, and walk through every field group with the explanation of what it proves.
Download it. Validate it. No account needed.
The packet was captured on August 1, 2026 from a live run of the product demo: the two API responses of one action, composed into the packet format with the public repository's composer and not edited afterwards. The validator runs locally and sends nothing anywhere, and the command pins the v1.0.0 release, so this packet keeps validating as the repository moves on.
git clone https://github.com/dorsharoni10/pruvz-evidence-packet.git cd pruvz-evidence-packet && git checkout v1.0.0 && npm ci npm run validate -- examples/captured/verified-refund.captured.packet.json
Where this packet comes from, and why it is safe to publish
The product demo runs against controlled billing and CRM source systems that generate their own payments, tickets and refunds on every run; the packet identifies them in its source fields as billing-sandbox and crm-sandbox. Every identifier in this file was generated by that environment for this run, so there is no customer data, no secrets and nothing to redact: the action and evidence data are published exactly as captured, which is what makes the file worth inspecting. Internal, operational and sensitive fields are deliberately absent from the public contract itself, not stripped after the fact. How the schema is kept true to the product is documented in the repository's conformance notes.
One detail worth noticing because it is real: executionStartedAtUtc is null even though the action completed. The agent reported completion without ever reporting an execution start, which is a legal transition on the wire. A hand-authored marketing sample would not have thought to include that.
How to read it: three values, kept apart on purpose.
The packet's core design is separation. What Pruvz expected, what the agent claimed, and what the systems of record actually showed are three different statements, held in three different places, so an unverified assertion can never masquerade as an observation.
Expected
REFUND_SUCCEEDED, 49.90 USD
Derived by Pruvz on the server from the decision and the immutable Policy Snapshot. It is never accepted from the agent, so the bar the action is measured against cannot be set by the system being measured.
SERVER-DERIVEDClaimed
REFUND_SUBMITTED at 21:51:59.859Z
The agent's own unverified assertion about its execution. It is recorded as evidence, and it never decides a verification result.
CLAIMEDObserved
1 refund found for the payment, 1 succeeded
What independent system-of-record read-back actually observed, summarized from the latest read-back on the timeline. If no independent observation exists yet, this block is null: reported honestly instead of echoing the claim.
INDEPENDENT_READBACKThe packet, field group by field group.
All displayed values in the excerpts below are verbatim from the published file; omitted sections are explicitly marked with an ellipsis. Every group links to its section of the public schema documentation, and amounts, ids and timestamps are the real values from the captured run.
1 · Action context and identity
Who did what, to what: the agent, the run, the business action (a refund), and the business entity it acted on (a payment). correlationId is the business key everything else correlates to, and crmTicketId is the support ticket the decision context referenced.
Every identifier here was generated by the demo environment for this run. That is what pay_, tick_ and act_ prefixes are: demo-generated ids, not customer references.
Schema reference: identity and business context ↗"actionId": "act_763ecaa1a06d4874999593ff76ed12be",
"agentId": "demo-agent",
"runId": "cefd0d9b-a06c-4468-99b8-03928f190fd5",
"correlationId": "pay_db80dba41dc141d394ea72e50fe2fa02",
"actionType": "refund",
"subject": {
"subjectType": "payment",
"subjectId": "pay_db80dba41dc141d394ea72e50fe2fa02"
},
"crmTicketId": "tick_a31f141bd6d844b9aee12db95a13c8b6"2 · The decision
What the policy evaluation approved: a refund of 49.90 USD. This is the decision amount, deliberately not a verified amount; whether the money actually moved is exactly what the rest of the packet establishes.
Schema reference: identity and business context ↗"decision": {
"decisionType": "REFUND_APPROVED",
"amount": {
"amount": 49.9,
"currency": "USD"
}
}3 · The Policy Snapshot
The complete policy that was in force at the moment of the decision, embedded with the action: the rules, the exact inputs the evaluation saw, and the explainable result of every rule. Immutable here means captured once at decision time and read back from stored state, never re-evaluated on read; if the policy changes tomorrow, this snapshot still shows v2 as it stood when the decision was made.
Immutable does not mean cryptographically sealed. The snapshot's integrity comes from the product's append-only, server-controlled storage; cryptographic sealing is a planned capability, and this page says so plainly in the integrity note below.
- PASSEDpurchase-age Purchase date 2026-07-29T21:51:59.639Z is within 14 days of the evaluation time 2026-08-01T21:52:00.040Z.
- PASSEDrefund-amount Refund amount 49.90 USD is within the policy limit 100.00 USD.
- PASSEDpayment-state Payment state SUCCEEDED is one of the allowed states: SUCCEEDED.
- PASSEDsupport-ticket Ticket status OPEN is one of the allowed statuses: OPEN.
"policySnapshot": {
"policyId": "refund-policy",
"policyVersion": "v2",
"rules": {
"maxPurchaseAgeDays": 14,
"maxRefundAmount": {
"amount": 100,
"currency": "USD"
},
"allowedPaymentStates": [
"SUCCEEDED"
],
"ticket": {
"ticketRequired": true,
"allowedTicketStatuses": [
"OPEN"
]
}
},
"input": {
"purchasedAtUtc": "2026-07-29T21:51:59.639Z",
"evaluatedAtUtc": "2026-08-01T21:52:00.04Z",
"refundAmount": {
"amount": 49.9,
"currency": "USD"
},
"paymentState": "SUCCEEDED",
"ticketStatus": "OPEN"
},
"evaluation": {
"policyPassed": true,
"ruleResults": [ ...four rule results, listed below... ]
}
}4 · The expected outcome
What should be true in the systems of record if the approved decision was executed correctly: exactly one succeeded refund of 49.90 USD. Pruvz derives this on the server from the decision and the Policy Snapshot; it is never accepted as an agent input.
Schema reference: the three value groups ↗"expectedOutcome": {
"outcomeType": "REFUND_SUCCEEDED",
"amount": {
"amount": 49.9,
"currency": "USD"
}
}5 · The agent's claim
CLAIMEDThe agent asserts it submitted the refund. The claim appears twice, on purpose: once on the action record as the agent's stated outcome, and once on the timeline as evidence item 1 with trust level CLAIMED, the lowest trust level in the packet.
A claim is recorded, never trusted as an outcome. Nothing the agent says can move an action to VERIFIED.
Schema reference: the evidence timeline ↗"claim": {
"claimedOutcome": "REFUND_SUBMITTED",
"claimedAtUtc": "2026-08-01T21:51:59.859Z"
}
{
"evidenceId": "evd_b1f7436dcbad40bf981160d1bad2a11f",
"sequence": 1,
"type": "AGENT_CLAIM",
"trustLevel": "CLAIMED",
"source": "demo-agent",
"sourceReference": "re_cefd0d9b-a06c-4468-99b8-03928f190fd5_1",
"occurredAtUtc": "2026-08-01T21:51:59.859Z",
"recordedAtUtc": "2026-08-01T21:52:00.371Z",
"summary": "Agent claimed the refund was submitted."
}6 · The execution receipt
EXECUTION_RECEIPTThe receipt the agent relayed from the billing system it executed against: refund re_..., status SUCCEEDED. A receipt carries more weight than a bare claim, but it still arrives through the agent's hands, so it gets its own trust level, below independent observation.
Schema reference: the evidence timeline ↗{
"evidenceId": "evd_e2a538da8cd443dfbd610ae14303b056",
"sequence": 2,
"type": "EXECUTION_RECEIPT",
"trustLevel": "EXECUTION_RECEIPT",
"source": "billing-sandbox",
"sourceReference": "re_cefd0d9b-a06c-4468-99b8-03928f190fd5_1",
"occurredAtUtc": "2026-08-01T21:51:59.859Z",
"recordedAtUtc": "2026-08-01T21:52:00.474Z",
"summary": "The billing sandbox issued refund re_cefd0d9b-a06c-4468-99b8-03928f190fd5_1 with status SUCCEEDED."
}7 · Independent observations
INDEPENDENT_READBACKPruvz reads both systems of record itself, read-only: the CRM shows the ticket in status REFUNDED, and the billing system shows exactly one refund for the payment, succeeded. These two items are the packet's source truth, and only internal Pruvz paths can create INDEPENDENT_READBACK evidence; no agent or external caller can.
The action record's observed block summarizes the latest read-back so a reviewer can compare expected, claimed and observed side by side without walking the timeline.
Schema reference: the three value groups ↗"observed": {
"source": "billing-sandbox",
"sourceReference": "pay_db80dba41dc141d394ea72e50fe2fa02",
"occurredAtUtc": "2026-08-01T21:52:01.18Z",
"recordedAtUtc": "2026-08-01T21:52:01.26Z",
"summary": "Independent billing read-back found 1 refund(s) for the payment (1 succeeded)."
}
{
"sequence": 3,
"type": "SOURCE_READBACK",
"trustLevel": "INDEPENDENT_READBACK",
"source": "crm-sandbox",
"summary": "Independent CRM read-back observed ticket tick_a31f141bd6d844b9aee12db95a13c8b6 in status REFUNDED."
}
{
"sequence": 4,
"type": "SOURCE_READBACK",
"trustLevel": "INDEPENDENT_READBACK",
"source": "billing-sandbox",
"summary": "Independent billing read-back found 1 refund(s) for the payment (1 succeeded)."
}8 · The derived result
PRUVZ_DERIVEDPruvz's verification Worker compares the independent observations with the server-derived expectation and assigns the terminal result: VERIFIED, because exactly one succeeded refund matches the expected refund. The result is PRUVZ_DERIVED evidence, produced by pruvz-worker: it is Pruvz's conclusion from the source evidence above it, never something the agent supplied.
finalOutcome exists precisely because the status is VERIFIED. On a mismatch or a technical failure the packet records null there: an unproven outcome is never fabricated.
Schema reference: terminal-result fields ↗"executionStatus": "COMPLETED",
"verificationStatus": "VERIFIED",
"finalOutcome": "REFUND_SUCCEEDED",
"verificationFailure": null,
"mismatch": null,
"verificationCompletedAtUtc": "2026-08-01T21:52:01.26Z"
{
"evidenceId": "evd_02eb95ac2ae74a73ae24adfb0537ed26",
"sequence": 5,
"type": "VERIFICATION_RESULT",
"trustLevel": "PRUVZ_DERIVED",
"source": "pruvz-worker",
"sourceReference": "vjob_e531817a11464339a81f5b0fabde22b7",
"occurredAtUtc": "2026-08-01T21:52:01.26Z",
"recordedAtUtc": "2026-08-01T21:52:01.26Z",
"summary": "Verification derived VERIFIED: REFUND_VERIFIED: exactly one succeeded refund matches the expected refund."
}9 · Human review
This action verified cleanly, so reviewState is NOT_REQUIRED: a verified outcome needs no business ruling. When independent read-back contradicts the expectation instead, the action becomes an OUTCOME_MISMATCH and routes to a human reviewer.
The reviewer's ruling is a later attestation, appended to the timeline as a HUMAN_REVIEW_DECISION evidence item. It never rewrites the verification result and never erases the original mismatch evidence: the packet keeps both the mismatch and the decision about it, in order.
Schema reference: review state ↗"reviewState": "NOT_REQUIRED"
The timeline: five items, one order, no gaps.
Inside the product, evidence is append-only and atomically sequenced. In the exported file, sequence positions must be unique, ascending and contiguous from 1: a packet-level consistency rule the public validator enforces on top of JSON Schema validation, so a renumbered or gapped timeline fails. Nothing on this trail is rewritten later; later facts are appended after it.
Agent claimed the refund was submitted.
The billing sandbox issued refund re_cefd0d9b-a06c-4468-99b8-03928f190fd5_1 with status SUCCEEDED.
Independent CRM read-back observed ticket tick_a31f141bd6d844b9aee12db95a13c8b6 in status REFUNDED.
Independent billing read-back found 1 refund(s) for the payment (1 succeeded).
Verification derived VERIFIED: REFUND_VERIFIED: exactly one succeeded refund matches the expected refund.
The sequence behind it, on the packet's own clock.
From agent execution through Pruvz verification: the same architecture the security page documents, walked through with this packet's real timestamps. One reading note: the order below follows the server-recorded evidence sequence. For agent claims, occurredAtUtc is agent-asserted and may precede server capture (here the claim's 21:51:59.859Z precedes the action's 21:52:00.04Z); recordedAtUtc is the authoritative audit ordering.
Action captured, policy snapshotted
At 21:52:00.04Z the action is recorded with the immutable decision-time Policy Snapshot embedded, and Pruvz derives the expected outcome (one succeeded refund of 49.90 USD) on the server from that snapshot. The expectation is never accepted from the agent.
The agent executes and claims
The agent executes the refund against the demo's controlled billing source system and submits its claim (agent-asserted at 21:51:59.859Z) with the receipt it relayed. Both are appended as ordered evidence, recorded at 21:52:00.371Z and 21:52:00.474Z, at their own trust levels.
Execution completes, a verification job opens
The agent reports completion at 21:52:00.493Z. Completing execution opens the action's verification job, off the agent's critical path, so verification never blocks the workflow. One job per action is a guarantee of the running product, documented on the security page; what the packet itself shows is the job this run got, the vjob_... reference on the result evidence.
Independent read-back, both systems
Inside the verification window, Pruvz's Worker reads the systems of record itself: the CRM ticket is observed in status REFUNDED at 21:52:01.178Z, and the billing read-back finds exactly one succeeded refund at 21:52:01.18Z. Read-only access; no external caller can produce this evidence.
The result is derived and recorded
At 21:52:01.26Z the Worker classifies the terminal observation: VERIFIED, with finalOutcome REFUND_SUCCEEDED. Recording exactly one terminal business fact per action is an invariant of the running product; in this packet, that fact is the single VERIFICATION_RESULT item that closes the timeline, with review NOT_REQUIRED.
What this packet guarantees, and what it does not
Inside the running product, evidence integrity rests on ordered, append-only, atomically sequenced storage with server-assigned trust levels: recorded evidence is never rewritten, and only internal Pruvz paths can create independent or derived evidence. Those are present-tense facts of the current product demonstration, and they are the honest strong claim.
Successful validation proves conformance to the published packet format, and nothing more. It does not prove the file was produced by Pruvz, that the recorded observations match any real system, or that the file was not modified after export. Packet format v1.0.0 deliberately contains no content hashes, signed manifests, hash chaining or external anchoring, because the current product demonstration does not implement them; this page will not claim otherwise.
On the roadmap: cryptographic sealing and external anchoring, so that exported packets are designed to become tamper-evident artifacts in their own right. Until that ships, the guarantee boundary above is the truthful one, stated the same way in the public repository and on the security page.
Curious what the unhappy paths look like? The repository publishes authored examples of every verification state, including an outcome mismatch with its recorded human review decision appended as evidence item 7, after the mismatch it rules on.
See the flow this packet came from
The product demo runs this verification flow end to end, including the paths this packet does not show: a caught mismatch with a human review decision, a delayed outcome, and an unreadable source system. The security architecture page documents the trust boundaries behind it, and the public schema and validator let you hold Pruvz to this contract offline.