Dynamic authority management system and method based on multi-source salary data integration

Abstract

The present invention discloses a dynamic authority management system and method based on the integration of multi-source salary data, which relates to the field of salary data management technology and includes the following steps: collecting role names, authority boundaries and operation granularity information from multiple business systems, generating structured role semantic ontology entries based on field-level semantic annotation; decomposing the roles to be mapped according to the authority dimension, and calculating the semantic similarity index between the roles to be mapped and the standard roles based on the role semantic ontology library, and outputting a role consistency scoring matrix. The present invention identifies authority differences through role semantic ontology and similarity scoring, combines rule engines with reinforcement learning to achieve minimum authorization rulings, and uses blockchain and dynamic graphs to ensure audit traceability and anomaly detection, and finally constructs a strategy self-evolution closed loop to effectively solve the authority mismatch and data leakage problems caused by inconsistent role semantics.

Description

Technical Field

[0001] The present invention relates to the technical field of salary data management, and in particular to a dynamic rights management system and method based on multi-source salary data integration. Background Art

[0002] A dynamic permissions management system based on the integration of multi-source payroll data refers to an intelligent management mechanism that achieves unified management of payroll information throughout the entire process by centrally collecting, standardizing, and storing payroll data from multiple channels, including human resources, finance, and internal departments. It also dynamically configures access and operational permissions based on user functions, job levels, and data sensitivity levels. This system not only breaks down payroll data silos and improves data accuracy and timeliness, but also ensures data security and compliance through hierarchical authorization and process traceability, avoiding information leakage and management control issues caused by confusion over permissions in traditional manual operations. At the same time, the system supports rapid adaptation to policy adjustments and automatically and synchronously updates relevant permission configurations, making payroll management more efficient, standardized, and intelligent.

[0003] The existing technology has the following deficiencies:

[0004] In the process of executing cross-system role mapping, the existing multi-source salary data integration technology lacks a unified and standardized definition of the permission levels of roles with the same name in various business systems. As a result, when permission conflicts occur in the role mapping stage, the management system is unable to dynamically parse and identify the differences in role semantics. Instead, it often defaults to using a role configuration with a higher permission level as the mapping result, causing low-level users who originally only have observation permissions to be abnormally granted role permissions with high-level operation capabilities such as salary approval and sensitive data export, which in turn leads to a series of serious security risks such as out-of-bounds access, cross-departmental salary data leakage, abnormal budget overdrafts, and hidden salary increases for key personnel.

[0005] The above information disclosed in this Background section is only for enhancement of understanding of the background of the invention and therefore it may contain information that does not form the prior art that is already known to a person of ordinary skill in the art. Summary of the Invention

[0006] The purpose of the present invention is to provide a dynamic permission management system and method based on the integration of multi-source salary data. By introducing a role semantic ontology and a similarity scoring mechanism, accurate identification of cross-system role permission differences can be achieved, avoiding the problem of misgranting high permissions due to inconsistent role semantics; combining a rule engine with reinforcement learning to construct a minimum authorization arbitration mechanism to ensure business integrity while minimizing permission configuration; and writing permission execution and behavior trajectories into a blockchain audit ledger, combining dynamic graph analysis to achieve abnormal behavior identification and risk response; finally, through permission freezing and audit data-driven model adaptive optimization, an intelligent permission governance system with closed-loop evolution capabilities is formed, comprehensively improving the security and compliance of the system, so as to solve the problems in the above-mentioned background technology.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a dynamic rights management method based on the integration of multi-source salary data, comprising the following steps:

[0008] S101. Collect role names, permission boundaries, and operation granularity information from multiple business systems, and generate structured role semantic ontology entries based on field-level semantic annotation to provide a standardized semantic weight reference benchmark.

[0009] S102: After receiving the role mapping request, the role to be mapped is decomposed according to the permission dimension, and based on the role semantic ontology library, the semantic similarity index between the role to be mapped and the standard role is calculated to output the role consistency score matrix;

[0010] S103. Based on the role consistency scoring matrix, identify role pairs with the same name but semantic similarity below a set threshold, and generate a structured analysis report including role conflict descriptions and permission difference details;

[0011] S104: Input the role conflict description and permission difference details into the minimum authorization decision unit constructed based on the rule engine and reinforcement learning fusion strategy, output the minimum authorization permission set that meets the functional integrity constraint, and generate a permission decision record with traceability attributes;

[0012] S105. Based on the permission decision record, a cross-system permission activation control list is constructed, and the permission activation control list is distributed to each business system node in a signature authentication manner, so that each node activates or revokes the corresponding permission item by item according to the control list;

[0013] S106. During the permission change process, each permission adjustment record is written into an unalterable blockchain audit ledger. At the same time, a dynamic graph differential analysis is performed on the call path, access objects, and historical permission usage baseline of the activated permission during the operation cycle to detect and respond to abnormal call behavior.

[0014] S107. Collect permission freeze events, permission rollback records, and audit log data to drive the adaptive optimization and evolution of the role semantic model and the minimum authorization decision policy model, forming a closed loop of permission configuration based on security and the principle of minimum authorization.

[0015] Preferably, the steps of generating structured role semantic ontology entries include:

[0016] Extract user role data from various business systems based on a unified access protocol. This data includes the role ID, the business system ID, the accessible functional unit ID, and the operation type ID for each function. This user role data is mapped to a predefined semantic extraction template to complete the initial structural organization of role names and permission boundary information.

[0017] A field-level semantic annotation engine is used to semantically classify and label key fields in each structured role record. Semantic classification includes access level, data object type, operation intensity level, and time constraint range. The annotation results are stored in the intermediate semantic database as triples, and each semantic label is assigned a numerical weight.

[0018] Based on the triple semantic labels and their weight values, the semantic term normalization process is performed. The role entries with similar semantic structures are aggregated into unified role semantic terms through the clustering algorithm. At the same time, a semantic association network between roles is constructed. Finally, a role semantic ontology library with unified structure, semantic computability and scalability is generated, which serves as the standard benchmark for subsequent role semantic matching.

[0019] Preferably, the semantic similarity index between the role to be mapped and the standard role is calculated, and a role consistency score matrix is ​​output. The specific steps include:

[0020] Extract the permission description information of the role to be mapped, including four permission dimensions: operation type, data object scope, permission level, and available time period. Then perform standardized parsing based on the field template to form a permission description vector composed of permission dimensions.

[0021] Retrieve the set of standard role semantic vectors corresponding to the business scenarios of the roles to be mapped from the role semantic ontology library, and construct a standard role feature matrix based on the same dimension fields to ensure that the vector structure remains consistent during the comparison process;

[0022] A multi-dimensional semantic weighted cosine similarity algorithm is used to calculate the semantic similarity between the role vector to be mapped and the standard role semantic vector one by one. The weight of each dimension is assigned according to the semantic sensitivity level defined in the semantic ontology library to reflect the importance of different permission dimensions to the overall semantic matching.

[0023] All calculation results are summarized to generate a role consistency scoring matrix. The matrix uses the role to be mapped as the row coordinate and the standard role as the column coordinate. Each matrix element represents the degree of structural similarity between the two roles at the semantic level, providing quantitative support for subsequent role mapping conflict identification and minimum authorization determination.

[0024] Preferably, the steps of identifying role pairs with the same name but a semantic similarity below a set threshold and generating a structured parsing report including a description of the role conflict and details of the authority differences include:

[0025] Traverse the role consistency score matrix and filter out all role pairs whose role names are exactly the same and whose corresponding semantic similarity values ​​are lower than the set threshold. Mark these role pairs as conflicting role pairs and create a corresponding index table.

[0026] For each conflicting role pair, the role semantic ontology library is called to extract the corresponding permission vector. The permission dimension fields are compared one by one, including differences in operation type, data object boundary, access level, and time limit, and a permission difference vector is constructed.

[0027] Generate a structured role conflict description document based on the extracted permission difference vector. This document is output in a standard template format and includes role identification, business system, semantic similarity score, conflict dimension classification, difference comparison of each permission, and security impact analysis.

[0028] The role conflict description document and the permission difference vector are encapsulated together as a structured analysis report, assigned a unique identification number, and stored in the role conflict report database for subsequent minimum authorization decision and permission audit process calls, and support retrieval and classification management by role dimension, system dimension or conflict level.

[0029] Preferably, the role conflict description and the permission difference details are input into the minimum authorization decision unit constructed based on the rule engine and reinforcement learning fusion strategy to output the minimum authorization permission set. The specific steps include:

[0030] The role conflict description and permission difference details are broken down into multiple groups of permission decision factors by field. The permission decision factors are labeled with multiple permission characteristics, including at least permission category, permission sensitivity level, upstream and downstream dependencies, and historical authorization paths. Based on the permission decision factors, a unified format permission decision state vector is constructed to drive the input calculation process of the minimum authorization decision model.

[0031] The integrated rule engine mechanism is called to perform preliminary filtering and screening of the input state vector according to the preset permission authorization rule set, eliminating permission combinations that have serious security conflicts or logical incompleteness, ensuring that the subsequent learning process only performs adjudication operations within the legal solution space;

[0032] Launch a reinforcement learning strategy model, using functional integrity as the reward function and permission convergence as the penalty factor. Dynamically adjust the minimum authorization combination during multiple rounds of iterations to output the minimum permission set required to cover core business functions. Simultaneously record the strategy path and behavior weight change trajectory.

[0033] The output minimum authorized permission set is packaged with the corresponding decision path, usage state vector and rule hit information to generate a standard permission decision record. The record is attached with a timestamp, conflict number and call traceability identifier, and written into the permission decision log database to provide a verifiable basis for subsequent permission activation, rollback, audit and policy evolution.

[0034] Preferably, the integrated rule engine mechanism is called to perform a preliminary filtering and screening of the input state vector according to a preset permission authorization rule set, specifically including the following steps:

[0035] Extract permission fields from permission difference details and role conflict descriptions, and map them to standard permission state vectors according to preset permission templates. The standard permission state vectors include multiple dimensions such as operation type, data scope, cross-role path, and historical conflict frequency, which are used to build a complete permission determination input structure.

[0036] The standard permission state vector is input into the integrated rule engine, which calls the embedded permission authorization rule set to perform rule matching operations. The rule set includes rules for mutually exclusive permissions, permission boundary verification, functional dependency integrity, and cross-system conflict restriction. The input vector is evaluated both semantically and structurally.

[0037] Automatically mark and remove permission combinations that match mutually exclusive permission rules or have logical incompleteness. The removal reason, rule number, conflicting fields, and recommended alternative paths are written into the removal record buffer to ensure that all high-risk or non-compliant permissions are filtered out before entering the adjudication model.

[0038] All state vectors that have passed rule verification, have complete structures, and whose permission logic complies with business continuity are output as a set of pre-determination candidate permissions, and are accompanied by a complete rule verification report. This serves as the compliance input baseline for the subsequent reinforcement learning model to perform minimum authorization decisions, ensuring the security and rationality of the permission decision logic from the source.

[0039] Preferably, the permission activation control list is distributed to each business system node in a signature authentication manner, so that each node activates or reclaims the corresponding permissions item by item according to the control list. The specific implementation steps are as follows:

[0040] Extract the generated minimum authorized permission set from the permission adjudication record, and associate multiple sets of parameters such as the role ID, system node ID, permission type, effective period, and rollback version number of each permission, and assemble them into a standardized format of permission control items. Summarize them one by one to form a cross-system permission activation control list;

[0041] Perform signature authentication on the constructed permission activation control list, generate an integrity verification signature based on an asymmetric encryption algorithm, and embed the decision source identifier, decision timestamp, and permission version hash value to ensure the authenticity and non-tamperability of the control list during distribution;

[0042] Distribute the permission activation control list that has completed signature authentication to each target business system node, using an asynchronous multi-channel push mechanism or blockchain node broadcast mechanism to ensure that all receiving nodes receive complete control instructions and verify the instruction structure and signature legitimacy;

[0043] After completing the control list verification and signing, each business system node will execute the permission activation or permission recovery operations item by item according to the permission operation instructions listed in the control list. At the same time, the execution results, operation feedback codes and system processing logs will be returned to the permission management main control unit, and simultaneously written into the audit log storage system to form a complete closed-loop record of permission issuance and execution.

[0044] Preferably, during the permission change process, the permission adjustment record is written into an unalterable blockchain audit ledger, and dynamic graph differential analysis is performed on the activated permissions to detect abnormal call behavior. The specific steps include:

[0045] After each permission activation or permission revocation operation is completed, a permission change record containing the permission adjustment type, adjustment object identifier, operation initiation node, permission field content, effective timestamp and signature verification information is automatically generated, and the record is packaged into chain structure transaction data;

[0046] The multi-node consensus mechanism is used to write the permission change transaction data into the blockchain audit ledger. The ledger adopts an unalterable data structure and generates blocks in chronological order, so that each permission change has a verifiable full-link historical tracking capability.

[0047] Based on the activated permission set, a dynamic graph node is constructed, and the permission call behavior is mapped to the edge relationship in the graph structure. At the same time, the historical permission usage frequency, object interaction path and role behavior template are constructed as a reference baseline graph for subsequent behavior differential judgment;

[0048] Perform graph structure differential analysis on the real-time call graph and the reference baseline graph regularly or according to trigger events. If graph patterns that do not conform to baseline characteristics, such as abnormal access paths, cross-domain data operations, and permission jump calls, are identified between nodes, an alarm mechanism will be triggered and high-risk permission behavior nodes will be marked for use in the linkage response of permission freezing and audit mechanisms.

[0049] Preferably, the steps of driving the adaptive optimization evolution of the role semantic model and the minimum authorization adjudication policy model include:

[0050] Regularly extract data on permission freeze events from the permission management unit, including the abnormal behavior pattern that triggered the freeze, the freeze time point, the frozen permission field, the call context, and historical permission trajectory data. This data is then uniformly numbered and structured along with permission rollback records and complete audit logs.

[0051] Based on the collated dataset, the role semantic model training unit is invoked. It leverages abnormal access behavior during freeze events and changes in permission structures before and after rollbacks to automatically annotate semantic conflict points and semantically ambiguous boundaries. This optimizes the semantic boundary divisions of the original role labels and retrains the semantic similarity scoring function, enabling the model to more accurately identify high-risk semantic mappings.

[0052] Compare freezing records with the actual execution results of minimum authorizations, apply policy penalty factors to combinations of permissions that are mistakenly granted or frozen multiple times, and adjust the reward function and policy path probability distribution in the reinforcement learning model to optimize its sensitivity to and avoidance of redundant permissions in the next round of adjudication.

[0053] The optimized role semantic model parameters and minimum authorization decision policy parameters are synchronously published to the permission decision main control unit, and the update log and change version information are recorded to form a permission configuration policy closed loop with adaptive evolution capabilities, realizing the dynamic evolution and continuous optimization of the permission management system based on security and minimum authorization principles.

[0054] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0055] By introducing a role semantic ontology and a semantic similarity scoring mechanism, the present invention effectively breaks through the limitations of traditional static mapping that relies on role names, achieves accurate identification of deep-seated permission differences between different roles, and avoids the risk of misgranting high permissions due to semantic deviations; at the same time, the minimum authorization adjudication mechanism constructed by integrating a rule engine and reinforcement learning can achieve minimal control of permission configuration while ensuring the integrity of business functions; in addition, the permission execution process and behavior trajectory are written into an unalterable blockchain audit ledger, and combined with dynamic graph analysis technology to identify permission call anomalies, the entire process of permission management is traceable and automated risk response is achieved; finally, through the continuous collection and analysis of permission freezing records, permission rollback operations, and audit log data, the adaptive optimization and evolution of the role semantic model and the authorization policy model are driven, forming a policy closed-loop governance mechanism oriented towards security and minimum authorization goals, fundamentally solving key security issues such as permission mismatch, unauthorized access, and data leakage caused by inconsistent role semantics in the existing system. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction to the drawings required for use in the embodiments will be given below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0057] Figure 1 This is a flow chart of the method for dynamic rights management based on multi-source salary data integration of the present invention.

[0058] Figure 2 This is a module diagram of the dynamic rights management system based on the integration of multi-source salary data of the present invention. DETAILED DESCRIPTION

[0059] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these example embodiments are provided so that the description of the present invention will be thorough and complete and will fully convey the concepts of the example embodiments to those skilled in the art.

[0060] The present invention provides Figure 1 The dynamic rights management method based on multi-source salary data integration shown includes the following steps:

[0061] S101. Collect role names, permission boundaries, and operation granularity information from multiple business systems, and generate structured role semantic ontology entries based on field-level semantic annotation to provide a standardized semantic weight reference benchmark.

[0062] Generate structured role semantic ontology entries. The specific steps include:

[0063] Extract user role data from various business systems based on a unified access protocol. This data includes the role ID, the business system ID, the accessible functional unit ID, and the operation type ID for each function. This user role data is mapped to a predefined semantic extraction template to complete the initial structural organization of role names and permission boundary information.

[0064] A field-level semantic annotation engine is used to semantically classify and label key fields in each structured role record. Semantic classification includes access level, data object type, operation intensity level, and time constraint range. The annotation results are stored in the intermediate semantic database as triples, and each semantic label is assigned a numerical weight.

[0065] Based on the triple semantic labels and their weight values, the semantic term normalization process is performed. The role entries with similar semantic structures are aggregated into unified role semantic terms through the clustering algorithm. At the same time, a semantic association network between roles is constructed. Finally, a role semantic ontology library with unified structure, semantic computability and scalability is generated, which serves as the standard benchmark for subsequent role semantic matching.

[0066] The annotation results are stored in the intermediate semantic database in the form of triples, and each semantic label is assigned a numerical weight, which means:

[0067] After field-level semantic annotation of role permission data, the multi-source payroll data integration system stores the semantic content of each field as a "triplet." This structure structures each semantic tag into a "subject-verb-object" or "object-attribute-attribute-value" format. Each semantic tag is also assigned a specific numerical weight. This weight represents the importance of the semantic tag in subsequent semantic calculations. For example, a tag representing "approval" permission has a higher weight in permission sensitivity than a tag representing "read-only" permission, and thus has a greater impact in semantic similarity calculations.

[0068] For example, if role "A" in a business system has the permission to "view basic employee information", after semantic annotation, it will be converted into the following triple form:

[0069] (Role A, Operation Type, View);

[0070] (Role A, data object, employee basic information);

[0071] (Role A, access level, read-only);

[0072] Furthermore, in each triplet, "operation type = view" might be assigned a weight of 0.2, while "operation type = approve" might be assigned a weight of 0.9. This way, when the multi-source payroll data integration system compares the semantic similarity between two roles, it can use these weighted semantic values ​​to determine whether they are logically similar or have significant differences in permission levels. This process enables comparisons between roles to move beyond mere names and into a quantitative assessment of the actual permissions they hold.

[0073] The purpose of this step is to establish a unified, standardized, and measurable semantic expression system for role information in multi-source heterogeneous business systems, thereby resolving the semantic conflict problem caused by the same role name but different permission definitions across business systems. Since different business systems are independent in role design, there are often situations where the role name is the same but the permission granularity, boundaries, and operation scope are completely different. Direct mapping can easily lead to permission abuse or omission. Therefore, it is necessary to perform semantic extraction and fine-grained annotation of key fields such as "role name", "permission boundary", and "operation granularity" to transform the originally vague and unstructured permission description information into structured semantic information that can be understood and processed by machines.

[0074] Specifically, this step decomposes the permission behavior of each role into several clear semantic labels through field-level semantic annotation, such as "Operation type: read", "Data object: salary details", "Scope of application: this department", "Permission level: medium", etc. These labels not only reveal the functional intentions of the role in actual system operations, but also provide basic information for calculating the semantic similarity between roles. Subsequently, the salary data integration system organizes these labels into structured semantic ontology entries, stores them in the semantic ontology library, and assigns a weight to each semantic label to reflect its importance in the overall permission system. Through this semantic ontology entry library, the salary data integration system can provide consistency evaluation standards and calculation basis when performing role matching and permission adjudication in the subsequent execution, ensuring that the alignment process between roles is both accurate and controllable, and providing a solid semantic support foundation for dynamic permission management.

[0075] S102: After receiving the role mapping request, the role to be mapped is decomposed according to the permission dimension, and based on the role semantic ontology library, the semantic similarity index between the role to be mapped and the standard role is calculated to output the role consistency score matrix;

[0076] Calculate the semantic similarity index between the role to be mapped and the standard role, and output the role consistency score matrix. The specific steps include:

[0077] Extract the permission description information of the role to be mapped, including four permission dimensions: operation type, data object scope, permission level, and available time period. Then perform standardized parsing based on the field template to form a permission description vector composed of permission dimensions.

[0078] Retrieve the set of standard role semantic vectors corresponding to the business scenarios of the roles to be mapped from the role semantic ontology library, and construct a standard role feature matrix based on the same dimension fields to ensure that the vector structure remains consistent during the comparison process;

[0079] A multi-dimensional semantic weighted cosine similarity algorithm is used to calculate the semantic similarity between the role vector to be mapped and the standard role semantic vector one by one. The weight of each dimension is assigned according to the semantic sensitivity level defined in the semantic ontology library to reflect the importance of different permission dimensions to the overall semantic matching.

[0080] All calculation results are summarized to generate a role consistency scoring matrix. The matrix uses the role to be mapped as the row coordinate and the standard role as the column coordinate. Each matrix element represents the degree of structural similarity between the two roles at the semantic level, providing quantitative support for subsequent role mapping conflict identification and minimum authorization determination.

[0081] Standardized parsing based on field templates means that when parsing role permission descriptions from different business systems, rather than directly processing raw free text or data with widely varying structures, a unified set of field templates is first defined. These field templates clearly define the key attribute fields that role permissions should include, such as "operation type," "data object," "permission level," "scope of use," and "time limit." After receiving the original permission information for the role to be mapped, the multi-source payroll data integration system maps and populates this information into pre-set field templates, transforming the inconsistent and non-standardized permission data into a clearly structured and consistent data format. This process ensures that subsequent semantic similarity calculations between roles can be performed on the same semantic dimension for comparison and quantitative analysis, avoiding mismatching caused by missing fields, inconsistent naming, or uneven granularity. For example, the permission "View employee information" is broken down into "Operation type: View," "Data object: Employee information," and "Permission level: Read-only" in the standardized template, ensuring semantic calculations can be performed on the same dimension as similar permissions in other systems.

[0082] To retrieve a set of standard role semantic vectors corresponding to the business scenario of the role to be mapped from a role semantic ontology, the system first predefines business scenario labels for each standard role semantic entry in the role semantic ontology, such as "personnel management," "payroll accounting," "performance evaluation," and "financial approval." These labels are then stored as index fields in the ontology database. When the payroll data integration system receives a role to be mapped, it first analyzes the system identifier, module affiliation, and role usage context associated with the role to determine its business scenario category. Subsequently, the ontology database retrieves all standard role semantic vectors matching the scenario using the business scenario labels. These vectors are composed of multiple semantic dimension fields, such as "operation type," "data object," and "authority level." After semantic labeling and weighting, they can be used to calculate semantic similarity with the role to be mapped. This semantic vector screening mechanism based on business scenario labels significantly improves the contextual relevance and semantic accuracy of role matching, avoiding permission configuration errors caused by cross-scenario mismatches.

[0083] The purpose of this step is to provide a semantically precise matching mechanism for the multi-source payroll data integration system when processing role permission mapping, so as to solve the permission mismatch, unauthorized access and data security risk problems caused by the inconsistent role permission definition standards in different business systems. In a multi-business system environment, even if the role name is the same, the permission meaning, operation scope and sensitivity level may be completely different. Traditional role mapping methods based on names or static templates are often unable to identify these semantic differences, resulting in problems such as high permission defaults, permission drift or missing functions during permission integration. Therefore, it is necessary to disassemble the role to be mapped from the perspective of permission semantics and conduct a detailed comparison with the standard role semantic system.

[0084] By breaking down the roles to be mapped according to the permission dimension, the system can obtain a structured permission vector containing multiple semantic elements such as "operation type: approval", "data object: performance data", and "permission level: medium". These elements are then used to calculate semantic similarity with the standard role semantic vectors defined in the role semantic ontology library, such as using weighted cosine similarity, multi-dimensional label overlap, and other methods to determine the degree of semantic similarity between each pair of roles. The final output is a role consistency scoring matrix, which quantitatively displays the matching degree between the role to be mapped and all standard roles in the semantic dimension. This role consistency scoring matrix not only provides basic data support for subsequent role conflict identification, minimum authorization adjudication, and other links, but also visually reveals the differences between permissions, thereby avoiding permission abuse due to semantic misjudgment and ensuring the accuracy, security, and controllability of the cross-system permission integration process.

[0085] S103. Based on the role consistency scoring matrix, identify role pairs with the same name but semantic similarity below a set threshold, and generate a structured analysis report including role conflict descriptions and permission difference details;

[0086] The steps for identifying role pairs with the same name but semantic similarity below a set threshold and generating a structured parsing report containing role conflict descriptions and permission difference details include:

[0087] Traverse the role consistency score matrix and filter out all role pairs whose role names are exactly the same and whose corresponding semantic similarity values ​​are lower than the set threshold. Mark these role pairs as conflicting role pairs and create a corresponding index table.

[0088] For each conflicting role pair, the role semantic ontology library is called to extract the corresponding permission vector. The permission dimension fields are compared one by one, including differences in operation type, data object boundary, access level, and time limit, and a permission difference vector is constructed.

[0089] Generate a structured role conflict description document based on the extracted permission difference vector. This document is output in a standard template format and includes role identification, business system, semantic similarity score, conflict dimension classification, difference comparison of each permission, and security impact analysis.

[0090] The role conflict description document and the permission difference vector are encapsulated together as a structured analysis report, assigned a unique identification number, and stored in the role conflict report database for subsequent minimum authorization decision and permission audit process calls, and support retrieval and classification management by role dimension, system dimension or conflict level.

[0091] The purpose of this step is to identify role conflict risk points with high name overlap but different permission semantics during the multi-source payroll data integration process, and to clearly reveal the substantial differences in permission content between roles in a structured manner, thereby providing accurate and actionable data basis for subsequent permission determination and security control. In actual applications, different business systems often have the same role names but different permission meanings. For example, a "payroll manager" only has data viewing permissions in the personnel system, but may have salary adjustment and export permissions in the financial system. This consistency in role names can easily mislead the permission merging logic, causing the system to default to executing permission upward merging, resulting in users with limited permissions being abnormally promoted to higher-privilege roles, leading to serious consequences such as unauthorized access, data leakage, and budget abuse. Therefore, it is necessary to identify these role pairs with the same names but inconsistent semantics through a scoring matrix.

[0092] In this step, the system first uses the role consistency scoring matrix to filter out all role combinations with semantic similarity below the preset threshold, and verifies whether their names are consistent. Once the conditions are met, they are determined to be conflicting role pairs. Subsequently, based on the role semantic ontology library, the conflicting roles are analyzed item by item in terms of operation type, data range, permission level, functional module and other dimensions, and a structured parsing report is generated. This report not only lists in detail the field content and strength difference of each permission difference, but also comes with a semantic scoring basis and conflict classification description, thereby providing standard input for subsequent minimum authorization calculations, and providing a clear and transparent reference for auditors to identify system permission mismatch problems. This mechanism plays a bridging role in dynamic permission management, effectively improving the accuracy of permission configuration and the controllability of security boundaries.

[0093] S104: Input the role conflict description and permission difference details into the minimum authorization decision unit constructed based on the rule engine and reinforcement learning fusion strategy, output the minimum authorization permission set that meets the functional integrity constraint, and generate a permission decision record with traceability attributes;

[0094] Input the role conflict description and permission difference details into the minimum authorization decision unit built based on the rule engine and reinforcement learning fusion strategy to output the minimum authorization permission set. The specific steps include:

[0095] The role conflict description and permission difference details are broken down into multiple groups of permission decision factors by field. The permission decision factors are labeled with multiple permission characteristics, including at least permission category, permission sensitivity level, upstream and downstream dependencies, and historical authorization paths. Based on the permission decision factors, a unified format permission decision state vector is constructed to drive the input calculation process of the minimum authorization decision model.

[0096] The integrated rule engine mechanism is called to perform preliminary filtering and screening of the input state vector according to the preset permission authorization rule set, eliminating permission combinations that have serious security conflicts or logical incompleteness, ensuring that the subsequent learning process only performs adjudication operations within the legal solution space;

[0097] Launch a reinforcement learning strategy model, using functional integrity as the reward function and permission convergence as the penalty factor. Dynamically adjust the minimum authorization combination during multiple rounds of iterations to output the minimum permission set required to cover core business functions. Simultaneously record the strategy path and behavior weight change trajectory.

[0098] The output minimum authorized permission set is packaged with the corresponding decision path, usage state vector and rule hit information to generate a standard permission decision record. The record is attached with a timestamp, conflict number and call traceability identifier, and written into the permission decision log database to provide a verifiable basis for subsequent permission activation, rollback, audit and policy evolution.

[0099] Call the integrated rule engine mechanism to perform preliminary filtering and screening on the input state vector according to the preset permission authorization rule set. The specific steps include:

[0100] Extract permission fields from permission difference details and role conflict descriptions, and map them to standard permission state vectors according to preset permission templates. The standard permission state vectors include multiple dimensions such as operation type, data scope, cross-role path, and historical conflict frequency, which are used to build a complete permission determination input structure.

[0101] The standard permission state vector is input into the integrated rule engine, which calls the embedded permission authorization rule set to perform rule matching operations. The rule set includes rules for mutually exclusive permissions, permission boundary verification, functional dependency integrity, and cross-system conflict restriction. The input vector is evaluated both semantically and structurally.

[0102] Automatically mark and remove permission combinations that match mutually exclusive permission rules or have logical incompleteness. The removal reason, rule number, conflicting fields, and recommended alternative paths are written into the removal record buffer to ensure that all high-risk or non-compliant permissions are filtered out before entering the adjudication model.

[0103] All state vectors that have passed rule verification, have complete structures, and whose permission logic complies with business continuity are output as a set of pre-determination candidate permissions, and are accompanied by a complete rule verification report. This serves as the compliance input baseline for the subsequent reinforcement learning model to perform minimum authorization decisions, ensuring the security and rationality of the permission decision logic from the source.

[0104] Taking functional integrity as the reward function and authority convergence as the penalty factor means:

[0105] In the reinforcement learning model, by defining "reward" and "penalty" mechanisms, the model is guided to learn an optimal permission combination strategy in the iterative process that can satisfy the integrity of business functions without generating redundant permissions. Among them, "functional integrity" is the reward function, which means that when the currently generated permission set can fully support all the key functions that the target business role needs to perform, the system will give the model a positive incentive to encourage it to retain these functional permissions. And "permission convergence" is the penalty factor, which means that when the model attempts to introduce redundant permissions, duplicate permissions, or non-essential highly sensitive permissions, negative feedback is applied based on the degree of deviation from the permission minimization goal to suppress unnecessary authorization expansion. This design ensures that the model will not blindly pursue the minimum authorization during training and undermine functional integrity, nor will it lose sensitive permission control due to conservative authorization, thereby achieving a dynamic balance between "business integrity" and "minimum authorization."

[0106] The purpose of this step is to automate and refine the adjudication of cross-system permission conflicts through an intelligent decision-making mechanism that integrates the rule engine and reinforcement learning strategy, and to generate a final permission set that not only meets the requirements of business function integrity but also strictly follows the principle of least authorization, thereby achieving dynamic balance, security control and traceable auditing in the permission configuration process. Traditional permission configuration methods rely heavily on manual experience to set fixed authorization templates, which cannot cope with complex role conflicts, inconsistent permission boundaries, large granularity differences and other issues in multi-source systems. Although a single rule engine mechanism can achieve static judgment, it lacks the ability to dynamically optimize in complex decision spaces. To this end, this step introduces a reinforcement learning algorithm and works together with the rule engine to enable the system to continuously learn and evolve based on historical permission decision data, achieving more accurate and flexible permission judgments.

[0107] Specifically, the role conflict description and permission difference details are first extracted into a state vector, which is used as input and submitted to the integrated rule engine unit for preliminary screening to eliminate obvious conflicts or logically incomplete permission combinations, ensuring that the data processed subsequently has business compliance. On this basis, the reinforcement learning model uses functional completeness as the reward function, that is, when the selected permission combination can cover all necessary business operations of the conflicting roles, positive feedback is given; at the same time, the permission convergence degree is used as the penalty factor. When the permission set generated by the model is redundant, highly sensitive, or out of range, the system will impose a negative penalty. This reward-penalty mechanism prompts the model to continuously adjust the policy path in multiple rounds of iteration, and ultimately outputs a streamlined, comprehensive, and risk-minimized permission set.

[0108] At the same time, the input status, rule hit information, policy path, decision results, and semantic interpretations during each decision-making process are encapsulated into permission decision records with timestamps and identity tags and written to the permission log database. These records not only provide a reliable basis for subsequent permission activation, rollback, and tracing, but also serve as the core data source for subsequent permission strategy evolution and model training, supporting the system's implementation of a closed-loop optimization mechanism of "authorization-verification-feedback-evolution." This step serves as the core intelligent decision-making engine in dynamic permission management and is a key link in achieving refined security governance and compliance control capabilities.

[0109] S105. Based on the permission decision record, a cross-system permission activation control list is constructed, and the permission activation control list is distributed to each business system node in a signature authentication manner, so that each node activates or revokes the corresponding permission item by item according to the control list;

[0110] The permission activation control list is distributed to each business system node in a signature authentication manner, so that each node can activate or revoke the corresponding permissions item by item according to the control list. The specific implementation steps are as follows:

[0111] Extract the generated minimum authorized permission set from the permission adjudication record, and associate multiple sets of parameters such as the role ID, system node ID, permission type, effective period, and rollback version number of each permission, and assemble them into a standardized format of permission control items. Summarize them one by one to form a cross-system permission activation control list;

[0112] Perform signature authentication on the constructed permission activation control list, generate an integrity verification signature based on an asymmetric encryption algorithm, and embed the decision source identifier, decision timestamp, and permission version hash value to ensure the authenticity and non-tamperability of the control list during distribution;

[0113] Distribute the permission activation control list that has completed signature authentication to each target business system node, using an asynchronous multi-channel push mechanism or blockchain node broadcast mechanism to ensure that all receiving nodes receive complete control instructions and verify the instruction structure and signature legitimacy;

[0114] After completing the control list verification and signing, each business system node will execute the permission activation or permission recovery operations item by item according to the permission operation instructions listed in the control list. At the same time, the execution results, operation feedback codes and system processing logs will be returned to the permission management main control unit, and simultaneously written into the audit log storage system to form a complete closed-loop record of permission issuance and execution.

[0115] The purpose of this step is to convert the minimum authorization permission result generated in the previous step into standardized control instructions with cross-system execution capabilities according to implementation requirements, and to ensure its credibility, integrity and non-tamperability during the distribution and execution process through an encrypted signature mechanism, and ultimately to achieve accurate activation or recovery of user permissions in multiple business systems, thereby forming a closed-loop, traceable dynamic permission control chain. In the multi-source payroll data integration scenario, multiple business systems are often involved, such as human resources management systems, financial systems, performance systems, etc. Each system has differences in permission models, role definitions and interface protocols. Without a unified permission control list mechanism, each system will not be able to accurately understand and execute the permission adjudication results, which may cause problems such as inconsistent authorization, delayed effectiveness of permissions or untimely recovery of permissions, which in turn lead to data security risks and compliance risks.

[0116] Therefore, in this step, a structured, standardized "cross-system permission activation control list" is first constructed based on the minimum set of authorized permissions identified in the permission decision record, combined with metadata such as user identity, system node, permission operation type, effective period, and permission version. This list serves as the sole authoritative instruction carrier for each business system to execute permission operations. To ensure that it is not forged, modified, or intercepted during network distribution and node execution, the system digitally signs and authenticates the control list, using asymmetric encryption to generate a tamper-proof signature. It also appends a permission decision source identifier and operation timestamp to establish a complete data trust chain.

[0117] Once signed, the system distributes the control list to each target business system node via a secure channel or blockchain node network. Upon receiving the control list, each node must first verify the signature to ensure the source is legitimate and the instructions have not been tampered with. It then executes permission activation or revocation operations item by item based on the list's contents. All execution results are fed back to the permission management master control unit in real time and recorded in the audit system, forming a complete permission operation log that can be used for tracking, comparison, and rollback. This step is a critical bridge from permission determination to actual control implementation, ensuring that the entire system permission change process is completed accurately, securely, and consistently across multiple systems.

[0118] S106. During the permission change process, each permission adjustment record is written into an unalterable blockchain audit ledger. At the same time, a dynamic graph differential analysis is performed on the call path, access objects, and historical permission usage baseline of the activated permission during the operation cycle to detect and respond to abnormal call behavior.

[0119] During the permission change process, the permission adjustment record is written into the tamper-proof blockchain audit ledger, and dynamic graph differential analysis is performed on the activated permissions to detect abnormal call behavior. The specific steps include:

[0120] After each permission activation or permission revocation operation is completed, a permission change record containing the permission adjustment type, adjustment object identifier, operation initiation node, permission field content, effective timestamp and signature verification information is automatically generated, and the record is packaged into chain structure transaction data;

[0121] The multi-node consensus mechanism is used to write the permission change transaction data into the blockchain audit ledger. The ledger adopts an unalterable data structure and generates blocks in chronological order, so that each permission change has a verifiable full-link historical tracking capability.

[0122] Based on the activated permission set, a dynamic graph node is constructed, and the permission call behavior is mapped to the edge relationship in the graph structure. At the same time, the historical permission usage frequency, object interaction path and role behavior template are constructed as a reference baseline graph for subsequent behavior differential judgment;

[0123] Perform graph structure differential analysis on the real-time call graph and the reference baseline graph regularly or according to trigger events. If graph patterns that do not conform to baseline characteristics, such as abnormal access paths, cross-domain data operations, and permission jump calls, are identified between nodes, an alarm mechanism will be triggered and high-risk permission behavior nodes will be marked for use in the linkage response of permission freezing and audit mechanisms.

[0124] The purpose of this step is to achieve transparent recording of the entire process of permission changes in the multi-source payroll data integration system, real-time detection of abnormal behavior, and risk response control by combining the blockchain's tamper-proof audit mechanism with dynamic graph differential analysis technology, ensuring that cross-system permission management is not only executable, but also verifiable, traceable, and dynamically secure. In an environment where permissions are dynamically changing, role permissions are often adjusted frequently due to job adjustments, policy updates, or changes in data sensitivity levels. If such changes lack a unified audit mechanism and behavioral baseline comparison, it will easily lead to problems such as permission drift, unauthorized access, implicit privilege escalation, and data abuse. Traditional log systems are difficult to meet compliance and accountability requirements because data is easily tampered with and call paths are difficult to restore. Therefore, strong auditing and dynamic behavior modeling mechanisms must be introduced.

[0125] In this step, after each permission activation or revocation operation, a structured permission adjustment record is automatically generated. This record includes the operation type, permission field, initiating system, role ID, operation time, version number, and digital signature. These change records are then written to the blockchain audit ledger through a multi-node consensus mechanism. Due to the blockchain's immutability, full-chain tracking, and node consensus mechanism, this ledger can serve as a system-level audit backbone, providing solid evidence for future permission disputes, accountability, and regulatory review.

[0126] At the same time, continuous behavioral modeling is performed on the permission usage process after activation. By constructing a "dynamic graph of permission calls", each actual permission call is mapped to a node and edge structure in the graph, and combined with the access object, operation method and time series, a dynamic graph model that reflects the actual permission call path is formed. This model performs periodic or real-time differential analysis with the historical permission usage baseline graph (that is, the permission call graph under normal behavior) to identify whether there are suspicious behaviors such as unauthorized paths, abnormal access combinations, sudden changes in permission call density, or data access jumps. Once a graph structure feature that deviates from the behavioral baseline is found, the system will automatically trigger a risk alert and include the corresponding role permissions in the freezing assessment process to prevent the expansion of potential security incidents. Through this mechanism, the system not only achieves a trusted audit of the permission execution process, but also builds a dynamically responsive security line of defense, providing strong compliance protection and behavior monitoring capabilities for the cross-system governance of salary data.

[0127] S107. Collect permission freeze events, permission rollback records, and audit log data to drive the adaptive optimization and evolution of the role semantic model and the minimum authorization decision policy model, forming a closed loop of permission configuration based on security and the principle of minimum authorization;

[0128] The steps to drive the adaptive optimization and evolution of the role semantic model and the minimum authorization adjudication policy model include:

[0129] Regularly extract data on permission freeze events from the permission management unit, including the abnormal behavior pattern that triggered the freeze, the freeze time point, the frozen permission field, the call context, and historical permission trajectory data. This data is then uniformly numbered and structured along with permission rollback records and complete audit logs.

[0130] Based on the collated dataset, the role semantic model training unit is invoked. It leverages abnormal access behavior during freeze events and changes in permission structures before and after rollbacks to automatically annotate semantic conflict points and semantically ambiguous boundaries. This optimizes the semantic boundary divisions of the original role labels and retrains the semantic similarity scoring function, enabling the model to more accurately identify high-risk semantic mappings.

[0131] Compare freezing records with the actual execution results of minimum authorizations, apply policy penalty factors to combinations of permissions that are mistakenly granted or frozen multiple times, and adjust the reward function and policy path probability distribution in the reinforcement learning model to optimize its sensitivity to and avoidance of redundant permissions in the next round of adjudication.

[0132] The optimized role semantic model parameters and minimum authorization decision policy parameters are synchronously published to the permission decision main control unit, and the update log and change version information are recorded to form a permission configuration policy closed loop with adaptive evolution capabilities, realizing the dynamic evolution and continuous optimization of the permission management system based on security and minimum authorization principles.

[0133] The purpose of this step is to build a data-driven policy self-evolution mechanism by continuously collecting and analyzing permission anomaly data during system operation, including permission freeze events, permission rollback records, and audit log data. This allows for dynamic optimization of the role semantic model and the minimum authorization adjudication policy model, thereby enabling the permission management system to self-adjust, self-optimize, and continuously evolve in actual applications, ultimately forming a closed-loop permission configuration system with "security first" and "minimum authorization" as its core goals. In a multi-source payroll data integration environment, permission configuration is not only complex but also changes frequently. Traditional static policy models often fail to cover all scenarios and role boundaries, easily leading to insufficient or excessive authorization. Therefore, it is necessary to leverage the actual permission usage data and exception handling feedback generated during system operation to feed back into the original model and drive its adaptive upgrade.

[0134] This mechanism first monitors permission freeze events in real time, including information such as the access behavior that triggered the anomaly, role identity, call path, data objects, and differences in permissions before and after the freeze. This data is then merged, numbered, and standardized with permission rollback records and complete audit logs. These high-value permission risk events are then fed into the training module of the role semantic model to adjust the boundaries of role semantic labels and improve the model's ability to identify semantically ambiguous areas. For example, by counting the fields that frequently trigger freezes for a particular role across multiple systems, the model can reassess the semantic drift risk of its original labels, thereby optimizing the calculation logic and matching algorithms for semantic similarity.

[0135] At the same time, in the minimum authorization adjudication policy model, policy penalty labels are applied to permission combinations that have been repeatedly adjudicated but rolled back or frozen. These penalties adjust their priority or reward function in the reinforcement learning policy path, prompting the model to prefer avoiding configuration paths that have been verified as high-risk in future permission combination calculations. Ultimately, the optimized role semantic model and authorization policy model are fed back to the permission adjudication engine, and the policy version is automatically updated and audited. This creates a closed-loop permission control mechanism encompassing "anomaly identification - policy reconstruction - dynamic feedback - behavior correction," significantly improving the system's security resilience, authorization accuracy, and evolutionary adaptability in complex business scenarios.

[0136] Through the above-mentioned dynamic permission management method based on the integration of multi-source salary data, semantic precision control, permission risk prevention and policy adaptive evolution are achieved in the cross-system role permission mapping process, significantly improving the security, accuracy and sustainability of permission configuration in a multi-system environment. By introducing the role semantic ontology and similarity scoring mechanism, this method breaks the traditional static mapping method based only on role name comparison, and can accurately identify the deep permission differences between roles and avoid the risk of misgranting high permissions. It combines the rule engine and reinforcement learning to build a minimum authorization adjudication mechanism to ensure that permissions are minimized without affecting the integrity of business functions. At the same time, the permission execution process and behavior trajectory are written into the blockchain audit ledger and abnormal behavior is identified based on the dynamic graph, achieving traceability and automated risk response of the entire permission behavior process. Finally, by freezing records and feeding back the audit data into the policy model, an intelligent permission governance mechanism with "policy closed-loop evolution" is constructed, which fundamentally solves the major security risks such as permission mismatch, unauthorized access and data leakage caused by inconsistent role semantics in the existing system.

[0137] The present invention provides Figure 2 The dynamic permission management system based on multi-source salary data integration shown in the figure includes a role semantic modeling module, a semantic similarity calculation module, a permission conflict identification and resolution module, a minimum authorization adjudication module, a permission activation control module, a blockchain audit and anomaly detection module, and a strategy self-evolution optimization module;

[0138] The role semantic modeling module collects role names, permission boundaries, and operation granularity information from multiple business systems and generates structured role semantic ontology entries based on field-level semantic annotation.

[0139] The semantic similarity calculation module decomposes the role to be mapped according to the permission dimension, and calculates the semantic similarity index between the role to be mapped and the standard role based on the role semantic ontology library, and outputs the role consistency score matrix;

[0140] The permission conflict identification and resolution module identifies pairs of roles with the same name but semantic similarity below a set threshold based on the role consistency scoring matrix, and generates a structured resolution report containing role conflict descriptions and permission difference details;

[0141] The minimum authorization decision module inputs the role conflict description and permission difference details into the minimum authorization decision unit built based on the rule engine and reinforcement learning fusion strategy, outputs the minimum authorization permission set, and generates a permission decision record;

[0142] The permission activation control module builds a cross-system permission activation control list based on the permission decision records, and distributes the permission activation control list to each business system node in a signature authentication manner, so that each node can activate or revoke the corresponding permissions item by item according to the control list;

[0143] The blockchain audit and anomaly detection module writes each permission adjustment record into an unalterable blockchain audit ledger during the permission change process. It also performs dynamic graph differential analysis on the permission usage baseline after activation to detect and respond to abnormal call behavior.

[0144] The policy self-evolution optimization module collects permission freezing events, permission rollback records and audit log data, drives the adaptive optimization evolution of the role semantic model and the minimum authorization decision policy model, and forms a closed loop of permission configuration based on the principles of security and minimum authorization.

[0145] The dynamic permission management method based on multi-source salary data integration provided in an embodiment of the present invention is implemented through the above-mentioned dynamic permission management system based on multi-source salary data integration. The specific methods and processes of the dynamic permission management system based on multi-source salary data integration are detailed in the above-mentioned embodiment of the dynamic permission management method based on multi-source salary data integration, which will not be repeated here.

[0146] The above description is merely illustrative of certain exemplary embodiments of the present invention. It goes without saying that those skilled in the art will be able to modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the above drawings and description are illustrative in nature and should not be construed as limiting the scope of protection of the claims.

Claims

1. A dynamic rights management method based on the integration of multi-source salary data, characterized by: The following steps are involved: S101. Collect role names, permission boundaries, and operation granularity information from multiple business systems, and generate structured role semantic ontology entries based on field-level semantic annotation. S102: Decompose the role to be mapped according to the permission dimension, and calculate the semantic similarity index between the role to be mapped and the standard role based on the role semantic ontology library, and output the role consistency score matrix; S103. Based on the role consistency scoring matrix, identify role pairs with the same name but semantic similarity below a set threshold, and generate a structured analysis report including role conflict descriptions and permission difference details; S104: Input the role conflict description and permission difference details into the minimum authorization decision unit constructed based on the rule engine and reinforcement learning fusion strategy, output the minimum authorization permission set, and generate a permission decision record; S105. Based on the permission decision record, a cross-system permission activation control list is constructed, and the permission activation control list is distributed to each business system node in a signature authentication manner, so that each node activates or revokes the corresponding permission item by item according to the control list; S106. During the permission change process, each permission adjustment record is written into the tamper-proof blockchain audit ledger. At the same time, a dynamic graph differential analysis is performed on the permission usage baseline after activation to detect and respond to abnormal call behavior. S107. Collect permission freeze events, permission rollback records, and audit log data to drive the adaptive optimization and evolution of the role semantic model and the minimum authorization decision policy model, forming a closed loop of permission configuration based on security and the principle of minimum authorization.

2. The dynamic rights management method based on multi-source salary data integration according to claim 1 is characterized in that: Generate structured role semantic ontology entries. The specific steps include: Extract user role data from various business systems and map the user role data to predefined semantic extraction templates; Perform semantic classification and labeling on the key fields in each structured role record. The labeling results are stored in the intermediate semantic database in the form of triples, and each semantic label is assigned a numerical weight. According to the triple semantic labels and their weight values, the role entries with similar semantic structures are aggregated into unified role semantic entries through clustering algorithm. At the same time, the semantic association network between roles is constructed, and finally the role semantic ontology library is generated.

3. The dynamic rights management method based on multi-source salary data integration according to claim 1 is characterized in that: Calculate the semantic similarity index between the role to be mapped and the standard role, and output the role consistency score matrix. The specific steps include: Extract the four permission dimension information of the role to be mapped, including operation type, data object scope, permission level, and available time period, and parse it into a permission description vector based on the field template standardization; Retrieve the standard role semantic vector set corresponding to the business scenario from the role semantic ontology library and build a standard role feature matrix with consistent fields. The multi-dimensional semantic weighted cosine similarity algorithm is used to calculate the semantic similarity between the character vectors, and the weight of each dimension is set according to the semantic sensitivity level; All similarity values ​​are summarized to generate a role consistency score matrix with the role to be mapped and the standard role as the coordinate axis.

4. The dynamic rights management method based on multi-source salary data integration according to claim 1 is characterized in that: The steps to identify semantically conflicting roles and generate a structured parsing report include: Traverse the role consistency score matrix, filter out role pairs with the same name but semantic similarity below the set threshold, mark them as conflicting roles and create an index; Call the role semantic ontology library to extract the conflicting role permission vectors, compare them one by one according to the permission dimension fields, and construct the permission difference vector; Generate a role conflict description document in a standard template format based on the permission difference vector; The conflict description document and the difference vector are encapsulated into a structured parsing report, assigned a unique identification number and stored in the conflict report database.

5. The dynamic rights management method based on multi-source salary data integration according to claim 1 is characterized in that: The steps of inputting the role conflict description and permission difference details into the minimum authorization decision unit and outputting the minimum authorization permission set include: Decompose role conflict descriptions and permission differences into permission decision factors and construct a permission decision state vector in a unified format; Perform a preliminary screening of the state vector through the integrated rule engine to eliminate permission combinations that have security conflicts or incomplete logic. Call the reinforcement learning policy model, use functional integrity as the reward function and permission convergence as the penalty factor, iteratively output the minimum authorized permission set, and record the policy path; The output permission set and decision information are packaged to generate a standard permission decision record, with timestamp, number and traceability identification attached, and written into the permission decision log database.

6. The dynamic rights management method based on multi-source salary data integration according to claim 5 is characterized in that: The steps of calling the integrated rule engine mechanism to perform initial filtering and screening on the input state vector include: Extract the permission fields from the permission difference details and conflict descriptions, and map them into a standard permission state vector according to the preset template; The state vector is input into the rule engine, matching mutually exclusive permission rules, boundary verification rules, functional dependency rules, and cross-system conflict rules, and performing semantic and structural judgments one by one; Mark and remove permission combinations that hit high-risk rules, and record the removal reason, number, and alternative path; Output the verified permission set and rule verification report as the compliance input baseline of the reinforcement learning adjudication model.

7. The dynamic rights management method based on multi-source salary data integration according to claim 1 is characterized in that: The steps to distribute and execute the permission activation control list in a signed and authenticated manner include: Extract the minimum authorized permission set from the permission adjudication record, associate multiple sets of parameters to build standard permission control items, and generate a cross-system permission activation control list; Perform signature authentication on the control list, embedding the decision source, timestamp and permission version hash; Distribute the signature list to each business system node through asynchronous push or blockchain broadcast mechanism, and complete the instruction structure and signature legitimacy verification; Each node activates or reclaims permissions item by item according to the list instructions, and returns the execution results and logs, which are written into the audit system to form a closed-loop record.

8. The dynamic rights management method based on multi-source salary data integration according to claim 1 is characterized in that: The steps for blockchain auditing and anomaly detection during the permission change process include: Each time a permission is activated or revoked, a permission change record is generated and packaged into chain-structured transaction data; Write change records into the blockchain audit ledger through a multi-node consensus mechanism; Build a dynamic graph based on activated permissions, map permission call behavior to a graph structure, and generate a reference graph based on historical permission usage baselines; Perform graph structure differential analysis regularly or according to trigger events to identify abnormal access paths, trigger alarm mechanisms, and mark high-risk permission behavior nodes.

9. The dynamic rights management method based on multi-source salary data integration according to claim 1 is characterized in that: The steps that drive the adaptive optimization and evolution of the role semantic model and the minimum authorization adjudication policy model include: Regularly extract permission freeze events, rollback records, and audit logs, uniformly number, and structure abnormal behavior and permission trajectory data; Use abnormal access behavior to train the role semantic model, mark semantic conflict points, optimize the role semantic boundaries and update the similarity scoring function; Imposing policy penalties on combinations of permissions that are incorrectly granted or frozen multiple times, and adjusting the reward function and path probability distribution in the reinforcement learning model; Synchronize the optimized model parameters to the arbitration master control unit, record the update log, and build a closed loop of permission configuration with continuous evolution capabilities.

10. A dynamic rights management system based on the integration of multi-source salary data, used to implement the dynamic rights management method based on the integration of multi-source salary data as described in any one of claims 1 to 9, characterized in that: It includes role semantic modeling module, semantic similarity calculation module, permission conflict identification and resolution module, minimum authorization adjudication module, permission activation control module, blockchain audit and anomaly detection module, and strategy self-evolution optimization module; The role semantic modeling module collects role names, permission boundaries, and operation granularity information from multiple business systems and generates structured role semantic ontology entries based on field-level semantic annotation. The semantic similarity calculation module decomposes the role to be mapped according to the permission dimension, and calculates the semantic similarity index between the role to be mapped and the standard role based on the role semantic ontology library, and outputs the role consistency score matrix; The permission conflict identification and resolution module identifies pairs of roles with the same name but semantic similarity below a set threshold based on the role consistency scoring matrix, and generates a structured resolution report containing role conflict descriptions and permission difference details; The minimum authorization decision module inputs the role conflict description and permission difference details into the minimum authorization decision unit built based on the rule engine and reinforcement learning fusion strategy, outputs the minimum authorization permission set, and generates a permission decision record; The permission activation control module builds a cross-system permission activation control list based on the permission decision records, and distributes the permission activation control list to each business system node in a signature authentication manner, so that each node can activate or revoke the corresponding permissions item by item according to the control list; The blockchain audit and anomaly detection module writes each permission adjustment record into an unalterable blockchain audit ledger during the permission change process. It also performs dynamic graph differential analysis on the permission usage baseline after activation to detect and respond to abnormal call behavior. The policy self-evolution optimization module collects permission freezing events, permission rollback records and audit log data, drives the adaptive optimization evolution of the role semantic model and the minimum authorization decision policy model, and forms a closed loop of permission configuration based on the principles of security and minimum authorization.

Images