A successful cryptographic check answers a particular question. Keep that question visible in your application's decisions and labels.
A positive reachability proof
The application must independently pin the issuer's attestation keys and the circuit verification key, pass the exact expected question, and verify the proof bytes. A signature alone is insufficient for a positive result.
Does not establish
The proof does not establish that the service published the complete graph. The service knows the graph and path. A proof does not establish completeness or recency of the committed graph, authenticate every original edge signature inside the circuit, establish humanhood, or certify a person's intentions. Endpoints, policy, evaluation time and path length remain public.A negative reachability report
The signature establishes that the configured issuer made the report. There is no zero-knowledge proof that a qualifying path does not exist.
Use “No path reported under this policy”. Reserve “Proof verified” for a successfully verified positive path proof.
A device membership certificate
The issuer attests that a device key belongs to a persona. Current certificate status is a separate signed check, and current device approval is governed by device authority.
Does not establish
Membership does not prove humanhood or your trust in the persona. A lifecycle-valid certificate is not by itself evidence of current device-chain approval.A signed message
The signature binds normalized text to a device key and its membership evidence. It can be checked separately from the channel that delivered the message.
Does not establish
The message does not establish signing time, live presence, ownership of the surrounding email address or phone number, current device access, or permission to execute an action. A copied valid signed message remains signed text.A current-epoch response
A graph root commits to a graph snapshot. The public epoch endpoint returns server claims; retaining a larger event-log size does not prove append-only continuity with an earlier root.
Design labels around evidence
| Evidence available | Suitable wording |
|---|---|
| Locally verified positive reachability attestation | Connected under your policy · proof verified |
| Verified negative attestation | No path reported under this policy · signed report |
| Valid content and membership signatures, status unchecked | Signature and membership verified · status not checked |
| Verification failed | Could not verify this evidence |
Do not turn a failed verification into a “not connected” answer. See security for verification responsibilities and calls for the additional work a live-call experience needs.
Positive answers use the UltraHonk ultrahonk-wot-path-v2 proof scheme; negative answers remain signed reports.