How this works, and what it does not do

Matching without sharing identifiers

The obvious objection to joining welfare data is that one department ends up holding another department’s roll. Adhikar avoids it. Each department encodes a record’s identifying fields into a Bloom filter under a key shared only with the linkage authority, using the cryptographic long-term key construction. Only that filter leaves the department. The matcher compares filters by Dice coefficient, so it can conclude that two records describe one person without ever receiving a name, a date of birth or an address.

Candidate pairs are first blocked by district, sex and birth year. Those are coarse attributes, and blocking on them is a stated trade-off: it makes the comparison tractable, and it is the one place where fields are used unblinded.

Precision

99.9%

Recall

99.4%

Accepted pairs

5,868

Access control lives in the query

Every read passes through one guarded layer that folds the officer’s department and district into the SQL itself. A row outside a posting is not fetched and then hidden; it is never selected. That is why the register can report how many cases it refused to return, and why the same query run by two officers produces different results. Identity fields stay masked until an officer with the right opens a specific case, and the reveal is recorded as its own event.

Eligibility is data, not a model

Scheme criteria are stored declaratively and evaluated field by field, so every case carries a trace showing which conditions were met, from which record, and what the held value was. An unexplainable denial of a pension is not a technical defect; it is a harm.