> ## Documentation Index > Fetch the complete documentation index at: https://docs.verifyyou.com/llms.txt > Use this file to discover all available pages before exploring further. # Identity and recognition > Everyone starts as a device. A bound identity gives a person a durable claim to their own uniqueness. Every person who enters the flow starts anonymous: recognized by a **device ID** stored in their browser, nothing else. When a verified email or phone is bound to them, they gain something stronger: a durable **claim to their own face record**, the thing their uniqueness hangs on. An anonymous person has a face record too, but nothing ties them back to it beyond the browser they used. ## Anonymous: a face record with no claim on it An anonymous person verifies without giving any identity. We recognize them by the device ID: no phone, no email, no name. That is the right shape for one-off anonymous flows, but the recognition is only as durable as the browser it lives in: * **Clear the browser, switch devices, or open a private window**, and the person looks brand new. Their face record is still there, but they have no way to claim it, so a fresh attempt can **collide with their own earlier verification** and come back denied. * **Anonymous records do not live forever.** Stale entries are cleaned up over time, which frees people who got stuck, at the cost that anonymous people re-verify more often. An anonymous person who loses their device ID can be blocked by their own prior verification until that record clears. If your people come back, bind an identity. ## Bound identity: a claim they can assert anywhere A **bound identity** is a verified phone or email tied to the person's face record, optionally linked to your own record via an [external id](/v3/advanced/account-linking). Ownership is always proven with a one-time code during the flow; there is no way to skip it. The identity is the claim. When that person shows up on a new device, their face is recognized as one that carries a claim, and instead of a dead-end collision the flow asks them to sign in with their number or email. One code later the claim is re-asserted, the new device is linked, and they are through. New browser, cleared cookies, a year later: same human, same uniqueness, no starting over. ## Identity in the flow The email or phone plays several roles, all controlled by the verification's identity configuration in the dashboard: * **How it is collected.** `anonymous` skips identity entirely. `collection` has the person enter their own email or phone in the flow. `provided` means your server supplies it at [initialize](/v3/dev/spec/server-api/initialize), and the person cannot swap it for a different one. * **Whether you receive it.** Identity **sharing** controls whether the verified email or phone is returned on the [confirmation](/v3/dev/spec/server-api/confirmations). Off by default: we prove ownership without exposing the value. * **Whether it is exclusive.** Identity **lock** holds each face to one identity within your company. The same face coming back with a different email or phone is reported as an `identity_mismatch`. ## Which to use Returning people, anything you will re-verify, or when you already know them (link phone or email plus an external id). A durable claim to their uniqueness, minimal repeat friction. One-off, no-login flows, such as a single collection form or a one-time gate, where you hold no identity and do not need the person to come back. This is a product decision more than a code one: the same hosted flow handles both. You steer toward a bound identity with the identity mode on your verification, or by binding a phone, email, or external id at [initialize](/v3/dev/spec/server-api/initialize). With nothing bound and identity optional, the person continues anonymous.