Concrete scenario
What this looks like in practice
A procurement officer sees Verified on a vendor dashboard. Offline, the same receipt only satisfies schema checks. Another receipt shows Valid offline but lacks inclusion proof for the on-log claim the UI implies. The officer needs precise states, not badge inflation.
Problem
What breaks today
A single checkmark hides which obligations were met. Teams need to distinguish structured claims, schema conformance, policy binding, offline validity, on-log recognition, and hybrid crypto assurance without collapsing them into one marketing label.
Mechanism
How ZK-SNAP responds
Depth-of-Trust profiles stack additive conditions over the receipt kernel: structured claim, schema-checked fields, constrained profiles, policy-bound context, offline-valid (DoT-4), recognized on-log (DoT-5), and hybrid crypto where declared. Each layer is evaluated independently so audit language stays precise.
Verifiable outcome
What a verifier can check
- Each declared profile is evaluated independently against its published rules.
- DoT-4 offline validity completes without network calls when profiles allow.
- DoT-5 requires inclusion and anchor evidence — it is not inferred from UI copy.
- Hybrid crypto profiles are evaluated only when explicitly declared and supported.
Scope boundary
What a receipt does not replace
Depth-of-Trust labels describe verified conditions on a receipt — not organizational trust, legal certification, or 3DVC operator certification unless separate program marks apply.
Spec authority
Public-safe sources for this topic
- Protocol Frame master spec — Base receipt validity is offline-verifiable; network-dependent signals such as recognized on-log status are additive.
- Sigils specification — Sigils are deterministic verifier outcomes; Verified is reserved for recognized on-log receipts.