Teams often ask for “face recognition” when they need a narrower operation. Does an image contain a usable face? Does it match the person who claims an identity? Or who, if anyone, in a registered gallery looks similar? These questions require different inputs and produce different results. Naming the operation first prevents an integration from treating a score or candidate as a final business decision.
Detection: where are the faces?
Face detection takes an image and locates face regions. It can return a face count, bounding boxes and confidence values. It does not say whose face was found. A camera flow might use detection to warn that no face is visible, that several people are in the frame, or that the face is too small for the next step.
In the Attface Core API, detection is presented separately from verification and search. Check image quality as well: a detected face can still be blurred, poorly lit or at a difficult angle. Detection is an input check, not proof that a person is live or authorized.
Verification 1:1: does this face match the claimed identity?
Verification compares a captured face with one reference for a known person. The application supplies the claimed identity or reference, and the result describes how similar the two faces are, often with a matched decision. This is a one-to-one question: “Is the person presenting now the person associated with this account?”
An employee checking in with an assigned profile or a customer completing an identity flow are examples. A comparison result should be interpreted with image quality, liveness and the organization's review policy. It should not silently become an attendance approval or an account approval when the evidence is incomplete. For the division between capture and server decisions, see the SDK and API guide.
Search or identification 1:N: which registered person is closest?
A gallery search compares one query face with a set of registered faces. It returns candidates or ranked matches from that gallery. The question is different from 1:1 verification because the application has not supplied a single claimed identity to compare. A candidate may need a threshold, contextual checks or human review before anyone can treat it as an identified person.
The gallery must also contain the relevant people. “No result” can mean the person was never enrolled, the image was unsuitable, or no candidate passed the chosen criteria. It is not, by itself, evidence of a fraudulent attempt. The Core API documentation describes detection, 1:1 verification and 1:N search as distinct capabilities.
Choose the operation from the decision you need
- Need to know whether a face is present and where it is? Start with detection.
- Already know which account or employee is claiming access? Use a 1:1 verification flow.
- Need to look for a person among registered identities? Use gallery search and define how candidates will be reviewed.
- Need to reject a printed photo or screen replay? Add the appropriate liveness and quality checks; none of the three operations alone covers that risk.
In product discussions, “recognition” can describe the whole family of operations. In an implementation plan, specify the actual input, output and decision owner for each step.
