In our synthetic Chicago replay, a facial-recognition alert scored 0.83 and the correct route was BLOCK. The capture had no consent on file, the evidence remained ambiguous after calibration, and the gallery photo was 15 years old.
That is the decision gap facial-recognition governance has to close. A vendor can return a score, but the organization still has to determine whether the scan was lawful, whether the evidence is sufficient, and what a trained reviewer is allowed to do next. We built FaceTrust to make that gap visible. The full walkthrough is at https://veriprajna.com/demos/biometric-facial-recognition-compliance.
FaceTrust demonstrates the Biometric Decision Firewall. It sits between a facial-recognition vendor and the decision workflow, then turns each alert into one of four governed routes: BLOCK, SUPPRESS, ESCALATE, or CONFIRM. CONFIRM still means routing the case to a trained reviewer. It never authorizes an automatic confrontation, detention, or accusation.
The workflow guide calls the operating flow a live review while stating that this demonstration uses a seeded session to keep outcomes reproducible. Every alert is part of a fixed synthetic replay. No camera, VMS, facial-recognition vendor, or customer-data connection is live.
The workflow guide makes the seeded, reproducible session explicit before any synthetic alert is reviewed.
A score becomes a decision only after governance
The LP-0834 scenario is synthetic by design. It replays a Chicago alert from FaceFirst with an 80 px low-light probe and a 15-year-old booking photo. The raw vendor score is 0.83. FaceTrust calibrates it to a 0.50 match probability, with an interval of [0.217, 0.783] and a 93% conformal prediction set containing both {mate, no_mate}.
That set matters operationally because it refuses to collapse uncertainty into a confident label. Both outcomes remain plausible. Enrollment age is recorded for the reviewer and the audit record, but it does not independently set the route. The deterministic policy gate checks jurisdiction, consent, the sub-72-pixel capture floor, and the calibrated prediction-set outcome.
BLOCK stops an unlawful or no-consent scan. SUPPRESS removes evidence that rules out a match or fails the capture floor. ESCALATE sends an uncertain case to trained review. CONFIRM routes a credible match to a trained reviewer to action.
The Decision Guide keeps all four deterministic routes distinct, including trained review before action for ESCALATE and reviewer routing for CONFIRM.
For LP-0834, the decisive fact is that no consent is on file. Under the demo's seeded BIPA rule, FaceTrust assigns BLOCK before the alert can become an operational action. The ambiguous prediction set also remains visible to the reviewer instead of being hidden behind the 0.83 score.
The 0.83 score enters the evidence packet. Consent state, capture quality, and the 93% prediction set determine which routes remain available.
Calibration has to survive inspection
Calibration is useful only if a team can examine how it behaves across the people and capture conditions the system will encounter. FaceTrust uses a local group- and capture-quality-conditional calibrator to produce a calibrated match probability, an interval, and a 93% conformal prediction set.
On the demo's deterministic synthetic 3,000-alert held-out test set, the conformal sets achieved minimum empirical coverage of 91.5% across the six evaluated Fitzpatrick groups. The raw-score baseline's minimum was 40.6%. These are synthetic test results, not customer, production, or open-world outcomes. Production calibration would need a client's adjudicated history.
The assurance view rounds the group bars to whole percentages; the held-out results are 91.5% minimum coverage for the firewall and 40.6% for the raw baseline.
A raw threshold tests only whether the vendor score is at least 0.70. FaceTrust evaluates jurisdiction, consent, capture quality, and the prediction set in sequence before assigning a route.
The record should exist before the dispute
The decision path does not end with a route label. Every FaceTrust decision creates a SHA-256 hash-chained audit record that can be exported as a printable HTML audit exhibit. The Compliance Reviewer can draft a readable memo from the structured facts, but it does not control the route. Deterministic code has already done that work.
The completed historical evaluation view retains the assigned route, decision latency, and an evidence link for each of the 364 recorded decisions in the fixed synthetic replay. That receipt lets a reviewer move from the aggregate replay result back to the evidence behind an individual route.
The completed replay receipt shows 364 of 364 cases processed, with 303 raw-workflow confrontations, 179 policy blocks, and 121 human-review routes.
The hash chain fixes the structured inputs and route before the memo is drafted, so the memo cannot alter the outcome.
What this demonstration establishes
The demo uses a fixed synthetic alert stream, a seeded store footprint, stubbed vendor adapters, and seeded statute and consent tables. It has no live camera, VMS, vendor, NIST, or customer-data connection. It is not a legal opinion or a guarantee of compliance.
Within that scope, it demonstrates an operational contract around existing recognition output. The contract accepts vendor evidence, exposes calibrated uncertainty, evaluates jurisdiction, consent, capture quality, and the prediction set, sends ambiguous cases to trained review, and leaves a hash-chained record for every route.
For compliance, privacy, loss-prevention, and security architecture teams, that contract creates a more useful design review than a debate about whether 0.83 is a high score. The review can focus on who owns the consent state, how jurisdiction rules are maintained, which evidence permits each route, and what record must exist before a person acts.
The complete FaceTrust breakdown is at https://veriprajna.com/demos/biometric-facial-recognition-compliance. If several teams share ownership of biometric decisions, put one synthetic high-score alert on the table and assign an owner to each control before discussing model performance.