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.

Human presentation

What was recorded before authorization?

Signed receipt

Contractor review record

A stated intent, one hash-only document, and a hardware-backed signing record.

The sample receipt records the intent “Approve $10M contractor review,” one PDF evidence digest, Secure Enclave signing metadata, policy-context labels, and receipt-chain metadata.

Verifier can checkReceipt integrity, disclosed signing key, evidence manifest, chain metadata
Still separateScreen observation, organizational authority, exact machine action, execution

Machine qualification

Was the measured candidate qualified for this request?

Qualified

Candidate and evaluation evidence

Cryptographic qualification under supplied relying-party policy.

The sample carries a candidate manifest, campaign and test evidence, a qualification statement, a status chain, and a current runtime measurement. OpenVerifier evaluates the bundle against the trust pins and expected request context supplied with the sample.

Verifier can checkSignatures, candidate match, assignment scope, campaign graph, status freshness
Still separateTrust-context provenance, human authorization, admission, execution

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

1

Download one sample file.

2

Return to the verifier and drop the file into the input card.

3

Read 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.