# Reachability and proofs

Ask a bounded policy question and verify a positive path locally.


Reachability asks whether a directed path connects your persona to a target under the policy you choose. The query is authorized by a device belonging to your source node.

Schematic path: your node and target are public; intermediate nodes and edges are hidden from the verifier, not from the service.

## Choose a policy

| Field | Meaning | Accepted values for new queries |
| --- | --- | --- |
| `scope` | Circuit compatibility scope | `identity` |
| `minTrust` | Minimum score on the path | 0–100 |
| `maxHops` | Maximum path length | 1–3 |
| `currentTime` | Optional future horizon that narrows eligibility | A parseable future timestamp |

Out-of-range values are rejected, not silently clamped. The service controls evaluation time. A requested future horizon can only narrow the result: edges must be active now and at that horizon. A path is non-empty; a query from a node to itself still needs qualifying edges.

## Sign the question you submit

Sign the exact query, including the policy fields you provide. Do not apply defaults after signing or reuse an authorization for another target. Generate a fresh read signature on a retry.

The source and target fields use node IDs despite their legacy names, `sourceGraphKeyId` and `targetGraphKeyId`. Authorization identifies the signing device separately.

Canonical JSON: trust-graph-read-v1, operation, graphKeyId, fresh nonce, signedAt, exact query. Sign with the device P-256 key.

## Verify the attestation

Use the SDK's `/zk` entry with your independently pinned attestation JWKS and `wotPathVerificationKey()`. The verifier checks the issuer signature, expected question, pinned circuit-key hash, correspondence of the circuit inputs, and proof bytes.

Use the verified result rather than the response's unsigned convenience fields. A failed check must remain a verification failure; it is not a negative reachability result.

Private witness: intermediate path nodes and edges. Public: endpoints, policy, time, path length and epoch commitment. Positive: ZK path proof. Negative: signed report.


**Establishes**
A verified positive proves that a qualifying path exists in the cited committed graph. Intermediate node identifiers and edges are hidden from the verifier.


**Does not establish**
The proof does not establish that the service published the complete graph. Endpoints, policy, evaluation time and path length remain public. The service sees the graph and query. A valid proof does not establish that the server committed the complete or latest graph.

## Treat a negative differently

A negative attestation has null proof bytes, circuit inputs and verification-key hash. Its signature can be verified, but it reports the server's answer without a proof of nonexistence. Label it “No path reported under this policy”, rather than “proved unconnected”.

A positive proving failure is an error. There is no signature-only positive fallback.

## Commitments and history

The current-epoch endpoint exposes graph and event-log commitments, including a Poseidon epoch root. A saved event-log size and root are useful continuity inputs. Growth alone does not prove that the old log is an unchanged prefix, and the current-epoch endpoint itself returns unsigned server claims.

Read [what a proof tells you](/concepts/what-a-proof-tells-you) before turning a result into a user-facing badge or an access decision.

Positive answers use the UltraHonk `ultrahonk-wot-path-v2` proof scheme; negative answers remain signed reports.