# Quality and Sequence Control When GBDS receives a new transaction, a quality and sequence control check is performed. This verification aims to prevent bad transactions from being inserted into the database. Any transaction rejected by quality and sequence control is sent to MIR for manual review. {% hint style="info" %} See the [MIR manual (Manual Image Review)](/gbs/en/applications/mirweb.md) for more information on how to handle transactions sent to it. {% endhint %} ## Verification Steps ### Quality Check The first step when a new transaction is received is for GBDS to perform a quality check on each submitted biometric template. If the quality of any template does not reach the configured threshold, the entire transaction is sent to MIR for manual verification. {% hint style="info" %} See the [GBDS Configuration Manual](/gbs/en/gbds-configuration/gbds4conf.md) or contact the Griaule support team for more information. {% endhint %} Any issue identified by this verification step will be returned as `"QualityIssue"` by the API. ### Duplication Check In this step, GBDS compares each fingerprint against the others to check for duplicates. If any duplicate is identified, the transaction is sent to MIR for manual verification. Any issue identified in this step will be returned as `"DuplicationIssue"` by the API. ### Sequence Check To perform this step, GBDS requires simultaneously captured slapped fingerprint images (*4-slap fingerprint*) (indices 940 and 941) GBDS will attempt to segment these images and extract a predetermined number of biometrics. Then, it will compare the segmented images against the individually captured fingerprints (usually rolled captures). {% hint style="info" %} In cases of amputation or temporary disability, the image may contain fewer than four fingers. {% endhint %} If any comparison identifies a mismatch, GBDS will try to correct the index of the mismatching fingers and perform a self-correction. If there is any identified issue that GBDS cannot self-correct, or if the number of self-corrections is greater than the configured maximum, no correction will be made and the transaction will be sent to MIR. {% hint style="info" %} See the [GBDS configuration manual](/gbs/en/gbds-configuration/gbds4conf.md) or contact the Griaule support team for more information. {% endhint %} Any issue identified in this verification step will be returned as `"SequenceControlIssue"` by the API. The comparison flow for sequence checking will be as follows: #### Comparison Workflow The individual fingerprint images (rolled or flat), with indices between 0 and 3, will be compared against the segmented images at index 940. Then, the individual fingerprint images at indices between 6 and 9 will be compared against the segmented images at index 941. The indices for the individual fingerprint images are: | Index | Fingerprint | Index | Fingerprint | | ----- | ----------- | ----- | ------------ | | 0 | Left Little | 5 | Right Thumb | | 1 | Left Ring | 6 | Right Index | | 2 | Left Middle | 7 | Right Middle | | 3 | Left Index | 8 | Right Ring | | 4 | Left Thumb | 9 | Right Little | ## Handling Anomalies For more information about MIR and anomaly handling processes, see the MIR manual, as mentioned above. In this section, the quality analysis processes performed by the server will be detailed, starting from the moment GBDS receives the decision provided by MIR. ### Approved Transaction Without Changes Given this decision, GBDS will keep the original transaction unchanged and continue the enrollment process. The GUID (Global Unique IDentifier) of the transaction (TGUID) will remain the same for both operations (`QUALITY_ANALYSIS` and `ENROLL`). The notification flow will be as follows: #### Quality Analysis - Approved The first notification will contain the status `"APPROVED"` for the operation `"QUALITY_ANALYSIS"`. ```json { "operation": "QUALITY_ANALYSIS", "tguid": "", "status": "APPROVED" } ``` #### Enrollment - Enrolled The second notification will contain the status `"ENROLLED"` for the following operation `"ENROLL"`. ```json { "operation": "ENROLL", "tguid": "", "status": "ENROLLED" } ``` ### Approved Transaction With Changes Given this decision, GBDS will keep the changes made by the examiner (deleted or edited images) and will generate a new TGUID for enrollment. The notification flow for this decision is similar to the one generated by "*Approved Transaction Without Changes*", adding the new TGUID: #### Quality Analysis - Approved The first notification will contain the status `"APPROVED"` for operation `"QUALITY_ANALYSIS"` and will include the new field `"newTransactionGUID"` indicating that the transaction was accepted with changes and pointing to the new TGUID. ```json { "newTransactionGUID": "", "operation": "QUALITY_ANALYSIS", "tguid": "", "status": "APPROVED" } ``` #### Enrollment - Enrolled The second notification will contain the status `"ENROLLED"` for the following operation `"ENROLL"`. {% hint style="info" %} The operation `ENROLL` will be performed for the altered transaction, so the TGUID mentioned will be the new one generated by the operation `QUALITY_ANALYSIS`. {% endhint %} ```json { "operation": "ENROLL", "tguid": "", "status": "ENROLLED" } ``` ### Rejected Transaction Given the decision, GBDS will not continue the enrollment process and will discard the entire transaction. The TGUID will remain the same. {% hint style="info" %} The transaction history will be kept, but the profile will not be inserted into the database as an active person record. {% endhint %} The notification flow will be as follows: #### Quality Analysis - Rejected The first notification will contain the status `"REJECTED"` for the operation `"QUALITY_ANALYSIS"`. ```json { "operation": "QUALITY_ANALYSIS", "tguid": "", "status": "REJECTED" } ``` #### Enrollment - Failed The result of the operation `QUALITY_ANALYSIS` will be followed by an enrollment notification pointing to the status `"FAILED"` for the operation `"ENROLL"`. ```json { "operation": "ENROLL", "tguid": "tguid", "status": "FAILED" } ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.griaule.com/gbs/en/gbds-integration/qualitycontrol.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.