A technical brief on registry fragmentation and the case for a single deduplicated social registry hub — prepared for programme and information-systems leadership evaluating Scolah Compass as an interoperability layer across existing benefit and civil-registration systems.
Most social protection systems did not fail to register people — they registered the same people multiple times, in different systems, under different identifiers, with no shared source of truth. A household enrolled in a cash transfer programme, a health subsidy, and an education grant can exist as three unrelated records, each unaware of the other two. Reconciling that is not a policy problem. It is a data architecture problem, and it has a known solution: a canonical registry that every downstream system reads from and writes to.
| Specification | Value |
|---|---|
| Deployment Model | Single-tenant registry hub; on-premises or government cloud |
| Data Model | Household → Individual → Case; canonical UUID identity keys |
| Integration Count | 6 upstream systems at reference deployment |
| Deduplication Method | Deterministic match with probabilistic fallback scoring |
| Sync Pattern | Event-driven (pub/sub) plus nightly batch reconciliation |
| Access Model | Role-based, audit-logged, consent-scoped |
This note is organized as a systems brief, not a proposal. Sections 01–03 describe the problem and the target architecture. Sections 04–06 describe how a deployment is actually built, governed, and started.
| No. | Section | Description | Page |
|---|---|---|---|
| 01 | The Problem | Why registries fragment, and what it costs in duplicate payment and audit burden | 04 |
| 02 | The Architecture | Hub-and-spoke deduplication model, with reference deployment topology | 06 |
| 03 | The Migration Path | Data mapping to cutover, phase by phase, with exit criteria | 08 |
| 04 | The Modules | Six components, technical capability by capability | 10 |
| 05 | Governance & Access Control | Roles, permissions, audit trail, consent scoping | 11 |
| 06 | Getting Started | Reference deployment path and technical point of contact | 13 |
Cash transfer, health subsidy, education grant, and disaster-response programmes are typically commissioned separately, years apart, by different agencies, on different procurement cycles. Each ships with its own beneficiary list. None of them were built to talk to each other, because none of them were built at the same time, by the same team, against the same requirement.
A household that appears under three unlinked identifiers is not three problems — it is one problem, paid for three times. Duplicate or stale records inflate disbursement totals, and reconciling them after the fact is a manual audit exercise, not a system function. Every duplicate that survives to disbursement is a payment that either goes to the wrong place or gets caught only by chance.
Connecting six systems directly to one another requires up to fifteen point-to-point integrations — each one bespoke, each one a maintenance liability, each one a new place for identity to drift out of sync. A hub-and-spoke model replaces that mesh with six connections to a single canonical registry: linear cost instead of combinatorial cost, and one place where "who is this person" is answered once.
Nothing here is aspirational. Every row on the right describes a mechanism the hub actually implements, mapped against the operational reality it replaces.
Every upstream system keeps its own database and business logic. What changes is where identity lives: a single deduplicated record hub owns the canonical household and individual graph, and every spoke system references it instead of maintaining its own copy.
In most mid-size social protection systems, five to eight registries operate in parallel with no shared identifier. That is not a failure of any single system — it is the predictable outcome of programmes built independently, over years, by different teams.
A hub does not replace those systems. It gives them one thing none of them had on their own: a canonical answer to the question every one of them is separately trying to answer — who is this, and have we already seen them somewhere else.
The hub is not switched on. It is grown into, in four phases, with an explicit exit criterion at each step — no phase begins until the previous one has been signed off.
| Phase | Objective | Duration | Exit Criterion |
|---|---|---|---|
| 01 · Data Mapping | Map each source system's schema to the canonical household / individual model; resolve field-level conflicts | 4–6 weeks | Field-mapping document signed off by every system owner |
| 02 · Dedup Pass | Run deterministic and probabilistic matching across all source extracts; generate merge / no-merge candidate list | 2–4 weeks | Duplicate rate below agreed threshold on sampled audit |
| 03 · Parallel Run | Hub operates alongside source systems, which remain the system of record; discrepancies are logged, not auto-resolved | 6–8 weeks | Reconciliation discrepancy rate stable and fully explainable |
| 04 · Cutover | Hub becomes the system of record; source systems switch to read/write against it via connector | 1–2 weeks | All programmes reading and writing the canonical record; legacy direct writes disabled |
Fig. 4 — Field office data entry during the mapping phase, prior to hub cutover, Nairobi. Photo · Cytonn Photography / Unsplash
Each module is independently deployable and independently versioned. Core is the only one every other module depends on.
Canonical household / individual / case identity graph. UUID-keyed records survive registry merges and system replacements. Exposes REST endpoints and event streams (created / updated / merged) for every downstream consumer.
Multi-channel case intake — web form, mobile app, paper-batch scan with OCR fallback. Schema-validated at point of entry. Duplicate-candidate flagging runs synchronously against the hub before a record is committed.
Indicator pipelines and cohort tracking against the canonical population. Exports to standard donor reporting formats. Point-in-time snapshots for audit and evaluation, independent of any source system's retention policy.
Offline-first mobile capture for enumerators without reliable connectivity. Conflict-free sync on reconnect; merge and last-write rules configurable per field.
Generates payment instructions from eligibility decisions computed against the canonical record. Reconciles against disbursement-provider callbacks; flags mismatches for manual review rather than auto-resolving them.
Matching and scoring assistance for duplicate-candidate review and anomaly detection on claims. Advisory only: any match above a configurable confidence threshold still requires human sign-off before a merge is committed.
Access is role-based and least-privilege by default. Every role below is scoped at the record level, not just the system level.
| Role | Scope | Permissions |
|---|---|---|
| Caseworker | Assigned households / cases only | Read; update intake fields |
| Programme Administrator | Full programme cohort | Read; approve eligibility; no raw PII export |
| System Integrator (API) | Fields declared in its connector contract only | Read/write via contract; no UI access |
| Auditor | Full registry, read-only | Read; export audit log; no data modification |
| Data Subject (self-service, where enabled) | Own household record only | Read; request correction; view own access log |
Every read and write is logged with actor, timestamp, and a field-level diff. Logs are append-only and exportable independent of the record they describe.
Records are tagged with a consent basis per programme. Withdrawing consent from one programme does not remove a household from others unless explicitly configured to do so.
We didn't need a seventh system. We needed the six we already had to agree on who a person was.
Engagements begin with a registry assessment, not a contract for the full architecture. Most teams connect one upstream system first, validate the deduplication pass against it, and only then commit to a phased cutover across the rest.
Mapping of existing systems, a duplicate-rate baseline, and a confirmed integration count.
Hub design scoped to your existing systems, with a named, phased migration path.
One upstream system connected and validated before any commitment to full rollout.
RBAC matrix, audit and consent model, packaged for procurement and technical review.