Planning reference: volumes and infrastructure figures in this document are hypothetical sizing scenarios, not measured product capacity or deployed installations. Validate workload, costs, security and recognition performance before procurement. The current feature overview is available at /features.
Sentinel ID is a working platform today. Reaching 4 billion records and 4 million cameras needs some additional components. They are part of the national-scale delivery (Phase 2), and their capacity is proven by the acceptance benchmark before rollout. This page lists exactly what is which, so architects and auditors can plan with confidence.
Available in the current release
| Capability | Notes |
|---|---|
| Fingerprint enrol, identify, verify, compare | Minutiae-triplet matcher |
| Sharded fingerprint matching | SHARD_ID / SHARD_COUNT matcher nodes; coordinator mode with MATCH_NODES; enrolments pushed to the owning node |
| Native matcher source | C++ matcher (npm run build:native); a slower reference matcher is used when it is not built |
| Finger-position filtering | Pass finger to identify; about 10× fewer comparisons |
| Face enrol, identify (photos, live cameras, video) | 128-number descriptors, searched inside the application |
| Plate recognition and vehicle papers | 65+ countries' formats; partner updates through the API |
| Cameras: push, snapshot and RTSP | Per-camera API keys and locations |
| Sightings, alerts, dispatch, voice, messages | Live in the web app and field app |
| MongoDB or Oracle | Copy data between them from the settings screen |
| Security: roles, approvals, audit chain, misuse detection, device binding, network allow-list | Enabled by default |
Delivered for national scale (Phase 2)
| Component | Why it is needed | How it is proven |
|---|---|---|
| Native matcher build and tuning on the delivered servers | The reference matcher is ~100× slower per core | Comparisons per second per core measured on site |
| Finger-position filter inside the native matcher | A scanner probe should only be compared with that finger's templates (10× less work) | Finger-known search time at the contracted size |
| Fingerprint shortlist index | Avoids comparing every probe with billions of templates | 1:N latency and accuracy at the contracted gallery size |
| Two copies of each matcher shard, with enrolments sent to both | A matcher failure must not slow down or stop searches | Failover test during the benchmark |
| Sharded face vector index (IVF-PQ) | Brute-force face search does not scale to billions | Face 1:N latency and accuracy at size |
| Ingest tier for millions of cameras, with in-memory watch-lists | ~90,000 reads a second on average | 24-hour sustained ingest test at the agreed rate |
| Object-storage adapter for files | Shared file systems do not scale to millions of camera crops | Throughput and recovery tests |
| Shared live-alert bus across application servers | Every control room sees every alert, whichever server it is connected to | Alert delivery test across servers |
Acceptance benchmark
Before national rollout, with the agency watching:
- Load a synthetic gallery at the contracted size (fingerprints and faces).
- Measure 1:N latency: 95% of searches within the agreed time.
- Sustain the agreed searches per second and camera reads per second for 24 hours.
- Measure false-match and miss rates on the agency's own sample data.
- Remove a matcher server, an index server and a database member during load: no loss of service.
Results are recorded in the acceptance report, and the server sizing is adjusted if needed before rollout.