A multi-element subject data collaborative governance method based on scene driving

Abstract

The application discloses a kind of multi-element subject data collaborative governance method based on scene driving, specifically related to audit data governance field, for solving field blood relationship path fracture identification and repair problem, is by running log and metadata snapshot synchronization into traceability system, form stable field label mapping mechanism, and then reconstruct field evolution logic in the form of structure diagram;By embedding two kinds of heterogeneous features of trend drift and chain break density, a multi-source correction coefficient is established that integrates structure and strength judgment, and in the subgraph isomorphism test, the deviation path identification and weight control are guided, so that the evaluation of deviation risk no longer depends on result comparison, but turns to the substantive analysis of intermediate transformation chain;Finally, it realizes active identification of potential field conflicts from distributed script evolution, and automatically repairs the gap of blood consistency, provides a reliable chain judgment basis for cross-node audit, and enhances the explainability and stability of the governance process.

Description

Technical Field

[0001] This invention relates to the field of audit data governance, and more specifically, to a scenario-driven, multi-entity collaborative data governance method. Background Technology

[0002] In cross-level auditing scenarios, multiple governance entities retain original business records on their respective nodes and repeatedly rearrange field order and semantic tags using self-written cleaning scripts. These scripts are frequently rewritten as business processes are fine-tuned, compressing, adding, deleting, or replacing table headers, resulting in different descriptions for fields with the same name at the source. Because script execution details often remain in local logs, the on-chain registration only covers the aggregated results. When faced with centralized data, the auditing process can only see a single summary table, making it difficult to understand the evolution of the underlying scripts.

[0003] However, the lack of reliable synchronization in the script version led to contradictory lineage paths for the same field on different nodes. While the aggregation results appeared consistent, the internal transformation chains were broken. Conventional reconciliation methods only compare terminal field values, ignoring intermediate transformation details, thus failing to reveal hidden conflicts and hindering responsibility allocation and anomaly backtracking. Only by extracting runtime logs and metadata snapshots into a graph structure and performing matching analysis across nodes can hidden discrepancies be identified at the data level, lineage consistency gaps be repaired, and a reliable basis for subsequent audit judgments be provided.

[0004] To address the aforementioned problems, a technical solution is provided. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of existing technologies, embodiments of the present invention provide a scenario-driven multi-subject data collaborative governance method. This method integrates runtime logs and metadata snapshots into a traceability system, forming a stable field label mapping mechanism, and then reconstructs the field evolution logic using a structural graph approach. By embedding two types of heterogeneous features—path drift and chain break density—a multi-source correction coefficient is established that fuses structure and strength judgments. This coefficient guides deviation path identification and weight adjustment during subgraph isomorphism testing, shifting the assessment of deviation risk away from result comparison and towards the substantive analysis of intermediate transformation chains. Ultimately, this method proactively identifies potential field conflicts from distributed script evolution and automatically repairs lineage consistency gaps, providing a reliable chain-like judgment basis for cross-node auditing, enhancing the interpretability and stability of the governance process, and thus addressing the problems raised in the background technology.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] S1: Periodically extract the latest running logs and metadata snapshots from each governance node, generate a traceability tag for each field based on the field name and script execution timestamp, and record it to a temporary mapping list;

[0008] S2: Read the mapping list, generate a hierarchical lineage graph according to the evolution order of fields, and perform cluster merging on cross-node labels with the same name, and output candidate consistent chains;

[0009] S3: For candidate consistent chains, first extract the direction drift features and chain break density features, and generate multi-source correction coefficients. Based on this, perform subgraph isomorphism test to locate the deviation path and assign weights to the differences. At the same time, write the test results back to the mapping list.

[0010] S4: Initiate the script repair process based on the differential weights, synchronously update the script version list and hierarchical lineage diagram, and push the traceability report to the audit end.

[0011] In a preferred embodiment, step S1 includes the following:

[0012] Periodically extract the latest operation logs and metadata snapshots from each governance node; generate a unique traceability tag for each field in the extracted data. The traceability tag is composed of the field name and the script execution timestamp, ensuring that the field's status is uniquely identified at a specific point in time; record the field name, script execution timestamp, and traceability tag to a temporary mapping list.

[0013] In a preferred embodiment, step S1 further includes the following:

[0014] Before recording, the extracted data is validated to confirm the integrity of the execution records and field definitions. If an anomaly occurs, the governance node is notified to correct the data and re-extract it.

[0015] In a preferred embodiment, step S1 further includes the following:

[0016] The runtime log contains script execution details, including version number, execution timestamp, input data records, and output data records. The metadata snapshot contains field structure and semantic information, including field name, data type, and description.

[0017] In a preferred embodiment, step S2 includes the following:

[0018] Extract field names, script execution timestamps, and tracing labels from the temporary mapping list to generate the original dataset; construct a hierarchical lineage graph based on the original dataset, where the tracing labels are nodes, nodes with the same field name are sorted by script execution timestamps and connected by directed edges, and nodes are hierarchically arranged according to script execution timestamps.

[0019] In a preferred embodiment, step S2 further includes the following:

[0020] For tracing labels with the same field name in the hierarchical lineage graph, clustering and merging are performed. Hierarchical clustering method is used, and distance calculation is defined based on the difference in script execution timestamps and script version numbers to merge them into candidate consistent chains. The candidate consistent chains are then organized into a candidate consistent chain dataset, which includes field names, candidate consistent chain identifiers, and tracing labels and script execution timestamps of the nodes in the candidate consistent chains.

[0021] In a preferred embodiment, step S3 includes the following:

[0022] For candidate consistent chains, firstly, a structural fingerprint based on the field transformation type and intensity is generated for each field transformation segment, and the directional dispersion difference of the structural fingerprint of each node is calculated by cosine similarity to generate directional drift features; then, broken segments in the candidate consistent chains are identified, and the frequency of recurrence of broken segments is statistically analyzed by graph editing distance to generate chain break density features.

[0023] In a preferred embodiment, step S3 further includes the following:

[0024] Then, the drift characteristics are mapped to the outer shell thickness of the graph nodes, and the chain break density characteristics are mapped to the kernel aperture of the nodes. Multi-source correction coefficients are generated by projecting mesh skin onto the hierarchical lineage graph and performing an iterative shrinkage algorithm.

[0025] In a preferred embodiment, step S3 further includes the following:

[0026] Finally, based on the multi-source correction coefficients, subgraphs are selected, and the graph isomorphism algorithm is used to compare the structure with the standard evolution path. Deviation paths are located and weights are assigned to the differences. At the same time, the test results are written back to the temporary mapping list.

[0027] In a preferred embodiment, step S4 includes the following:

[0028] The system sorts off-paths based on their differential weights and selects a repair strategy. It automatically generates and executes repair scripts to adjust field transformations, updates the script version list to record the repaired version number, repair time, and repair content, and updates the nodes and edges in the hierarchical lineage graph to reflect the repaired field status and transformation relationships. It generates a traceability report containing off-paths, differential weights, repair strategies, execution records, and post-repair status, and pushes it to the audit end through an encrypted transmission channel.

[0029] The technical effects and advantages of the scenario-driven multi-subject data collaborative governance method of the present invention are as follows:

[0030] This invention addresses data collaborative governance scenarios involving multiple stakeholders. By constructing a dynamically traceable field lineage path, it accurately reconstructs the field transformation chain globally, even under real-world conditions of inconsistent source nodes and frequent script evolution. During processing, runtime logs and metadata snapshots are synchronously incorporated into the traceability system, forming a stable field label mapping mechanism, which then reconstructs the field evolution logic using a structural graph approach. By embedding two heterogeneous features—path drift and chain break density—a multi-source correction coefficient is established, fusing structure and strength judgments. This coefficient guides deviation path identification and weight adjustment during subgraph isomorphism testing, shifting the assessment of deviation risk from result comparison to the substantive analysis of intermediate transformation chains. Ultimately, it proactively identifies potential field conflicts from distributed script evolution and automatically repairs lineage consistency gaps, providing a reliable chain-like judgment basis for cross-node auditing and enhancing the interpretability and stability of the governance process. Attached Figure Description

[0031] Figure 1 This is a flowchart illustrating a scenario-driven multi-subject data collaborative governance method according to the present invention.

[0032] Figure 2 This is a flowchart illustrating step S2 of a scenario-driven multi-subject data collaborative governance method according to the present invention. Detailed Implementation

[0033] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0034] Example 1: Figure 1 This invention presents a scenario-driven, multi-subject data collaborative governance method, comprising:

[0035] S1: Periodically extract the latest running logs and metadata snapshots from each governance node, generate a traceability tag for each field based on the field name and script execution timestamp, and record it to a temporary mapping list.

[0036] S2: Read the mapping list, generate a hierarchical lineage graph according to the order of field evolution, and perform cluster merging on cross-node labels with the same name, outputting candidate consistent chains.

[0037] S3: For candidate consistent chains, first extract the direction drift features and chain break density features, and generate multi-source correction coefficients. Based on these, perform subgraph isomorphism test to locate the deviation path and assign weights to the differences. At the same time, write the test results back to the mapping list.

[0038] S4: Initiate the script repair process based on the differential weights, synchronously update the script version list and hierarchical lineage diagram, and push the traceability report to the audit end.

[0039] In cross-level auditing scenarios, multiple governance entities are responsible for processing data at their respective nodes. This data originates from original business records and is processed using cleansing scripts written by each entity. Due to frequent changes in business requirements, the cleansing scripts are constantly updated, leading to changes in the order and semantic labels of data fields, and inconsistencies in the description of the same field at different nodes. This inconsistency becomes a major obstacle during data aggregation and auditing because auditors only have access to a single aggregated summary table, making it difficult to trace the evolution of scripts and the details of field transformations during data processing. Traditional methods only compare terminal field values, ignoring intermediate transformation processes, and cannot detect potential conflicts or anomalies, hindering the allocation of responsibility and anomaly backtracking.

[0040] To address this issue, this invention proposes a scenario-driven, multi-entity data collaborative governance method. This method constructs a dynamically traceable field lineage path, ensuring accurate reconstruction of the field transformation chain even with inconsistent data sources and frequent script evolution. Its core lies in integrating scattered runtime logs and metadata snapshots from various nodes into analyzable structured information, and through step-by-step processing logic, gradually achieving visualization, consistency verification, and deviation correction of field evolution. Step S1, as the starting point of the entire method, aims to lay the data foundation for subsequent lineage analysis. Specifically, it solves the initial challenge of tracing field evolution by periodically extracting key information and generating traceability tags.

[0041] Step S1 involves periodically extracting the latest runtime logs and metadata snapshots from each governance node, generating a traceability tag for each field, and finally writing the relevant information into a temporary mapping list. The specific processing logic is as follows.

[0042] Periodically extract runtime logs and metadata snapshots:

[0043] The latest runtime logs and metadata snapshots are extracted from each governance node, with the operation executed at pre-defined time intervals. The runtime logs record script execution details, including the script version number, execution time, input data records, and output data records. Metadata snapshots contain the structure and semantic information of data fields, such as field names, data types, and descriptions. The time interval is determined based on business needs and the frequency of data changes; for example, when business needs change frequently and data updates rapidly, extraction is set to once daily; when data changes are slower, extraction is set to once weekly. The extraction process is triggered by a system scheduled task, reading runtime logs and metadata snapshots from the storage location of the governance nodes and storing them in the central data processing area. This periodic extraction ensures that the acquired data always reflects the latest state of script execution and data structure.

[0044] Generate traceability tags:

[0045] A unique traceability tag is generated for each field to mark its state at a specific point in time. The calculation logic for generating the traceability tag is to combine the field name with the specific timestamp of the script execution to form an identifier. In practice, the field name is directly extracted from the metadata snapshot to ensure consistency with the source data; the script execution timestamp is extracted from the execution log, accurate to the second; the combination method is to connect the field name and the timestamp with an underscore. The unique identifier distinguishes the state of the field at different times and nodes, avoiding confusion. Field names may be repeated at multiple nodes, but their states differ due to different script execution times. The unique identifier can clearly distinguish these states, improving the accuracy of field state tracking and facilitating the accurate construction of subsequent lineage relationships.

[0046] Write to the temporary mapping list:

[0047] Record the mapping relationship between field names, script execution timestamps, and generated traceability tags in a temporary mapping list. The temporary mapping list is in tabular form, containing three columns: the first column is the field name, such as "User ID"; the second column is the script execution timestamp; and the third column is the traceability tag. Record the above information for each field row by row to ensure that each record corresponds completely. The storage format can be a database table or a structured file.

[0048] Data validation:

[0049] Before writing the data to the temporary mapping list, the extracted runtime logs and metadata snapshots are verified for completeness and accuracy. Specific verification includes: checking for missing execution records in the runtime logs, such as missing timestamps or output data; and checking the completeness of field definitions in the metadata snapshots, such as undefined field names or data types. The extracted data is compared line by line with the expected format. If any missing or incorrect data is found, the anomaly is recorded, and the corresponding governance node is notified to supplement the complete data before re-executing the extraction process.

[0050] Update frequency adjustment:

[0051] The extraction cycle for runtime logs and metadata snapshots is dynamically adjusted based on actual business needs and the frequency of data changes. Specifically, the adjustment logic involves continuously monitoring the frequency of field changes and script updates. For example, it involves counting the number of changes to field definitions or script versions per unit of time. If changes are frequent, the extraction interval is shortened; if changes are infrequent, the extraction interval is extended. An adaptive mechanism optimizes the extraction time interval to match actual needs.

[0052] Step S1, through the five sub-steps described above, forms a complete processing flow: First, it periodically extracts runtime logs and metadata snapshots from the governance node to obtain raw data; then, it generates a unique traceability tag for each field to mark its status; next, it records the field name, script execution timestamp, and traceability tag to a temporary mapping list for centralized data storage; before this, data quality is ensured through data validation; finally, the extraction frequency is dynamically adjusted according to business needs to optimize the process. The output of step S1, namely the temporary mapping list, directly serves as the input for subsequent steps. Subsequent steps will utilize the field names, script execution timestamps, and traceability tags in the list to construct the lineage relationships of fields, ensuring the continuity and consistency of cross-node data analysis.

[0053] Step S1 generates traceability tags for fields and writes them to a temporary mapping list by periodically extracting runtime logs and metadata snapshots, thus establishing a traceable foundation for field status. However, relying solely on this scattered field status information cannot directly reveal the evolutionary relationships and potential conflicts between fields across different nodes. To address this issue, step S2, based on the output of step S1, introduces a hierarchical lineage graph and cluster merging techniques. This aims to integrate field evolution paths and identify candidate consistency chains with the same tag across nodes, providing structured support for subsequent consistency checks and deviation repairs.

[0054] Step S2 involves reading the temporary mapping list, generating a hierarchical lineage graph based on the order of field evolution, merging identically named labels across nodes, and outputting candidate consistent chains. For example... Figure 2 As shown, the specific technical logic is as follows.

[0055] Read the temporary mapping list:

[0056] Step S2 first extracts field names, script execution timestamps, and tracing tags from the temporary mapping list generated in Step S1. The temporary mapping list is a dataset containing the correspondence between field names, script execution timestamps, and tracing tags. The processing method involves retrieving all records from the temporary mapping list using database queries or file parsing techniques, ensuring that each record is complete and without omissions. The output is a raw dataset recording the state of each field at a specific point in time, serving as input data for subsequently generating a hierarchical lineage map.

[0057] Generate a hierarchical lineage chart:

[0058] Based on the original dataset, a hierarchical lineage graph is constructed according to the chronological relationship of field evolution. The processing logic is as follows: each source label in the original dataset is regarded as a node in the hierarchical lineage graph, representing the state of the field at a specific point in time; for related records with the same field name, directed edges are formed by connecting the corresponding source labels according to the order of script execution timestamps, with the directed edges pointing from nodes with earlier timestamps to nodes with later timestamps; at the same time, all nodes are hierarchically arranged in ascending order of timestamps, with nodes with earlier timestamps located in lower layers and nodes with later timestamps located in higher layers. In specific operations, for each field name, all related records are extracted from the original dataset, sorted by script execution timestamp from smallest to largest, and then these nodes are connected sequentially in the hierarchical lineage graph to form a path. The complexity of field state changes over time is clearly presented through the graph structure, and the hierarchical lineage graph can intuitively display the evolution path.

[0059] Implement cluster merging:

[0060] Based on the hierarchical lineage graph, cross-node labels with the same name are clustered and merged to identify candidate consistent chains. The processing logic is as follows: First, the set of traceability labels with the same field name is identified in the hierarchical lineage graph; then, a hierarchical clustering method is used to group these labels with the same name according to their timestamps and script version numbers, merging them into candidate consistent chains. The calculation logic is as follows: a distance calculation method is defined to measure the proximity between two traceability labels: first, the difference in timestamps between the two traceability labels is calculated; the smaller the difference, the closer they are in time and the closer they are in distance; if a script version number exists, the version numbers are compared; if they are different, a fixed value is added to the timestamp difference to represent the impact of the version difference; based on this distance calculation method, traceability labels with the same field name are grouped, and each group forms a candidate consistent chain.

[0061] Output candidate consistent chains:

[0062] The results of cluster merging are organized and output as a candidate consistent chain dataset. The processing logic is as follows: for each candidate consistent chain, the source label of each node in the chain is recorded, and the corresponding field name and script execution timestamp are associated. The output candidate consistent chain dataset contains field names, unique identifiers of the candidate consistent chain, and the source label and timestamp of each node in the chain, serving as input data for step S3. The calculation logic is as follows: traverse each clustering result after cluster merging, arrange the nodes in timestamp order, and generate structured records.

[0063] In cross-level auditing scenarios, step S2 transforms scattered field status information into a structured candidate consistency chain by reading a temporary mapping list, generating a hierarchical lineage graph, performing cluster merging, and outputting candidate consistency chains. This process addresses the issues of frequent script evolution and heterogeneous data sources by constructing the evolution path of fields in terms of time and nodes, providing technical support for revealing field conflicts and fixing lineage consistency issues.

[0064] Step S2 further reads the temporary mapping list, constructs a hierarchical lineage graph, and outputs candidate consistent chains through cluster merging to initially reveal the field evolution relationships. However, simply identifying candidate consistent chains is insufficient to resolve potential conflicts and lineage consistency issues in field evolution; a deeper analysis of the internal structure of the candidate consistent chains is needed to locate deviation paths and quantify the deviations. Step S3 addresses this need by designing specific technical logic, using feature extraction and verification analysis to provide precise evidence for subsequent repairs.

[0065] Step S3 is to extract the path drift features and chain break density features from the candidate consistent chains generated in step S2, generate multi-source correction coefficients, perform subgraph isomorphism test to locate the deviation path and assign weights to the differences, and write the test results back to the temporary mapping list.

[0066] Extracting drift features:

[0067] First, a structural fingerprint is generated for each field transformation in the candidate consistent chain, and the directional dispersion difference of the structural fingerprints at each node is calculated to generate directional drift features. The generation of structural fingerprints is based on the type and intensity of the field transformation. In practice, each field transformation (e.g., field rearrangement, addition, deletion, or replacement) is encoded into a multi-dimensional vector, where each dimension represents a transformation type or intensity index. For example, the first dimension represents the number of rearrangements, and the second dimension represents the change in the number of fields.

[0068] Next, the directional drift feature of each node is calculated. Specifically, the directional differences between the structural fingerprints of all outgoing edges (i.e., subsequent field transformations) of that node are evaluated. These directional differences are quantified using cosine similarity, which is calculated as the dot product of two structural fingerprint vectors divided by the product of their respective magnitudes. If a node has multiple outgoing edges and the structural fingerprint directions of these outgoing edges differ significantly, the directional drift feature value of that node is high, indicating that the evolution direction of the field at that node is inconsistent. By quantifying the dispersion of the field transformation direction, unstable regions in the evolution path are identified. Inconsistency in the field evolution direction may indicate potential conflicts or anomalies; early identification helps to accurately locate problem areas.

[0069] Extracting chain break density features:

[0070] Next, broken segments in the candidate consistent chains are scanned, and the recurrence frequency of these broken segments is accumulated to generate a chain break density feature. The identification of broken segments is based on disconnected or anomalously connected portions in the candidate consistent chains caused by inconsistent script versions or abnormal timestamps. The processing logic is as follows: First, broken segments in all candidate consistent chains are identified. Then, the recurrence frequency of these broken segments in the entire dataset is counted. Recurrence is determined by comparing the structural similarity of the broken segments, specifically using graph edit distance, defined as the minimum number of operations required to transform one broken segment into another. When the edit distance between two broken segments is less than a preset threshold, they are considered the same segment. The chain break density feature is the sum of the recurrence frequencies of all broken segments in each candidate consistent chain, reflecting the degree of breakage in that chain.

[0071] The frequent recurrence of broken segments may indicate a systemic problem in the field evolution, which requires close attention. By quantifying the recurrence of broken segments, the consistency level of candidate consensus chains can be evaluated, and the reliability of candidate consensus chains can be assessed from a global perspective, providing a basis for subsequent deviation analysis.

[0072] Generate multi-source correction coefficients:

[0073] By combining orientation drift characteristics and chain break density characteristics, multi-source correction coefficients are generated. The processing logic is as follows: First, the orientation drift characteristic values ​​are mapped to the outer shell thickness of graph nodes, and the chain break density characteristic values ​​are mapped to the node kernel aperture. Specifically, the node kernel aperture is the chain break density characteristic value divided by the degree (i.e., the number of connected edges) of the node. Then, a virtual mesh skin is projected onto the layered lineage graph generated in step S2. The stiffness of the mesh is determined by the outer shell thickness, and the size of the holes is determined by the kernel aperture. Next, the deformation process of the mesh is simulated through an iterative shrinkage algorithm. The iterative shrinkage algorithm selects regions with low stiffness (i.e., small outer shell thickness) and large holes (i.e., large kernel aperture) for priority collapse each time. The displacement of the collapse is the distance change of the mesh after deformation in that region.

[0074] Ultimately, the multi-source correction coefficient is the sum of the collapse displacements of all nodes, quantifying the degree of deviation in the entire hierarchical lineage map.

[0075] The technical logic for generating multi-source correction coefficients transforms complex graph structure analysis into an intuitive physical simulation process by integrating orientation drift features and chain break density features, yielding significant benefits. First, by mapping orientation drift features to outer shell thickness and chain break density features to core aperture, and projecting a mesh skin onto the hierarchical lineage graph, it can intuitively reflect structural changes and consistency issues during field evolution, providing a comprehensive deviation assessment index. This mapping method transforms abstract graph features into physical properties, facilitating understanding and visualization. Second, the iterative shrinkage algorithm prioritizes the collapse of regions with low stiffness and large pores, highlighting severely deviated areas and ensuring that the multi-source correction coefficients accurately capture key deviation points, improving the relevance and accuracy of the assessment. Furthermore, the multi-source correction coefficients, as the sum of the collapse displacements of all nodes, quantify the degree of deviation in the entire graph, providing a global guiding index for subsequent subgraph isomorphism verification and repair. This method not only improves the accuracy and interpretability of deviation assessment but also simplifies the implementation process, enabling efficient resolution of complex problems.

[0076] Perform subgraph isomorphism test:

[0077] Finally, based on the multi-source correction coefficients, a subgraph isomorphism test is performed to locate deviation paths and assign weights to the differences. The processing logic is as follows: First, based on the multi-source correction coefficients and node collapse displacements, the region with the largest collapse displacement is selected as the subgraph to be tested. Then, the selected subgraph is structurally compared with the standard evolution path, which is defined by historical data or expert knowledge. The graph isomorphism algorithm is used to calculate the difference between the subgraph and the standard path, determining structural similarity by comparing the matching degree of nodes and edges. Finally, deviation path indexing weights are assigned. The weights are calculated by multiplying the multi-source correction coefficients by the ratio of the edit distance between the subgraph and the standard path to the total number of edges in the subgraph. The edit distance is the minimum number of operations required to convert the subgraph into the standard path.

[0078] Subgraph isomorphism testing can accurately locate abnormal parts in field evolution, while weight indexing provides a reference for repair priorities; structural comparison quantifies the degree of deviation and provides a basis for repair.

[0079] Step S3 forms a coherent processing flow through the above four sub-steps: First, it extracts the direction drift feature to identify inconsistencies in the field evolution direction; then, it extracts the chain break density feature to assess the degree of breakage in candidate consistent chains; next, it combines the direction drift feature and the chain break density feature to generate multi-source correction coefficients, quantifying the overall deviation of the hierarchical lineage graph; finally, it performs subgraph isomorphism testing based on the multi-source correction coefficients to locate deviation paths and index their weights. Step S3, through feature extraction and structured analysis, successfully locates deviation paths in candidate consistent chains and quantifies differences, addressing the shortcomings of conventional reconciliation methods that neglect intermediate transformation details. This provides precise guidance for script repair, improving the reliability of data governance and the traceability of audits.

[0080] Step S3 generates multi-source correction coefficients by extracting drift characteristics and chain break density characteristics. It then locates the deviation path and assigns difference weights in the subgraph isomorphism test, providing a precise basis for subsequent repair. However, simply identifying and quantifying deviations is insufficient to resolve field conflicts. A repair process must be initiated based on the difference weights, relevant records must be updated synchronously, and a reliable report must be pushed to the auditing department to restore lineage consistency and support audit judgment. Step S4 addresses this need by designing specific technical logic to achieve proactive repair and transparent auditing of field evolution.

[0081] The task of step S4 is to start the script repair process based on the difference weights generated in step S3, synchronously update the script version list and hierarchical lineage diagram, and push the traceability report to the audit end.

[0082] Start the script to repair the process:

[0083] First, based on the difference weights generated in step S3, a script repair process is initiated for the deviation paths. The difference weights are quantified values ​​used to index the deviation paths after subgraph isomorphism testing in step S3, and are used to measure the severity of field evolution deviations. The processing logic is as follows: First, all deviation paths are sorted from highest to lowest according to their difference weights, ensuring that the paths with the most severe deviations are addressed first to optimize the allocation of repair resources; then, based on the characteristics of the deviation paths (such as field transformation types and fragmentation characteristics), an appropriate repair strategy is selected, including field rearrangement, semantic label correction, or script version synchronization; finally, a repair script is automatically generated and executed to adjust the field transformations in the deviation paths, aligning them with the standard evolution paths.

[0084] The ranking of difference weights is determined by comparing the quantified values ​​of each deviation path, with larger values ​​indicating more severe deviations and higher rankings. The selection of repair strategies is based on a predefined rule base, matching the corresponding repair methods according to the characteristics of the deviation paths. The generation of repair scripts is based on templates, which dynamically fill in parameters according to field transformation types and difference weights to ensure the relevance and effectiveness of the repair.

[0085] Deviation paths with higher weighting have a greater impact on audits, and prioritizing their remediation can quickly restore data consistency. Selecting appropriate remediation strategies allows for precise handling of different deviation types, avoiding resource waste during the remediation process. By prioritizing and selecting strategies, precise remediation of field evolution deviations can be achieved, efficiently restoring consistency in field evolution and reducing audit risks and accountability challenges caused by deviations.

[0086] Synchronously update the script version list and hierarchical lineage diagram:

[0087] After the repair is completed, the script version list and hierarchical lineage graph are updated synchronously to reflect the latest field states and evolution relationships. The processing logic is as follows: First, the repaired script version number is recorded in the script version list. The version number is incremented sequentially and associated with the repair time and repair content to form a historical record of script evolution. At the same time, based on the repaired field states, the nodes and edges in the hierarchical lineage graph are updated. Nodes represent field states, and edges represent transformation relationships between fields, ensuring that the lineage path accurately reflects the post-repair evolution logic.

[0088] The script version number is incremented by checking the latest number in the existing version list, adding one to generate the new version number; the hierarchical lineage graph is updated by comparing the field status before and after the repair, adjusting the node content and reconnecting the edges to ensure that the graph structure is consistent with the actual evolution.

[0089] The script version list records the script's evolution history, helping auditors trace the remediation process; updates to the hierarchical lineage diagram ensure the accuracy of field evolution paths, avoiding information lag caused by remediation. Through version management and graph structure updates, the real-time nature and traceability of the data governance process are maintained, providing auditors with a complete record of script evolution and field evolution paths, enhancing the traceability and transparency of data governance, and ensuring that audit decisions are based on the latest and most accurate data.

[0090] Push the traceability report to the audit end:

[0091] Finally, a traceability report is generated and pushed to the audit end, providing a detailed record of the remediation process and results. The traceability report includes key information such as a list of deviation paths, difference weights, remediation strategies, remediation execution records, and post-remediation field statuses, using a structured format (such as JSON) for easy parsing and display by the audit end. The processing logic is as follows: First, various data from the remediation process are integrated, including the original state of the deviation path, the execution details of the remediation strategy, and the post-remediation field statuses, to generate a report containing before-and-after comparisons. Then, the report is pushed to the audit end via an encrypted transmission channel to ensure data security and real-time performance.

[0092] The report content is generated by extracting log data from the repair process and organizing the information according to a predefined template to ensure completeness and structure; the push process confirms the receiving status of the audit end through network protocols to ensure successful transmission.

[0093] The traceability report provides auditors with a detailed record of the remediation process, helping them understand changes in field evolution and the effectiveness of the remediation. The structured format and secure transmission ensure the report's usability and confidentiality. By providing auditors with complete information about the remediation process through transparent and structured reporting, the interpretability of the audit process is enhanced, ensuring that audit decisions are based on accurate and transparent data, thus improving audit efficiency and credibility.

[0094] Step S4 forms a coherent processing flow through the three sub-steps described above: First, based on the difference weights output in Step S3, the script repair process is initiated to accurately repair deviations from the path; then, the script version list and hierarchical lineage diagram are updated synchronously based on the repair results to ensure the real-time nature and accuracy of data governance records; finally, a traceability report is generated and pushed to the audit end, completing the transparent traceability of the repair process. Step S4, through an automated repair and update mechanism, successfully restores the consistency of field evolution and provides transparent and reliable traceability evidence for the audit end, resolving the field conflict problem caused by frequent script evolution among multiple entities, and improving the efficiency and credibility of collaborative data governance.

[0095] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0096] It should be noted that the system of the present invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting a variety of hardware environments and usage requirements.

[0097] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

[0098] It should be noted that, in this document, the use of relational terms such as "first" and "second" is merely to distinguish one entity or operation from another, and does not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0099] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for collaborative governance of multi-agent data based on scenario driving, characterized in that, Including the following steps: S1: Periodically extract the latest running logs and metadata snapshots from each governance node, generate a traceability tag for each field based on the field name and script execution timestamp, and record it to a temporary mapping list; S2: Read the mapping list, generate a hierarchical lineage graph according to the evolution order of the fields, where the source label is used as a node, nodes with the same field name are sorted according to the script execution timestamp and connected by directed edges, nodes are hierarchically arranged according to the script execution timestamp, and clustering and merging of labels with the same name across nodes are performed, and candidate consistent chains are output. S3: For candidate consistent chains, first extract the orientation drift feature and chain break density feature. The orientation drift feature is generated by calculating the directional scattering difference of the structural fingerprint of each node using cosine similarity. The chain break density feature is generated by statistically analyzing the recurrence frequency of broken segments using graph editing distance. A multi-source correction coefficient is generated by mapping the orientation drift feature to the outer shell thickness of the graph node and the chain break density feature to the kernel aperture of the node. The multi-source correction coefficient is generated by projecting a mesh skin onto the layered lineage graph and executing an iterative shrinkage algorithm. Based on this, a subgraph isomorphism test is performed to locate the deviation path and assign weights to the differences. At the same time, the test results are written back to the mapping list. S4: Initiate the script repair process based on the differential weights, synchronously update the script version list and hierarchical lineage diagram, and push the traceability report to the audit end. 2.The method of claim 1, wherein, Step S1 includes the following: Periodically extract the latest operation logs and metadata snapshots from each governance node; generate a unique traceability tag for each field in the extracted data. The traceability tag is composed of the field name and the script execution timestamp, ensuring that the field's status at that point in time is uniquely identified; record the field name, script execution timestamp, and traceability tag to a temporary mapping list. 3.The method of claim 2, wherein, Step S1 also includes the following: Before recording, the extracted data is validated to confirm the integrity of the execution records and field definitions. If an anomaly occurs, the governance node is notified to correct the data and re-extract it.

4. The multi-agent data collaborative governance method based on scene driving according to claim 2, characterized in that, Step S1 also includes the following: The runtime log contains script execution details, including version number, execution timestamp, input data records, and output data records. The metadata snapshot contains field structure and semantic information, including field name, data type, and description.

5. The multi-agent data collaborative governance method based on scene driving according to claim 2, characterized in that, Step S2 includes the following: Extract field names, script execution timestamps, and source tags from the temporary mapping list to generate the original dataset; A hierarchical lineage graph is constructed based on the original dataset, where the tracing label serves as a node. Nodes with the same field name are sorted by script execution timestamp and connected by directed edges, and the nodes are hierarchically arranged according to the script execution timestamp.

6. The multi-agent data collaborative governance method based on scene driving according to claim 5, characterized in that, Step S2 also includes the following: For tracing labels with the same field name in the hierarchical lineage graph, clustering and merging are performed. Hierarchical clustering method is used, and distance calculation is defined based on the difference in script execution timestamps and script version numbers to merge them into candidate consistent chains. The candidate consistent chains are then organized into a candidate consistent chain dataset, which includes field names, candidate consistent chain identifiers, and tracing labels and script execution timestamps of the nodes in the candidate consistent chains.

7. The scenario-driven multi-subject data collaborative governance method according to claim 6, characterized in that, Step S3 includes the following: For candidate consistent chains, firstly, a structural fingerprint based on the field transformation type and intensity is generated for each field transformation segment, and the directional dispersion difference of the structural fingerprint of each node is calculated by cosine similarity to generate directional drift features; then, broken segments in the candidate consistent chains are identified, and the frequency of recurrence of broken segments is statistically analyzed by graph editing distance to generate chain break density features.

8. The scenario-driven multi-subject data collaborative governance method according to claim 7, characterized in that, Step S3 also Includes the following: Then, the drift characteristics are mapped to the outer shell thickness of the graph nodes, and the chain break density characteristics are mapped to the kernel aperture of the nodes. Multi-source correction coefficients are generated by projecting mesh skin onto the hierarchical lineage graph and performing an iterative shrinkage algorithm.

9. The scenario-driven multi-subject data collaborative governance method according to claim 8, characterized in that, Step S3 also Includes the following: Finally, based on the multi-source correction coefficients, subgraphs are selected, and the graph isomorphism algorithm is used to compare the structure with the standard evolution path. Deviation paths are located and weights are assigned to the differences. At the same time, the test results are written back to the temporary mapping list.

10. A scenario-driven multi-subject data collaborative governance method according to claim 9, characterized in that, Step S4 includes the following: The system sorts off-paths based on their differential weights and selects a repair strategy. It automatically generates and executes repair scripts to adjust field transformations, updates the script version list to record the repaired version number, repair time, and repair content, and updates the nodes and edges in the hierarchical lineage graph to reflect the repaired field status and transformation relationships. It generates a traceability report containing off-paths, differential weights, repair strategies, execution records, and post-repair status, and pushes it to the audit end through an encrypted transmission channel.

Images