What a Signed Receipt Can—and Cannot—Prove
Verify a record outside the dashboard—and understand what its signatures, trust roots, and observations establish.
A dashboard says an AI agent completed an approved cancellation. You download the evidence, verify it on another machine, change a field covered by a signature, and run the same check again. This time verification fails.
That is a useful property. The record can be checked without trusting the dashboard to render it honestly. But what exactly has the check established?
Start with the signed claim
A digital signature binds a key to particular bytes. In a supported Witnora evidence format, verification recomputes the relevant canonical representation, checks signatures, and evaluates the required bindings and trust information.
Changing a signed business field while retaining the old signature should fail verification. Reformatting the surrounding JSON is a different matter: canonicalization exists so that supported representations of the same data produce consistent bytes.
Witnora’s Python verifier implements a strict, versioned canonical JSON profile. It rejects ambiguous inputs such as duplicate keys and unsupported numeric values. It is an independently implemented verifier, not a claim that an independent organization audited Witnora.
The key must be trusted for a reason
Suppose an attacker supplies a fake record, signs it with a new key, and places that key next to the signature. The signature may be mathematically valid. It does not establish that the signer is someone you intended to trust.
Witnora’s v0.2 evidence verification therefore requires a root supplied by the caller. The root fingerprint must be confirmed through a channel separate from the packet being checked. A packet cannot appoint its own trusted authority.
Verification also checks subordinate signing roles, the action and environment bindings, and revocation information. The trust-pinning guide explains the required inputs and historical event-time checks. “Offline” does not mean that key compromise stops mattering: the verifier needs an appropriately current trusted revocation journal before it is disconnected.
A correct signature does not make a claim true
Someone can sign an inaccurate statement. A valid signature alone cannot prove that a human understood the approval, that no other write route existed, or that a payment reached the customer’s bank.
The evidence behind the statement matters. An independently observed result needs a configured source outside the agent’s reporting path. A controlled-execution claim needs evidence of the relevant write boundary. A retained log only establishes what that collection path recorded; it cannot account for activity that was never collected.
For a cancellation, a signed probe observation might establish that the configured order system returned CANCELLED for the specified order at a particular time. It does not establish every downstream consequence. The receipt should preserve that distinction rather than turning several scoped claims into an unlimited “verified” label.
Check the supported packet yourself
The open Python verifier includes the implementation and tests. The design-partner quickstart produces a witnora.verifiable_evidence_packet.v0.2 packet in a local emulator workflow.
After installing the verifier and obtaining that packet, your separately pinned root, and the latest trusted revocation journal, its verification command is:
python -m witnora_verifier.cli evidence packet.json --root pinned-root.json --revocation-journal revocation-journal.json
The filenames above refer to those local inputs. Cloning the repository, downloading dependencies, or obtaining a fresh journal may require a network connection. This verification step reads the prepared files locally and does not contact Witnora or the customer’s target system.
Use a copy for a tamper test. Change a business field covered by the packet’s signature and rerun the same command with the same pinned root. Inspect the failure report and exit code; do not substitute a JSON field that merely says verified: true.
This command is for the specified v0.2 packet. The public refund demo’s sample receipt structure is a different artifact. A result from one schema must not be presented as verification of another.
Useful evidence stays specific
Portable verification gives customers a practical check outside our interface. It helps them detect changes to signed records and inspect the authority and observation claims attached to an operation.
Its value depends on keeping the boundaries visible: which key, which action, which source, which time, and which checks actually passed. A receipt becomes more credible when those answers are available alongside its conclusion.