Project acceptance effect evaluation method and system based on data analysis

Abstract

The invention discloses a project acceptance effect evaluation method and system based on data analysis, and relates to the technical field of data analysis, and the method comprises the steps: extracting acceptance contacts from a project acceptance conclusion, constructing an invertible path set corresponding to each contact, theoretically defining a process behavior record or data evidence which should be left when the invertible path set actually exists, and evaluating the project acceptance effect. And empirical verification is carried out based on data sources such as system logs, process records and document archiving. If it is found that the path is missing, incomplete or conflicted, the contact is marked as a structural support missing contact. The method further integrates the number and importance of the distortion contacts and the coverage range of the distortion contacts in the acceptance conclusion to form an authenticity evaluation result of the acceptance effect. According to the method, based on structural path inversion and support integrity judgment, a counterfeit acceptance conclusion lacking a process basis can be effectively identified, scientificity and credibility of acceptance work are improved, and the problem that an acceptance result is inconsistent with an actual project state and is difficult to identify is solved.

Description

Technical Field

[0001] This invention relates to the field of data analysis technology, specifically to a method and system for evaluating project acceptance results based on data analysis. Background Technology

[0002] With the widespread implementation of various industry support projects, scientific research tasks, information technology projects, and construction projects, project acceptance has become a crucial stage for measuring project outcomes and management efficiency. To enhance the objectivity and scientific rigor of project acceptance, data-driven project acceptance effectiveness evaluation methods have been gradually introduced in recent years. These methods typically collect key indicator data, system operation data, performance data, and testing data during project execution, combining this data with relevant indicators provided in the acceptance conclusion. Through data comparison, deviation calculation, and consistency analysis, they attempt to determine whether the acceptance results align with the actual project situation, thereby assisting in assessing the validity and credibility of the acceptance conclusion. Existing data-driven project acceptance effectiveness evaluations primarily rely on analyzing the numerical relationship between acceptance data and historical project data. For example, by constructing a data indicator system, setting reasonable thresholds, analyzing deviation rates, or introducing machine learning methods to fit and model process data and outcome data, anomalies in the acceptance conclusion can be identified. Some methods also incorporate log verification, process document comparison, and behavioral path tracing to enhance judgment, striving to improve the objectivity and tamper-proof capabilities of acceptance judgments through technological means.

[0003] However, while existing methods have improved in data utilization and technical analysis, they remain fundamentally based on a data-level analytical framework, making it difficult to identify potential distortions or human optimizations in the acceptance process from a behavioral or structural perspective. Particularly in some projects, while the acceptance conclusions may appear to meet standards, the processes supporting these conclusions exhibit unnatural characteristics such as severe compression, falsification, and fabrication, making the acceptance results unable to accurately reflect the project's execution status and actual value. Existing methods often focus on whether the acceptance data appears reasonable, failing to determine whether these results are genuinely supported by behavioral rhythm, preparation logic, and time structure. This makes it difficult to identify and intervene in distorted conclusions in a timely manner. Therefore, there is an urgent need to propose an evaluation mechanism that can judge and identify the authenticity of project acceptance results from a more fundamental perspective. Summary of the Invention

[0004] The purpose of this invention is to address the problem mentioned in the background art that existing methods are unable to identify potential result distortions or human optimization phenomena in the acceptance process from the behavioral or structural levels, and to propose a project acceptance effect evaluation method and system based on data analysis.

[0005] A first aspect of this invention provides a method for evaluating project acceptance effectiveness based on data analysis, the method comprising: Extract at least one acceptance touchpoint from the project acceptance conclusion. The acceptance touchpoint is used to represent the key results or key indicators declared in the acceptance conclusion. For each acceptance touchpoint, construct a set of invertible paths corresponding to it; Based on system logs, process records, document archives, or running trajectories generated during project execution, the set of invertible paths is inverted and verified to determine whether the acceptance touchpoints can be found in the project process data with their corresponding inverted paths. During the inversion verification process, if the inversion path of a certain acceptance touchpoint is missing, incomplete, or conflicts with the project execution record, the acceptance touchpoint will be marked as a touchpoint with missing structural support. The authenticity assessment results of the project acceptance effect are generated based on the number of missing structural support contacts, and the authenticity assessment results are used for subsequent review or acceptance decisions.

[0006] Optionally, for each acceptance contact point, the steps to construct the corresponding set of invertible paths are as follows: Semantic analysis is performed on the acceptance touchpoints, and the entity categories, event types and corresponding process generation conditions involved in the touchpoints are identified based on the preset touchpoint semantic feature library. Based on the entity category and event type of the touchpoint, at least one path composition rule matching the touchpoint is retrieved from the preset path composition rule base. The path composition rule is used to define the behavioral event nodes, data record nodes and document generation nodes that must appear in the implementation process of the touchpoint. Based on the path composition rules obtained through matching, the original data records corresponding to the event nodes are retrieved from the system log sources, task scheduling record tables, data acquisition cache areas and document management systems accessible during project execution, and the retrieval results are sorted by timestamp to form a candidate inversion sequence of touch points. The candidate inversion sequence of touch points is processed by path structuring. Based on the temporal correlation, operational causal relationship and data reference relationship between event nodes, an inversion path object containing at least two source nodes is generated. The inverted path object is matched and verified with the path composition rules corresponding to the acceptance contact. If the inverted path object meets the node coverage requirements and node order requirements defined in the path composition rules, the inverted path object is added to the invertible path set of the contact.

[0007] Optionally, the steps for verifying the set of invertible paths based on system logs, process records, document archives, or runtime trajectories generated during project execution, to determine whether the acceptance touchpoint can find its corresponding invertible path in the project process data, are as follows: Read each invertible path object in the invertible path set in sequence, and extract the source node sequence defined in the invertible path object so that each invertible path object corresponds to a source node sequence to be verified. For each source node in the sequence of source nodes to be verified, based on the node type, time range and data source identifier recorded in the inversion path object, candidate data records corresponding to the source node are retrieved from the system log source, process record table, document archive or running trajectory database formed during project execution, and the candidate data records are combined into a node candidate record set. Based on the candidate record set of each node, according to the order of the source node sequence, the candidate records corresponding to adjacent source nodes are compared for time consistency, trigger relationship and same source reference relationship to generate the node association comparison results, so that each group of adjacent source nodes has the corresponding association comparison results. Based on the comparison results of the association between nodes, all candidate record groups that meet the requirements of time sequence consistency, trigger chain continuity and data reference coherence are selected, and the candidate record groups are combined into an inversion path verification chain according to the sequence order of the source nodes. The inversion path verification chain is structurally compared with its corresponding inversion path object. If the inversion path verification chain covers all the source nodes in the inversion path object and maintains the consistency of the order and the consistency of the association between the source nodes, then the inversion path verification chain is determined to be a valid inversion path; otherwise, the inversion path object is determined to be a path object that has failed inversion verification.

[0008] Optionally, the step of marking the acceptance contact as a contact with missing structural support is as follows: For each acceptance touchpoint, obtain all inversion path objects and their inversion path verification chains from its corresponding inversion path set; For each pair of inverted path objects, the node structure is compared with its verification chain to identify whether there are missing nodes, inconsistent node order, or conflicting node field values ​​in the verification chain, and a difference detection list is generated based on the comparison results. In the difference detection list, if at least one necessary tracing node is missing, or if two or more consecutive nodes have reversed order, conflicting fields, or logical inconsistencies, the inversion path object will be marked as a structurally abnormal path. When all inversion path objects of an acceptance contact are marked as structurally abnormal paths, or when the remaining non-abnormal path objects are insufficient to cover the core support chain originally defined for that contact, the acceptance contact is marked as a structural support missing contact, and its missing type is recorded as one or more of node missing type, sequence break type, or logical conflict type.

[0009] Optionally, the steps for generating a realistic assessment result of the project acceptance effect based on the number of missing structural support contacts are as follows: The concentration distortion index and link breakage index are calculated based on the number of missing structural support contacts. The concentration distortion index and link breakage index are added together to obtain the acceptance result falsification index. The authenticity of the project acceptance effect is judged based on the acceptance result falsification index.

[0010] Optionally, the calculation steps for the lumped distortion index are as follows: For each contact point lacking structural support, extract contact point behavioral feature tags. The behavioral feature tags include at least one of the following: whether the contact points occur within the same time window, whether the project functional modules to which the contact points belong are the same, whether the execution responsible person or acceptance responsible person corresponding to the contact points is the same, and whether the contact points occur in the critical time period before project acceptance. Combine the behavioral feature tags of each contact point to form a feature tag set for the contact point. For any two contact points with missing structural support, the feature tag sets of the two contact points are compared item by item, the number of the two with the same feature tags is counted, and the number of the same feature tags is divided by the total number of feature tags to obtain the set consistency value of the corresponding contact point pair; when the set consistency value of a contact point pair is not lower than the preset judgment threshold, the contact point pair is marked as a high consistency contact point pair. The number of highly consistent contact pairs is counted, and the number of highly consistent contact pairs is divided by the total number of contact pairs to obtain the concentration distortion index.

[0011] Optionally, the calculation steps for the link breakage index are as follows: Abstract the source nodes in the inversion path objects of all structural support missing touch points into nodes of the graph structure, and abstract the temporal sequence, causal relationship or data reference relationship between the source nodes into directed connection edges to construct the project acceptance support graph structure. For the contact path that fails the inversion verification, identify the key nodes that break in the support diagram and record them as a set of broken nodes. For each fracture node, calculate the number of nodes along the longest downstream path that can be reached in the original graph structure, denoted as the number of reachable nodes. Divide the number of reachable nodes by the maximum path length among all paths in the entire support graph to obtain the influence coefficient of the fracture node.

[0012] Optionally, the calculation step of the link breakage index further includes: Starting from all broken nodes, recursively trace all reachable node paths in subsequent directions of the graph structure to construct a set of broken propagation paths. The number of all nodes in the fracture propagation path set is counted, and the ratio is calculated with the total number of nodes in the entire support graph to obtain the coverage ratio of the fracture propagation range. For all inversion path verification chains that fail verification but are not completely interrupted, determine whether there are skip connections, count the number of all skip connection segments, and calculate the ratio with the total number of all path segments that should exist to obtain the skip rate. Select the maximum value among the impact degree coefficients, multiply the maximum impact degree coefficient by the coverage ratio of the break propagation range, and multiply by the jump rate to obtain the link break index.

[0013] Optionally, the steps for determining the authenticity of project acceptance results based on the falsity index are as follows: Compare the falsity index of the acceptance results with a preset threshold. If the falsity index of the acceptance results is less than the preset threshold, it means that the project acceptance effect is genuine. If the falsity index of the acceptance results is not less than the preset threshold, it means that the project acceptance effect is fake.

[0014] A second aspect of this invention provides a project acceptance effect evaluation system based on data analysis, the system comprising: Acceptance Point Module: Extract at least one acceptance touchpoint from the project acceptance conclusion. The acceptance touchpoint is used to represent the key results or key indicators declared to have been achieved in the acceptance conclusion. Reversible Path Module: For each acceptance touchpoint, construct a set of reversible paths corresponding to it; Inversion module: Based on system logs, process records, document archives or running trajectories generated during project execution, the inversion verification of the set of invertible paths is performed to determine whether the acceptance touchpoint can find its corresponding inversion path in the project process data; Missing Module: During the inversion verification process, if the inversion path of a certain acceptance touchpoint is missing, incomplete, or conflicts with the project execution record, the acceptance touchpoint will be marked as a structural support missing touchpoint. Evaluation module: Generates a realistic evaluation result of the project acceptance effect based on the number of missing structural support contacts, and uses the realistic evaluation result for subsequent review or acceptance decision.

[0015] The beneficial effects of this invention are: This invention proposes a data analysis-based method and system for evaluating project acceptance effectiveness. It extracts acceptance touchpoints from project acceptance conclusions, constructs a set of invertible paths for each touchpoint, theoretically defines the process behavior records or data evidence that should exist when these paths actually exist, and conducts empirical verification based on data sources such as system logs, process records, and document archives. If a path is found to be missing, incomplete, or conflicting, the touchpoint is marked as a structural support deficiency touchpoint. The method further integrates the number, importance, and coverage of distorted touchpoints in the acceptance conclusions to form a genuine evaluation result of the acceptance effectiveness. Compared to traditional methods based on numerical values ​​or reports, this method, based on structural path inversion and support integrity judgment, can effectively identify falsified acceptance conclusions lacking process evidence, improve the scientific rigor and credibility of the acceptance work, and solve the problem of inconsistencies between acceptance results and the actual project status, which are difficult to identify. Attached Figure Description

[0016] Figure 1 A flowchart of a project acceptance effect evaluation method based on data analysis provided in an embodiment of the present invention; Figure 2 This is a framework diagram of a project acceptance effect evaluation system based on data analysis, provided for an embodiment of the present invention. Detailed Implementation

[0017] To further illustrate the technical means and effects adopted by the present invention in order to achieve the intended purpose, the following detailed description is provided in conjunction with the accompanying drawings and preferred embodiments, based on the specific implementation methods, structures, features and effects of the present invention.

[0018] This invention provides a method for evaluating project acceptance effectiveness based on data analysis. See also... Figure 1 , Figure 1 A flowchart illustrating a project acceptance effectiveness evaluation method based on data analysis, provided as an embodiment of the present invention. The method includes the following steps: S1: Extract at least one acceptance touchpoint from the project acceptance conclusion. The acceptance touchpoint is used to represent the key results or key indicators declared to have been achieved in the acceptance conclusion. S2: For each acceptance touchpoint, construct a set of invertible paths corresponding to it. The set of invertible paths is used to represent the traceable behavior records, process data or supporting evidence that should be formed during the project execution if the acceptance touchpoint actually exists. S3: Based on system logs, process records, document archives or running trajectories generated during project execution, perform inversion verification on the set of invertible paths to determine whether the acceptance touchpoint can find its corresponding inversion path in the project process data; S4: During the inversion verification process, if the inversion path of a certain acceptance touchpoint is missing, incomplete, or conflicts with the project execution record, the acceptance touchpoint will be marked as a touchpoint with missing structural support. S5: Generate a authenticity assessment result of the project acceptance effect based on the number of missing structural support contacts, and use the authenticity assessment result for subsequent review or acceptance decision.

[0019] This invention provides a data analysis-based method for evaluating project acceptance effectiveness. By extracting acceptance touchpoints from project acceptance conclusions, the method identifies core deliverables or key indicators requiring verification. For each acceptance touchpoint, a set of invertible paths that should exist is constructed, theoretically defining the traceable behavioral records or data evidence that should be left during project execution if the touchpoint truly exists. Subsequently, the method empirically retrieves and verifies these inverted paths based on data sources such as system logs, process records, document archives, or runtime trajectories to determine whether each acceptance touchpoint possesses its expected true generation trajectory. When inverted paths for certain acceptance touchpoints are detected to be missing, incomplete, or conflicting, the method marks them as structurally deficient touchpoints and constructs a support integrity evaluation framework for the project acceptance conclusions based on this. Finally, the method comprehensively considers the number, importance, and coverage of distorted touchpoints in the overall acceptance conclusions to output the authenticity evaluation result of the project acceptance effectiveness. This method no longer relies on traditional numerical comparisons or single report judgments, but instead identifies authenticity based on touch point inversion and structural support integrity. It can effectively discover potential fraudulent acceptance conclusions that appear to be qualified but lack process support, thereby improving the credibility and scientific nature of project acceptance work. It solves the core problem in existing technologies where acceptance results are inconsistent with the actual state of the project and are difficult to identify.

[0020] In one embodiment, S1: Extract at least one acceptance touchpoint from the project acceptance conclusion. The acceptance touchpoint is used to represent the key results or key indicators declared to have been achieved in the acceptance conclusion. It should be noted that extracting at least one acceptance touchpoint from the project acceptance conclusion in step S1 is the starting point of the method of this invention. An acceptance touchpoint refers to a key achievement, indicator, function, or state that is explicitly stated in the project acceptance report or conclusion as completed, achieved, realized, or possessed. These are typically the core content used in the acceptance process to determine whether a project is qualified; examples include the proportion of R&D expenditure, the number of valid invention patents, the number of industry-university-research cooperation projects, new product sales revenue, the number of standards participated in, and the number of provincial-level R&D platforms established. These touchpoints often directly affect the score composition of the technology center's level assessment. Therefore, in this step, the core task is not to directly process data, but to identify and parse these achievement descriptions from the acceptance text, and to establish a structured list of touchpoints to be verified through semantic parsing, rule extraction, or template recognition, thus clarifying the target points for subsequent inversion verification. This structured processing provides a logical starting point and task boundaries for subsequent path construction, data comparison, and authenticity assessment, ensuring that the entire assessment method closely addresses the core issue of whether the results declaration is authentic and traceable. It is particularly suitable for verifying and supporting the investigation of whether there are instances of falsified indicators, misreported data, or unrealized results in the evaluation conclusions of enterprise technology centers.

[0021] In one embodiment, S2: For each acceptance touchpoint, construct a set of invertible paths corresponding to it. The set of invertible paths is used to represent the traceable behavior records, process data or supporting evidence that should be formed during the project execution if the acceptance touchpoint actually exists. In one implementation, the steps for constructing a set of reversible paths corresponding to each acceptance touchpoint are as follows: Semantic analysis is performed on the acceptance touchpoints, and the entity categories, event types and corresponding process generation conditions involved in the touchpoints are identified based on the preset touchpoint semantic feature library. Based on the entity category and event type of the touchpoint, at least one path composition rule matching the touchpoint is retrieved from the preset path composition rule base. The path composition rule is used to define the behavioral event nodes, data record nodes and document generation nodes that must appear in the implementation process of the touchpoint. Based on the path composition rules obtained through matching, the original data records corresponding to the event nodes are retrieved from the system log sources, task scheduling record tables, data acquisition cache areas and document management systems accessible during project execution, and the retrieval results are sorted by timestamp to form a candidate inversion sequence of touch points. The candidate inversion sequence of touch points is processed by path structuring. Based on the temporal correlation, operational causal relationship and data reference relationship between event nodes, an inversion path object containing at least two source nodes is generated. The inverted path object is matched and verified with the path composition rules corresponding to the acceptance contact. If the inverted path object meets the node coverage requirements and node order requirements defined in the path composition rules, the inverted path object is added to the invertible path set of the contact.

[0022] It should be noted that the above steps are illustrated with an example: for each acceptance touchpoint extracted from the acceptance conclusion, the system needs to construct its corresponding set of reversible paths. This means defining and extracting the traceable behavioral records and supporting evidence chains that should theoretically remain if the touchpoint actually existed during the project's execution. Specifically, the touchpoint content is first semantically parsed. For example, the touchpoint of achieving a valid invention patent is mapped to an intellectual property entity and a results-output event, and its generation conditions typically include multiple stages such as patent application, authorization, maintenance fee payment, related R&D projects, and economic transformation. Subsequently, the system matches the key nodes that this type of touchpoint should include from the path composition rule base, such as patent authorization certificate generation, patent fee payment record entry, patent-project association record registration, patent transformation revenue accounting, and patent inclusion in the company's annual intellectual property statistical report. Based on this rule, the system will retrieve patent lists and certificate documents from the patent database, extract patent annuity payment records from the financial subsystem, and locate whether the patent belongs to the science and technology project listed during the application from the R&D task archive records, such as the corresponding project number in the "Technology Center Application Materials," which includes the "Unit R&D Project Information Table" and the "Unit R&D Activities and Related Information Table" (the names of the materials listed here are for illustrative purposes only and are not specific limitations). Furthermore, it will trace whether the patent has generated direct economic benefits from ERP or financial statements, such as whether there are sales records of converted products or revenue recognition included in other business income. All retrieved process data will be sorted by timestamp to initially form candidate inversion paths. Next, the system will structure the paths according to the sequence of events (e.g., authorization before conversion), causal relationships (e.g., sales only occur with a patent), and data reference relationships (e.g., consistency of project number in patent ownership and financial statements), generating an inversion path object containing multiple tracing nodes. Finally, the system performs a structural comparison between the path object and the original composition rules to determine whether it covers all the key nodes that should appear, whether the order is reasonable, and whether the association is closed. If the match is successful, the path is included in the invertible path set of the acceptance touchpoint, serving as supporting evidence for subsequent verification of the touchpoint's authenticity. This completes the mapping from the theoretical support chain of the touchpoint to the actual data chain. This process not only bridges the gap between semantic conclusions and data evidence but also ensures the logical closure and repeatability of the authenticity verification process.

[0023] In one embodiment, S3: Based on system logs, process records, document archives, or runtime trajectories generated during project execution, the set of invertible paths is inverted and verified to determine whether the acceptance touchpoint can find its corresponding inverted path in the project process data. Read each invertible path object in the invertible path set in sequence, and extract the source node sequence defined in the invertible path object so that each invertible path object corresponds to a source node sequence to be verified. For each source node in the sequence of source nodes to be verified, based on the node type, time range and data source identifier recorded in the inversion path object, candidate data records corresponding to the source node are retrieved from the system log source, process record table, document archive or running trajectory database formed during project execution, and the candidate data records are combined into a node candidate record set. Based on the candidate record set of each node, according to the order of the source node sequence, the candidate records corresponding to adjacent source nodes are compared for time consistency, trigger relationship and same source reference relationship to generate the node association comparison results, so that each group of adjacent source nodes has the corresponding association comparison results. Based on the comparison results of the association between nodes, all candidate record groups that meet the requirements of time sequence consistency, trigger chain continuity and data reference coherence are selected, and the candidate record groups are combined into an inversion path verification chain according to the sequence order of the source nodes. The inversion path verification chain is structurally compared with its corresponding inversion path object. If the inversion path verification chain covers all the source nodes in the inversion path object and maintains the consistency of the order and the consistency of the association between the source nodes, then the inversion path verification chain is determined to be a valid inversion path; otherwise, the inversion path object is determined to be a path object that has failed inversion verification.

[0024] It should be noted that in this step, the system will verify each invertible path set constructed in the previous step to determine whether each acceptance touchpoint has left traceable process evidence in the project execution data. Specifically, the system first reads each invertible path object in the invertible path set in sequence and extracts the predefined traceability node sequence. For example, for the acceptance touchpoint of valid invention patent achievement, its traceability node sequence may include patent authorization certificate generation, payment record archiving, project ownership confirmation, conversion revenue registration, etc. The system will use this sequence as an index to locate the candidate data record of each node from multiple data sources: for example, querying the intellectual property management system to see if there is a patent authorization certificate PDF file and its number, extracting the annual fee payment flow corresponding to the patent number from the financial system, checking whether the patent has been successfully applied for under the project number bound in the "Technology Center Application Materials" from the project task database, and searching the financial module for sales records or conversion revenue accounting vouchers associated with the patent. Each traceability node forms a set of candidate records. The system sequentially compares the candidate records of adjacent nodes to determine if there is a reasonable temporal relationship (e.g., patent authorization time precedes revenue receipt time), operational logic chain (e.g., payment is triggered by the patent department to file subsequent records), and whether cross-table fields can reference each other (e.g., project number remains consistent in the patent database and task database). If the comparison results show that there is a reasonable and consistent connection relationship between each set of nodes, the system combines these records into a complete inversion path verification chain. Next, the system performs a structural comparison of this verification chain with the original path object. If all traceability nodes are covered and the connection logic matches, the path is determined to be a valid inversion path, indicating that the contact point has a complete and traceable support chain; otherwise, if there are missing nodes, reversed order, or conflicting reference relationships, it is marked as a failed verification path object. Through this rigorous data-level comparison and structural verification mechanism, the system can effectively identify false contact points that superficially claim to meet standards but lack process support, improving the evaluation process's ability to identify the authenticity of results.

[0025] In one embodiment, S4: During the inversion verification process, when the inversion path of an acceptance contact is missing, incomplete, or conflicts with the project execution record, the step of marking the acceptance contact as a contact with missing structural support is as follows: For each acceptance touchpoint, obtain all inversion path objects and their inversion path verification chains from its corresponding inversion path set; For each pair of inverted path objects, the node structure is compared with its verification chain to identify whether there are missing nodes, inconsistent node order, or conflicting node field values ​​in the verification chain, and a difference detection list is generated based on the comparison results. In the difference detection list, if at least one necessary tracing node is missing, or if two or more consecutive nodes have reversed order, conflicting fields, or logical inconsistencies, the inversion path object will be marked as a structurally abnormal path. When all the inversion path objects of a certain acceptance contact are marked as structurally abnormal paths, or when the remaining non-abnormal path objects are insufficient to cover the core support chain originally defined for that contact, the acceptance contact is marked as a structural support missing contact, and its missing type is recorded as one or more of node missing type, sequence break type, or logical conflict type. Output all acceptance touchpoints marked as lacking structural support as an anomaly alert list for acceptance authenticity assessment, for subsequent review or risk assessment.

[0026] It should be noted that, for each acceptance touchpoint, the system retrieves all inversion path objects generated in step S2 and their corresponding inversion path verification chains formed in step S3. The goal of the system is to identify those acceptance touchpoints that, although declared as achieved in the acceptance conclusion, have missing, incomplete, or logically conflicting inversion path verification chains, and mark them as touchpoints with missing structural support. Specifically, the system first retrieves all inversion path objects generated in step S2 and their corresponding verification chains formed in step S3 for each acceptance touchpoint. Then, the system performs a node structure comparison on each pair of path objects and verification chains, checking one by one whether key traceability nodes failed to be successfully inverted (i.e., missing), whether the node execution order violates the normal logical flow (i.e., disordered order), and whether field values ​​are inconsistent across nodes or systems (e.g., conflicting project numbers, patent numbers, or responsible person IDs). The system summarizes the above comparison results into a discrepancy detection list. If at least one necessary node is missing in a verification chain, or if two or more consecutive nodes exhibit significant anomalies such as reversed order or conflicting fields, the path object is marked as a structurally abnormal path. When all path objects under an acceptance touchpoint are marked as structurally abnormal, or although some paths are not abnormal, the scope of nodes covered is insufficient to meet the core support requirements of that touchpoint (for example, the rule requires verification of at least three nodes: patent authorization, payment record, and conversion revenue, but the verification chain only completes the first two), then the entire touchpoint is judged as a touchpoint with missing structural support. For example, if a company declares that it has two valid invention patents in the technology center evaluation, but the system only retrieves one authorization certificate and payment record in the data, and the other only has application information without subsequent supporting data; or if a company applies to carry out three industry-university-research cooperation projects, but the system only retrieves one project with a cooperation agreement and funding disbursement record, and the remaining projects have task numbers in the task management system but lack any contracts, invoices, or research activity records, such situations will be judged as having a serious lack of supporting structure. The system ultimately outputs a list of all missing structural support points for subsequent verification or as a risk warning reference, ensuring that the project acceptance conclusions are supported by data rather than just superficial descriptions.

[0027] In one embodiment, S5: Generate a authenticity assessment result of the project acceptance effect based on the number of missing structural support contacts, and use the authenticity assessment result for subsequent review or acceptance decision.

[0028] In one implementation, S5: The step of generating the authenticity assessment result of the project acceptance effect based on the number of missing structural support contacts is as follows: The concentration distortion index and link breakage index are calculated based on the number of missing structural support contacts. The concentration distortion index and link breakage index are added together to obtain the acceptance result falsification index. The authenticity of the project acceptance effect is judged based on the acceptance result falsification index.

[0029] In one embodiment, the calculation steps for the lumped distortion index are as follows: For each contact point lacking structural support, extract contact point behavioral feature tags. The behavioral feature tags include at least one of the following: whether the contact points occur within the same time window, whether the project functional modules to which the contact points belong are the same, whether the execution responsible person or acceptance responsible person corresponding to the contact points is the same, and whether the contact points occur in the critical time period before project acceptance. Combine the behavioral feature tags of each contact point to form a feature tag set for the contact point. For any two contact points with missing structural support, the feature tag sets of the two contact points are compared item by item, the number of the two with the same feature tags is counted, and the number of the same feature tags is divided by the total number of feature tags to obtain the set consistency value of the corresponding contact point pair; when the set consistency value of a contact point pair is not lower than the preset judgment threshold, the contact point pair is marked as a high consistency contact point pair. The number of highly consistent contact pairs is counted, and the number of highly consistent contact pairs is divided by the total number of contact pairs to obtain the concentration distortion index. The concentration distortion index is used to determine the degree of concentration of structural support missing contacts in the overall distribution. The concentration distortion index is used to characterize whether all missing contacts exhibit clustering, commonality, or unnatural distribution characteristics. This allows the concentration distortion index to characterize the degree of clustering of structural support missing contacts in terms of time, personnel, modules, or acceptance stages, thereby reflecting the degree of suspicion of organized falsification or centralized tampering of project acceptance results.

[0030] It should be noted that the data sources for the touchpoint behavioral feature labels involved in the calculation steps of the concentration distortion index all come from the meta-information analysis and process data extraction of touchpoints with structural support deficiencies during project execution. Specifically, this includes the module classification involved in the inversion path for each touchpoint (such as "R&D personnel", "intellectual property", "industry-university-research cooperation", "expenditure"), trigger time (such as whether it occurs within one week before acceptance), responsible entity information (such as the project team, executor, and acceptor), and the stage of the event (such as the task execution stage, the results transformation stage, or the acceptance preparation stage). This information is mainly extracted and generated from various business systems or acceptance documents, including task scheduling tables in the enterprise R&D management system, R&D personnel lists and participation records in the human resources system, fund usage nodes in the financial system, and records such as contracts, agreements, and meeting minutes in the document archiving system. For example, during the evaluation of an enterprise technology center, if the system finds that multiple structural support deficiencies are concentrated in the "R&D Personnel" module, manifested as the inability to derive personnel records from the number of PhDs, the lack of contracts and labor records for external experts, and the absence of system operation tracks or attendance records for multiple personnel in the core project team, the system will categorize these behavioral characteristics into the same module, the same time period, and the same responsibility domain. During the comparison process, it will identify highly consistent tag sets, thus determining them as "high-consistency touchpoint pairs." Further, by calculating the proportion of high-consistency touchpoint pairs, a concentration distortion index is derived. Such highly clustered anomalies are often not accidental; the system infers the potential for concentrated fabrication, organized data filling, etc., indicating "significant doubts about the overall authenticity of the R&D team." Therefore, the concentration distortion index not only reflects the distribution structure of missing touchpoints but is also a crucial basis for identifying whether there is unnatural behavior such as concentrated fabrication or selective data filling in the project.

[0031] In the above steps, the system calculates a concentration distortion index through structural extraction and automatic comparison to identify whether there are obvious concentrated distribution characteristics of acceptance touchpoints with structural support deficiencies. First, the system extracts behavioral feature tags for each acceptance touchpoint identified as having structural support deficiencies. These tags correspond to four dimensions: time dimension, module dimension, personnel dimension, and node timing dimension. Whether the time is within the same window can be determined by extracting the failure timestamp of the touchpoint and clustering the timestamps into hourly time buckets. Whether the functional modules are the same can be obtained through the module number field bound to the inverted path object, which is usually mapped to the system module ID during the path construction process. Whether the responsible persons are the same is extracted from the task responsible person field in the acceptance scheduling record or operation log. Whether it is a critical stage is determined by comparing the touchpoint time with the preset formal acceptance time in the system to determine whether it is within the previous 24 hours. Subsequently, the system packages the four tags of each touchpoint into a tag set, compares the tag sets of all touchpoints pairwise, counts the number of overlapping tags for each pair, and calculates the concentration consistency value by dividing the number of overlapping tags by the total number of tags (i.e., 4). If the concentration consistency value of a pair of touchpoints is greater than a set threshold (e.g., 0.75), it is marked as a high-consistency touchpoint pair. The system continues to count the number of all high-consistency touchpoint pairs and calculates the concentration distortion index by proportionally calculating the total number of touchpoint pairs. For example, if all structural support deficiencies in a company's touchpoints are concentrated in the R&D personnel module (no support for PhDs or external experts per month), the concentration distortion index is high, suggesting potential fraud by the R&D team. Therefore, the consistency value of any pairwise comparison will be 1.0, and all such pairs will be marked as high-consistency touchpoint pairs. Ultimately, the concentration distortion index for this type of touchpoint will be 1, and the system will determine that there is significant suspicion of organized fraud. This process requires no manual operation and is entirely automated based on touchpoint logs, module structure tables, acceptance responsibility tables, and time settings, ensuring repeatable and consistent results.

[0032] It should be noted that the Concentration Distortion Index is an indicator used to measure whether structural support deficiencies are highly concentrated during project acceptance. Specifically, it is used to determine whether these deficiencies occur in a specific time period, within a specific functional module, under specific personnel responsibilities, or at a specific acceptance stage, thereby revealing whether these distortions are organized, batch-based, and unnatural. Essentially, it reflects whether abnormal acceptance conclusions in a project have a high degree of commonality and simultaneity, rather than being random, discrete, or sporadic individual errors or oversights that may occur randomly during normal project execution. The reason why a higher concentration distortion index indicates a lower level of project acceptance authenticity is that, in actual execution, the generation of various deliverables is often distributed across different times, driven independently by different modules and personnel. It is unlikely that they would fail simultaneously in a very short period of time, by the same person in charge, and concentrated in a specific functional area. Conversely, if the system detects that the supporting structures of multiple touchpoints fail almost simultaneously, with overlapping modules, the same person in charge, and all occurring within the critical period before acceptance, this high degree of consistency is unlikely to be accidental. Rather, it is more likely a concentrated act of fraud under human manipulation. Therefore, if the system calculates a concentration distortion index close to 1, it can infer that the authenticity of the project deliverables is seriously questionable and prompts the triggering of a deep review mechanism. Thus, the concentration distortion index is not just a mathematical ratio, but a key indicator for identifying whether a project involves purposeful concentrated forgery. A higher value indicates stronger commonalities and a more unnatural appearance among the abnormal touchpoints, making it more likely to constitute systemic acceptance fraud.

[0033] In one implementation, the calculation steps for the link breakage index are as follows: Abstract the source nodes in the inversion path objects of all structural support missing touch points into nodes of the graph structure, and abstract the temporal sequence, causal relationship or data reference relationship between the source nodes into directed connection edges to construct the project acceptance support graph structure. For the contact path that fails the inversion verification, identify the key nodes that break in the support diagram and record them as a set of broken nodes. For each broken node, calculate the number of nodes in the longest downstream path that can be reached in the original graph structure, and denot it as the number of reachable nodes. Divide the number of reachable nodes by the maximum path length among all paths in the entire support graph to obtain the influence degree coefficient of the broken node, which represents the link collapse depth that may be caused by its breakage. Starting from all broken nodes, recursively trace all reachable node paths in subsequent directions of the graph structure to construct a set of broken propagation paths. The number of all nodes in the fracture propagation path set is counted and the ratio is calculated with the total number of nodes in the entire support diagram to obtain the coverage ratio of the fracture propagation range, which is used to measure the size of the area affected by the fracture in the support structure. For all inversion path verification chains that fail to be verified but are not completely interrupted, determine whether there is a skip connection phenomenon, that is, an abnormal path structure in which some intermediate tracing nodes are missing but the start and end nodes are still connected. The number of all skip connection segments is counted and the ratio is calculated with the total number of all path segments that should exist. The skip rate is used to characterize whether abnormal links have non-natural path behaviors such as manual splicing or skipping completion. Select the maximum value among the impact degree coefficients, multiply the maximum impact degree coefficient by the coverage ratio of the break propagation range, and multiply by the jump rate to obtain the link break index.

[0034] It should be noted that all data involved in the calculation of the link breakage index comes from the structural analysis of the inversion path objects of each acceptance touchpoint and traceable information such as system logs, task scheduling records, data write events, and call trajectory data generated during project execution. Specifically, this includes: the timestamp, node type, upstream dependencies, and path verification status of each traceable node and its corresponding touchpoint. The system automatically extracts these nodes and their logical relationships during the inversion path construction process and builds a complete acceptance support diagram within the system. Each node in the diagram represents a necessary process behavior, such as device registration, data acquisition initiation, data caching, or page display, while the edges represent their sequential execution relationships or data dependencies. For example, in the evaluation of a company's technology center, if the system finds that although R&D expenditures are recorded in the "Unit R&D Activities and Related Information Table," but no corresponding R&D project task ledger can be found in the "Unit R&D Project Information Table," or the task ledger does not record any personnel participation, equipment usage records, or other execution traces, it indicates that the expenditure has not formed a genuine R&D behavior chain. In this case, the expenditure node is a breakpoint. Its absence will prevent the subsequent paths of personnel support for output and expense reimbursement from being constructed. The system judges the link to be severely broken, with a wide range of breakage propagation, and the link breakage index value will increase significantly, thus indicating that the contact point has a risk of financial authenticity or structural fraud. Through this index, the system can identify potential problematic contact points that appear compliant but have broken process support from the perspective of path structure, improving the depth and accuracy of project acceptance authenticity evaluation.

[0035] It should be noted that the Link Breakage Index is a quantitative indicator used to measure whether critical structural breaks have occurred in the support chain during project acceptance, and whether the path structure has been tampered with or damaged. Its essential purpose is to assess the structural continuity, stability, and authenticity of the project acceptance support process. This index analyzes the breakage of critical nodes in the support chain, the extent of the impact after a break, and whether there are path jumps or unnatural connections to determine whether the acceptance support chain conforms to the actual execution logic and whether there are any abnormal structures that have been artificially forged, patched, spliced, or cut. The reason why a higher link breakage index indicates a lower authenticity of project acceptance is that a genuine acceptance chain should have a clear structural closure and a natural causal sequence. For example, a platform launch touchpoint should have a complete path including deployment, initialization, user access, and data writing nodes, with clear log records and time logic between these nodes. If a break occurs in this chain, especially a break in the critical path's initial stage (such as a missing deployment stage), and this break causes a large number of downstream node structures to fail, or even a jump-and-stitch phenomenon where the beginning and end are connected but the middle is missing, it means that the entire support path lacks a natural evolution process and is very likely a temporary chain created or data simulated to pass acceptance. For example, if the system detects that the data collection node and the display page node in a certain touchpoint path both have logs, but the data entry node that should exist in the middle is completely missing, and there are large blank areas in the path, and the propagation effect caused by the structural breakage node affects multiple other paths, the system will determine that the structure does not have a reliable closed loop, the link breakage index will increase, reflecting a serious distortion of the support of the project acceptance results. Therefore, this index not only focuses on whether there is a break, but also considers the location of the break, the scope of the impact, and whether there are splicing marks, which can comprehensively reveal the real defects and structural integrity risks in the project acceptance process.

[0036] In one embodiment, the steps for determining the authenticity of project acceptance results based on the falsehood index are as follows: Compare the falsity index of the acceptance results with a preset threshold. If the falsity index of the acceptance results is less than the preset threshold, it means that the project acceptance effect is genuine. If the falsity index of the acceptance results is not less than the preset threshold, it means that the project acceptance effect is fake.

[0037] It should be noted that the calculated falsification index is compared with the system's preset judgment threshold. If the falsification index is less than the threshold, it indicates that the structural support deficiencies in the project are still within a reasonable range in terms of distribution and link structure, without showing abnormal concentration or severe breakage. Therefore, it can be preliminarily determined that the project's acceptance conclusion and process behavior are basically consistent and have high authenticity. Conversely, if the falsification index is greater than or equal to the preset threshold, it indicates that there are multiple support deficiencies concentrated in one area, severe link structure breakage, support logic jumps, and other unnatural behaviors in the project, which are very likely the result of human manipulation or data falsification. In this case, the system... The system will determine if the authenticity of the project acceptance results is questionable and may trigger subsequent manual review or risk warning processes. For example, in an acceptance scenario, it was found that most of the missing touchpoints were concentrated in the three hours before acceptance, all controlled by the same person. The data acquisition and database writing nodes in the link structure were completely missing. The system calculated a concentration distortion index of 0.92, a link breakage index of 0.85, and a synthetic falsification index of 0.89, which exceeded the system's preset threshold of 0.75. Therefore, the system automatically determined that the authenticity of the project acceptance conclusion was seriously insufficient and suggested initiating a review mechanism to ultimately achieve an objective, quantifiable, and structurally logical authenticity assessment of the project results.

[0038] Based on the same inventive concept, this invention also provides a project acceptance effect evaluation system based on data analysis. See also Figure 2 , Figure 2 A framework diagram of a project acceptance effect evaluation system based on data analysis, provided for embodiments of the present invention, includes: Acceptance Point Module: Extract at least one acceptance touchpoint from the project acceptance conclusion. The acceptance touchpoint is used to represent the key results or key indicators declared to have been achieved in the acceptance conclusion. Reversible Path Module: For each acceptance touchpoint, a set of reversible paths is constructed. The set of reversible paths is used to represent the traceable behavior records, process data or supporting evidence that should be formed during the project execution if the acceptance touchpoint actually exists. Inversion module: Based on system logs, process records, document archives or running trajectories generated during project execution, the inversion verification of the set of invertible paths is performed to determine whether the acceptance touchpoint can find its corresponding inversion path in the project process data; Missing Module: During the inversion verification process, if the inversion path of a certain acceptance touchpoint is missing, incomplete, or conflicts with the project execution record, the acceptance touchpoint will be marked as a structural support missing touchpoint. Evaluation module: Generates a realistic evaluation result of the project acceptance effect based on the number of missing structural support contacts, and uses the realistic evaluation result for subsequent review or acceptance decision.

[0039] This invention provides a data analysis-based project acceptance effectiveness evaluation system. By extracting acceptance touchpoints from project acceptance conclusions, the system identifies core deliverables or key indicators requiring verification. For each acceptance touchpoint, a set of invertible paths is constructed, theoretically defining the traceable behavioral records or data evidence that should exist during project execution if the touchpoint truly exists. Subsequently, the system empirically retrieves and verifies these inverted paths based on data sources such as system logs, process records, document archives, or runtime trajectories to determine if each acceptance touchpoint possesses its expected true generation trajectory. When inverted paths for certain acceptance touchpoints are detected to be missing, incomplete, or conflicting, the system marks them as structurally deficient touchpoints and uses this as the basis for constructing a support integrity evaluation framework for the project acceptance conclusions. Finally, the system comprehensively considers the number, importance, and coverage of distorted touchpoints within the overall acceptance conclusions to output the authenticity evaluation result of the project acceptance effectiveness. This method no longer relies on traditional numerical comparisons or single report judgments, but instead identifies authenticity based on touch point inversion and structural support integrity. It can effectively discover potential fraudulent acceptance conclusions that appear to be qualified but lack process support, thereby improving the credibility and scientific nature of project acceptance work. It solves the core problem in existing technologies where acceptance results are inconsistent with the actual state of the project and are difficult to identify.

[0040] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention should still fall within the scope of the claims of the present invention.

Claims

1. A method for evaluating project acceptance effectiveness based on data analysis, characterized in that, Includes the following steps: Extract at least one acceptance touchpoint from the project acceptance conclusion. The acceptance touchpoint is used to represent the key results or key indicators declared in the acceptance conclusion. For each acceptance touchpoint, construct a set of invertible paths corresponding to it; Based on system logs, process records, document archives, or running trajectories generated during project execution, the set of invertible paths is inverted and verified to determine whether the acceptance touchpoints can be found in the project process data with their corresponding inverted paths. During the inversion verification process, if the inversion path of a certain acceptance touchpoint is missing, incomplete, or conflicts with the project execution record, the acceptance touchpoint will be marked as a touchpoint with missing structural support. The authenticity assessment results of the project acceptance effect are generated based on the number of missing structural support contacts, and the authenticity assessment results are used for subsequent review or acceptance decisions.

2. The project acceptance effect evaluation method based on data analysis according to claim 1, characterized in that, For each acceptance touchpoint, the steps to construct its corresponding set of invertible paths are as follows: Semantic analysis is performed on the acceptance touchpoints, and the entity categories, event types and corresponding process generation conditions involved in the touchpoints are identified based on the preset touchpoint semantic feature library. Based on the entity category and event type of the touchpoint, at least one path composition rule matching the touchpoint is retrieved from the preset path composition rule base. The path composition rule is used to define the behavioral event nodes, data record nodes and document generation nodes that must appear in the implementation process of the touchpoint. Based on the path composition rules obtained through matching, the original data records corresponding to the event nodes are retrieved from the system log sources, task scheduling record tables, data acquisition cache areas and document management systems accessible during project execution, and the retrieval results are sorted by timestamp to form a candidate inversion sequence of touch points. The candidate inversion sequence of touch points is processed by path structuring. Based on the temporal correlation, operational causal relationship and data reference relationship between event nodes, an inversion path object containing at least two source nodes is generated. The inverted path object is matched and verified with the path composition rules corresponding to the acceptance contact. If the inverted path object meets the node coverage requirements and node order requirements defined in the path composition rules, the inverted path object is added to the invertible path set of the contact.

3. The project acceptance effect evaluation method based on data analysis according to claim 1, characterized in that, Based on system logs, process records, document archives, or runtime trajectories generated during project execution, the steps for inverting and verifying the set of invertible paths to determine whether an acceptance touchpoint can find its corresponding inverted path in the project process data are as follows: Read each invertible path object in the invertible path set in sequence, and extract the source node sequence defined in the invertible path object so that each invertible path object corresponds to a source node sequence to be verified. For each source node in the sequence of source nodes to be verified, based on the node type, time range and data source identifier recorded in the inversion path object, candidate data records corresponding to the source node are retrieved from the system log source, process record table, document archive or running trajectory database formed during project execution, and the candidate data records are combined into a node candidate record set. Based on the candidate record set of each node, according to the order of the source node sequence, the candidate records corresponding to adjacent source nodes are compared for time consistency, trigger relationship and same source reference relationship to generate the association comparison results between nodes, so that each group of adjacent source nodes has the corresponding association comparison results. Based on the comparison results of the association between nodes, all candidate record groups that meet the requirements of time sequence consistency, trigger chain continuity and data reference coherence are selected, and the candidate record groups are combined into an inversion path verification chain according to the sequence order of the traceability nodes. The inversion path verification chain is structurally compared with its corresponding inversion path object. If the inversion path verification chain covers all the source nodes in the inversion path object and maintains the consistency of the order and the consistency of the association between the source nodes, then the inversion path verification chain is determined to be a valid inversion path; otherwise, the inversion path object is determined to be a path object that has failed inversion verification.

4. The project acceptance effect evaluation method based on data analysis according to claim 1, characterized in that, The steps for marking acceptance contacts as structural support missing contacts are as follows: For each acceptance touchpoint, obtain all inversion path objects and their inversion path verification chains from its corresponding inversion path set; For each pair of inverted path objects, the node structure is compared with its verification chain to identify whether there are missing nodes, inconsistent node order, or conflicting node field values ​​in the verification chain, and a difference detection list is generated based on the comparison results. In the difference detection list, if at least one necessary tracing node is missing, or if two or more consecutive nodes have reversed order, conflicting fields, or logical inconsistencies, the inversion path object will be marked as a structurally abnormal path. When all inversion path objects of an acceptance contact are marked as structurally abnormal paths, or when the remaining non-abnormal path objects are insufficient to cover the core support chain originally defined for that contact, the acceptance contact is marked as a structural support missing contact, and its missing type is recorded as one or more of node missing type, sequence break type, or logical conflict type.

5. The project acceptance effect evaluation method based on data analysis according to claim 1, characterized in that, The steps for generating a true assessment of the project acceptance results based on the number of missing structural support contacts are as follows: The concentration distortion index and link breakage index are calculated based on the number of missing structural support contacts. The concentration distortion index and link breakage index are added together to obtain the false acceptance result index. The authenticity of the project acceptance effect is judged based on the false acceptance result index.

6. The project acceptance effect evaluation method based on data analysis according to claim 5, characterized in that, The calculation steps for the lumped distortion index are as follows: For each contact point lacking structural support, extract contact point behavioral feature tags. The behavioral feature tags include at least one of the following: whether the contact points occur within the same time window, whether the project functional modules to which the contact points belong are the same, whether the execution responsible person or acceptance responsible person corresponding to the contact points is the same, and whether the contact points occur in the critical time period before project acceptance. Combine the behavioral feature tags of each contact point to form a feature tag set for the contact point. For any two contact points with missing structural support, the feature label sets of the two contact points are compared item by item, the number of the two with the same feature labels is counted, and the number of the same feature labels is divided by the total number of feature labels to obtain the set consistency value of the corresponding contact point pair. When the concentration consistency value of a certain contact pair is not lower than the preset judgment threshold, the contact pair is marked as a high consistency contact pair; The number of highly consistent contact pairs is counted, and the number of highly consistent contact pairs is divided by the total number of contact pairs to obtain the concentration distortion index.

7. The project acceptance effect evaluation method based on data analysis according to claim 5, characterized in that, The calculation steps for the link breakage index are as follows: Abstract the source nodes in the inversion path objects of all structural support missing touch points into nodes of the graph structure, and abstract the temporal sequence, causal relationship or data reference relationship between the source nodes into directed connection edges to construct the project acceptance support graph structure. For the contact path that fails the inversion verification, identify the key nodes that break in the support diagram and record them as a set of broken nodes. For each fracture node, calculate the number of nodes along the longest downstream path that can be reached in the original graph structure, denoted as the number of reachable nodes. Divide the number of reachable nodes by the maximum path length among all paths in the entire support graph to obtain the influence coefficient of the fracture node.

8. The project acceptance effect evaluation method based on data analysis according to claim 1, characterized in that, The calculation steps for the link breakage index also include: Starting from all broken nodes, recursively trace all reachable node paths in subsequent directions of the graph structure to construct a set of broken propagation paths. The number of all nodes in the fracture propagation path set is counted, and the ratio is calculated with the total number of nodes in the entire support graph to obtain the coverage ratio of the fracture propagation range. For all inversion path verification chains that fail verification but are not completely interrupted, determine whether there are skip connections, count the number of all skip connection segments, and calculate the ratio with the total number of all path segments that should exist to obtain the skip rate. Select the maximum value among the impact degree coefficients, multiply the maximum impact degree coefficient by the coverage ratio of the break propagation range, and multiply by the jump rate to obtain the link break index.

9. The project acceptance effect evaluation method based on data analysis according to claim 1, characterized in that, The steps to determine the authenticity of project acceptance results based on the falsity index are as follows: Compare the falsity index of the acceptance results with a preset threshold. If the falsity index of the acceptance results is less than the preset threshold, it means that the project acceptance effect is genuine. If the falsity index of the acceptance result is greater than or equal to the preset threshold, it means that the project acceptance effect is false.

10. A project acceptance effect evaluation system based on data analysis, used to implement the project acceptance effect evaluation method based on data analysis as described in any one of claims 1-9, characterized in that, The system includes: Acceptance Point Module: Extract at least one acceptance touchpoint from the project acceptance conclusion. The acceptance touchpoint is used to represent the key results or key indicators declared to have been achieved in the acceptance conclusion. Reversible Path Module: For each acceptance touchpoint, construct a set of reversible paths corresponding to it; Inversion module: Based on system logs, process records, document archives or running trajectories generated during project execution, the inversion verification of the set of invertible paths is performed to determine whether the acceptance touchpoint can find its corresponding inversion path in the project process data; Missing Module: During the inversion verification process, if the inversion path of a certain acceptance touchpoint is missing, incomplete, or conflicts with the project execution record, the acceptance touchpoint will be marked as a structural support missing touchpoint. Evaluation module: Generates a realistic evaluation result of the project acceptance effect based on the number of missing structural support contacts, and uses the realistic evaluation result for subsequent review or acceptance decision.

Images