Skip to content

Biometrics Glossary

This glossary explains the key terms used in UFME’s documentation, ordered from foundational concepts to system-specific terms. No prior biometrics knowledge is assumed.


The database of enrolled face templates. When you enrol a person, their face template is added to the gallery. When you search, the probe is compared against every template in the gallery.

The input face image submitted for a search or verification request. The probe is processed through the pipeline to produce a template, which is then compared against the gallery.

A compact numerical representation of a face. UFME converts a face photo into a 512-dimensional vector of floating-point numbers (2,048 bytes). This vector captures the identity-distinguishing features of the face — geometry, texture patterns, spatial relationships — in a form that can be compared mathematically. Raw imagery is never stored; only the template is kept.

Synonym for template. The term comes from machine learning: the neural network “embeds” the high-dimensional image (millions of pixels) into a lower-dimensional space (512 numbers) where similar faces are close together and different faces are far apart.

A measure of how similar two templates are. It computes the cosine of the angle between two vectors: 1.0 means identical direction (same person), 0.0 means perpendicular (completely unrelated), and -1.0 means opposite. In practice, genuine matches score 0.4—0.9 and impostors score below 0.3. UFME uses L2-normalised templates, so cosine similarity is equivalent to the inner product.

A decision boundary. If the similarity score between a probe and a gallery template exceeds the threshold, the system reports a match. Higher thresholds reduce false matches but may miss genuine matches taken under different conditions (lighting, age, pose).


The proportion of genuine match attempts that the system correctly accepts. Also called “recall” or “sensitivity”. A TAR of 99.6% means 4 in 1,000 genuine pairs are incorrectly rejected.

The proportion of impostor attempts that the system incorrectly accepts as a match. At a 200-million-entry gallery, even a 0.01% FAR produces ~20,000 false alarms per search. This is why threshold tuning matters enormously at scale.

The complement of TAR: FRR = 1 - TAR. The proportion of genuine pairs incorrectly rejected.

The probability that the true match appears in the top K results of a search. Recall@1 = 97% means 97 out of 100 searches return the correct person as the top result.


A check that the submitted image is a genuine, live face — not a printed photo, screen replay, or 3D mask held in front of the camera. UFME uses MiniFASNetV2, which outputs a spoof score between 0 and 1. Images above the configured threshold are rejected before matching. Compliant with ISO/IEC 30107-3.

A check that the submitted image has not been digitally blended from two people’s faces. Morphed photos are a known threat in document issuance: a passport photo blended from two identities could match both. UFME uses HRNet-W18 trained on the SelfMAD dataset for single-image (no-reference) morphing detection.

A check that the face image meets minimum quality standards before proceeding to template extraction. Low-quality images (blurred, occluded, extreme pose, poor lighting) produce unreliable templates. UFME uses eDifFIQA for ISO/IEC 29794-5 compliant quality scoring. Images below the threshold are rejected with a clear error, not silently degraded.

An optional check for synthetically generated face images (GANs, diffusion models, face swaps). Uses a ViT-based binary classifier. Operates as a configurable pipeline gate.


Facebook AI Similarity Search — an open-source library for efficient nearest-neighbour search on dense vectors. UFME uses FAISS to search the gallery of face templates.

IVF-PQ (Inverted File with Product Quantisation)

Section titled “IVF-PQ (Inverted File with Product Quantisation)”

The index type UFME uses for large galleries. It works in two steps: IVF partitions the vector space into cells (like postal codes) so only a fraction of the gallery is scanned per query. PQ compresses each 2,048-byte template down to 64 bytes, so the entire gallery fits in memory. The combination trades a small amount of accuracy for dramatic speed and memory savings.

The number of IVF cells (partitions) in the index. Rule of thumb: roughly the square root of the gallery size. UFME defaults to 16,384 cells for 200M+ galleries.

The number of IVF cells scanned per query. Higher nprobe improves recall but increases latency. At nprobe=96 with nlist=16,384, about 0.6% of the gallery is scanned per query — enough for 97%+ recall in under 3 ms.

A partition of the FAISS index stored on a separate machine. UFME distributes the gallery across multiple shards (typically 4—6) and queries them in parallel (scatter-gather), then merges the results. This allows the gallery to exceed the memory of a single machine.

The query pattern for multi-shard search: the API sends the query vector to all shards simultaneously (scatter), each shard returns its top candidates, and the API merges and re-ranks them (gather).


Hexagonal architecture (ports and adapters)

Section titled “Hexagonal architecture (ports and adapters)”

A software design pattern where the core business logic has no dependencies on external systems. All I/O (HTTP, databases, file systems, ML inference) is accessed through interfaces called “ports”, with concrete implementations called “adapters”. This means you can swap out FAISS for a different vector store, or ONNX Runtime for a different inference engine, without changing any domain logic.

An interface (Python Protocol) that defines what the core domain needs from the outside world. Examples: DetectionPort (detect faces in an image), VectorSearchPort (search for similar templates), ClockPort (get the current time).

A concrete implementation of a port. Examples: FaissLocalStore implements VectorSearchPort using FAISS; StubDetectionPort implements DetectionPort with synthetic test data.

A step in the biometric processing pipeline. Each stage is a pure async function that takes a dict (the payload) and returns a modified dict. Stages declare what keys they require and produce. The pipeline runner chains them together. Example stages: detect, align, quality, pad, extract, search.

A decision point in the pipeline that can reject a request. Gates are pure functions configured with a threshold. If the quality score is below the quality gate threshold, the request is rejected with an error — it does not proceed to extraction or search.

A logical subdivision of the gallery. Queries can be scoped to one or more partitions. Useful for multi-tenant deployments or separating watchlists from general enrolment databases.