Model Card: Smart Driver ID (SDID)

Model name: Smart Driver ID (SDID)

Goal: To automatically enroll, identify, and continuously verify MyGeotab drivers from vehicle camera snapshots using facial recognition, so trips and safety events can be assigned to the correct driver without manual tap-in, login, or active driver interaction.

Developed by: Geotab GVP (AI Team + Backend Team)

Primary Intended Uses:

• Passively enroll a driver's biometric template from existing camera snapshots/video-event captures, without requiring active driver participation.
• Identify the driver operating a vehicle for a given trip so MyGeotab can auto-assign or suggest a driver-to-trip/event link.
• Continuously verify in-trip that the assigned driver has not changed, flagging a driver-change event when confidence drops.
• Surface a Verification Reference Image so an authorized MyGeotab user can adjudicate uncertain ("gray zone") matches against the Enrollment Reference Image.

Out-of-scope Uses:

• Replace or override a fleet manager's/human reviewer's decision on ambiguous or contested driver-identity matches — the design calls for human adjudication of uncertain matches, not fully autonomous resolution.
• Serve as the sole basis for punitive or disciplinary action against a driver without human review of the underlying reference images.
• Operate as a general-purpose facial-recognition or surveillance system outside the specific driver-to-trip/event assignment use case.
• Provide a driver-facing authentication mechanism (SDID identifies drivers for fleet-management purposes; it is not a login/access-control system for the driver).

Target Users/User Groups:

• Fleet administrators and supervisors in MyGeotab who manage driver assignments and review/adjudicate uncertain matches.
• The GVP/Smart Driver ID engineering team (Backend Team, AI Team) operating and maintaining the service.
• Indirectly, drivers whose trips and events are assigned via SDID (they do not interact with the system directly).

This section outlines the key aspects of the data used by Smart Driver ID (SDID). SDID has two distinct data lineages: the production service's operational data (driver templates, trip snapshots), and the prototype evaluation data used to select and calibrate the underlying face-recognition model, which comes from a separate, single-author research repository, not from production.

Description on Data and Features

• Trip/Event Snapshot Data: Camera image frames captured from existing GVP video-event and trip-snapshot pipelines (no new/dedicated camera capture is added for SDID) — reused at near-zero incremental cost.
• Face Embedding Data: 512-dimensional floating-point vectors produced by InsightFace buffalo_l from a detected, aligned face crop. Non-reversible by design; cannot be used to reconstruct the source image.
• Enrollment/Verification Template Data: A per-driver collection of quality-weighted anchor embeddings (50; in practice templates hold 17-24 embeddings under the admission gates), plus one retained high-quality Reference Image used only so an authorized MyGeotab user can visually confirm a template-to-driver match.
• Image Quality Assessment (IQA) Data: A quality score per candidate face crop (brightness, contrast, occlusion, resolution, sharpness, head-pose), used to decide whether a crop is good enough to enroll or update a template.
• Prototype Evaluation Data (not production): The public Labeled Faces in the Wild (LFW) benchmark dataset, used only in the prototype repository to compare candidate face-recognition models (InsightFace vs. DeepFace-family: ArcFace, Facenet512, SFace, VGG-Face) and to calibrate the FAR/FRR/EER-derived thresholds later carried into production configuration.

Data Pipeline and Preprocessing

Data Ingestion and Source

Production: trip/event snapshot images already captured by the Geotab Video Platform are consumed by SDID via Google Cloud Pub/Sub (template-mutation and driver-matching subscriptions) — SDID does not ingest raw video directly, only existing GVP-generated frames. Prototype: the LFW dataset is downloaded from a public academic source solely for offline model-selection benchmarking in the prototype repository.

Data Preprocessing for Model Training

• Face Detection and Alignment: RetinaFace (bundled with InsightFace) detects and aligns the face prior to embedding extraction.
• Image Quality Assessment: Each candidate crop is scored for brightness, contrast, occlusion, resolution, sharpness, and head-pose before being considered for enrollment.
• Embedding Extraction: InsightFace buffalo_l (ArcFace) produces a 512-dimensional embedding per accepted crop.
• Template Construction/Mutation: A diversity- and quality-aware algorithm selects which embeddings are kept in a driver's template (up to 50 anchor exemplars, at most 5 added per trip), replacing lower-quality/redundant entries as better crops arrive.
• Prototype-only benchmarking preprocessing: genuine-vs-impostor pair construction, cosine-similarity sweeps, and FAR/FRR/EER computation against LFW — not part of the production request path.

Model Training and Storage

• Both constituent models (InsightFace buffalo_l face embedding, and the custom ResNet + FaceQuality quality-assessment model) are procured/pretrained artifacts; SDID does not train or fine-tune them on Geotab customer data. The quality model's own training-data lineage is not documented in either repository.
• The face-recognition model choice was made via the prototype's LFW benchmark, which found InsightFace buffalo_l to have the best accuracy versus the DeepFace-family alternatives evaluated.
• Production driver templates (the only artifact that is "trained" per-driver, in the sense of being built from data) are stored as encrypted objects in Google Cloud Storage (AES-256 at rest), with a Redis cache layer for low-latency lookups.
• No PII in Model Weights: The InsightFace and quality-assessment model weights are fixed, procured artifacts; they do not encode or make recoverable any individual driver's identity.

Post-processing for Forecast Output

• Progressive Search: Level 1 (vehicle-based, ~90% success, <100ms) -> Level 3 (extended/tenant-wide search) is applied to find the best-matching driver template for a snapshot; the documented Level 2 (location-based) tier is not yet implemented in production.
• Threshold Decision: A cosine-similarity score is compared against the face-match threshold to accept/reject a match, and against a separate confidence threshold to decide whether a new template should be created instead.
• Gray-Zone Flagging: Matches near the decision boundary are intended to be routed for human adjudication (per the design spec); this adjudication UI itself lives outside this repository (in the GVP application layer).
• Event/Driver Assignment Output: Accepted matches produce a driver-to-trip/event assignment, published back onto the Pub/Sub topics for downstream consumption by GVP/MyGeotab.

Data Privacy

SDID runs on the Geotab Video Platform and inherits its Data Controller / Data Processor model: the fleet customer (Controller) decides why data is collected, which events trigger processing and how long source data is kept; Geotab (Processor) operates the service on the Controller's instructions. The SDID-specific stores below are governed by this card and the SDID design document.

• Biometric data processed: 512-dimensional face embeddings (up to 50 anchor exemplars per driver template), one reference face image per template, and operational identifiers (tenant, template UUID, event, vehicle, trip). Templates carry no driver name; the link to the MyGeotab driver record is by UUID. Embeddings are treated as non-reversible but remain personal data of a special category.
• Encryption: template JSON is AES-256 encrypted before upload to Cloud Storage; transport is TLS. Templates are also held in a short-lived in-memory cache (7-day TTL) for low-latency lookups. Further hardening of the cache and of the reference-image storage is tracked as part of the internal security review.
• Deletion on driver / database removal or SDID disablement: templates are withdrawn from matching immediately and moved to a soft-deleted location in storage. Permanent purge is provided by a 30-day storage lifecycle rule that is being implemented by the Backend Team; until it is applied, soft-deleted templates persist. The customer-facing design document (v1.1, Oct 2026) describes this behaviour; the earlier "immediate, permanent deletion" wording was corrected.
• Consent and activation: SDID is off by default. A MyGeotab Administrator must review and acknowledge the Terms and Conditions in the GVP Video Add-In to activate it; activations and deactivations are audited. Drivers are enrolled passively; obtaining any driver-level notice or consent required by local law is the Controller's responsibility. The legal basis per jurisdiction (GDPR Art. 9, US state biometric statutes, Quebec Law 25) is being confirmed with the Privacy and AI governance office. A Privacy review and an AI Impact Threshold Assessment were completed in October 2026 under Geotab's change-management process; SDID is rated HIGH impact (automated identification of individuals using special-category biometric data), which requires a full AI impact assessment and periodic re-evaluation. Security review is conducted under the same process.
• Validation data: a validation set of ~19,000 in-cab face crops from 342 drivers of two customer fleets is held under restricted internal access with a documented custody record and a hard deletion date of 2026-12-31. A proposal to retain a minimised version of the set (face crops and identifiers only, no names) under an annual necessity review -- so the fairness evaluation can be re-run against the same baseline after model or threshold changes, as the HIGH-impact rating requires -- is pending a Privacy decision; the deletion date stands until it is accepted. Identity-level perceived gender / age attributes inferred for the fairness evaluation are kept with that set, never committed, and deleted with it.
• Access: template management and match review are gated by MyGeotab role-based access and Company Groups. Service logs carry identifiers only (no images, embeddings or names), are reachable only through cloud IAM with an approved access entitlement, and are retained for 30 days. Service-level hardening items are tracked in the internal security review.
• Residency: deployed per region (EU and US) with regional storage, topics and GPU clusters; no cross-region transfer in production.

Risks in Training

SDID does not train models on Geotab data: the face-embedding model (InsightFace buffalo_l) and the face-quality model are procured, pretrained artifacts. The risks therefore sit in model selection, threshold calibration and validation rather than in a training run.

• Validation representativeness. The production thresholds were calibrated on a public benchmark (LFW) and then re-measured on an in-cab validation set of 342 drivers from two customer fleets (Oct 2026). The in-cab set covers real camera conditions but two fleets only; see Data Bias Handling for its demographic limits.
• Protocol fidelity. The first system-level evaluation differed from production in three ways (quality gate applied to queries, best-frame templates, detector settings). A production-faithful re-run (2026-10-14) that matches every detected face, builds templates exactly as the service does and uses the production detector settings gave the same result for events with three or more snapshots (FRR 0, FAR 0.0019%) and a one-point higher FRR for single-snapshot events (3.12% vs 2.07%). The optimism is therefore measured and immaterial for the operating case.
• Single-frame events. When an event carries only one usable snapshot, the measured false-reject rate is 3.12% (production-faithful); with three or more snapshots no false reject was observed. The production snapshot count per trip is being confirmed with the Backend Team.
• Threshold provenance. The automatic-assignment threshold (0.5) was set above the FAR = 0.1% calibration points (0.319 LFW, 0.29 in-cab) as a deliberate margin; the system-level sweep now shows it sits where FAR has flattened while multi-frame FRR is still zero. Any change is a material change requiring re-validation before deployment.
• Validation stack. The validation environment (insightface 2.1, torch 2.14) differs from the production pins (insightface < 1.0, torch 2.5); no parity statement exists yet.

Data Bias Handling

Per-group fairness was measured on 2026-10-13 by replaying the production protocol per group of the validation set.

• Attributes and method. Perceived gender and age bucket (18-30 / 31-45 / 46+) were inferred for each identity by the production model's own gender/age head (majority vote / median over all acquired frames); fully automated, no manual labelling. 34% of identities had low per-frame agreement, which is reported as an attribute-noise indicator. Skin tone / race was deliberately not inferred; facial hair and glasses are not available from the model. Attributes are labelled "perceived" because they are a model's inference.
• Criterion. A group's error rate (FRR, FAR, FTA) must not exceed 3x the overall rate for groups of at least 15 identities (NIST-style disparity ratio; to be replaced by the Geotab Bias Detection Standard value once confirmed).
• Result. For the groups that can be judged -- perceived male (297 identities), age 31-45 (193) and age 46+ (112) -- no disparity was observed: FRR 0 in every group, FAR 0.9-1.6x and FTA 0.87-1.24x the overall rate. One observation below the criterion: the quality gate drops frames of the 46+ group 1.38x more often than 31-45 (19.4% vs 14.0%), meaning older drivers more often need an extra snapshot; this is being watched.
• Coverage gap (open risk). The validation set contains 10 perceived-female identities (3%) and 1 identity aged 18-30, so fairness for women and for young drivers cannot be assessed from it. This is a property of the two source fleets, not of the model. Extending the set with at least 30 identities in each of those groups from fleets with a different driver mix is tracked (due Dec 2026). Until then the fairness statement is: no disparity observed for perceived male drivers aged 31+; female and under-30 drivers not yet assessed.
• Human oversight. Matches below the automatic-assignment threshold are routed to a suggestion card for review by a MyGeotab user rather than rejected; above-threshold matches are assigned automatically. Reviewer confirmations and dismissals are not yet aggregated into a fairness or quality metric; doing so is a planned improvement.

Model Assumptions and Constraints

Assumptions:

• Usable face crops are available from the existing GVP snapshot pipeline; SDID does not control camera placement, exposure or capture timing.
• Each identification event carries at least three usable snapshots (the model owner's understanding; being confirmed). With fewer, the measured false-reject rate rises to ~3% and the event falls to human review.
• Driver templates grow over time up to the configured limit of 50 anchor exemplars (at most 5 added per trip; in practice 17-24 are admitted under the quality, impostor and diversity gates); thin templates (few enrolled frames) are the main source of the single-frame rejects seen in validation.
• Production environment-variable overrides of the four matching thresholds are not used, or are re-validated when used (Helm values were not inspected for this card).

Constraints:

• FAR per attempt depends on search scope. The design target is per identification attempt; measured per-comparison FAR is 0.0019%, so vehicle-scoped search (3-10 candidates) is at 0.006-0.019%, within target, while a tenant-wide fallback over more than about 50 templates exceeds 0.1% and needs a higher fallback threshold or suggestion-card routing.
• No per-demographic guarantee for women or drivers under 30 until the validation set is extended.
• Permanent deletion depends on a storage lifecycle rule not yet applied; until then soft-deleted templates persist.
• No CI gate currently blocks a deployment on a model-quality regression; re-validation before threshold changes is a documented manual rule.
• No robustness or presentation-attack evaluation (occlusion, sunglasses, spoofing) has been quantified; partner-camera accuracy is unverified.
• Not a sole basis for action. Automatic assignments feed trip and HOS records; disputed or uncertain identifications are to be resolved by a MyGeotab user, and SDID should not be the sole basis for disciplinary action against a driver.

Figures below are from the in-cab validation set (342 drivers, two customer fleets, 9,826 frames) measured in October 2026 (pair-level and event-level replay, Oct 12-14) and re-validated on Nov 3, 2026 after the exemplar-limit change, at the production threshold of 0.5.

Terminology (ISO/IEC 19795-1). FTA (failure to acquire) counts frames that never reach matching (no face detected, or quality below the enrolment gate) and is reported separately from FRR. Pair-level figures compare one frame to one frame and are used for calibration only. Event-level figures replay the production protocol -- up to 10 snapshots per event compared against a driver template (centroid of the admitted exemplars; the October figures were measured with a limit of 20, the current limit is 50, and the Nov 3 re-validation at 50 showed no measurable change), maximum score vs threshold -- and are the acceptance figures.

Acquisition

• Production FTA: 0.8% of frames (82 of 9,826) have no acceptable face at the production detector settings. A further 12.9% score below the template-admission quality gate; production still matches them as queries (they are only excluded from templates), so they are not acquisition failures. The 16.07% figure in earlier material was the evaluation's own frame filter, not a production property.

Matching accuracy (event-level, production protocol)

Production-faithful replay (no quality gate on queries, templates built the way the service builds them, production detector settings; run 2026-10-14):

An earlier, slightly optimistic replay (queries quality-filtered, best-frame templates) gave FRR 2.07% at one snapshot and the same 0 at three or more; the difference measures the optimism and is immaterial for multi-snapshot events.

• Design targets: FAR <= 0.1% per identification attempt, FRR <= 1%. FRR is met for events with three or more usable snapshots. Single-snapshot events exceed the FRR target and are routed to human review. FAR per attempt is the per-comparison figure times the number of candidate templates searched (about N x 0.0019%): for vehicle-scoped search (3-10 candidates) it is 0.006-0.019%, within target; for the tenant-wide fallback it exceeds 0.1% once more than about 50 templates are searched, so large tenants need either a higher fallback threshold (0.55 keeps FRR at 0 for multi-snapshot events) or suggestion-card routing of fallback results. Actual candidate counts are being measured in production.
• Pair-level diagnostics (single frame vs single frame): EER 0.50% at threshold 0.235; at 0.5, FAR 0 observed and FRR 16.5%. These explain the choice of threshold; they are not the acceptance figures.
• Acceptance table signed by the Computer Vision Team Lead (2026-10-13); acknowledgement by the Backend Team Lead as system owner pending (SDID has no separate product owner).

Fairness (per group, event-level)

• No disparity above the 3x criterion for perceived male, age 31-45 and age 46+ (FAR 0.9-1.6x, FTA 0.87-1.24x, FRR 0 in every group). Female and under-30 drivers are under-represented (3%, <1%) and not assessed; see Data Bias Handling.

Known limits of these figures

• The optimism of the first replay (quality-gate placement, template construction, detector settings) was measured by the production-faithful re-run above: nil for events with three or more snapshots, about one percentage point of FRR for single-snapshot events. The FRR verdict is conditional on at least three snapshots per event (being confirmed with the Backend Team). Events are simulated by sampling frames of the same driver, so real events (one moment, one lighting) are more homogeneous than simulated ones.

Operational metrics

• Service health, readiness and Pub/Sub subscriber status are exposed over HTTP; Prometheus metrics are limited to service info and subscriber counts. No model-quality metric (confidence distribution, override rate) or SLA metric (latency, availability vs the design targets of <= 1 s and 99.999%) is monitored in production yet; instrumenting them is a tracked action.