A method for detecting anomalies in procuratorial processes based on data lineage

Abstract

The present invention belongs to the field of data lineage technology, and specifically is a method for detecting anomalies in procuratorial work processes based on data lineage. In order to detect different types of anomalies in procuratorial work scenarios, the method of the present invention includes: designing a new lineage model that can support subsequent procuratorial work process anomaly detection; designing a consistency verification method to detect abnormal information in the lineage graph according to the consistency rule constraints extracted from the lineage model; designing a lineage graph process anomaly detection and analysis algorithm to produce a lineage subgraph that can explain different abnormal behaviors. The present invention meets the demand for traceability information of different types of anomalies in procuratorial work scenarios without changing the case logs generated by the unified business platform of the procuratorate.

Description

Technical Field

[0001] The present invention belongs to the technical field of data lineage, and in particular to a method for detecting anomalies in inspection processes based on data lineage. Background Art

[0002] The procuratorate is a national legal oversight and regulatory agency. It exercises procuratorial authority over criminal cases submitted by other relevant departments, overseeing, reviewing, and adjudicating these cases. Due to the complexity of its operations, the procuratorate typically needs to collaborate with other departments (such as courts, public security bureaus, and prisons) across multiple scenarios and systems, as well as with procuratorates at other levels.

[0003] Currently, procuratorial organs at all levels in China use the unified national procuratorial business platform to handle cases. Functionally, this system can help case handlers handle cases and relatively improve case handling efficiency. However, during the case handling process, some case handlers may make mistakes in filling in case information due to negligence. Subsequent case handlers need to trace the source of the problem and find the source information of different types of anomalies. For example, in criminal prosecution business, the case needs to be accepted and reviewed by the relevant case handlers. If an error occurs when filling in the case name in the case card item, and the subsequent erroneous information enters the case consolidation stage, it will have a significant negative impact on the entire case handling process.

[0004] Therefore, when analyzing abnormal information throughout the case handling process, a unified business platform is required to provide case information. However, the current unified business platform system is unable to trace information related to different abnormalities throughout the entire case. Furthermore, as a business-oriented workflow system, its inherent process-focused architecture lacks the ability to control information. Therefore, the timely introduction of log information-related technologies is particularly important for solving the problem of information source tracking.

[0005] Data lineage captures the evolution of data and meets traceability requirements, parsing coarse-grained logs containing complex and redundant information into concise, visual lineage data. It not only contains the data's origin information but also records its evolution and historical information. After nearly four decades of development, data lineage has flourished in various fields and scenarios. Examples include machine learning and deep learning in the algorithmic field; agriculture, atmospheric science, geography, and biomedicine in scientific fields; and blockchain, cloud computing, and the Internet of Things in the internet.

[0006] Different fields differ in how they record data changes and interpret traceability information, leading to significant disparities in the application of data lineage in different fields. Therefore, data lineage technology still holds research value in describing changes in case information and tracing back different abnormal information within procuratorial scenarios. For example, the Internet of Things focuses more on data changes between devices within a cluster, requiring detection of data that does not exist on the device, that is, whether the data appears in the IoT cluster. Scientific workflows, on the other hand, require data to be tracked from input to output, tracing the source of abnormal information that occurs throughout the entire processing process. In collaborative procuratorial scenarios, it is necessary to record changes in the case handling process and case information throughout its lifecycle, and to explain the source of abnormal types across the entire case during anomaly detection.

[0007] Due to the complexity of handling cross-scenario and cross-system cases, as well as the diversity of anomalies, lineage models need to be able to support fine-grained and different types of anomaly detection. However, existing lineage models for procuratorial scenarios mainly focus on single cases and a single type of data recording and traceability, and cannot meet the needs of anomaly detection in procuratorial collaborative scenarios. Therefore, the present invention implements a lineage model that supports process anomaly detection in the collaborative business scenario of the procuratorate, and proposes an anomaly detection method based on lineage data. Summary of the Invention

[0008] In order to realize the function of tracing the source information of different anomaly types in procuratorial scenarios, the purpose of the present invention is to propose a method for detecting anomalies in procuratorial processes based on data lineage. The present invention can support subsequent anomaly detection in procuratorial processes based on the lineage model of the directed acyclic lineage graph. At the same time, a consistency verification method is designed to detect anomaly information in the lineage graph according to the consistency rule constraints extracted from the lineage model. In addition, a lineage graph process anomaly detection and analysis algorithm is designed to produce lineage subgraphs that can explain different abnormal behaviors to meet the demand for tracing the source information of different anomaly types in procuratorial scenarios. It can ensure accurate detection of anomaly information when facing different anomaly types that arise in cross-institution, cross-department, and cross-organizational collaborative case handling. At the same time, if there is redundant information in the lineage graph, based on the incremental detection of the lineage graph sequence, branches, and closure structure, it can also ensure accurate detection of all anomaly information under rule constraints.

[0009] After detecting anomalies in the case-generated lineage graph, different anomaly types need to be explained separately. Specifically, for all anomaly information in procuratorial scenarios, the source of each anomaly scenario can be explained, eliminating the need to display all anomaly information. Based on the label propagation and combined consistency rules, lineage subgraphs representing different anomaly behaviors can be generated from the original lineage graph. Three conflict resolution strategies are proposed, providing a concise explanation of the lifecycle evolution of different anomaly types.

[0010] The present invention proposes a method for detecting anomalies in inspection processes based on data lineage, and the specific steps are as follows:

[0011] (1) Design a lineage model to support anomaly detection in the collaborative case-handling process of prosecutors

[0012] First, the collection module uses Redis distributed real-time collection of massive logs from the procuratorate's unified business platform. These logs are then converted through the lineage data conversion module. Regular matching, formed by formally defining refined lineage nodes and extended lineage relationships, is automatically converted into lineage data to generate a lineage graph. The generated lineage graph is then stored in the Neo4j graph database to support anomaly detection.

[0013] The PROV-DM model defines three top-level nodes: entity, activity, and agent. This paper builds a PADPM (Process Anomaly Detection Provenance Model) lineage model based on these three types of nodes.

[0014] The formal definition based on PROV-DM can be expressed as:

[0015] PROV-DM = (Node : [Entity,Activitiy,Agent], Relation :[WasDerivedFrom,Usage,

[0016] Communication,WasAssociatedWith], Id,[attribute,…])

[0017] The lineage model is based on existing procuratorial scenarios. It further refines the three core nodes of entities, activities, and agents. By expanding lineage relationships, it strengthens connections with the field and provides support for subsequent process anomaly detection.

[0018] Based on the above principles, the present invention models the lineage model as follows:

[0019] PADPM = < ID, NodeID, RelationID, Node, Relation >

[0020] Node = < Entity,Activitiy,Agent >

[0021] Relation = < Influenced,Used,Derived,Included,Invalidate,Producted,Noticed,

[0022] Managed,Delegated,AssociatedWith>

[0023] Among them: ID is the unique identifier of the relationship and node of the lineage model, NodeID\RelationID are the unique identifiers of the node and relationship respectively;

[0024] (2) Perform consistency test on the lineage model obtained in step (1)

[0025] A lineage graph is a directed acyclic graph, which can be structurally divided into three forms: sequential, branching, and closed. In public interest litigation cases, consistency testing is extended from sequential structures to branching and closed structures. After the closed structure is tested, nodes are replaced and the sequential structure is tested again.

[0026] First, select() queries the graph database Neo4j to obtain the case's lineage diagram, and Group() can directly obtain the lineage diagram G(V,E) After consistency rule verification, sequentially associated nodes E and edges V are expanded into branch structures and closure structures through Extend(). Information about nodes E and edges V is added to this structure, and constraint rule verification is performed after each addition. Replace() is then used to return to the last node in the closure structure and re-execute Group(). This method incrementally completes consistency verification of the lineage graph. Finally, the closure structure path containing the exception and a specific set of exception information are returned to support subsequent process anomaly detection and analysis.

[0027] (3) Detect and analyze anomalies in the genealogy process

[0028] The first anomaly point found according to the consistency rules in the lineage graph is called the initial detection point (IDP). Starting from the anomaly vertex, the anomaly information process is captured by the lineage subgraph, forming a lineage subgraph describing the changes of different types of anomalies. For each IDP vertex, a lineage subgraph related to the IDP and belonging to the same type of anomaly information is generated. Through the IDP vertex anomaly traceability query, the consistency rules corresponding to different anomaly type combinations are generated into an APG graph. A lineage subgraph containing only IDP vertices and related anomaly information is included in the Process Abnormal Detection Analysis (PADA) algorithm.

[0029] The above method takes the entire lineage graph as input to generate an APG graph set. First, AI is used to represent all abnormal information detected by all rules, and Seen is used to represent the abnormal information found in this tracing process. List <idp>The first exception information found in the graph is recorded; then the exception information is traversed through the ForwardPath method, which can use the Influenced relationship in the lineage graph to find the path of the exception information through depth-first search; after constructing the IDP graph of the primary exception information vertex, the path is traversed to find the exception information contained in the path, and non-abnormal information in this path is ignored, thus forming multiple IDP graphs starting with the exception information vertex; finally, all IDP graph sets containing each exception information are traversed, and the exception information is traversed using the rule combination corresponding to different exception types to form a new APG graph;

[0030] The conflict resolution algorithm of the present invention is to score according to the amount of abnormal information contained after the consistency rule verification when a conflict occurs in the abnormal detection analysis. The lineage subgraph will retain the node with the highest consistency rule score and use the influence relationship to record the abnormal information contained in the rule.

[0031] The conflict coverage algorithm of the present invention scores the nodes with the highest scores according to the consistency rule when a conflict occurs in the anomaly detection analysis, and does not retain the nodes or relationships with low scores.

[0032] The conflict filtering algorithm of this invention directly filters out conflicts within the anomaly detection and analysis algorithm, eliminating the conflicting anomaly information from the lineage subgraph. Conflict filtering is a specialized algorithm for displaying anomaly information, bypassing the lineage subgraph and directly submitting the detected anomaly information to case investigators for review.

[0033] The beneficial effects of the present invention are:

[0034] 1. This paper studies the business scenarios and case handling processes of the procuratorate, and investigates in detail the need for anomaly detection during the case handling process. It then designs and verifies a lineage model PADPM that can describe the process of case information changes and support anomaly detection in the procuratorial case handling process. By integrating Redis to collect the massive case handling logs generated by the unified business platform, in order to be able to describe case information in a more fine-grained manner and support dynamic anomaly detection during and after the procuratorial process, the lineage model refines the three types of entities, activities, and agents from an abstract to concrete hierarchical structure and extends the lineage relationship, and gives a formal definition. By mapping the formal definition to a regular matching formula, the log is dynamically converted into the required lineage data and the lineage graph is stored in the Neo4j database.

[0035] 2. Based on the practical challenges of anomaly detection in procuratorates' case handling processes and analyzing the difficulties of anomaly detection within lineage models, we propose a process anomaly detection method based on the procuratorial process lineage graph. In the procuratorial context, we first extract multiple consistency rules from the PADPM model and incrementally detect anomalies based on loops, branches, and closures in the lineage graph. We then implement a lineage graph process anomaly detection and analysis algorithm (PADA) based on label propagation. By combining consistency rules, we traverse different anomaly scenarios to generate multiple lineage subgraphs. We then propose three conflict resolution strategies to explain different anomalous behaviors in the case handling process. Experimental results show that the generated lineage subgraphs can concisely explain different anomalous behaviors.

[0036] 3. We designed and implemented a system for procuratorial case logs, from lineage data generation to anomaly detection. This system integrates a lineage data collection module, a lineage model construction module, and a procuratorial process anomaly detection module. This system is used to record and query case information that changes during the procuratorial process. This system can meet the need for tracing case changes and support anomaly detection and analysis during case handling. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 Construct a diagram for the lineage model of the present invention.

[0038] Figure 2 Schematic diagram of the consistency verification method of the present invention.

[0039] Figure 3 This is an example of consistency checking of the present invention.

[0040] Figure 4 FIG. 4 is a diagram illustrating the anomaly detection method of the present invention.

[0041] Figure 5 This is a diagram of the design of the inspection process anomaly detection system of the present invention.

[0042] Figure 6 This is a diagram of embodiment 1 of the present invention.

[0043] Figure 7 This is a diagram of embodiment 2 of the present invention.

[0044] Figure 8 This is a diagram of embodiment 3 of the present invention. DETAILED DESCRIPTION

[0045] The present invention is further described below by way of examples with reference to the accompanying drawings.

[0046] Example 1:

[0047] (1) Design a lineage model to support anomaly detection in the collaborative case-handling process of prosecutors

[0048] First, real-time data collection is required. Within the cross-system, distributed unified procuratorate business platform, the system must be able to collect massive amounts of logs with high availability and reliability. This must also handle high concurrency scenarios while maintaining stable and efficient data collection. Then, based on procuratorial scenarios and anomaly detection requirements, lineage nodes are refined and lineage relationships are extended. This ensures that the lineage graph fully and granularly describes multi-source anomaly information throughout the case evolution process, while also providing concise explanations of abnormal behavior during case handling.

[0049] The PROV-DM model defines three top-level nodes: Entity, Activity, and Agent. This paper builds on these three node types to construct the PADPM (Process Anomaly Detection Provenance Model) lineage model. By combining the key case and process data types in procuratorial scenarios, this paper refines node subclasses through a hierarchical structure from abstract to concrete, providing a more granular representation of the full lifecycle of case data while ensuring consistency between the model's representation of diverse historical information and the ongoing evolution of procuratorial data.

[0050] The formal definition based on PROV-DM can be expressed as:

[0051] PROV-DM = (Node : [Entity,Activitiy,Agent], Relation :[WasDerivedFrom,Usage,

[0052] Communication,WasAssociatedWith], Id,[attribute,…])

[0053] PROV-DM is designed to meet the needs of data models in different fields. It is expanded on the basis of the Prov general model. It allows logs in specific fields and application scenarios to be converted into the required data lineage model, describing the changes in single data and the lack of the ability to explain different types of anomalies. In combination with the procuratorial business scenario, the present invention requires the concurrent collection of massive case logs, and expands the lineage nodes and relationships from the abstract to the concrete to meet the needs of case process anomaly detection. The lineage model designed by the present invention is based on the existing procuratorial business scenario. On the basis of this model, it continues to refine the three core nodes of entities, activities and agents, and strengthens the connection with the field by expanding the lineage relationship and provides support for subsequent process anomaly detection.

[0054] Based on the above principles, this invention models an off-chain transaction as follows:

[0055] PADPM = < ID, NodeID, RelationID, Node, Relation >

[0056] Node = < Entity,Activitiy,Agent>

[0057] Relation = < Influenced,Used,Derived,Included,Invalidate,Producted,Noticed,

[0058] Managed,Delegated,AssociatedWith>

[0059] Among them, ID is the unique identifier of the relationship and node of the lineage model, and NodeID\RelationID represent the unique identifiers of the node and relationship respectively. When collecting data lineage, the log sources vary greatly due to different application fields. Moreover, the lineage data collection method is single, and lacks the concurrent collection of massive logs. When generating the lineage model, there is currently little research on lineage models in the procuratorial field, and the modeling method lacks the support of the procuratorial business background. Moreover, there is a lack of in-depth research on fine-grained, multi-source anomaly interpretation in the anomaly detection process. When expanding the lineage model, the present invention combines the procuratorial business scenario, and refines the lineage nodes (entity\activity\agent) and extends the lineage relationships (influence\use\derivation\inclusion\invalidity\production\notification\management\delegation\association) from the abstract to the concrete hierarchy to ensure the integrity of the lineage data conversion and provide support for subsequent anomaly detection.

[0060] like Figure 1 As shown in the figure, Redis distributed collection logs are automatically converted into lineage data through the lineage data conversion module, using regular matches formed by formal definitions of lineage nodes and relationships. The generated lineage graph is stored in the Neo4j graph database to provide support for anomaly detection.

[0061] After the lineage model is constructed, the lineage graph generated by the lineage model is a directed acyclic graph composed of PADPM models. For abnormal information in the lineage graph, consistency rules can be extracted based on the characteristics of the inspection scenario. Based on the rule constraints, a consistency verification algorithm can be implemented to detect abnormal information.

[0062] The present invention adopts an improved consistency checking method to detect the generated directed acyclic graph.

[0063] like Figure 2 As shown, the lineage graph is a directed acyclic graph, which can be divided into three structural forms: sequential, branching, and closure. Generally, the recursive and iterative method is used to detect abnormal information in the lineage graph, but the detection efficiency is low and the correctness cannot be guaranteed. Figure 1 Based on the characteristics of the lineage graph, the present invention implements a structural incremental detection method. Figure 3 As shown in the figure, in the "public interest litigation case", the consistency check is extended from the sequential structure to the branch structure and the closure structure. After the closure structure is checked, the node is replaced and the sequential structure is checked again.

[0064] In the consistency test method, the lineage consistency rule is used to detect "public interest litigation cases". First, select() queries the graph data Neo4j to obtain the lineage diagram of the case, and Group() can directly obtain the lineage diagram. G(V, E) After consistency checks, sequentially associated nodes E and edges V are expanded into a branching structure and then a closure structure using Extend(). Information about nodes E and edges V is added to this structure, and constraint checks are performed after each addition. Replace() is then used to return to the last node in the closure structure and re-execute Group(). This method incrementally completes consistency checks on the lineage graph. Finally, the closure structure path containing the anomaly and a collection of specific anomaly information are returned to support subsequent process anomaly detection and analysis.

[0065] (2) Anomaly detection and analysis of lineage graph processes

[0066] Specific methods such as Figure 4 As shown in the figure, after the inspection method detects the abnormal information, the process anomaly detection and analysis algorithm (PADA) traverses from the vertex where the anomaly occurs and processes the conflicting data, and reflects the explanatory power of the lineage subgraph for different anomaly types through the explanatory power of the anomaly and density in the lineage graph.

[0067] The first anomaly point found in the procuratorial service lineage graph according to the consistency rule is called the initial detection point (IDP). Starting from the abnormal vertex of the graph, the abnormal information process is captured by the lineage subgraph, thus forming a lineage subgraph that describes different types of abnormal changes. This is an effective method for classifying and displaying abnormal information.

[34] For each IDP vertex, a lineage subgraph of anomaly information of the same type associated with that IDP is generated. Through IDP vertex anomaly tracing queries, an APG graph is generated for the consistency rules corresponding to different anomaly type combinations. This lineage subgraph only contains IDP vertices and related anomaly information. The APG graph generation process is included in the Process Abnormal Detection Analysis (PADA) algorithm.

[0068]

[0069] This algorithm takes the entire lineage graph as input and generates an APG graph set. First, AI is used to represent all abnormal information detected by all rules, and Seen is used to represent the abnormal information found in this tracing process. <idp>The exception information first found in the graph is recorded. Then, the exception information is traversed through the ForwardPath method, which can use the Influenced relationship in the lineage graph to find the path of the exception information through depth-first search. After constructing the IDP graph of the primary exception information vertex, the path is traversed to find the exception information contained under the path. Non-abnormal information is ignored in this path, thereby forming multiple IDP graphs starting with the exception information vertex. Finally, all IDP graph sets containing each exception information are traversed, and the exception information is traversed using the rule combinations corresponding to different exception types to form a new APG graph. As shown in Table 1, the rule combinations corresponding to different exceptions correspond to the six common exception types in the case handling process in the procuratorial scenario mentioned above, and finally the lineage subgraph corresponding to the different exception types is returned.

[0070] Table 1:

[0071]

[0072] In the process anomaly analysis algorithm, the ForwordPath method generates different paths for different anomaly types based on the consistency rules corresponding to the anomaly scenario. With the exception information as a parameter, a For loop will traverse all paths. The GetAbormalInformation method selects the first exception with an IDP vertex as the path. If the path is not empty, the IDPG formed by each IDP vertex during the recursive lineage graph is stored in a collection. The IDPG graph is then traversed, matching different anomaly scenarios according to the corresponding consistency rule definitions. Conflicting data is processed, and nodes and relationships in the lineage graph are connected to generate a lineage subgraph that can explain the source information of different abnormal behaviors.

[0073] The combination of anomaly classification and corresponding consistency rules distinguishes the lineage graph and generates a lineage subgraph of edges and nodes related to the anomaly. This can help prosecutors have a clear understanding of common anomaly types in procuratorial scenarios, which is of great significance for process anomaly analysis during case handling and post-case quality review.

[0074] Furthermore, during the anomaly detection and analysis process, different rules within the same anomaly scenario may contain the same anomaly information after detection when generating a lineage subgraph. For example, in a process detection and analysis method, rule A detects that a document is expired, while rule B detects that the document is not delivered on time. However, these two entities are identical and belong to the same anomaly scenario, resulting in a conflict when generating the lineage subgraph. This invention proposes three methods for handling conflicts in process anomaly detection and analysis: conflict resolution, conflict coverage, and conflict filtering.

[0075] The conflict resolution algorithm of the present invention is to score according to the amount of abnormal information contained after the consistency rule verification when a conflict occurs in the abnormal detection analysis. The lineage subgraph will retain the node with the highest consistency rule score and use the influence relationship to record the abnormal information contained in the rule.

[0076] The conflict coverage algorithm of the present invention scores the nodes with the highest scores according to the consistency rule when a conflict occurs in the anomaly detection analysis, and does not retain the nodes or relationships with low scores.

[0077] The conflict filtering algorithm of the present invention directly filters out conflicts within the anomaly detection and analysis algorithm, without retaining the conflicting anomaly information in the lineage subgraph. Conflict filtering is a specialized algorithm for displaying anomaly information, not reflected in the lineage subgraph.

[0078] Use a PC with LINUX REDHAT operating system as the terminal device, such as Figure 5 As shown, the procuratorial service lineage model construction module and the procuratorial service process anomaly detection module use Spring Boot to quickly integrate and automatically configure the development kit. This eliminates the need to install containers such as Tomcat for web applications and simplifies the construction of the Spring MVC framework. Redis, Mybatis, and Bootstarp middleware are integrated on top of the basic framework to pre-process and save time, user, and case information, ensuring the efficiency of the entire system. The front end provides a convenient human-computer interaction interface, demonstrating lineage data collection and lineage graph generation. It can also perform anomaly detection on lineage graphs generated for different case instances and then generate lineage subgraphs that can explain anomalous behavior. The back end implements data collection, data conversion, model generation, and anomaly detection. After generating the lineage graph, it uses consistency rule verification to detect anomaly information. After analyzing the anomaly information, it generates lineage subgraphs that explain different anomaly types. The database uses Mysql and Neo4j databases for two data forms. The Mysql database will save the case handling logs, process information and system configuration information generated in the unified business platform of the procuratorate. The Neo4j database can save the genealogical chart generated by converting logs into genealogical data in the case handling process.

[0079] Example 2: Figure 6 As shown in the figure, after obtaining all case information, anomaly detection can be performed on each case instance that has generated lineage data. However, this requires generating lineage data before performing anomaly detection. After performing anomaly detection on a case instance that has generated lineage data, if no anomaly information is found, the case instance is normal. Case instances that return anomaly information require further anomaly analysis to provide more granular explanations for different anomaly types.

[0080] Example 3: Figure 7 As shown in the figure, after anomaly detection, clicking the "Anomaly Analysis" button displays multiple lineage subgraphs explaining different abnormal behaviors on the web application frontend page, based on the consistency rules and anomaly analysis modules defined during anomaly detection. Furthermore, based on the aforementioned process anomaly analysis algorithm, multiple lineage subgraphs represent explanations for various anomaly types in procuratorial cases. A drop-down box allows you to select the lineage subgraphs containing the anomaly type. After analysis, a lineage subgraph explaining the missing data in the case is generated. The relationship section turns red, indicating a data missing anomaly in the prosecution process. You can then view case information and the specific missing information for that prosecution process step.

[0081] Example 4: Figure 8 As shown, after expanding the case information of the prosecution link with missing data, the case card items and document information related to it are displayed graphically, and the abnormal case information of this link is specifically displayed at the top, and statistics are made in the table in the upper right corner. Click to view the case information displayed in a timeline format.< / idp> < / idp>

Claims

1. A method for detecting anomalies in inspection process based on data lineage, characterized by The specific steps are as follows: (1) Design a lineage model to support anomaly detection in the collaborative case-handling process of prosecutors First, the collection module uses Redis distributed real-time collection of massive logs from the procuratorate's unified business platform. These logs are then converted through the lineage data conversion module. Regular matching, formed by formally defining refined lineage nodes and extended lineage relationships, is automatically converted into lineage data to generate a lineage graph. The generated lineage graph is then stored in the Neo4j graph database to support anomaly detection. The PROV-DM model defines three top-level nodes: entity, activity, and agent. Based on these three types of nodes, the PADPM lineage model is constructed. The formal definition based on PROV-DM is expressed as: PROV-DM = (Node: [Entity,Activitiy,Agent], Relation: [WasDerivedFrom,Usage, Communication,WasAssociatedWith], Id,[attribute,…]) The lineage model is based on existing procuratorial scenarios. It further refines the three core nodes of entities, activities, and agents. By expanding lineage relationships, it strengthens connections with the field and provides support for subsequent process anomaly detection. Model the lineage model as: PADPM = < ID, NodeID, RelationID, Node, Relation > Node = < Entity,Activitiy,Agent > Relation = < Influenced,Used,Derived,Included,Invalidate,Producted,Noticed, Managed,Delegated,AssociatedWith> Among them: ID is the unique identifier of the relationship and node of the lineage model, NodeID\RelationID are the unique identifiers of the node and relationship respectively; (2) Perform consistency test on the lineage model obtained in step (1) The lineage graph is a directed acyclic graph, which has three structural forms: sequential, branching, and closed. In public interest litigation cases, consistency testing is extended from sequential structures to branching and closed structures. After the closed structure is tested, the node is replaced and the sequential structure is tested again. First, select() queries the graph database Neo4j to obtain the case's lineage diagram, and Group() can directly obtain the lineage diagram G(V,E) After consistency rule verification, sequentially associated nodes E and edges V are expanded into branch structures and closure structures through Extend(). Information about nodes E and edges V is added to this structure, and constraint rule verification is performed after each addition. Replace() is then used to return to the last node in the closure structure and re-execute Group(). This method incrementally completes consistency verification of the lineage graph. Finally, the closure structure path containing the exception and a specific set of exception information are returned to support subsequent process anomaly detection and analysis. (3) Detect and analyze anomalies in the genealogy process The first anomaly point found according to the consistency rules in the lineage graph is called the initial detection point (IDP). Starting from the anomaly vertex, the anomaly information process is captured by the lineage subgraph, forming a lineage subgraph describing the changes of different types of anomalies. For each IDP vertex, a lineage subgraph related to the IDP and belonging to the same type of anomaly information is generated. Through the IDP vertex anomaly traceability query, the consistency rules corresponding to different anomaly type combinations are generated into an APG graph. A lineage subgraph containing only IDP vertices and related anomaly information is included in the Process Abnormal Detection Analysis (PADA) algorithm. Take the entire lineage graph as input and generate an APG graph set. First, use AI to represent all abnormal information detected by all rules, and use Seen to represent the abnormal information found in this tracing process. <idp> The first exception information found in the graph is recorded; then the exception information is traversed through the ForwardPath method, which can use the Influenced relationship in the lineage graph to find the path of the exception information through depth-first search; after constructing the IDP graph of the primary exception information vertex, the path is traversed again to find the exception information contained in the path, and non-abnormal information in this path is ignored, thus forming multiple IDP graphs starting with the exception information vertex; finally, all IDP graph sets containing each exception information are traversed, and the exception information is traversed using the rule combination corresponding to different exception types to form a new APG graph.< / idp>

Images