A multi-source data fusion engineering full-chain monitoring and early warning method

Abstract

The application relates to the technical field of smart contracts and discloses an engineering project full-chain monitoring and early warning method based on multi-source data fusion, which comprises the following steps: step S1, generating standard load data; step S2, performing merging and hash operation; step S3, generating a chain summary sequence and a continuous coefficient value of a storage certificate; step S4, obtaining a closed loop distortion value; step S5, outputting a breakpoint strength value, an abnormal breakpoint coordinate and a warning trigger parameter; step S6, performing summary packaging and signature operation; and step S7, constructing a warning positioning image. Through the establishment of a candidate bucket and the execution of event merging and semantic hash operation, the chain summary is constructed, and multiple storage certificate verification is performed, so that continuous and reliable verification of source records is realized. Through the execution of closed loop coherent operation and the utilization of three-source time closed loop constraint for the detection of abnormalities, the false positive rate of abnormal detection is reduced, so that the automation level and the safety and reliability of engineering project full-chain monitoring are improved.

Description

Technical Field

[0001] This invention relates to the field of smart contract technology, and more specifically, to a method for full-chain monitoring and early warning of engineering payments based on multi-source data fusion. Background Technology

[0002] In the construction engineering field, project payment and settlement involve multiple stakeholders and business processes, with related electronic records scattered across different business systems. With the development of information technology, various project management systems have gradually achieved electronic storage of project payment-related data, capable of recording information throughout the entire process from progress reporting, quantity confirmation, acceptance approval to payment. Current technologies typically manage project payment-related data through centralized database storage, monitoring and managing the payment process through manual verification or simple rule checks. The widespread application of Building Information Modeling (BIM), Internet of Things (IoT), and big data technologies has continuously expanded the scope of project payment-related data collection and led to a sustained increase in data volume, providing a data foundation for achieving refined monitoring.

[0003] In existing technologies, project payment monitoring mainly relies on statistical analysis of data from a single business system, or manual cross-comparison of data from multiple systems. Common implementation methods include establishing a unified data warehouse, periodically synchronizing data from various business systems to a central database, and then performing queries, statistics, and anomaly detection based on the central database; or setting up approval processes at key nodes, using multi-level manual review to ensure the compliance of project payment. Some systems have introduced simple data verification rules to alert administrators to payment amounts exceeding preset thresholds, assisting them in identifying anomalies. With the introduction of electronic signatures and blockchain technology, some systems have begun to use digital signatures to store key records, thereby improving data credibility.

[0004] Existing technologies have several limitations in practical applications. Differences in format and field naming of multi-source heterogeneous data make cross-system data fusion difficult, and human intervention can easily be introduced during data standardization. Inherent time delays exist between different business systems, making simple time comparisons insufficient to distinguish between normal system delays and abnormal data tampering. Missing data is typically handled by downgrading or discarding it, making the missing data location a blind spot for security detection. Evidence verification methods are relatively simplistic and easily bypassed. Anomaly detection usually outputs generalized risk levels, making it difficult to pinpoint specific anomaly locations and data sources. Warning results are mostly in text or table format, lacking intuitiveness and inherently susceptible to tampering. These limitations mean that existing technologies fall short of meeting practical requirements in complex engineering payment security scenarios in terms of detection accuracy and location precision. Summary of the Invention

[0005] This invention provides a method for full-chain monitoring and early warning of engineering payments based on multi-source data fusion, which solves the technical problems mentioned in the background.

[0006] This invention provides a method for full-chain monitoring and early warning of engineering payments based on multi-source data fusion, comprising the following steps:

[0007] Step S1: Receive multi-source electronic records, perform standardization and time unification operations, and generate standard load data, basic attribute data, and reliable time values;

[0008] Step S2: Perform merge and hash operations on the specification payload data, basic attribute data, and trusted time values, and output the event node set, node category label, link sequence number, and semantic hash sequence.

[0009] Step S3: Input the standard load data, basic attribute data and reliable time value into the anti-counterfeiting model for verification, and generate a chained summary sequence and evidence continuity coefficient value.

[0010] Step S4: Perform closed-loop coherence operation based on the node category label in the event node set, the trusted time value, the semantic hash sequence, and the evidence continuity coefficient value to obtain the closed-loop distortion value.

[0011] Step S5: Calculate the local mutation gradient from the event node set, link sequence number, evidence continuity coefficient value and closed-loop distortion value, and output the breakpoint strength value, abnormal breakpoint coordinates and early warning trigger parameters.

[0012] Step S6: Perform digest encapsulation and signature operation on the chain digest sequence, closed-loop distortion value, breakpoint strength value and abnormal breakpoint coordinates to obtain evidence digest data and monitoring signature data;

[0013] Step S7: Use the link sequence number, abnormal breakpoint coordinates, early warning trigger parameters, evidence summary data and monitoring signature data to perform graphic rendering and encapsulation, and construct early warning positioning images and image verification data for monitoring display.

[0014] The beneficial effects of this invention are as follows: By performing payload normalization and time unification processing on multi-source electronic records, this invention achieves standardization of heterogeneous data formats, eliminating the impact of differences in field naming between different business systems on subsequent verification. By establishing candidate buckets and performing event merging and semantic hashing operations, it can accurately identify multi-source records of the same engineering event while protecting the privacy and security of the original data. By constructing chained digests and performing multiple evidence verifications, it achieves continuous and reliable verification of records within the source. By performing closed-loop coherence operations, calculating the phase residual after deducting the normal delay between sources, and using three-source time closed-loop constraints to detect anomalies, it can distinguish between reasonable system hysteresis and data tampering behavior, reducing the false alarm rate of anomaly detection. By calculating the local mutation gradient and breakpoint strength values, combined with the adaptive triggering benchmark within the chain, it can locate specific security breakpoint positions and output source-level anomaly coordinates. By generating evidence digests and digital signatures, it constructs a minimum verifiable evidence package, achieving anti-tampering and non-repudiation of anomaly evidence. By performing deterministic graphics rendering, it generates an early warning location image containing complete evidence information, making the anomaly location intuitively presented. This helps to improve the automation level and security reliability of the entire chain monitoring of engineering funds. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating the calculation process of a multi-source data fusion-based full-chain monitoring and early warning method for engineering payments according to the present invention.

[0016] Figure 2 This is the early warning positioning image of the present invention. Detailed Implementation

[0017] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, features described in some examples may be combined in other examples.

[0018] It should be noted that, unless otherwise defined, the technical or scientific terms used in one or more embodiments of the present invention should have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The terms "first," "second," and similar terms used in one or more embodiments of the present invention do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" indicate that the element or object preceding the term encompasses the elements or objects listed following the term and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0019] like Figures 1-2 As shown, a method for full-chain monitoring and early warning of engineering payments based on multi-source data fusion includes the following steps:

[0020] Step S1: Receive multi-source electronic records, perform standardization and time unification operations, and generate standard load data, basic attribute data, and reliable time values;

[0021] Step S2: Perform merge and hash operations on the specification payload data, basic attribute data, and trusted time values, and output the event node set, node category label, link sequence number, and semantic hash sequence.

[0022] Step S3: Input the standard load data, basic attribute data and reliable time value into the anti-counterfeiting model for verification, and generate a chained summary sequence and evidence continuity coefficient value.

[0023] Step S4: Perform closed-loop coherence operation based on the node category label in the event node set, the trusted time value, the semantic hash sequence, and the evidence continuity coefficient value to obtain the closed-loop distortion value.

[0024] Step S5: Calculate the local mutation gradient from the event node set, link sequence number, evidence continuity coefficient value and closed-loop distortion value, and output the breakpoint strength value, abnormal breakpoint coordinates and early warning trigger parameters.

[0025] Step S6: Perform digest encapsulation and signature operation on the chain digest sequence, closed-loop distortion value, breakpoint strength value and abnormal breakpoint coordinates to obtain evidence digest data and monitoring signature data;

[0026] Step S7: Use the link sequence number, abnormal breakpoint coordinates, early warning trigger parameters, evidence summary data and monitoring signature data to perform graphic rendering and encapsulation, and construct early warning positioning images and image verification data for monitoring display.

[0027] In one embodiment of the present invention, step S1 specifically includes the following steps:

[0028] Receive multi-source electronic records from a fixed source set, which includes building information model and real-world progress sources, quantity measurement sources, acceptance confirmation sources, contract milestones and approval sources, and payment confirmation and log storage sources.

[0029] Perform load normalization processing on multi-source electronic records to generate normalized load data. Specifically, load normalization processing includes field name normalization, key sorting, code normalization, blank folding, and unit label preservation.

[0030] The source generation time is converted into a trusted clock coordinate, and the source system clock offset is written into the basic attribute data. Specifically, the basic attribute data includes the source class identifier, the generator public key identifier, the source sequence number, and the missing placeholder identifier.

[0031] For source classes that lack business records in the input window, a missing placeholder record is generated. Specifically, the missing placeholder record includes the source class identifier, node candidate identifier, trusted window boundary, and empty payload summary.

[0032] Outputs standard load data, basic attribute data, and confidence time values.

[0033] It should be noted that the fixed source set consists of five predefined categories of electronic data sources, including building information model and real-world progress sources, quantity measurement sources, acceptance confirmation sources, contract milestones and approval sources, and payment confirmation and log storage sources, representing all data source categories covering the entire project payment chain.

[0034] Standardized payload data consists of multi-source electronic records that have undergone field name normalization, key sorting, encoding normalization, blank folding, and unit label retention, representing a unified data form after standardization of multi-source data.

[0035] The basic attribute data consists of metadata containing the source class identifier, the generator public key identifier, the source sequence number, and the missing placeholder identifier, representing the basic identity information of each electronic record.

[0036] The trusted time value is a unified time value obtained by converting the source-generated time into trusted clock coordinates, representing a standard timestamp after clock synchronization calibration.

[0037] Missing placeholder records are placeholder data generated for source classes that lack business records within the input window. They include source class identifier, node candidate identifier, trusted window boundary, and empty payload summary, representing placeholder markers at the missing data locations.

[0038] The method for determining the input window is as follows: The window duration is set according to the business cycle of the project payment chain, with a preferred value of 24 hours, and a range of 1 hour to 168 hours. Specifically, a 24-hour window is used for daily progress nodes, and a 168-hour window is used for monthly settlement nodes. The sliding method uses a fixed step size, with a preferred step size of 1 hour, meaning that the window slides forward 1 hour every 1-hour period.

[0039] The specific execution standards for each step in the load normalization process are as follows: Field name normalization uses a pre-defined standard field name dictionary, which contains all synonymous field names that may be used in the business system and their corresponding standard names. For example, synonymous fields such as completion time, completion date, and acceptance time that may be used in the business system are uniformly mapped to node completion time. Key sorting follows the lexicographical order of the standard field names in ascending order, ensuring that records with the same content generate the same sorting result. Encoding normalization adopts a unified character encoding standard, and all input data is uniformly converted to UTF-8 encoding format. Whitespace folding merges consecutive whitespace characters into a single space, while removing leading and trailing whitespace characters. Unit labels are retained, with all numeric fields retaining their original unit labels without unit conversion.

[0040] The specific method for converting trusted clock coordinates is as follows: The trusted clock source is the standard time signal released by the National Time Service Center. The synchronization mechanism uses the Network Time Protocol for periodic synchronization, with a preferred synchronization period of 15 minutes, meaning time calibration is performed with the trusted clock source every 15 minutes. The time generated within the source is first converted to Coordinated Universal Time (UTC), then calibrated according to the offset of the trusted clock source, ultimately yielding the trusted time value.

[0041] It should be noted that during multi-source data fusion, differences in field naming across different business systems can lead to inconsistencies in subsequent verification logic. Furthermore, the manual correction of timestamps may introduce subjective factors or even be maliciously exploited. This embodiment does not directly fuse business fields at the monitoring entry point. Instead, it converts all project payment link records into a standardized payload with source class identifiers, trusted timestamps, original summaries, and a missing placeholder mechanism. This ensures that subsequent security verification does not rely on the field naming of any single business system. This eliminates the impact of differences in field naming across different business systems on subsequent security verification, preserves the source system clock offset as metadata, avoids the risk of tampering caused by manual time correction, and ensures that all source classes participate in the calculation through missing placeholder records, preventing tamperers from evading detection by deleting records.

[0042] In one embodiment of the present invention, step S2 specifically includes the following steps:

[0043] Candidate buckets are created based on project segment identifiers, engineering entity identifiers, and node category labels;

[0044] Within the candidate bucket, perform token segmentation, field path marking, and unit label retention on the canonical payload data;

[0045] Records with the same key are grouped into the same event node, and unique merging is performed on records with incompletely identical keys. Specifically, unique merging includes determining candidate event nodes based on the similarity value of the character fragment set and the adjacency relationship of the source sequence, and when the candidate similarity values ​​are consistent, determining the unique event node according to the rule of the smallest absolute value of the reliable time difference and the rule of the smallest lexicographical order of the source sequence number.

[0046] A semantic hash sequence is generated based on each specification payload data. Specifically, the semantic hash sequence is a locality-sensitive hash bit sequence.

[0047] Output the event node set, node category label, link sequence number, and semantic hash sequence.

[0048] It should be noted that the candidate bucket is a temporary storage container for event nodes established according to the project fragment identifier, engineering entity identifier, and node category label, representing the event storage unit corresponding to each unique identifier combination.

[0049] A semantic hash sequence is a locally sensitive hash bit sequence generated from normalized payload data, representing the binary sequence obtained after hash transformation of the normalized payload data.

[0050] Locality-sensitive hashing bit sequences are binary bit sequences that can preserve semantic similarity, representing the mapping result of the semantic similarity of the original data in the hash space.

[0051] The specific method for calculating the similarity of character segment sets is as follows: The rule for dividing character segments is to use a sliding window of fixed length to divide the text. The window length is preferably 4, with a range of 2 to 8. Specifically, starting from the beginning of the text, four consecutive characters are taken as a character segment each time, and the window sliding step is 1 character. The similarity calculation function uses Jaccard similarity, which is the number of elements in the intersection of two character segment sets divided by the number of elements in the union.

[0052] The criteria for determining the adjacency of sequences within a source class are as follows: The preferred value for the sequence number interval threshold is 5, with a range of 1 to 10. Specifically, if the absolute value of the difference between the source sequence numbers of two records in the same source class is less than or equal to the threshold, they are considered to have an adjacency relationship. For example, in a source class, the interval between record number 10 and record number 14 is 4, which is less than or equal to the threshold of 5, and they are considered adjacent; the interval between record number 10 and record number 16 is 6, which is greater than the threshold of 5, and they are considered not adjacent.

[0053] The specific implementation of Locality Sensitive Hashing (LSH) is as follows: the preferred number of hash functions is 128, with a value ranging from 64 to 256. The preferred dimension is 256 bits, with a value ranging from 128 to 512 bits. Specifically, multiple independent hash functions are used to calculate the input data, with each hash function outputting a 1-bit result. All results are concatenated to form the final hash sequence. For example, 128 hash functions can be used to generate a 128-bit hash sequence, where each bit corresponds to the output result of one hash function.

[0054] It should be noted that traditional event merging methods typically rely on key field matching, which is susceptible to differences in field naming and poses a risk of data privacy leakage when directly comparing the original data. Single-dimensional event matching is prone to mis-merging of different events, and directly exposing the original data content does not meet the requirements of data security and privacy protection. Introducing financial evaluation fields during the merging process may also interfere with the independence of security verification. This embodiment merges records of the same project payment link node from different sources into a unified event node and generates a semantic hash sequence that does not expose the original text, enabling subsequent cross-source comparisons to retain semantic offset information while protecting data content. This embodiment accurately identifies multi-source records of the same project event through multi-dimensional merging rules. The generated semantic hash sequence retains semantic information while protecting the privacy of the original data. Event merging does not use financial evaluation fields, ensuring the independence of security verification.

[0055] In one embodiment of the present invention, step S3 specifically includes the following steps:

[0056] Following the order of each source class and event node within the fixed source set, the digest of the previous link node, the canonical payload data, the basic attribute data, and the trusted time value are concatenated, and a collision-resistant hash operation is performed to generate a chained digest sequence. The calculation formula for the chained digest sequence is as follows:

[0057]

[0058] in, Indicates the first The source class is in the first A chained summary of each event node. Indicates the first The source class is in the first Summary of the previous link node of each event node Indicates the first The source class is in the first The canonical payload data for each event node. Indicates the first The source class is in the first Basic attribute data for each event node. Indicates the first The source class is in the first The reliable time value of each event node. Represents a collision-resistant hash function;

[0059] Perform verification on the source system signature, Merkel path, and chain digest;

[0060] Perform a logical AND operation on the verification result to generate the evidence continuity coefficient value; the formula for calculating the evidence continuity coefficient value is as follows:

[0061]

[0062] in, Indicates the first The source class is in the first The continuity coefficient value of evidence storage for each event node Indicates an indicator function, Indicates the first The source class is in the first The source system signature verification value of each event node. Indicates the first The source class is in the first Merkel path verification value for each event node This indicates a logical AND operation.

[0063] Among them, the continuity coefficient value of the evidence for missing placeholder records is fixed at 0.

[0064] It should be noted that the chained digest sequence is a continuous hash value sequence generated in the order of source class and event node, representing a continuous hash chain of source class records in the time dimension.

[0065] The evidence continuity coefficient is a binary flag indicating whether the source record has passed signature verification, Merkel path verification, and chain digest verification. It represents the result of the source record passing multiple evidence verifications. A value of 1 indicates that all verifications have passed, while a value of 0 indicates that at least one verification has failed.

[0066] The specific selection and parameter settings for the collision-resistant hash function are as follows: SHA-256 is the preferred hash function, with parameters set to a standard output length of 256 bits, without truncation or expansion. For example, input data of any length will generate a fixed-length 256-bit hash value after being processed by this hash function, and the probability of different inputs generating the same hash value is extremely low.

[0067] The specific methods for obtaining and managing the public keys of the source systems are as follows: Public keys are distributed offline. Before connecting to the monitoring system, each source system submits its public key to the monitoring system administrator through a secure channel. After review, the administrator enters the public key into the system's public key repository. The public key update mechanism combines regular updates and emergency updates. The preferred regular update cycle is 90 days, and emergency updates can be performed immediately upon discovery of a key leak. For example, if a source system submits its public key upon connection, this public key is valid for 90 days, and the system prompts for an update 7 days before the expiration date.

[0068] The specific process for generating and verifying the Merkel path is as follows: The Merkel tree is constructed by using the hash values ​​of all records within the same source class and time window as leaf nodes, and generating parent nodes by hashing each pair of records from bottom to top until the root node. The Merkel path is the set of hash values ​​of all sibling nodes traversed from the leaf node to the root node. During verification, the hash value of the leaf node to be verified is hashed sequentially with the nodes in the Merkel path. If the final result matches the root node of the Merkel tree, the verification is successful. For example, if a leaf node requires four sibling nodes to reach the root node, then the Merkel path contains the hash values ​​of these four nodes.

[0069] It should be noted that traditional evidence verification typically employs only a single verification method, making it vulnerable to targeted bypasses. Traditional hash chains usually only hash the payload content, allowing attackers to adjust timestamps without altering the content to evade detection. The coexistence of multiple verification methods also increases the complexity of subsequent calculations, and the ambiguous status of missing placeholder records can lead to misjudgments. This embodiment establishes a continuous hash within the source for each source class's normalized payload at each event node, unifying multiple evidence verification methods into a single evidence continuity coefficient value, which serves as a gating factor for subsequent cross-source distortion calculations. This embodiment incorporates both trusted time and metadata into the hash chain, ensuring that attackers will be detected even if they only replace the payload or move the timestamp. The unified evidence continuity coefficient value simplifies the complexity of subsequent cross-source calculations, and the evidence continuity coefficient value for missing placeholder records is fixed at 0, ensuring that missing data is not misjudged as valid evidence.

[0070] In one embodiment of the present invention, step S4 specifically includes the following steps:

[0071] Based on the node category label, the source class offset baseline and the median inter-source delay deviation are read from the trusted baseline library. The normal inter-source delay is obtained by the difference between the source class offset baselines of the two source classes.

[0072] The reliable time difference between the two source classes is subtracted from the normal inter-source delay and normalized using a preset time stability term to generate a signed phase residual. The formula for calculating the signed phase residual is as follows:

[0073]

[0074] in, Indicates the first The source class and the first The source class is in the first The signed phase residuals of each event node, Indicates the first The source class is in the first The reliable time value of each event node. Indicates the first The source class is in the first The reliable time value of each event node. Indicates the first The source class and the first The source class is in the first Inter-source normal latency under the node category label of each event node Indicates the first The source class and the first The source class is in the first The median inter-source delay deviation under the node category label of each event node. Indicates the preset time stability term. Indicates the first Node category labels for each event node;

[0075] The semantic hash difference is generated by XORing the semantic hash sequences of the two source classes bit by bit and dividing by the number of semantic hash bits. The formula for calculating the semantic hash difference is as follows:

[0076]

[0077] in, Indicates the first The source class and the first The source class is in the first Semantic hash differences of each event node Indicates the first The source class is in the first A semantic hash sequence of event nodes, Indicates the first The source class is in the first A semantic hash sequence of event nodes, Indicates bitwise XOR. This indicates the number of bits that are 1. Indicates the number of bits in the semantic hash;

[0078] The evidence continuity coefficients, signed phase residuals, and semantic hash differences of the two source classes are coherently processed to generate dual-source coherence coefficient values. The formula for calculating the dual-source coherence coefficient values ​​is as follows:

[0079]

[0080] in, Indicates the first The source class and the first The source class is in the first The dual-source coherence coefficient values ​​of each event node. Indicates the first The source class is in the first The continuity coefficient value of evidence storage for each event node Indicates the first The source class is in the first The continuity coefficient value of evidence storage for each event node This indicates exponentiation. Indicates the first The source class and the first The source class is in the first The absolute value of the signed phase residual of each event node;

[0081] The three-source closed-loop residuals are calculated using the three-source closed triplet, and the closed-loop distortion value is generated by combining the two-source coherence coefficient value. The formula for calculating the three-source closed-loop residuals is as follows:

[0082]

[0083] in, Indicates the first Source class, the first The source class and the first The source class is in the first The three-source closed-loop residuals formed by the event nodes Indicates the first The source class and the first The source class is in the first The signed phase residuals of each event node, Indicates the first The source class and the first The source class is in the first The signed phase residuals of each event node, Indicates the first The source class and the first The source class is in the first The signed phase residuals of each event node, with a constant of 1 representing the stable baseline; the formula for calculating the closed-loop distortion value is as follows:

[0084]

[0085] in, Indicates the first The closed-loop distortion value of each event node. Indicates the first A set of three-source closed triplets for each event node. Indicates the first The number of three-source closed triples for each event node. Indicates the first The source class and the first The source class is in the first The dual-source coherence coefficient values ​​of each event node. Indicates the first The source class and the first The source class is in the first The dual-source coherence coefficient values ​​of each event node. Indicates the first The source class and the first The source class is in the first The dual-source coherence coefficient value of each event node, where the constant 3 represents the number of edges in the three-source closed triplet.

[0086] It should be noted that the Trusted Baseline Library is a database that stores normal latency statistics for various sources under different node types, representing a set of statistical results that includes all combinations of node types and source classes.

[0087] The source class offset baseline is the robust median offset of the source class relative to the reference clock for a specific node type, representing the systematic clock offset level of the source class under a specific node type.

[0088] The median inter-source delay deviation is the median absolute deviation of the inter-source delay between two source classes under a specific node type, representing the normal level of delay difference between the two source classes.

[0089] The signed phase residual is the inter-source time difference after deducting the normal inter-source delay and normalizing it, which represents the degree of temporal anomaly of the two source class records after deducting the normal deviation.

[0090] Semantic hash difference is the bit-level distance between the semantic hash sequences of two source classes, representing the degree of semantic difference between the contents of the records of the two source classes.

[0091] The dual-source coherence coefficient is a measure of the continuity, temporal consistency, and semantic consistency of evidence from two source classes, representing the overall consistency level of the records from the two source classes.

[0092] A three-source closed triplet is a closed loop composed of three source classes selected from a fixed set of sources, representing the set of all possible three-source combinations.

[0093] The three-source closed-loop residual is the absolute value of the algebraic sum of the phase residuals in the three-source closed triplet, which characterizes the degree of closure of the temporal relationship between the three source classes.

[0094] The closed-loop distortion value is a node anomaly metric obtained by combining the three-source closed-loop residual and the two-source coherence coefficient value, which characterizes the likelihood of data tampering at the event node.

[0095] The construction method and update frequency of the trusted baseline library are as follows: The construction method adopts the historical data statistical method, extracting the latency data of each source class under each node type from the verified historical normal data for statistical analysis. The selection criteria for historical data are normal engineering project data that has been manually confirmed to have not been tampered with, with a sample size preferably not less than 100, and a value range of 50 to 500. The preferred update frequency is 30 days, that is, the baseline value is recalculated every 30 days using the latest normal data.

[0096] The statistical methods for determining the source class offset baseline and the median inter-source delay deviation are as follows: Robust statistical methods are employed. The source class offset baseline is the median of all samples, and the median inter-source delay deviation is the median of all absolute inter-source delay deviations. Outlier handling utilizes the median absolute deviation method; samples with deviations exceeding three times the median absolute deviation are considered outliers and removed. A minimum of 50 samples is preferred. When the sample size is less than 30, a global baseline of the same node type is used as a temporary replacement.

[0097] The traversal method for three-source closed triplets is as follows: A combination traversal is used, selecting three source classes from the five source classes without repetition to form a triplet, regardless of order. That is, source class A, source class B, and source class C are considered the same combination as source class B, source class A, and source class C. A total of 10 different three-source closed triplets are generated from the five source classes. For example, if the fixed source set contains source class 1, source class 2, source class 3, source class 4, and source class 5, then the first triplet will be source class 1, source class 2, and source class 3; the second will be source class 1, source class 2, and source class 4; and so on, traversing all combinations.

[0098] It should be noted that traditional multi-source consistency verification typically uses a simple time difference threshold, which cannot distinguish between normal system latency and abnormal tampering behavior. Different business systems have inherent processing delays, and directly comparing time differences will produce a large number of false positives. When all three source classes experience overall lag simultaneously, it is difficult to distinguish them from single-source anomalies. Records that fail the evidence verification may also interfere with the fusion results. This embodiment treats asynchronous multi-source records as phase projections of the same event in different computer sources. It utilizes the algebraic closed-loop constraint of time difference combined with semantic hash coherence to determine data tampering prevention, generating a closed-loop distortion value that can distinguish between reasonable lag and local anomalies. This embodiment subtracts the verified normal inter-source latency, transforming reasonable lag into a near-zero phase residual, improving the sensitivity of anomaly detection. The three-source closed-loop residual can distinguish between normal overall lag and single-source anomalies, coupling intra-source reliability and cross-source similarity, and suppressing the participation of unsigned replacement records in the fusion.

[0099] In one embodiment of the present invention, step S5 specifically includes the following steps:

[0100] The continuity ratio of source evidence is calculated based on the evidence continuity coefficient values ​​of each source class within the fixed source set; the formula for calculating the continuity ratio of source evidence is as follows:

[0101]

[0102] in, Indicates the first The proportion of continuous source memory certificates for each event node. Represents a fixed source set. This indicates the number of source classes in a fixed source set. Indicates the first The source class is in the first The continuity coefficient value of evidence storage for each event node;

[0103] Based on the predecessor and successor neighbors in the event node set, calculate the local abrupt gradient between the closed-loop distortion value and the neighbor's closed-loop distortion value;

[0104] The breakpoint strength value is generated by combining the closed-loop distortion value, the continuity ratio of source memory evidence, and the local mutation gradient; the calculation formula for the breakpoint strength value is as follows:

[0105]

[0106] in, Indicates the first The breakpoint strength value of each event node. Indicates the first The closed-loop distortion value of each event node. Indicates the first The proportion of continuous source memory certificates for each event node. Indicates the first The set of predecessor and successor neighbors of each event node Indicates the first The number of neighbors of each event node. This indicates a preset numerical stability term. Indicates the first The closed-loop distortion value of each neighbor event node;

[0107] The source class coordinates are determined based on the breakpoint strength values ​​and the dual-source coherence coefficient values;

[0108] A triggering baseline is generated based on the median of the breakpoint strength values ​​within the chain and the median of the absolute deviation. Early warning triggering parameters are calculated, and abnormal breakpoint coordinates are generated. The calculation formulas for the abnormal breakpoint coordinates and early warning triggering parameters are as follows:

[0109]

[0110]

[0111]

[0112]

[0113]

[0114] in, The breakpoint event node represents the breakpoint with the highest breakpoint strength value. Represents a set of event nodes. Indicates the first The source class coordinates that have the smallest combination of evidence continuity coefficient value and dual-source coherence coefficient value among all event nodes. Indicates the trigger reference. This represents the median of the breakpoint strength values ​​within the event node set. This represents the median absolute deviation of the breakpoint strength values ​​within the event node set. Indicates the parameter that triggers the warning. Indicates the coordinates of the abnormal breakpoint. Indicates the first The node category label for each event node. Indicates the first The link sequence number of each event node.

[0115] It should be noted that the continuity ratio of source evidence is the average value of the continuity coefficient of all source evidence of the event node, which represents the overall credibility of the evidence of the event node.

[0116] The local mutation gradient is the average difference between the closed-loop distortion value of an event node and the closed-loop distortion values ​​of its neighboring nodes, representing the degree of mutation of the event node's distortion value relative to its neighborhood.

[0117] The breakpoint strength value is a measure of the degree of anomaly obtained by combining the closed-loop distortion of the integrated node, the continuity ratio of the source memory evidence, and the gradient of local mutations, which characterizes the severity of the event node as a safe breakpoint.

[0118] The source class coordinates are the source class identifier with the weakest evidence and lowest coherence in the breakpoint event node, representing the location of the data source most likely to be tampered with.

[0119] The triggering benchmark is an adaptive warning threshold generated from the median of the breakpoint strength values ​​and the median of the absolute deviation within the chain, representing the anomaly judgment standard obtained based on the current link data statistics.

[0120] The warning trigger parameter is a binary flag indicating whether the breakpoint strength value exceeds the triggering benchmark. It represents whether a warning is triggered. A value of 1 indicates that a warning is triggered, and a value of 0 indicates that a warning is not triggered.

[0121] The abnormal breakpoint coordinates are complete breakpoint location information including node category label, link sequence number, source class coordinates and warning trigger parameters, representing the complete location information of the safe breakpoint.

[0122] The method for determining the neighbor set of an event node is as follows: The rules for determining predecessor and successor nodes are based on the link sequence number. The predecessor node is the node with the smallest link sequence number difference that is less than the current node, and the successor node is the node with the smallest link sequence number difference that is greater than the current node. For the starting node of a link, only a successor node exists; for the ending node of a link, only a predecessor node exists; intermediate nodes contain both predecessor and successor nodes.

[0123] The specific sorting rules for breakpoint strength values ​​are as follows: First, sort the breakpoints by strength value from largest to smallest, with larger strength values ​​indicating higher priority. When strength values ​​are the same, sort them by local mutation gradient from largest to smallest, with more pronounced mutations indicating higher priority. If mutation gradients are also the same, sort them by the proportion of continuous evidence in the source memory from smallest to largest, with weaker evidence indicating higher priority.

[0124] The in-chain median and absolute deviation median are calculated as follows: The in-chain median is the median value after sorting all node breakpoint strength values ​​in the current link. The absolute deviation median is the median of the absolute deviations of all node breakpoint strength values ​​from the median. When the sample size is less than 10, a preset fixed threshold is used as the triggering benchmark, with a preferred value of 0.5.

[0125] It should be noted that traditional anomaly detection typically only outputs risk scores or levels, failing to pinpoint specific anomaly locations or distinguish between localized mutations and overall anomalies. When the entire link experiences overall delays due to network issues or system maintenance, the distortion values ​​at each node may be high, easily leading to false alarms. Manually set fixed thresholds are also difficult to adapt to different scales and types of engineering projects. Traditional early warning systems usually only locate the event node, unable to further pinpoint the specific data source. This embodiment maps closed-loop distortion values ​​to the engineering project link diagram, combining the distortion gradients of adjacent link nodes and the continuity of source memory evidence to locate the coordinates of the most critical safety breakpoint requiring early warning. This embodiment combines node-specific distortion and local gradients to avoid overall false alarms caused by synchronization delays across the entire link. It employs an intra-link adaptive triggering benchmark, eliminating the need for manually set thresholds, and simultaneously outputs source coordinates, enabling early warnings to pinpoint the specific source of electronic records, significantly narrowing the investigation scope.

[0126] In one embodiment of the present invention, step S6 specifically includes the following steps:

[0127] Extract the chained summary sequence, closed-loop distortion value, breakpoint strength value, and adjacent link node summary of the breakpoint event node corresponding to the abnormal breakpoint coordinates;

[0128] The chained summary sequence, closed-loop distortion value, breakpoint strength value, abnormal breakpoint coordinates, and adjacent link node summaries are encapsulated to generate evidence summary data. The calculation formula for the evidence summary data is as follows:

[0129]

[0130] in, This represents the summary of evidence data. Indicates the first The source class is in the first A chained summary of each breakpoint event node. Indicates the first The closed-loop distortion value of each breakpoint event node. Indicates the first The breakpoint strength value of each breakpoint event node. Indicates the coordinates of the abnormal breakpoint. Indicates the first A set of source-interlinked summaries of adjacent link nodes of each breakpoint event node;

[0131] The evidence digest data is concatenated with the time of generation of the early warning location image, and a digital signature operation is performed using the monitoring private key to obtain the monitoring signature data; the calculation formula for the monitoring signature data is as follows:

[0132]

[0133] in, This indicates monitoring signature data. This indicates the monitoring private key. This represents the summary of evidence data. Indicates the time when the warning location image was generated. This indicates a digital signature operation performed using the monitoring private key;

[0134] The evidence summary data does not contain the original text that can restore personal identity or business evaluation, and the isolation marker is only written to the read copy in the monitoring cache.

[0135] It should be noted that the adjacent link node summary is a set of source-internal chain summaries of the predecessor and successor nodes of the breakpoint event node, representing the summary information of the breakpoint context node.

[0136] The evidence digest data is a hash value generated by encapsulating breakpoint-related information and adjacent node summaries, representing a unique identifier for the breakpoint evidence package.

[0137] The monitoring private key is the private key used by the monitoring system to generate digital signatures, representing a 256-bit key generated using an asymmetric encryption algorithm.

[0138] The monitoring signature data is a digital signature generated using the monitoring private key for the evidence digest data and the time of the early warning image generation, representing the monitoring system's authentication and integrity guarantee of the evidence package.

[0139] The read-only isolation flag is a read-only access permission flag set for the source record copy in the monitoring cache, representing the read-only lock state at the cache level.

[0140] The specific methods for generating and managing the monitoring private key are as follows: Key generation uses an elliptic curve digital signature algorithm to generate a 256-bit private key and a corresponding public key. Key storage employs a hardware security module for encrypted storage; the private key never appears in plain text in memory or on disk. The backup mechanism uses multiple geographically distributed cold backups, with backup keys stored in segments by multiple people, requiring authorization from multiple parties for recovery. For example, during monitoring system deployment, key pairs are generated in an offline security environment, the private key is imported into the hardware security module, and the public key is publicly used for signature verification.

[0141] The specific algorithm and parameter settings for the digital signature are as follows: The preferred algorithm is the elliptic curve digital signature algorithm, with the curve parameter being the 256-bit curve recommended by the national standard. The hash algorithm used is SHA-256. The signature output format adopts the standard Abstract Syntax Notation-encoded format. For example, the concatenation result of the evidence digest data and the generation time is hashed, and then the hash value is signed using the monitoring private key to generate 64 bytes of signature data.

[0142] The implementation of the read-only isolation tag is as follows: The caching system preferably uses an in-memory key-value store, supporting key-level access control. The tag is implemented by setting a read-only attribute for the cache key; after setting this attribute, all write and delete operations will return an error. The preferred expiration time for the tag is 24 hours, after which the isolation is automatically lifted, but it can also be manually extended as needed.

[0143] It should be noted that within the time window between detecting an anomaly and generating an early warning image, tamperers may attempt to repair the altered data to cover their tracks. Individual node summaries may be replaced, and the exposure of original business data poses a privacy risk. Evidence may also be contaminated or modified during processing, leading to inconsistencies between the final early warning result and the state at the time of detection. This embodiment extracts the minimum verifiable evidence package and writes a read-only isolation tag to the corresponding source record in the monitoring cache, ensuring that the altered or overwritten variable record will not be read again during subsequent early warning image rendering. The minimum evidence package in this embodiment only contains summary information and does not contain original text content that can restore personal identity or business evaluation, thus protecting data privacy. The breakpoint node and its neighbor summaries are encapsulated together to form a verifiable local context, preventing isolated replacement of single-node evidence. The read-only isolation tag ensures the consistency and immutability of the evidence.

[0144] In one embodiment of the present invention, step S7 specifically includes the following steps:

[0145] Image coordinates are calculated based on the link sequence number and a fixed source set; the formula for calculating image coordinates is as follows:

[0146]

[0147] in, Indicates the first The horizontal normalized coordinates of each event node Indicates the first The link sequence number of each event node Indicates the minimum order of links. Indicates the maximum order of links. This indicates a preset numerical stability term. Indicates the first The vertical normalized coordinates of each source class Indicates the first Source class index of each source class. Represents a fixed source set. Indicates the number of source classes in a fixed source set;

[0148] The event node set, fixed source set, image coordinates, abnormal breakpoint coordinates, early warning trigger parameters, and evidence summary data are input into a deterministic graphics rendering function to generate an early warning location image; the calculation formula for the early warning location image is as follows:

[0149]

[0150] in, This indicates the location image for the early warning. This represents a deterministic graphics rendering function. Represents a set of event nodes. Represents a fixed source set. Represents the set of image coordinates. Indicates the coordinates of the abnormal breakpoint. Indicates the parameter that triggers the warning. This represents the summary of evidence data;

[0151] Write the evidence summary data and monitoring signature data into the image metadata area;

[0152] The early warning location image, evidence digest data, and monitoring signature data are concatenated and then hashed to generate image verification data. The calculation formula for the image verification data is as follows:

[0153]

[0154] in, This represents image verification data. This indicates the location image for the early warning. This represents the summary of evidence data. This indicates the monitoring signature data.

[0155] It should be noted that the image coordinates are normalized coordinates obtained by mapping the link sequence number and source class index to the image plane, representing the position of the event node and source class in the warning image.

[0156] A deterministic graphics rendering function is a rendering function that always outputs the same image when given the same input parameters, representing a pure function rendering logic that does not contain random factors.

[0157] The early warning positioning image is an image generated by visualizing the entire chain information and breakpoint information of the project funds, representing the visualized presentation result of the security status of the entire chain of project funds.

[0158] Image verification data is a hash value generated by concatenating the early warning location image, evidence summary data, and monitoring signature data. It represents the integrity verification value of the entire early warning image and its associated evidence.

[0159] The specific mapping rules for image coordinates are as follows: The preferred image resolution is 1920×1080 pixels. The horizontal coordinate corresponds to the link sequence number, with the smallest number mapped to horizontal coordinate 0, the largest number mapped to horizontal coordinate 1919, and intermediate numbers linearly interpolated. The vertical coordinate corresponds to the source class index, with the first source class mapped to vertical coordinate 0, the fifth source class mapped to vertical coordinate 1079, and intermediate source classes linearly interpolated. For example, if a link has 10 nodes and 5 source classes, then the image coordinates of the third source class at node number 5 are horizontal coordinate 959 and vertical coordinate 539.

[0160] The specific implementation of the deterministic graphics rendering function is as follows: Nodes are rendered as solid circles with a preferred radius of 8 pixels; normal nodes are green, and breakpoint nodes are red. Breakpoints are rendered with a red border added around the circle, with a preferred border width of 3 pixels. Connections are rendered as gray straight lines between adjacent nodes, with a preferred line width of 2 pixels. No anti-aliasing, gradients, or random noise are used during the rendering process to ensure completely deterministic output.

[0161] The specific format for writing image metadata is as follows: The metadata is stored in the exchangeable image file format data area of ​​the image file. The encoding method uses basic encoding rules, and the metadata includes evidence digest data, monitoring signature data, and image generation time. The metadata length is fixed at 512 bytes, with any insufficient space padded with zeros.

[0162] It should be noted that this embodiment maps the link sequence and source class coordinates to the same image coordinate system, so that the security breakpoint can be presented in a fixed two-dimensional coordinate. The image metadata area embeds evidence digests and signatures, so that the warning image has a non-repudiation and tamper-proof verification entry point. The final image verification data further ensures the integrity of the warning result.

[0163] Specifically, this invention can be deployed within the security monitoring module of an engineering project management platform as an independent security verification component for the entire process of project payment. During deployment, the access configuration of each business system is first completed, including data interface integration with the building information modeling system, quantity measurement system, project acceptance system, contract approval system, and financial payment system. Each source system submits its public key through a secure channel to establish a system identity authentication system. After configuration, a historical data learning process is initiated, extracting data from completed normal engineering projects to construct a trusted baseline library and statistically analyzing the normal latency parameters of each source class under different node types.

[0164] In actual operation, the monitoring system continuously receives electronic records from various source systems according to a preset time window. Data processing is performed automatically in the background without manual intervention. The system first standardizes and synchronizes the input data, then performs a series of operations including event merging, evidence verification, loop closure detection, and breakpoint location, all automatically. When an abnormal breakpoint is detected, the system automatically extracts the evidence package and generates an early warning location image. The early warning information is sent to relevant management personnel via a message push mechanism and simultaneously stored in the system log for subsequent auditing and tracing.

[0165] The final output mainly includes three aspects. The first is the early warning positioning image, such as... Figure 2 As shown, the image uses a two-dimensional coordinate system to present the security status of the entire payment chain. The horizontal axis represents the sequence of nodes in the chain, and the vertical axis represents the data source category. Normal nodes are displayed as green circles, and abnormal breakpoints are displayed as red circles with red borders. Managers can intuitively see the specific location of the anomaly in the chain and the data source involved through the image. The metadata area of ​​the image file embeds evidence digests and monitoring signatures, allowing anyone to verify the authenticity and completeness of the warning information using standard tools. Secondly, there are the coordinates of the abnormal breakpoints, including node category labels, chain sequence numbers, source category coordinates, and warning trigger flags. This structured data can be directly imported into other management systems for further processing, such as automatically triggering audit processes or suspending related payment operations. Thirdly, there is the evidence digest data, including chain summaries of the breakpoint node and its adjacent nodes, closed-loop distortion values, and breakpoint strength values, forming a complete and verifiable chain of evidence to support subsequent investigation and evidence collection.

[0166] For example, at the monthly settlement node of a construction project, the monitoring system detects an anomaly in the acceptance confirmation source record, with the breakpoint strength value exceeding the adaptive trigger benchmark. The system automatically generates an early warning location image, marking the location of the acceptance confirmation source corresponding to the monthly settlement node in red on the link diagram. Simultaneously, the output coordinates of the anomaly breakpoint clearly point to the node and the data source, and the evidence summary contains complete summary information of the three nodes before and after this node. After receiving the early warning, management personnel can quickly locate the specific acceptance record based on the location information, verify it in conjunction with the evidence summary, promptly detect and handle data tampering, and prevent abnormal project payment.

[0167] The content of this embodiment has been described above, but this embodiment is not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms based on the guidance of this embodiment, all of which are within the protection scope of this embodiment.

Claims

1. A method for full-chain monitoring and early warning of engineering payments based on multi-source data fusion, characterized in that, Includes the following steps: Step S1: Receive multi-source electronic records, perform standardization and time unification operations, and generate standard load data, basic attribute data, and reliable time values; Step S2: Perform merge and hash operations on the specification payload data, basic attribute data, and trusted time values, and output the event node set, node category label, link sequence number, and semantic hash sequence. Step S3: Input the standard load data, basic attribute data and reliable time value into the anti-counterfeiting model for verification, and generate a chained summary sequence and evidence continuity coefficient value. Step S4: Perform closed-loop coherence operation based on the node category label in the event node set, the trusted time value, the semantic hash sequence, and the evidence continuity coefficient value to obtain the closed-loop distortion value. Step S5: Calculate the local mutation gradient from the event node set, link sequence number, evidence continuity coefficient value and closed-loop distortion value, and output the breakpoint strength value, abnormal breakpoint coordinates and early warning trigger parameters. Step S6: Perform digest encapsulation and signature operation on the chain digest sequence, closed-loop distortion value, breakpoint strength value and abnormal breakpoint coordinates to obtain evidence digest data and monitoring signature data; Step S7: Use the link sequence number, abnormal breakpoint coordinates, early warning trigger parameters, evidence summary data and monitoring signature data to perform graphic rendering and encapsulation, and construct early warning positioning image and image verification data for monitoring display.

2. The method for full-chain monitoring and early warning of engineering payments based on multi-source data fusion according to claim 1, characterized in that, Step S1 includes the following steps: Receive multi-source electronic records from a fixed source set, which includes building information model and real-world progress sources, quantity measurement sources, acceptance confirmation sources, contract milestones and approval sources, and payment confirmation and log storage sources. Perform load normalization processing on multi-source electronic records to generate normalized load data; The source generation time is converted into a reliable clock coordinate, and the source system clock offset is written into the basic attribute data; For source classes that lack business records in the input window, generate missing placeholder records and write the missing placeholder records into the basic attribute data; Outputs standard load data, basic attribute data, and confidence time values.

3. The method for full-chain monitoring and early warning of engineering payments based on multi-source data fusion according to claim 1, characterized in that, Step S2 includes the following steps: Candidate buckets are created based on project segment identifiers, engineering entity identifiers, and node category labels; Within the candidate bucket, perform token segmentation, field path marking, and unit label retention on the canonical payload data; Records with the same key are grouped into the same event node, and records with keys that are not completely identical are uniquely merged. Generate a semantic hash sequence based on the payload data of each specification; Output the event node set, node category label, link sequence number, and semantic hash sequence.

4. The method for full-chain monitoring and early warning of engineering payments based on multi-source data fusion according to claim 1, characterized in that, Step S3 includes the following steps: Following the order of each source class and event node within the fixed source set, concatenate the previous link node summary, canonical payload data, basic attribute data, and trusted time value, perform anti-collision hashing operation, and generate a chained summary sequence. Perform verification on the source system signature, Merkel path, and chain digest; Perform a logical AND operation on the verification result to generate a continuity coefficient value for the evidence storage; Among them, the continuity coefficient value of the evidence for missing placeholder records is fixed at 0.

5. The method for full-chain monitoring and early warning of engineering payments based on multi-source data fusion according to claim 1, characterized in that, Step S4 includes the following steps: Based on the node category label, read the source class offset baseline and the median inter-source delay deviation from the trusted baseline library; Subtract the normal inter-source delay from the reliable time difference between the two source classes and normalize it using a preset time stability term to generate a signed phase residual. The semantic hash difference is generated by bitwise XORing the semantic hash sequences of the two source classes and dividing by the number of semantic hash bits. The evidence continuity coefficient values, signed phase residuals, and semantic hash differences of the two source classes are coherently processed to generate dual-source coherent coefficient values. The three-source closed-loop residuals are calculated based on the three-source closed triplet, and the closed-loop distortion values ​​are generated by combining the two-source coherence coefficient values.

6. The method for full-chain monitoring and early warning of engineering payments based on multi-source data fusion according to claim 1, characterized in that, Step S5 includes the following steps: Calculate the continuity ratio of source evidence based on the evidence continuity coefficient value of each source class in the fixed source set; Based on the predecessor and successor neighbors in the event node set, calculate the local abrupt gradient between the closed-loop distortion value and the neighbor's closed-loop distortion value; The breakpoint strength value is generated by combining the closed-loop distortion value, the continuity ratio of source memory evidence, and the local mutation gradient. The source class coordinates are determined based on the breakpoint strength values ​​and the dual-source coherence coefficient values; Triggering benchmarks are generated based on the median of the chain strength and the median of the absolute deviation of the breakpoint values. Warning triggering parameters are calculated, and abnormal breakpoint coordinates are generated.

7. The method for full-chain monitoring and early warning of engineering payments based on multi-source data fusion according to claim 1, characterized in that, Step S6 includes the following steps: Extract the chained summary sequence, closed-loop distortion value, breakpoint strength value, and adjacent link node summary of the breakpoint event node corresponding to the abnormal breakpoint coordinates; The chained summary sequence, closed-loop distortion value, breakpoint strength value, abnormal breakpoint coordinates and adjacent link node summary are encapsulated to generate evidence summary data; The evidence digest data is concatenated with the time of generation of the early warning location image, and a digital signature operation is performed using the monitoring private key to obtain the monitoring signature data. The evidence summary data does not contain the original text that can restore personal identity or business evaluation, and the isolation marker is only written to the read copy in the monitoring cache.

8. The method for full-chain monitoring and early warning of engineering payments based on multi-source data fusion according to claim 1, characterized in that, Step S7 includes the following steps: Calculate image coordinates based on link sequence number and fixed source set; Input the event node set, fixed source set, image coordinates, abnormal breakpoint coordinates, early warning trigger parameters, and evidence summary data into the deterministic graphics rendering function to generate an early warning location image; Write the evidence summary data and monitoring signature data into the image metadata area; The warning location image, evidence summary data, and monitoring signature data are concatenated and then hashed to generate image verification data.

Images