For verifiers

Someone sent you a link like verify.olocus.com/p/<token> or a small CBOR file with a .cbor extension. Both are the same thing: a scoped proof composed by the person you're advising, on their device, addressed to you specifically (or to anyone with the link, depending on the policy).

Opening a link

Open the URL in a browser. The verify bundle is a static page — no account, no install, no plugin. The bytes are fetched from the Olocus relay, decoded in your browser, and rendered on the page. The relay never holds the plaintext.

Opening a CBOR file

Drop the file onto the upload field at verify.olocus.com, or paste the hex into the textarea below it. Same result as opening a link, with the bytes never leaving your machine.

What you see

The verifier matrix renders each field independently. Per the Olocus brand contract there is no single verified badge — the verifier reads the parts and judges. The rows you see:

• Recipe — the question this proof answers (e.g. presence-per-country (v1)).
• Claim support — how the underlying evidence is qualified (self-recorded, device-corroborated, peer-witnessed, multi-witnessed, …).
• Subject binding — which device key signed this proof. Device-bound means the bytes were signed by the same device that wrote the receipts.
• View policy — bearer (anyone with the link can read it) or recipient-bound (encrypted to your X25519 public key; only you can read it).
• Validity — the window in which the proof is intended to hold.
• Sensitive claim — standard or sensitive. The user marked this proof's underlying context as sensitive at compose time.
• Proof nonce — the disclosure-uniqueness token.
• Signature — the Ed25519 signature over the canonical-CBOR proof bytes.
• Disclosed payload — the actual rows the user chose to disclose for this question (countries, date ranges, continuity windows). Nothing else from their record is visible to you.

What you do not see

• The user's underlying graph. You see only the rows the recipe required and the user chose to disclose for this single proof.
• The user's witnesses by name. Where witnesses strengthened the claim, you may see an assurance label (peer-witnessed, multi-witnessed) but never witness identities — that's a deliberate relationship-leakage guard.
• Any aggregated verified indicator. The eight rows above are how you decide whether the proof is sufficient for your purpose.

How to read it

1. Check the recipe matches the question you asked. If you asked about presence and the recipe is continuity, the user composed the wrong proof.
2. Read the claim support. A self-recorded claim is the user's own record, not corroborated by anyone else. A multi-witnessed claim has multiple independent peers attesting. Olocus does not adjudicate strength; you do.
3. Confirm the subject binding. Device-bound is the v1 default — the signing key is held on the user's device. v1.1+ will add stronger subject bindings (e.g. seed-recovery-corroborated).
4. Check the validity window covers the period your question is about.
5. Read the disclosed payload. These are the rows the user chose to show you — the literal answer to your question.

If the proof is missing

If the URL returns "this proof is not available", the relay deliberately does not distinguish between never-existed, revoked, and expired. Ask the user to issue a fresh proof. The single-message absence is a privacy guarantee for the user, not a bug — it prevents you from learning anything about their revocation behaviour.

If you need to retain the proof

Download the CBOR file. The bytes are cryptographically self-contained: the signature can be re-verified offline, and the canonical encoding is designed to round-trip byte-exactly. You can archive the file alongside your client's other evidence; Olocus does not require your verification to be online.

Olocus does not sell certainty. It shows evidence boundaries. A single self-recorded receipt is not the same as a long-running pattern supported by multiple independent witnesses, and Olocus refuses to collapse the two into one indicator. If you are asked to make a judgement on what an Olocus proof means for your professional practice, the parts above are how to read it. You make the call.