Prototype · October 2026
NADRA: when two registers disagree, explain why — and leave the decision to an officer.
A birth is recorded at a Union Council and an identity record is kept at NADRA, and the two do not always agree: a day and month transposed, a name spelled two ways, a field left blank, an entry that never reached the central system. NADRA’s own policy framework names fragmented records and duplicated work as problems. This is a working prototype of the layer that compares the two registers, explains each discrepancy with the evidence beside it, and routes it to an authorised officer — without ever being allowed to change an identity record itself. The data is fictional and it runs in your browser; the guided run performs every step for real as it explains it.
The gap
Two registers that should agree, and do not always.
The national registration policy framework approved on 1 January 2025 aims at one technology-driven way to record vital events across Pakistan. NADRA’s own annual report counts about 31.9 million births recorded at Union Councils that are not yet in its central system — and wherever the same event is recorded twice, by two offices, the two records can disagree.
Today a discrepancy tends to surface when a citizen is standing at a counter, and the cost is a repeat visit, a correction application and an officer’s time. Found ahead of time, explained, and corrected from the source register, most of them never reach the citizen at all.
NADRA already runs online applications and biometric verification, and its core identity systems are security-critical. The proposal is not to replace any of it or to reach into it, but to build the reconciliation workflow around it through authorised interfaces, with the decision always left to an authorised officer.
The loop
Predictive, prescriptive, closed-loop, auditable.
A list of mismatches is a report. A system that explains each one, says what the officer should check, records what was decided and from which document, and refuses to decide identity questions itself is a control.
Five solutions
Five places AI could help, and the one to start with.
Five ways AI could help NADRA. The first is the pilot worth starting with, because the problem is named in NADRA’s own policy framework and the result is countable in case-resolution time — it is the one this prototype implements.
| Solution | What it does |
|---|---|
| Registration record reconciliationpilot first · in the demo | Compares Union Council entries with NADRA records, explains each discrepancy and routes it to an authorised officer to decide. |
| Application success assistant | Checks completeness and image quality before submission, inside PakID through approved interfaces, so fewer applications bounce. |
| Citizen service orchestrator | Forecasts demand by centre and service, spreads appointments, and catches a growing backlog before the queue does. |
| Identity-access security monitor | Flags unusual lookups and verification patterns by systems and privileged users, with tamper-evident logs and human review. |
| Service integration and consent layer | The specific missing workflow on top of NADRA’s own data-exchange plans: purpose, authorisation and result recorded for each request. |
What it adds
An exception engine, not another dashboard.
What has to sit on top of the existing systems for a problem to stop going quiet.
Predictive.
Each week’s Union Council entries are compared with NADRA records. Almost all agree outright or once a known transliteration is applied; what is left is a short list of discrepancies ranked by how serious the kind is and how sure the engine is.
Explained, not asserted.
Every case shows both records side by side with the signals behind the score — day and month transposed, parents’ CNICs agree, which entry came first — and the weights add up to the likelihood.
Minimum data.
The comparison sees only the fields it compares. Identity numbers are masked on every screen, and Internal Audit sees the trail without seeing more of the person than the case needs.
The engine never decides identity.
It cannot change, merge or cancel a record, decide that two registrations are one person, or contact a citizen about suspected fraud. Those are locked out in the product, with no switch to turn them on.
Corrected from the source.
A routine correction closes on the officer’s authority, with the register volume and page recorded. A possible duplicate always goes to the Centre In-charge for in-person verification, whatever the score — twins and two mothers are as likely as fraud.
Spelling is not suspicion.
Transliteration variants below the confidence threshold are kept out of the officer’s queue, and the threshold shows exactly which cases it holds back before anybody relies on it.
Auditable by construction.
Every step writes an append-only line: what the engine flagged, what the officer checked and decided, who approved it and what followed.
The guided run
It explains itself, by doing it.
Thirteen steps: this week’s Union Council batch is compared; a transposed date of birth is opened, explained, and corrected by the Verification Officer from the register page; a possible duplicate — same father, two Union Councils, births three days apart — is referred for in-person verification and signed by the Centre In-charge; then the guardrails, the scorecard and Internal Audit’s view. Every step performs the real action, and it reads itself aloud unless you turn that off.
Guardrails
What it never does, and a trail nobody can edit.
Proof
A baseline, a controlled pilot, and targets that say they are targets.
A department will not approve AI because it sounds innovative. These are proposed 90-day pilot objectives, to be fixed only after the baseline is measured — not established figures.
| Solution | Proposed 90-day target | Measured by |
|---|---|---|
| Registration record reconciliation | 30% less time resolving selected discrepancies | Median case-resolution time |
| Registration record reconciliation | Fewer corrections discovered at the counter | Correction applications for the pilot UCs, against baseline |
| Registration record reconciliation | No identity change without a source document | Audit sample of closed cases |
Roadmap
Ninety days, one pilot, then a decision.
Discovery and access
One accountable owner and one technical counterpart. The Union Council link, the record fields in scope and the correction workflow reviewed; the discrepancy baseline measured; privacy and security constraints written down.
Prototype on their process
This demo rebuilt on NADRA’s own workflow with synthetic or authorised, protected data, agreed with the identity-system owners, plus the integration and evaluation plan.
Controlled pilot
A small set of Union Councils, run alongside the existing process. Officers decide every case; resolution time, corrections, false alarms and any privacy incident tracked against the baseline.
Business case and decision
Results validated with NADRA, costs, privacy and security risks, and a phased rollout with acceptance criteria — through the applicable procurement rules.
Architecture
How it would be built.
Around the identity system, not inside it
The engine reads authorised Union Council entries and the record fields it compares through approved interfaces, and writes back nothing but cases. NADRA’s systems stay the system of record and the only place a record changes.
Rules and models together
Deterministic comparison with known transliterations does the bulk; a scoring model ranks what is left. Thresholds are configuration with a logged approver.
Data minimisation
Only the fields in the comparison; identity numbers masked everywhere; role-based access; no free-text search across citizens.
Locks, not settings
Changing, merging or cancelling an identity record and deciding that two registrations are one person are outside what the engine can do, in code.
Audit and evidence
An append-only history on every case, including the source document an officer relied on, so every correction can be traced to a page in a register.
Hosted where the data has to be
Deployable only on infrastructure NADRA approves, with tamper-evident logs and model monitoring for error patterns across regions and groups.
Scope
What this is, and what it is not.
- It is a prototype built from published policy reporting and a strategy paper, not a deployed or commissioned system, and it is not affiliated with NADRA.
- Every case, Union Council entry, officer, name and identity number in it is invented. No real person or record is reproduced.
- It holds no data: state lives in the visitor’s browser and never leaves it.
- The pilot targets are proposed objectives, not results. The scorecard’s baselines are invented for the demo; a real pilot measures them first.