Overview#
A transport hub installs a network of cameras and connects them to a watchlist containing known persons of interest. When a camera detects a face matching an entry on the watchlist with a similarity score above the configured threshold, a match record is created immediately, capturing the timestamp, GPS coordinates of the camera, and the confidence level. A human operator then verifies or dismisses the match before any action is taken. The Face Recognition domain manages both sides: the camera detection records and the watchlists that define who is being searched for.
Human verification is a deliberate design requirement. Automated similarity scoring can produce false positives, and acting on unverified matches creates both operational and legal risks. Every match in the domain carries a verification status, and the audit log records who verified it, when, and under what authorisation reference.
Key Features#
- Face match records with similarity scoring and verification tracking
- Camera-to-watchlist-entry matching with GPS coordinate capture at time of detection
- Watchlist management with classification types and authorisation references
- UPSERT semantics for watchlist create and update operations
- Soft deletes for watchlists: deactivation rather than removal preserves the audit trail
- Audit logging via Operations Log service for all mutations
- Row-level access control filtering for organisation-scoped data
- Paginated face match queries ordered by detection time
Use Cases#
- Matching live camera detections against suspect watchlists with similarity scoring and human verification before action is taken
- Managing authorised watchlists for different operational purposes: suspects, missing persons, and protected persons (VIPs)
- Verifying automated face matches through human confirmation workflows to maintain accountability and reduce false positive actions
- Auditing all watchlist operations and match decisions to satisfy legal and oversight requirements
Industry Context#
National law enforcement agencies deploy facial recognition at border crossings and major transport hubs to detect persons on immigration or criminal watchlists. City police services use camera networks linked to missing persons lists to locate vulnerable individuals. Stadium security teams maintain VIP protection watchlists to detect persons subject to attendance banning orders. Intelligence agencies maintain classified watchlists requiring higher clearance levels to access match records, enforced through row-level security.
Integration#
The Face Recognition domain integrates with Operations Log for audit trails and uses shared access control utilities for row-level security enforcement. All match and watchlist records are stored in PostgreSQL with organisation-scoped isolation.
Open Standards#
- EU AI Act (Regulation (EU) 2024/1689): The service layer explicitly enforces Articles 5(1)(e) and 5(1)(h), prohibiting real-time remote biometric identification in publicly accessible spaces by default and requiring a judicial or independent administrative authorisation reference before any override is permitted; the system is classified as HIGH-RISK under Annex III, and every face match query is audit-logged in compliance with Article 12.
- GDPR (Regulation (EU) 2016/679): Face images and similarity scores constitute biometric data and are treated as a special category under Article 9; the platform-wide Data Subject Access Request (DSAR) domain (Article 15) applies to all face match and watchlist records, and organisation-scoped row-level isolation enforces the data minimisation and purpose limitation principles.
- GraphQL (June 2018 specification): All queries and mutations for face matches and watchlist management are exposed exclusively through a typed GraphQL schema, with field-level permission classes enforcing authentication and ontology access checks on every resolver.
- WGS 84 (EPSG:4326): Camera detection coordinates are stored as WGS 84 decimal-degree latitude and longitude pairs at the moment of each match, enabling interoperability with any mapping or geospatial system that uses the standard geodetic datum.
- OAuth 2.0 (RFC 6749) / JSON Web Tokens (RFC 7519): All API access is gated by RS256-signed JWTs issued through the platform's OpenID Connect infrastructure; the GraphQL permission layer validates the token on every request and extracts the organisation identity used for row-level filtering.
- JSON (RFC 8259): Match records, watchlist payloads, audit metadata, and all GraphQL request and response bodies are serialised as JSON, providing a language-neutral interchange format for downstream consumers and audit systems.
Last Reviewed: 2026-02-24 Last Updated: 2026-04-14