Problem Statement
When ABIS detects multiple matches for a given biometric, the system — based on its configuration — forwards the request to a Manual Adjudicator, who approves or rejects the packet for further processing.
In the current (As-Is) Manual Adjudication (MA) request, the referenceURL field at the top level and inside the gallery is sent as a stringified JSON array (datatype: String). This forces consumers to double-parse the value (parse the request, then parse the embedded string) and is inconsistent with how structured data should be represented. The behaviour also differs by packet type, and one packet type is not handled at all:
New Registration: referenceURL carries data from a single source (packet details), as a stringified array.
Update Packet: referenceURL carries data from two sources (packet details + ID Repo data for the UIN), as a stringified array.
Lost UIN: Not currently routed to Manual Adjudication — when more than one match is found, the packet is simply rejected.
Biometric Correction: Not applicable.
This story captures the To-Be change: rename/convert the top-level field to referenceURLs as a native JSON array, convert the gallery referenceURL to a native JSON array as well, and route Lost UIN packets to Manual Adjudication on multiple matches — applied appropriately per packet type.
Goals
- Convert the top-level referenceURL (stringified JSON array, datatype String) to referenceURLs as a native JSON array in the MA request.
- Convert the gallery.referenceIds[].referenceURL value from a stringified array to a native JSON array.
- Preserve the existing per-source content per packet type:
- New Registration — referenceURLs contains a single source (packet, status PROCESSING).
- Update Packet — referenceURLs contains two sources (packet with status PROCESSING, and idrepo with status PROCESSED for the UIN).
- Lost UIN — referenceURLs contains two sources (packet and idrepo).
- Route Lost UIN packets to Manual Adjudication when more than one match is found, instead of rejecting the packet.
Non-Goals
- Biometric Correction packet type — not applicable; no MA request change.
- Changing the data share service or the generation of the underlying datashare URLs themselves.
- Changing the adjudicator's decision logic or the approve/reject semantics beyond the new Lost UIN routing.
- Changing the addtional field or the ABIS response content carried in the gallery.
- Applying the changes in MOSIP v1.1.5.x
Acceptance Criteria
- AC1 — Top-level field conversion
- Given an MA request is generated, when the request is built, then the top-level field is referenceURLs and its value is a native JSON array of objects (source, status, url) — not a stringified array, and not datatype String.
- AC2 — Gallery field conversion
- Given an MA request contains a gallery, then each gallery.referenceIds[].referenceURL is a native JSON array (not a stringified array).
- AC3 — New Registration content
- Given a New Registration packet with multiple matches, then referenceURLs contains a single source object with source = packet and status = PROCESSING, pointing to the datashare URL for the reg id.
- AC4 — Update Packet content
- Given an Update packet with multiple matches, then referenceURLs contains two source objects: source = packet (status = PROCESSING, datashare URL for the reg id) and source = idrepo (status = PROCESSED, datashare URL for the UIN).
- AC5 — Lost UIN routing
- Given a Lost UIN packet for which more than one match is found, then the packet is forwarded to Manual Adjudication (it is no longer auto-rejected).
- AC6 — Lost UIN content
- Given a Lost UIN packet routed to MA, then referenceURLs contains two source objects (packet and idrepo) as a native JSON array.
- AC7 — Biometric Correction unaffected
- Given a Biometric Correction packet, then no MA request structure change is applied (NA).
- AC8 — Cross-version parity
- Given platform v1.2.x and v1.1.5.x, then both produce the MA request with referenceURLs (and gallery referenceURL) as native JSON arrays, with identical per-packet-type content.
- AC9 — Consumer compatibility
- Given the Manual Adjudication system consumes the request, then it correctly parses referenceURLs and gallery referenceURL as JSON arrays without requiring a secondary string-parse step.
Problem Statement
When ABIS detects multiple matches for a given biometric, the system — based on its configuration — forwards the request to a Manual Adjudicator, who approves or rejects the packet for further processing.
In the current (As-Is) Manual Adjudication (MA) request, the referenceURL field at the top level and inside the gallery is sent as a stringified JSON array (datatype: String). This forces consumers to double-parse the value (parse the request, then parse the embedded string) and is inconsistent with how structured data should be represented. The behaviour also differs by packet type, and one packet type is not handled at all:
New Registration: referenceURL carries data from a single source (packet details), as a stringified array.
Update Packet: referenceURL carries data from two sources (packet details + ID Repo data for the UIN), as a stringified array.
Lost UIN: Not currently routed to Manual Adjudication — when more than one match is found, the packet is simply rejected.
Biometric Correction: Not applicable.
This story captures the To-Be change: rename/convert the top-level field to referenceURLs as a native JSON array, convert the gallery referenceURL to a native JSON array as well, and route Lost UIN packets to Manual Adjudication on multiple matches — applied appropriately per packet type.
Goals
Non-Goals
Acceptance Criteria