# What a proof tells you

Use precise labels for signatures, membership, positive proofs, and negative reports.


A successful cryptographic check answers a particular question. Keep that question visible in your application's decisions and labels.

## A positive reachability proof


**Establishes**
The verified answer contains a path satisfying the checked policy between the checked endpoints in the cited graph commitment. The verifier does not learn intermediate node identifiers or edges.

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](/security) for verification responsibilities and [calls](/build/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.