Concrete scenario
What this looks like in practice
A fintech workflow runs inside a SaaS dashboard for three years. Regulators ask for proof of automated credit decisions from 18 months ago. The vendor has sunset the product, the API is gone, and the exported CSV rows have no independent signature. Each row is plausible, but none of them prove what the system actually signed at decision time.
Problem
What breaks today
The record lives inside the system being questioned. When the account closes, retention expires, or the vendor disputes the export, the proof usually stays with the platform — not with the people who need it later.
Mechanism
How ZK-SNAP responds
Verifiable Machine Activity is recorded as a ZK-SNAP receipt at the moment of the accountable event. The receipt carries provenance, an inputs_root commitment to the claim, timestamp, declared profiles, and a signature under the ZKAI-SNAPSHOT domain prefix — material that can leave the dashboard as portable bytes.
Verifiable outcome
What a verifier can check
- Ed25519 signature verifies over the canonical receipt preimage with sig and receipt_id omitted.
- receipt_id recomputes from the signed payload; any post-hoc edit breaks the match.
- inputs_root commits to the structured claim without requiring private fields to be published.
- Declared profiles state which offline-valid (DoT-4) conditions apply to this receipt.
Scope boundary
What a receipt does not replace
Receipts prove what was signed at production time. They do not recreate unsigned platform events, guarantee vendor uptime, or by themselves establish on-log recognition — that requires governed Chain evidence when DoT-5 is in scope.