Verification library
See each trust boundary in action.
Start with a human-presentation record, then inspect a qualified machine candidate, a successful consequence, a refused replay, and an unresolved outcome. Every file is processed locally in your browser.
Consequence control
What happened after admission?
These signed fixture projections demonstrate three materially different outcomes for the same $7,500 payment-release action.
Settled
Payment release · attempt 1
Admitted, consumed once, and reconciled.
The action is admitted, its single-use authority is consumed, provider-outcome evidence is committed, and the observed effect is consistent.
Boundary: This is a signed offline fixture projection, not proof of a live provider database or production source-system state.
Download settled sample
Refused
Payment release · attempt 2
A duplicate attempt is stopped.
The second attempt binds to the exact prior consumed projection and is refused as already consumed rather than being executed again.
Boundary: The verifier checks supplied lineage; durable global single-use enforcement remains a live-system responsibility.
Download refusal sample
Indeterminate
Payment release · attempt 3
Authority was consumed, but the outcome is unresolved.
The action was admitted and consumed, but provider outcome evidence is missing. The projection preserves uncertainty and prohibits a blind retry.
Boundary: “Unknown” is kept as a real state instead of being silently converted into success, failure, or another attempt.
Download unresolved sample
Important action-binding boundary
These projections intentionally attach the existing SYNC presentation fixture to demonstrate an exact receipt-byte reference. Because that receipt does not carry the typed payment action or CAID, OpenVerifier reports human-to-machine action binding as NOT ASSESSED, not as a match.
How to use the samples
1Download one sample file.
2Return to the verifier and drop the file into the input card.
3Read the verified result and the boundaries that remain unproven.
These are demonstration artifacts, not production authority records. Some raw payloads retain protocol-specific identifiers because OpenVerifier checks exact signed bytes and compatibility profiles; those identifiers are technical metadata, not a public endorsement or partnership claim.