> ## 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.

# Humanness and uniqueness

> How we prove someone is a live human, then prove they're the only one.

Every verification answers two questions in order: **is this a live human?** and **is this human new here?** The first is the humanness check; the second is the uniqueness check. A person has to pass both.

## Humanness

Humanness is a short, guided **face check** using the device camera. The person centers their face in an oval, holds steady for a few seconds, and a brief sequence of colors plays. That is the whole thing: about ten seconds, no documents, no license or passport uploads.

The capture is scored for confidence that a real, present person is in front of the camera, not a photo, a video replay, a mask, or a generated face. Below the threshold, the verification doesn't pass.

The capture itself doesn't stick around as a picture. It becomes a **face code**, a numeric representation used for the uniqueness check below. That's the promise the flow makes on its consent screen: your selfie becomes a code, not a photo.

### Any device, including desktop

The flow runs wherever the person is:

* **On a phone**, the face check runs right there.
* **On a desktop with a webcam**, the flow runs in place too. No phone required.
* **On a desktop, continuing on a phone** is one click away: the page shows a QR code, the person scans it, and the same session continues in their phone's browser. The desktop follows along over a realtime channel, so the moment the phone finishes, the desktop returns to your site on its own. Nobody copies codes or refreshes.

## Uniqueness

Once we know the person is live, we check that they're new. The face code from the capture is searched against the faces of people who have already verified.

A match to **this same person's own record** is recognition, not a problem. That's how returning users get through quickly and how a [member](/v3/concepts/members-vs-guests) is recognized on a new device.

A match to **someone else's record** is a **collision**: the same face already verified under a different person. What happens next is up to two settings on your verification:

| Setting              | Options                | What it means                                                                                                                                                                     |
| -------------------- | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Check group**      | `company` or `network` | Who the face is compared against. Company scope only checks people verified through your own verifications. Network scope checks everyone who has verified anywhere on VerifyYou. |
| **Collision action** | `block` or `flag`      | What a finding does. Block denies the verification outright. Flag lets it pass as `flagged` so you can review it, and the finding shows up in the confirmation's `reasons`.       |

One more face rule applies to signed-in members: if someone signs in with their identity and the new capture doesn't match the face on their record, that's a **self mismatch** and it's reported the same way.

This combination is what lets you say "one real human, once": no duplicates, no second submission from the same face, scoped as tightly or as widely as your product needs.

## What you get back

A confirmation reports `verified: true` only when the person cleared **both** checks. The confirmation also carries a `status` (`approved`, `flagged`, or `denied`) and the `reasons` behind it, such as `collision`. You confirm that result on your backend; see [Confirmations](/v3/api/confirmations).