There is a quiet assumption inside most enrolment software: that the network is normally there, and offline is what you handle when it drops. Everything follows from it — the sync model, the deduplication flow, the way conflicts are resolved. And in a capital city with fibre to the enrolment centre, the assumption holds.
It does not hold in a district where the nearest reliable connection is a day's drive away, where a mobile team works for three weeks between uploads, and where "the network is up" is the rare event. Design for that place by bolting an offline mode onto an online system and you get a programme that works in the demonstration and breaks in the field — precisely where the hardest-to-reach and most-worth-reaching people are.
Offline-first is a different starting assumption: the device is the source of truth until it can safely hand off, and the network is an optimisation, not a dependency. That single inversion changes four things.
Enrolments are signed where they are captured
If a record might sit on a device for three weeks before it reaches a server, the device cannot be a dumb collector. Each enrolment is signed at the point of capture — bound to the operator, the device and the moment — so that when it finally arrives, its integrity does not rest on the trustworthiness of the sync channel it travelled through.
This is a signed local queue: an append-only, tamper-evident log of enrolments on the device, each entry cryptographically chained to the last. You are not trusting the upload. You are trusting the signature that was applied the instant the person was in front of the operator.
The question offline-first answers is not "what if the network drops?" It is "what do I trust when the network was never there to begin with?"
You cannot deduplicate live, so stop pretending you can
Online systems check for duplicates at the moment of enrolment against the central gallery. A team working offline for weeks cannot. Pretending otherwise — assuming the field can catch duplicates in real time — is how the same person ends up enrolled twice by two teams working two valleys apart.
The honest design issues a provisional identity at capture and resolves uniqueness later, when the record reaches the central ABIS. The provisional credential is useful immediately for local purposes; the biometric deduplication that promotes it to a confirmed national identity happens on sync. The programme has to be explicit that this two-stage model exists, because it changes how downstream services should treat a brand-new record.
Conflict resolution is a policy decision, not a database default
When records finally sync, they will conflict. Two teams enrolled the same person. A record was edited on the device and centrally in the same window. A provisional ID collides with a confirmed one on biometric match. The wrong answer is whatever the database does by default — usually "last write wins," which silently discards real work and can overwrite a correct record with a wrong one. Offline-first forces conflict resolution to be a stated policy.
- Biometric collisions go to human adjudication, not automatic merge — the algorithm surfaces the candidate, a person decides.
- Demographic edits carry provenance, so a later supervisor correction beats an earlier field entry, but the field entry is retained and visible.
- Nothing is destroyed on merge; superseded records are kept, because the audit will ask.
A stolen device is a designed-for event, not a disaster
A device holding weeks of un-synced enrolments will, eventually, be lost or stolen. If that is a crisis, the design was wrong. Offline-first assumes it.
- Data at rest is encrypted with keys held in the device's secure element, so a stolen device is a brick, not a database.
- Device keys can be revoked centrally, so a lost device's future sync is refused and its signing identity is invalidated the moment it is reported.
- The queue is recoverable — captured records are backed up to a second local medium during long deployments, so a lost device is lost hardware, not three weeks of a district's enrolments.
Test it by pulling the plug
The single most useful thing you can do in a pilot is unplug the network and leave it unplugged. Not for a graceful five-minute failover demo — for the duration. Run a full enrolment-to-sync cycle with connectivity genuinely absent for days, then restore it and watch the reconciliation.
Most systems that claim offline support pass the five-minute test and fail the five-day one. The gap between those two is the entire difference between offline-as-fallback and offline-first, and it is invisible on the procurement slide. It is only visible in the field — which is exactly where it will be discovered if you do not look for it first.