Forty Jan Aadhaar Forms, a Devanagari-Only Portal and a 6 p.m. Cutoff
A data-entry operator at an e-Mitra kiosk in Rajasthan is entering 40 Jan Aadhaar-linked beneficiary records before a 6 p.m. cutoff. The portal accepts the address block in Devanagari only and rejects Latin characters, so the English 'S/o' printed on the paper forms must be entered as 'पुत्र'. The portal also validates the PIN code against the selected district. In the batch: one form pairs PIN 313001 with district 'जोधपुर'; one writes the district as 'गंगानगर'; one writes 'झुन्झुनू'; two forms carry PIN 302001 with district 'जयपुर' but a tehsil that the operator does not recognise as belonging to that district. The supervisor says, 'Type exactly what is on the form - matching it is not our job, the block will verify later.' The kiosk has one operator, a slow connection, and a queue outside.
1. Which records should be stopped rather than saved, and why is a PIN–district mismatch an integrity failure rather than a spelling problem?
Read the worked answer
Stop and hold: the form pairing PIN 313001 with 'जोधपुर' (313001 is a Udaipur PIN, not a Jodhpur one), and the two forms whose tehsil does not belong to the stated district. Do not stop: the district spellings, which are a different kind of problem - the facts of the record are consistent, only the rendering differs.
The distinction matters because of what the field controls. District and PIN are administrative keys: the portal uses them to route the record to the correct block, and Jan Aadhaar linkage ties the family to a district for scheme delivery. A misspelt name still identifies the same person; a wrong district attaches a real person to the wrong office, and once the record is saved and linked, correcting it means an administrative correction, not an edit.
So the rule is: never guess an administrative field. Correct it only from the source form or an authoritative PIN/district list; if the form itself is wrong, hold the record, mark the reason, and return it to the supervisor. Saving a knowingly inconsistent record to clear the queue transfers the error to a beneficiary who will discover it months later.
2. Evaluate the supervisor's instruction. In which fields is 'type exactly what is written' correct, and in which is it wrong?
Read the worked answer
The instruction is half right, and the split is principled rather than arbitrary.
It is right for the citizen's own particulars - name, father's or husband's name, date of birth, address as stated. A data-entry operator is not entitled to 'improve' a person's name. Hindi names routinely carry variant spellings, and silently normalising one can break the match with an earlier record. Faithful transcription, with the source document retained, is the correct standard.
It is wrong for fields with an official master list - district, tehsil, block, PIN, scheme name. These are not the citizen's spelling; they belong to the State and exist in one authoritative form. Typing a variant creates a record that the portal's own reports will not count, which is exactly the kind of failure that surfaces at verification time.
Either way, the instruction is wrong about documentation. 'Somebody will check later' only works if the operator flags the doubt; an untouched record with a wrong PIN looks identical to a correct one. Any departure from the source, and any hold, must be recorded in the remarks column or a batch note.
3. The portal rejects Latin characters, and one name contains a character the operator's keyboard cannot produce. What rule governs the Hindi and English columns, and what should the operator do about the missing character?
Read the worked answer
Rule for the columns: the Devanagari column carries the Hindi form as printed - 'पुत्र', 'पुत्री', 'पत्नी' in place of S/o, D/o, W/o - entered with a proper Devanagari keyboard layout or input method, not by typing Latin letters and hoping the portal transliterates. The English column carries the romanised form 'S/o', 'D/o' with the name transliterated consistently across the batch, so that one beneficiary is not 'Shri Ganganagar' in one record and 'Sri Ganga Nagar' in the next.
The missing character: do not substitute a lookalike character. A nukta or an anusvara that is close but not identical produces a string that differs at byte level, and every later search, sort and duplicate check on that name will miss it. Use the operating system's character map or a Devanagari input method to insert the correct character; if the portal's field itself rejects it, photograph or note the exact form, hold the record and escalate.
In short: match the source for identity, match the master list for administration, and never approximate a character - an approximation is invisible on the screen and permanent in the database.