> For the complete documentation index, see [llms.txt](https://docs.griaule.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.griaule.com/gbs/en/applications/trust.md).
# Trust
## 1. Tool Overview
Trust is a GBS tool used to resolve conflicts between biometric or biographical data that require human intervention. In these situations, a specialist analyzes the profiles involved and chooses whether to keep, merge, or reject any of them. The decisions directly affect the database, and queued transactions are only reprocessed after the case is resolved. The tool is used in different contexts, such as:
* **Identity issuance**: when there are registration attempts with inconsistent data;
* **Banking systems:** to ensure that the authenticity and uniqueness of each customer or account holder are guaranteed, and their identity correctly verified;
* **Elections**: to ensure voter uniqueness.
### 1.1 What does Trust solve in practice?
Trust was created to deal with **inconsistencies that compromise the integrity of the single database**, such as:
* The same individual trying to register with **different documents and names**;
* **Matching biometrics** associated with conflicting biographical data;
* **Incorrect registration updates**, which differ from the original identity.
### 1.2 What are the main benefits of using Trust?
By using Trust, you can have:
* **Database reliability:** ensures that only legitimate and consistent profiles remain, preventing duplicates and fraud.
* **Transparency and traceability:** all actions are logged, allowing audits and ensuring confidence in the decisions.
* **Operational agility:** intuitive interface, with well-defined flows that make analysts' work easier.
* **Security in decisions:** offers detailed comparisons between biometric and biographical data, supporting technical and well-founded decisions.
* **Integration with other tools:** connects to Intelligence for quick access to transaction history.
## 2. Essential Concepts
In this section, you will find the main concepts and structures that make up how Trust works. They help explain how the system organizes information, how conflicts are detected and handled, and what role users and permissions play in the decision-making process.
### 2.1 Profile
The profile represents a unique individual in the database. Each profile brings together consolidated and validated biographical and biometric data.
The database ensures that there are not two profiles with the same key or biometrics, guaranteeing uniqueness. Existing profiles are compared with the data received in a new registration to check for possible conflicts with the database rules.
### 2.2. Nonconformity
In the context of Trust, a nonconformity is a situation in which the data from a new registration or an update does not match the information already registered in the database. This can happen, for example, when:
**1. Identical Biometrics with Different Keys (Same biometrics)**\
This situation occurs in *enroll* transactions (registration) when two individuals, with the same type of key (such as CPF), but with different values, present identical biometrics (fingerprint and facial), which may indicate duplicate registrations.
**2. Different Biometrics with the Same Key**\
Occurs in *update* transactions (update) when two people share the same key (the same CPF number, for example), but present different biometrics. This suggests a possible inconsistency or identity swap.
**3. Inconclusive Biometrics**\
May occur both in *enroll* as well as in *update*, in two main scenarios:
* When one biometric modality is the same (e.g., fingerprints) and another is different (e.g., face), which may indicate an attempt at fraud or the existence of identical twins.
* When the quality of the biometrics is so poor that neither the system nor the experts can conclude whether they are the same or different.
**4. Update Nonconformity**\
The biometrics recorded during the update are different from the previous ones, indicating a possible identity swap or error in the process.
**5. Registration Nonconformity**\
The biometrics provided already exist in the database, but are associated with another profile, which may indicate duplication or an attempt at fraud.
#### Types of nonconformity
These conflicts prevent the system from automatically approving the data entry. Therefore, the nonconformity must be analyzed manually in Trust, to decide what to do with the profiles involved, whether they should be unified, rejected, or kept separate.
The system can detect different types of nonconformity:
* **Biometric**: When there is pending biometric analysis in the group (e.g., the fingerprints or face from the transaction match those of another profile).
* **Biographical**: When there is pending biographical analysis in the group (all biometric analyses have already been performed)
* **Mixed**: occurs when there is a simultaneous conflict between biometric and biographical data.
### 2.3 Nonconformity Group (or Group)
In Trust, the group is the central unit of analysis. It is made up of all profiles and transactions related to the same nonconformity, originating from a transaction that tries to enter the database. This transaction is compared with existing profiles and, when there is a conflict, all those involved are brought together into a single group to make viewing and handling easier. The group is analyzed as a whole, allowing the specialist to understand the full case before deciding what should happen in the database.
### 2.4 Transaction
In the context of Trust, a transaction is the attempt to insert or update data in the GBDS database. It may refer either to the registration of a new individual or to a data update for an individual already existing in the database.
Each transaction contains biometric information (such as fingerprints and face) and biographical information (such as name, CPF, date of birth) for an individual. The system evaluates whether the provided key (e.g., CPF, Voter ID) already exists in the database to determine whether the transaction is an update or a new registration.
There are two main forms of transaction:
* **Registration:** When a new individual is added to the database.
* **Update:** When a new transaction is submitted for an individual who was already registered in the database.
### 2.5 Pending Resolution Transactions
These are transactions that conflict with a profile already involved in an unresolved nonconformity group. For this reason, they cannot be handled immediately and remain in a waiting state until the previous group is finalized.
After the group that caused the block is resolved, these transactions are automatically reprocessed. At that point, they may be accepted directly or generate a new nonconformity group, depending on the result of the duplication.
### 2.6 Biometric Comparison
The biometric comparison feature allows the operator to view biometric pairs side by side (face and fingerprints) between the transaction and the profile under analysis. Each pair is shown with a colored border, which indicates the result of the comparison performed by the system:
* **Green:** high similarity between the biometrics
* **Red:** low similarity between the biometrics
* **Gray:** inconclusive result
### 2.7 Treatment Confirmation
Choice made at the end of a group analysis, defining what will happen to the profiles and to the incoming transaction. The main decisions are:
* **Reject transaction**
* **Unify profiles**
* **Keep profiles as separate**
### 2.8 Hierarchy and Permissions
Users have different permission levels based on the organization they are linked to, and this affects what they can view and decide within the Trust system.
Only users with the proper permissions can make certain changes, since some actions require validation by a higher organization, which ensures greater security and governance in decisions that affect multiple institutions.
### 2.9 Biometric Conflict
A biometric conflict occurs when the biometric presented in a transaction (such as fingerprints or face) differs from the biometric already registered for the same key or matches the biometric of another existing profile in the database with another key. This inconsistency may indicate a registration error, a duplicate, or even an attempt at fraud. Biometric conflicts are among the main reasons that generate nonconformities and require manual analysis.
### 2.10 Biometric Decision
The biometric decision is the conclusion about the similarity between two biometrics. It can be made automatically by the system, based on the comparison score, or manually by experts. Very high scores indicate compatible biometrics, while very low scores indicate different biometrics. When the score falls within an intermediate (inconclusive) range, expert evaluation is required. The biometric decision guides how the nonconformity is handled, indicating whether the data belong to the same person or not.
### 2.11 Biometric Analysis
Biometric analysis is the process of visually evaluating the biometrics involved in a nonconformity. It only takes place when the biometrics fall into an inconclusive zone (neither with a very high score nor a very low one). In this case, experts compare fingerprints or facial images to determine whether they belong to the same person. The analysis is performed independently by more than one expert and requires consensus to proceed with handling. The possible decisions are: compatible biometric, incompatible biometric, or inconclusive.
## 3. Operational Flow
This section describes, step by step, how the Trust tool works, reflecting the real workflow of users in the analysis and handling of nonconformities. It includes the detection logic, the criteria that define the possible flows, and the decisions that affect the database.
### 3.1 Initial screen
This is the screen that gives access to the analyses available to a user. The information displayed varies according to the user's permissions (types of analysis they can perform) and the organization they are linked to.
At the top of the screen, there are buttons that take you to the next available analysis. The choice of analysis to be performed follows the prioritization logic defined by the system settings; the operator does not select which transaction to analyze, but rather handles the next one in the queue.
Counters are also displayed showing how many analyses are still available for that user.
### 3.1.2 Detection of Nonconformity
The Trust system detects a nonconformity when a registration or update transaction conflicts with the consolidated data in the database. Verification is carried out using algorithms that assess consistency between the received data and the existing data, considering biometric information (such as fingerprints and face) and biographical information (such as name, date of birth, and document numbers).
#### Detection criteria for registrations and updates
The transaction may represent:
* **A new registration**, when the identification key (for example, CPF or Voter ID) does not yet exist in the database.
* **An update**, when the key is already registered in the database and a new transaction with the same keys is made.
The nonconformity detection logic varies according to the type of transaction:
* In the case of **registration**, the submitted data are compared with all existing profiles in the database, looking for biometric similarities that indicate duplication.
* In the case of **update**, the transaction data are compared with the data from the source profile. If there is an inconsistency (for example, the biometric submitted belongs to another person), a nonconformity is generated.
#### Detection algorithms
The database uses matching algorithms that compare the transaction data with existing profiles. For biometrics, defined similarity thresholds are used to determine whether there is a match or not. In case of doubt or uncertainty, the system does not make the decision automatically; the analysis is forwarded to human operators, with the support of facial and fingerprint analysis tools.
**Examples of situations that generate nonconformities:**
* A new registration has fingerprints that match those of an existing profile, even with different biographical data.
* An update tries to change a profile's biometric (for example, the face), but the new biometric does not match the reference profile with the same keys.
These situations prevent the transaction from entering automatically and trigger manual analysis flows by specialists.
### 3.1.3 Possible analysis flows from the nonconformity
After the nonconformity is detected, the system can route the generated group to different types of biometric and biographical analysis:
* **Facial analysis only**: if the conflict is facial and there are no signs of a fingerprint problem.
* **Fingerprint analysis only**: if the conflict is exclusively in the fingerprints.
* **Facial and fingerprint analysis**: if inconsistencies are detected in both biometric modalities.
* **Facial and/or fingerprint analysis, but no need to compare data or image**: in some cases, even when biometric analysis is needed, biographical analysis is not enabled, due to the absence of conflict in the biographical data.
Biographical analysis is shown only if the system identifies discrepancies in the biographical data. If the biographical data are compatible and there is no risk of changing the database content, the biographical analysis step may not occur.
### 3.2. Access to the Analysis Queue
After a nonconformity is detected, the corresponding group is sent for analysis by authorized operators. The system organizes and makes these analyses available through a specific interface, which allows controlled and ordered access to pending nonconformities that need handling.
### 3.2.1 Queue organization (prioritization and allocation)
The prioritization of analyses follows rules that consider, among other factors, the waiting time of the nonconformity and the current status of the group. There is an administrator panel that allows priority rules to be configured for certain groups or transaction types.
The allocation of analyses can happen in two ways:
* **Automatic distribution**: the system directly delivers an available analysis to the user, according to their permission and organizational scope.
* **Manual selection:** the user freely chooses which nonconformity to analyze; currently, this type of selection is only possible in the administrator panel, through a direct search by the key of the person involved.
### 3.2.2 How the user receives an analysis
When accessing the analysis screen, the system can automatically present an available group, according to the distribution logic. Alternatively, the operator can use the search and filter tools in the administrator panel to select the analysis they want to handle. The permissions of the organization to which the operator is linked determine which groups will be visible or available for handling.
#### 3.2.3 Access interface: priority queue analysis and assigned analyses panel
The access interface to Trust allows the operator to choose the type of nonconformity to be handled, within the specific groups they have access to. The main features of this interface include:
* **Nonconformity analyses in order of priority**, which include:
* **Fingerprint analysis**: comparison of fingerprints to verify whether they belong to the same person.
* **Face analysis**: comparison of facial images when there is uncertainty in the automatic match.
* **Biographical analysis**: assessment of conflicts between data such as name, date of birth, and parentage.
* **Pending approval**: cases already handled that are awaiting final confirmation by a second operator.
* **Assigned analyses panel:** each operator has a panel with the analyses already assigned to them, that is, those in which they started the biographical analysis but have not yet completed the handling. This panel allows pending cases to be resumed and ensures that the same nonconformity is not handled by more than one operator.
### 3.3. Biometric Analyses
The biometric analysis stage involves checking the similarity between facial and fingerprint records detected by the system as possible matches. The analyses are separated into two distinct interfaces: **face analysis** and **fingerprint analysis**. Each has its own flows and specific evaluation criteria.
### 3.3.1. Face analysis
#### Display criterion in face analysis (uncertainty threshold)
A case is sent for manual handling whenever the facial similarity score between two images falls within an uncertainty range, that is, within an interval in which the system does not have enough confidence to make an automatic decision. The logic is to avoid false positives or negatives in cases of low or medium reliability.
#### Facial biometric comparison modal
By clicking the button **Face analysis** on the Trust home screen, the system automatically selects the first case in the queue and opens a comparison modal, which displays the facial images of the two profiles being compared side by side, without indicating which profile they belong to.
**How the interface works**
The facial analysis interface shows the pairs of facial images to be compared. After the analysis, the operator must indicate their decision using the three buttons at the bottom of the screen, or through the corresponding keyboard shortcuts:
* **Different faces - red (key A)**
* **I can't decide - gray (key S)**
* **Same faces - green (key D)**
The operator's decision is recorded and used in the following steps of the flow.
Once the decision is indicated, the case will be closed and the next case will be automatically displayed on the operator's screen. If there are no more cases to be handled, the corresponding message will be shown on the screen.
To return to the home screen, simply click the Trust logo in the upper-left corner or on **Analysis**. The case that may be open without a decision will return to the analysis queue to be sent to another operator.
**When marking as inconclusive**
The option to mark the analysis as inconclusive should be used when the operator cannot determine with confidence whether the facial images correspond to the same person, even after detailed observation in the comparison modal. This button serves to signal that the decision cannot be made based on the data presented.
### 3.3.2. Fingerprint Analysis
#### Fingerprint biometric comparison modal
By clicking the button **Analysis** **of fingerprints** on the home screen, the system automatically selects the first case in the queue and opens a comparison modal, which displays the fingerprint images of the two profiles being compared side by side, without indicating which profile they belong to.
**How the interface works**
The fingerprint analysis interface shows the pairs of fingerprint images to be compared. After the analysis, the operator must indicate their decision using the three buttons at the bottom of the screen, or through the corresponding keyboard shortcuts:
* **Different fingerprints - red (key A)**
* **I can't decide - gray (key S)**
* **Same fingerprints - green (key D)**
The operator's decision is recorded and used in the following steps of the flow.
Once the decision is indicated, the case will be closed and the next case will be automatically displayed on the operator's screen. If there are no more cases to be handled, the corresponding message will be shown on the screen.
To return to the home screen, simply click the Trust logo in the upper-left corner or on **Analysis**. The case that may be open without a decision will return to the analysis queue to be sent to another operator.
#### Biometric merging rules
The system considers multiple factors to determine whether the biometrics belong to the same person:
* **Similarity threshold**: comparison scores between fingerprints.
* **Quality of the biometrics**: low-quality biometrics can make the decision difficult and justify an inconclusive status.
* **Number of fingers with a “hit”**: the number of matching fingers is a relevant factor in decision-making. Agreement on only a few fingers may or may not be enough, depending on the quality and the score.
It is important to note that not all 10 fingers will always be available for analysis in Trust. The system only sends for manual verification the fingerprint pairs whose automatic comparison was not conclusive. In other words, fingers with good quality and a very high score (indicating strong similarity) or a very low score (indicating strong difference) are automatically classified by the system, without the need for manual review. Therefore, the operator may see only some pairs, such as 6 or 7 fingers, depending on the quality of the biometrics and the performance of the initial comparison.
**When marking as inconclusive**
As in facial analysis, the inconclusive button should be used when, after observing the fingerprints in the comparison modal, the operator cannot confidently state whether the fingerprints belong to the same person or not.
### 3.4. Biographical Analysis
After the biometric analysis stage (facial and/or fingerprints), the system can forward the profile to the biographical analysis stage, depending on the characteristics of the nonconformity. Biographical analysis is performed based on the comparison between the biographical data of the transaction (registration or update) and the data of the database profile being compared.
#### How to view and compare
**Biographical data between profiles**
The interface presents the biographical data of the transaction and the biographical data of the database profile, allowing the operator to compare the two sets of information. This view aims to highlight convergences and divergences in the data, such as name, date of birth, parentage, among others.
{% hint style="info" %}
During biographical analysis, it is also possible to view the biometrics (face and fingerprints) of the profiles involved. This helps the user make a more informed decision, should it be necessary to review the biometric match previously analyzed.
{% endhint %}
#### Handling the nonconformity
In the **Biographical Analysis** the transaction type is displayed because each transaction type has specific situations that generate nonconformities:
* Registration - The nonconformity is generated when the profiles in the group present identical biometrics and different biographical keys.
* Update - The nonconformity is generated when the profiles in the group present different or inconclusive biometrics and identical biographical keys.
Each profile listed on the screen has a card with specific actions, according to the type of biometric match:
* For profiles with the same biometrics, the following actions are available:
* **Database decision**: allows rejecting or unifying the profile with the incoming transaction.
* **Compare biometrics:** opens a modal with a detailed comparison of the biometrics.
* **View profile in Intelligence:** redirects to the profile in Intelligence.
{% hint style="info" %}
Click "View profile in Intelligence" to check all the registration data for a specific individual.
{% endhint %}
* For profiles with inconclusive biometrics, the available actions are:
* **Database decision:** allows rejecting, unifying, or keeping separately (used in false positive cases).
* **Compare biometrics:** opens a modal with a detailed comparison of the biometrics.
* **View profile in Intelligence:** redirects to the profile in Intelligence.
In the biometric comparison modal, the similarity results between the biometrics of the incoming transaction and the selected profile are shown, with the following color code:
* **Green:** same biometrics
* **Red**: different biometrics
* **Gray**: inconclusive result
It is possible to select a specific biometric by clicking directly on it or using the index selection dropdown. The biometrics of the incoming transaction are displayed on the left and those of the selected profile on the right. Starting with Trust version 1.1.0, these positions were reversed: the selected profile biometric began to be displayed on the left, while the incoming transaction biometric began to appear on the right.
After performing the biometric comparison, the operator will be directed to a screen where the biographical data of the profiles involved will be displayed, highlighting the divergent data. This data must be analyzed so that the correct values are kept in the final profile.
On the confirmation screen, the following are displayed:
* **Profiles that will be unified**
* **Profiles that will be rejected**
* **Biographical data selected for the resulting profile**
* **Field for comments with the justification for the decisions**
If there are transactions in the waiting queue for the group under analysis, they are displayed in the Blocked Transactions section. After handling, if there are no more blocking groups, the transaction is automatically reprocessed.
#### Actions available by analysis type (registration or update)
The actions available on the biographical analysis screen vary according to the type of transaction that generated the nonconformity:
* **For registration transactions**:
* **Reject**
* **Keep separately**
* **Unify**
* **For update transactions**:
* **Reject**
* **Keep** (only one of the profiles)
* **Unify**
{% hint style="info" %}
These actions must be chosen based on the biographical and biometric information available on the screen.
{% endhint %}
#### Choosing the keys that will make up the final profile
The user can select, if there is a discrepancy, which keys should prevail in the final profile. For each divergent key, it is possible to choose whether the value to be kept is the one from the transaction or from the database profile. This feature is especially important in unification cases, where the system allows the operator to compose the unified profile with the most correct or complete data.
#### Rules for enabling the "Confirm treatment" button
The **"Confirm treatment"** button is only enabled when all mandatory decisions have been made:
* The decision about the relationship between the profiles (unify, keep separate, or reject) has been recorded.
* All divergent fields had a value chosen by the operator (transaction or database).
* A **textual justification**was entered, explaining the decision made.
Only after these requirements are met does the system allow the analysis to be concluded and the nonconformity treatment to be recorded.
**Actions available according to the type of transaction**
**For registration transactions**
* **Reject**: used when there is an attempted fraud or when the transaction should not be inserted into the database.
* **Unify**: used when the transaction corresponds to a profile already existing in the database and the data should be consolidated.
* **Keep separately**: used when the biometric was marked as inconclusive and the operator identified that they are actually different biometrics.
**For update transactions**
* **Reject**: used when the data sent for update do not belong to the profile in question, or constitute an attempted fraud.
* **Unify**: used in cases of inconclusive biometrics, when the decision is to consolidate the transaction data into the existing profile.
#### When to use each decision
The choice of action depends on the combined analysis of the biometrics (face and fingerprints) and the biographical data. For example:
* If the biometrics confirm that the profiles belong to the same person and the biographical data are compatible, the indicated action is **unify**.
* When biometrics and biographical data differ, the system recommends **keep** (in registrations with different keys) or **reject** (in updates with the same key).
* When there is not enough certainty, especially in cases of inconclusive biometrics, you may choose to **keep separately** (for registration) or **unify** with reservations (for update), depending on the context.
The decision must always be **well-founded** based on the evidence presented by the interface.
#### How to enter a justification
Before confirming the treatment, the operator must **fill in a justification field**, explaining the reasons for the decision. This justification serves as an audit basis and should objectively present the elements supporting the conclusion reached (e.g., biographical data mismatch, biometric match, evidence of attempted fraud, etc.).
#### What happens when treatment is confirmed
When clicking on **"Confirm treatment"**, the system:
* **Updates the nonconformity status** to resolved.
* **Records the decision and the justification**.
* **Executes the actions corresponding to the decision**:
* If it is **unification**, the transaction data are consolidated into the existing profile.
* If it is **rejection**, the transaction is discarded and recorded as invalid.
* If it is **keep separately** or **keep**, the profiles remain distinct and are not merged.
In addition, the system can trigger automatic mechanisms, such as the **reprocessing previously blocked transactions**, if resolving the nonconformity allows dependent flows to continue.
### 3.6. Validation by Other Organizations
The **validation by other organizations** is required when there is the presence of **multiple organizations** responsible for handling and validating profile nonconformities. In scenarios where a profile belongs to another organization, there is a need for an analysis by a higher-level instance to confirm the truthfulness of a transaction. The resulting pending item is directed to an organization above those involved for a final assessment. This functionality is configurable and may or may not be enabled in the client's environment.
#### When validation is required
Validation by other organizations occurs in the following cases:
* When a **nonconformity** is detected in a profile that belongs to another organization, the system triggers the need for validation by the other organizations involved.
* When analyzing a transaction requires **external confirmation** or **review** from another organization, especially in situations involving high-risk decisions or where there are **discrepancies** in biometrics or biographical data.
#### How the pending item is generated and assigned
The **pending item** validation is generated automatically by the system, which, upon identifying that a nonconformity must be checked by another organization, **creates a pending item** associated with the transaction in question. The assignment of a pending item occurs according to the workflow configured for each organization, and the system will **send the pending item to the responsible organization** or to the operator who must carry out the validation.
* **Assigned pending item**: As soon as the pending item is created, it is **assigned to the operator or organization** that must validate it.
#### What the first operator who handled it sees in the interface
When the **first operator** handles the nonconformity, they will be able to see in the interface an indication that **other organizations need to validate** the transaction or nonconformity. The interface offers a **pending status**, with information about which organization or operator must complete the validation.
* The operator may also see the **details** of the nonconformity, with the evidence and data associated with the transaction that needs to be validated.
* If the operator does not have permission to complete the process, they will see the option to **forward the pending item** to the responsible organization for completion of the validation.
#### What happens if the pending item is approved or rejected
Depending on the decision made by the organization that received the pending item, the following occurs:
* **If the pending item is approved**: The system **completes the process** and the transaction is handled according to the previous decisions, such as **unification** or **separate maintenance**. The nonconformity status is updated to resolved, and the base profile is updated according to the approved treatment.
* **If the pending item is rejected**: If the other organization does not validate the transaction, the group will return to the biographical analysis stage and will be assigned to a new investigator.
### 3.7. Process Completion
The **process completion** of nonconformity handling occurs when all analysis and decision stages are completed, resulting in the **database update** and the possible reprocessing of transactions. This process is critical to ensure that the database information is always up to date and correct, reflecting all treatment decisions made during the analysis.
#### Automatic database update
After all nonconformity handling is completed, the system performs the **automatic database update**. This includes:
* **Addition or update of profiles**: When a nonconformity is resolved, the affected profiles' biographical and biometric data are updated in the database according to the decisions made (merging, separate maintenance, rejection, etc.).
* **Deletion of transactions**: If a transaction has been rejected, it is deleted from the database or marked as invalid, according to the organization's policy.
The automatic update process is carried out without the need for manual intervention, ensuring agility and accuracy in the changes made to the database.
#### Reprocessing previously blocked transactions
In some cases, transactions may have initially been **blocked** due to unresolved nonconformities. After these nonconformities are handled and a decision is made, the system performs the **reprocessing** of these blocked transactions.
* **Reevaluation of transactions**: Blocked transactions can be reevaluated based on the new information or treatment decisions made. If the nonconformity has been resolved and the transaction is now considered valid, it will be processed and integrated into the database.
* **Impact on blocked transactions**: Reprocessing may update the profiles involved, depending on the decision made during the analysis (for example, profile merging or data separation).
#### Possibility of generating new nonconformities from the resolution
After a nonconformity is resolved, there is the **possibility of new nonconformities being generated**. This may occur in the following cases:
* **Change in profile status**: Resolving a nonconformity can lead to **new checks** of data which, in turn, may generate new nonconformities. For example, when merging two profiles, additional discrepancies may arise between the biographical or biometric data, resulting in a new nonconformity.
* **Reprocessing of previous transactions**: As part of the reprocessing of blocked transactions, new nonconformities may be detected in profiles or transactions that previously showed no obvious issues.
* **Changes in validation criteria**: Updating the database and reprocessing transactions can also lead to a **reevaluation of similarity criteria** and merging criteria, which can generate new nonconformities when the system detects additional differences.
This continuous cycle of analysis and handling of nonconformities ensures that the database is always in compliance with quality and security standards.
### 3.8. Administrator Dashboard
The **Administrator Dashboard** is a dedicated interface for monitoring and managing the nonconformities registered in the system. It allows for specific searches, detailed viewing of each nonconformity, as well as prioritization and, in some cases, the handling itself directly through the interface.
#### Nonconformity Search (Transaction Search)
In the dashboard, it is possible to search for nonconformities based on **specific keys**, such as CPF, ID card, voter registration, among others. The search returns a **list of nonconformities** that match the provided key. When clicking one of the listed nonconformities, the system displays its **details page**.
#### Nonconformity Status
Each nonconformity may be in one of the following **statuses**, according to its stage in the handling flow:
* **Biometric analysis**: pending biometric analysis in some group.
* **Biographical analysis**: all biometric analyses have been completed, and there is a pending biographical analysis.
* **Pending approval**: the biographical analysis has been performed and is awaiting approval from a higher organization.
* **Processing**: the nonconformity is being processed by the ABIS, with no user action required.
* **Accepted**: the nonconformity has been resolved and the transaction has been accepted into the database.
* **Rejected**: the nonconformity has been resolved and the transaction has been rejected.
* **Error**: an error occurred while processing the nonconformity in the ABIS.
* **Blocked**: the transaction is linked to a group that has not yet been resolved. The related nonconformities must be handled so that the transaction can be unblocked.
* **Resent for processing**: the nonconformities that were blocking the transaction have been resolved, and it was resent to the ABIS with a new transaction identifier.
#### Nonconformity Details
In the **details page** of a nonconformity, the system displays:
* The **current status** and its description.
* The **profiles involved** in the group.
* The **available actions** which vary according to the status.
Starting with Trust version 1.1, it is possible to forward profiles that are under biometric analysis to biographical analysis through the “Nonconformity Details” screen. Then, the nonconformity can be handled. In these cases, the system assigns the result of the biometric analysis as *INCONCLUSIVE*.
#### Blocked Nonconformities
For nonconformities in the statuses **Blocked** or **Resent for processing**, the interface does not directly display the conflicting profiles. Instead, it lists the **nonconformities that are blocking the transaction**, and the operator can access them by clicking each item.
When **prioritizing a blocked transaction**, the system also **automatically prioritizes** all related nonconformities that are blocking the transaction, ensuring they are handled more quickly.
This functionality enables the administrative team to act more efficiently, ensuring agility in resolving critical cases and greater control over the nonconformity handling flow.
### 3.9. Reports
*Check availability in the deployed environment.*
Trust also offers a tool for visualizing charts and metrics about the environment's transaction and nonconformity history. This data makes it possible to extract insights about nonconformity handling, helping supervisors and coordinators improve the operation of Trust users.
Currently, the system provides two categories of reports:
* Transactions
* Nonconformities
Each category has dashboard tabs that present specific metrics and charts.
In the category *Transactions*, there is a single dashboard tab:
* General
In the category *Nonconformities*, the following dashboard tabs are available:
* General
* Biometric Analysis
* Biometric Analysis - Comparison by user:
* Biographical Analysis
* Biographical Analysis - Comparison by user
#### Applying filters
All dashboards have a series of filters that directly affect the data used in calculating the metrics and generating the visualizations.
The available filters may vary between dashboards, but some examples are:
* **Period:** defines the date range considered in the data.
* **Source label:** corresponds to the *label* of the transaction in the GBDS.
* **Source city:** corresponds to the transaction's source city in the GBDS.
* **Transaction type:** indicates the type of operation in the GBDS (registration or update).
* **Biometric type:** specifies the biometric modality of the data (face or fingerprint).
* **User:** corresponds to the user associated with the filtered data.
#### Metric tooltips
The metrics and charts display *tooltips* when hovering the mouse cursor over dashboard elements. These *tooltips* can provide descriptions of the metrics or detail values and specific information shown in the chart.
## 4. Common Use Cases
This section presents real or simulated examples of using the Trust tool. The examples help consolidate understanding of the system and guide users' decisions.
#### Profiles with the same biometrics and different names: what should be done?
The system can identify a nonconformity between two profiles with **biometrics considered identical**, but **divergent biographical data**, such as differences in the name. This is the typical case of a name change after marriage.
The analyst used Trust to:
* Verify the biometric match through the comparison modal;
* Evaluate the biographical discrepancies directly on the analysis screen;
* Consult each profile's transaction history in Intelligence.
Manual analysis identified that the only change was from the maiden name to the married name. Based on the evidence, the decision was **to reject the reference profile and accept the incoming profile**.
#### A profile with identical biometrics, but divergent biographical data: what should be prioritized?
In biographical registration analyses with identical biometrics, Trust allows you to compare the biographical data between the profiles in the group. When there are discrepancies, the analyst must choose, field by field, which information will make up the resulting profile.
This process occurs after selecting a base action (such as "merge"), and before confirming the treatment. Trust displays the divergent biographical data side by side, and the analyst selects the correct information based on the available data and the transaction history accessible via Intelligence.
Note: The field selection functionality depends on proper integration with the system where the biographical data is stored. If updating the biographical data is not possible, field selection will be disabled.
#### Fraud suspicion
Trust was designed to handle cases of fraud suspicion. One example involves an individual trying to obtain a new document with different biographical information. The system detected the biometric match and generated the nonconformity for analysis.
Based on the evidence, such as the transaction history and the origin of the registrations, the analyst can reject the suspicious profile, justifying their decision on the confirmation screen. If the group is blocking any transaction, it will be automatically reprocessed after the treatment is completed.
## 5. FAQ
This section brings together frequently asked questions. The goal is to help the user make safer decisions, avoid common mistakes, and understand the impact of their actions in the system.
### 1) What happens if I reject the wrong profile?
When rejecting a transaction or marking a profile as invalid, the system records this decision and may permanently block that record. If the rejection is incorrect, the consequence may be the loss of a legitimate piece of data or the need for intervention by another body with higher permission.
{% hint style="info" %}
Before rejecting, carefully check all available biographical data, histories, and biometrics. When in doubt, use the pending item feature for review by another responsible person.
{% endhint %}
### 2) Can I undo a decision?
No. Once the decision is recorded and confirmed, it **cannot be directly undone** by the user. This ensures traceability and security in actions.
However, depending on the organization's flow, an impacted profile may be handled again within the pending-item analysis process.
### 3) How should an inconclusive match be interpreted?
A match is considered inconclusive when the biometric score is in an intermediate zone, that is, neither high enough to confidently say that the profiles belong to the same person, nor low enough to rule out a relationship.
In these cases:
* Check whether the image (face or fingerprint) has sufficient quality.
* Analyze the biographical data in parallel.
* Use the zoom and side-by-side comparison features in the modal.
* If uncertainty persists, document the doubt in the justification and choose to **reject the incoming profile**. This way, an improper update is avoided and the biometrics can be collected again, eventually resulting in a more accurate match.
### 4) How should profiles that seem legitimate but do not match be handled?
These cases are common and may involve legitimate variations or attempts at fraud. Carefully analyze the profiles' history, biometrics, and key data. If there is clear evidence that it is the same person, merge the records with the correct data.
### 5) What are the best practices for investigating and documenting a decision?
Always assess the full set of information: biographical data, history, and biometrics. Give special attention to divergent fields such as name, documents, and date of birth. Use the filters to understand the transaction context and, if necessary, involve other organizations via a pending item. When recording the decision, be clear and objective in the justification — this helps with traceability and future audits. Prioritize accuracy, even in seemingly simple cases.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.griaule.com/gbs/en/applications/trust.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
