Cross-departmental coordination examination and supervision system for industrial projects based on trusted computing

Abstract

The application provides an industry project cross-departmental collaborative examination and approval and supervision system based on trusted computing, relates to the technical field of cross-departmental processing, and comprises an extraction module used for triggering an intelligent contract deployed on a consortium chain based on on-chain evidence records, generating an examination and approval event, and quantifying each behavior characteristic into a risk index corresponding to each dimension through a preset risk model according to the data integrity, process time sequence and operation behavior characteristics in the examination and approval process event, and the set of risk indexes of each dimension constitutes a multi-dimensional vector. Through on-chain trusted evidence, multi-dimensional risk measurement, dynamic credit evaluation and closed-loop regulation and control, the application realizes the precision, credibility and dynamic optimization of the cross-departmental collaborative examination and approval and supervision of industry projects, improves the examination and approval efficiency and supervision effectiveness, and guarantees the scientificity and safety of collaborative control.

Description

Technical Field

[0001] This invention relates to the field of cross-departmental processing technology, and in particular to a cross-departmental collaborative approval and supervision system for industrial projects based on trusted computing. Background Technology

[0002] In business scenarios involving multi-departmental collaborative approval and supervision of industrial projects, the participating parties typically submit and transfer business data through electronic systems. Existing technical solutions mainly rely on soft identity verification methods such as user accounts and digital certificates, which have achieved electronic processes and online collaboration to a certain extent. However, such methods are still insufficient in ensuring the authenticity and integrity of data at the source of generation and in the initial submission stage, which may affect the credibility of the basis for subsequent multi-departmental collaborative approval.

[0003] For example, in a municipal rail transit construction project, the construction unit is required to regularly submit construction quality acceptance records to the quality supervision station, the construction unit, and the supervision party. The current practice is that construction personnel fill out the records and upload electronic documents through the project management system, which records the upload account and time. In this process, there are multiple steps between data generation and final submission (such as exporting, temporary storage, and transmission), which may pose a risk of unauthorized data modification. Existing systems typically struggle to independently verify the complete state of data before submission. When different departments raise questions about the consistency of the same record during subsequent approvals or supervision, there is often a lack of sufficient technical means to efficiently and objectively verify the original state of the record at the time of submission, potentially increasing the cost of collaborative verification and impacting the efficiency of supervision and decision-making. Summary of the Invention

[0004] The technical problem to be solved by this invention is to provide a cross-departmental collaborative approval and supervision system for industrial projects based on trusted computing, so as to improve the smoothness of cross-departmental approval and supervision.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0006] The first aspect is a cross-departmental collaborative approval and supervision system for industrial projects based on trusted computing, including:

[0007] The extraction module is used to trigger smart contracts deployed on the consortium blockchain based on on-chain evidence records, generate approval events, and quantify each behavioral feature into corresponding risk indicators in each dimension through a preset risk model based on the data integrity, process sequence and operation behavior characteristics in the approval process events. The set of risk indicators in each dimension constitutes a multi-dimensional vector.

[0008] The module is used to define the multi-dimensional vector set corresponding to historical normal approval events as the normal event vector set; a vector space is constructed with risk indicators of each dimension as coordinate axes; and a benchmark hypersurface is fitted and generated based on the distribution of the normal event vector set in the vector space.

[0009] The measurement module is used to calculate the shortest projection distance from the multidimensional vector corresponding to the current approval event to the benchmark hypersurface, and uses the shortest projection distance as the comprehensive risk measurement value.

[0010] The scheduling module is used to plan tasks through the supervision strategy engine, generate a sequence of supervision tasks sorted by comprehensive risk metric, and assign them to predefined gridded supervision nodes.

[0011] The assessment module is used to construct on-chain audit trails and generate dynamically updated credit evaluation results based on the data in the on-chain audit trails through a preset credit assessment model.

[0012] The feedback module is used to convert dynamic credit evaluation results into approval rule adjustment parameters and risk monitoring threshold adjustment parameters, and feed the adjustment parameters back to the smart contract's preset rule base and supervision strategy engine to dynamically optimize approval conditions and risk monitoring strategies, forming a closed-loop approval supervision and control mechanism.

[0013] In a second aspect, a computer-readable storage medium is provided for storing a computer program for performing the system described in the first aspect.

[0014] The above-described solution of the present invention has at least the following beneficial effects:

[0015] Leveraging trusted computing technology and consortium blockchain evidence storage mechanisms, a security barrier is built from the source of data generation to ensure the authenticity and non-repudiation of data relied upon for cross-departmental collaborative approvals. This provides a reliable basis for departmental approval decisions and avoids approval disputes and decision-making errors caused by unreliable data. By extracting multi-dimensional features from the approval process and utilizing vector space modeling and benchmark hypersurface fitting, quantitative assessment of approval risks is achieved. This enables the identification of abnormal risk points in the approval process, changing the reliance on manual experience to judge risks and improving the objectivity and targeting of risk identification. Based on comprehensive risk metrics, supervisory tasks are prioritized and combined with a grid-based supervisory node allocation mechanism to concentrate supervisory resources on high-risk matters, avoiding resource waste, improving the targeting and execution efficiency of supervisory work, and strengthening the control over key risk links. Finally, the entire approval process data is integrated. An on-chain audit trail is constructed, which serves as the basis for dynamically updated credit evaluation results. This comprehensively and objectively reflects the behavior of project participants, providing a basis for differentiated management. The credit evaluation results are dynamically linked with approval rules and risk monitoring thresholds to form a closed-loop mechanism. This enables adaptive adjustments to approval and supervision strategies without human intervention, continuously improving the efficiency and standardization of cross-departmental collaborative approvals. By automating the triggering of approval events and departmental linkages through smart contracts, process delays and operational deviations caused by human intervention are reduced, breaking down collaboration barriers between departments. At the same time, relying on standardized risk assessment and credit management mechanisms, collaboration criteria among departments are unified, improving the smoothness of cross-departmental approval and supervision collaboration. The on-chain audit trail completely records the operation and data flow information of the entire approval process, forming an immutable traceability chain, providing sufficient technical support for regulatory audits and dispute arbitration. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of a cross-departmental collaborative approval and supervision system for industrial projects based on trusted computing, provided by an embodiment of the present invention.

[0017] Figure 2 This is a schematic diagram of the process of constructing an on-chain audit trail and generating dynamically updated credit evaluation results based on the data in the on-chain audit trail through a preset credit evaluation model, provided by an embodiment of the present invention. Detailed Implementation

[0018] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0019] like Figure 1As shown, embodiments of the present invention propose a cross-departmental collaborative approval and supervision system for industrial projects based on trusted computing, comprising:

[0020] The extraction module is used to trigger smart contracts deployed on the consortium blockchain based on on-chain evidence records, generate approval events, and quantify each behavioral feature into corresponding risk indicators in each dimension through a preset risk model based on the data integrity, process sequence and operation behavior characteristics in the approval process events. The set of risk indicators in each dimension constitutes a multi-dimensional vector.

[0021] The module is used to define the multi-dimensional vector set corresponding to historical normal approval events as the normal event vector set; a vector space is constructed with risk indicators of each dimension as coordinate axes; and a benchmark hypersurface is fitted and generated based on the distribution of the normal event vector set in the vector space.

[0022] The measurement module is used to calculate the shortest projection distance from the multidimensional vector corresponding to the current approval event to the benchmark hypersurface, and uses the shortest projection distance as the comprehensive risk measurement value.

[0023] The scheduling module is used to plan tasks through the supervision strategy engine, generate a sequence of supervision tasks sorted by comprehensive risk metric, and assign them to predefined gridded supervision nodes.

[0024] The assessment module is used to construct on-chain audit trails and generate dynamically updated credit evaluation results based on the data in the on-chain audit trails through a preset credit assessment model.

[0025] The feedback module is used to convert dynamic credit evaluation results into approval rule adjustment parameters and risk monitoring threshold adjustment parameters, and feed the adjustment parameters back to the smart contract's preset rule base and supervision strategy engine to dynamically optimize approval conditions and risk monitoring strategies, forming a closed-loop approval supervision and control mechanism.

[0026] In this embodiment of the invention, relying on trusted computing technology and a consortium blockchain evidence storage mechanism, a security barrier is built from the source of data generation to ensure the authenticity and non-repudiation of data relied upon for cross-departmental collaborative approvals. This provides a reliable basis for approval decisions by various departments and avoids approval disputes and decision-making errors caused by unreliable data. By extracting multi-dimensional features from the approval process and using vector space modeling and benchmark hypersurface fitting, a quantitative assessment of approval risks is achieved. This enables the identification of abnormal risk points in the approval process, changing the mode of relying on human experience to judge risks and improving the objectivity and pertinence of risk identification. Based on comprehensive risk metrics, supervision tasks are prioritized and combined with a grid-based supervision node allocation mechanism to concentrate supervision resources on high-risk matters, avoiding resource waste, improving the targeting and execution efficiency of supervision work, and strengthening the control over key risk links. The entire approval process is integrated. The process data constructs an on-chain audit trail, which serves as the basis for dynamically updated credit evaluation results. This comprehensively and objectively reflects the behavior of project participants, providing a basis for differentiated management. The credit evaluation results are dynamically linked to approval rules and risk monitoring thresholds, forming a closed-loop mechanism. This allows for adaptive adjustments to approval and supervision strategies without human intervention, continuously improving the efficiency and standardization of cross-departmental collaborative approvals. Smart contracts automatically trigger approval events and departmental collaborations, reducing process delays and operational deviations caused by human intervention and breaking down inter-departmental collaboration barriers. Simultaneously, relying on standardized risk assessment and credit management mechanisms, it unifies collaboration criteria across departments, improving the smoothness of cross-departmental approval and supervision. The on-chain audit trail fully records the operation and data flow information of the entire approval process, forming an immutable traceability chain, providing ample technical support for regulatory audits and dispute arbitration.

[0027] In another preferred embodiment of the present invention, the process of obtaining the on-chain evidence record is as follows:

[0028] Step 001: Collect raw business data generated during the cross-departmental collaboration of industrial projects. This raw business data includes application documents, approval documents, on-site inspection records, and progress reports. Specifically, throughout the entire process of cross-departmental collaborative approval and supervision of industrial projects, the system comprehensively collects key business data from all participants, including applicants, approval departments, supervisory agencies, and project implementation units, focusing on each crucial stage from project initiation to acceptance and handover. The collection scope precisely covers four core data types: a complete set of application documents submitted by the applicant in a standardized format during the project application stage, including project feasibility study reports, qualification certificates, and project initiation application documents; approval documents issued by relevant approval departments according to their business responsibilities during the approval process, including preliminary review opinions, review conclusions, and final approval decisions. The system includes: on-site inspection records generated by supervisors during the on-site verification process, containing detailed information such as inspection time, inspection content, problems found, and rectification requirements; progress reports submitted by relevant parties at agreed intervals during project progress, covering core content such as project progress, fund usage, and phased results; and to ensure secure and controllable data transmission, the system first completes identity authentication and encryption negotiation with the business terminals of each participating party, establishing a secure data transmission channel based on an encryption protocol. During transmission, end-to-end encryption is used to protect the original business data, and a data verification mechanism verifies data integrity in real time, ensuring that the original business data is transmitted completely, without omissions, and without tampering to the preprocessing node designated by the system, thus avoiding the risk of data theft, tampering, or loss during transmission from the source.

[0029] Step 002: In the trusted execution environment deployed on the business terminals, the original business data is hashed to obtain a data hash value. The data hash value is then digitally signed using the hardware key embedded in the trusted execution environment, and a current trusted timestamp obtained by the trusted execution environment is appended to generate a trusted data fingerprint containing the data hash value, digital signature, and timestamp. Specifically, after the original business data is collected and transmitted to the preprocessing node, the system immediately initiates the trusted processing flow, importing the complete original business data into the trusted execution environment deployed on the business terminals of each participating party. This trusted execution environment is a dedicated security environment independent of the business terminal operating system. The fully isolated space, constructed with hardware-level isolation technology, creates a closed operating environment that effectively resists external attacks such as malicious code injection and unauthorized access, ensuring the security and independence of data processing. Within the trusted execution environment, the system calls a preset hash algorithm to perform byte-by-byte operations on the original business data. Specifically, the original business data is first divided into several data blocks of fixed byte length. Each data block is then hashed sequentially to obtain an intermediate hash value. Finally, all intermediate hash values ​​are combined in sequence and subjected to a second hash operation, ultimately generating a unique hash string of fixed length, i.e., the data hash value. This operation process possesses strong resistance to external attacks. Collision resistance ensures that even a single byte addition, deletion, or modification to the original business data will fundamentally change the generated data hash value, thus enabling precise verification of the original data integrity. Subsequently, the system invokes the hardware key embedded in the Trusted Execution Environment (TEE). This hardware key is permanently embedded in a dedicated hardware chip within the TEE, deeply bound to the hardware device and cannot be exported, copied, or modified through software, ensuring the security of the key itself. The system uses an asymmetric encryption algorithm, employing the hardware key as the private key to encrypt the generated data hash value. Specifically, a digest operation is first performed on the data hash value to obtain a data digest, and then the hardware private key is used to encrypt the hash value. The data digest is encrypted to generate a unique digital signature, completing the irreversible binding between the hardware key and the data hash value. At the same time, the trusted execution environment obtains the current time information through an internally integrated high-precision secure clock. This secure clock is isolated from the external network time and ensures time accuracy through a hardware synchronization mechanism, generating a trusted timestamp with tamper-proof characteristics to accurately record the specific time node of data processing. Finally, the system integrates and splices the data hash value, digital signature, and trusted timestamp according to a preset data structure to generate a trusted data fingerprint containing these three types of core information, completely solidifying the key characteristics and processing trajectory of the original business data.

[0030] Step 003 involves encapsulating the trusted data fingerprint with associated metadata describing the data source's identity, business data type, and related project number to generate a data packet to be stored. This data packet is then broadcast to the consortium blockchain network. Consensus nodes in the network verify and sort the data packet according to the consensus algorithm and record it in a new block of the distributed ledger, forming an on-chain notarization record with time sequence and consensus endorsement. Specifically, after the trusted data fingerprint is generated, the system immediately initiates the on-chain notarization process. First, it collects and organizes associated metadata. The collection of associated metadata must cover three core dimensions: the data source's identity information, including the full name of the data submitting entity, the unified social credit code, the system registration number, and other unique identifiers to ensure accurate identification of the data generating entity; business data type classification information, which is standardized and labeled according to the business process (such as application, approval, supervision, progress reporting) and data format (such as document, table, image); and associated project number information, i.e., the unique project code of the industry project to which the data belongs, to achieve accurate association between the data and the specific project. After collection, the system standardizes the format of this information and integrates it into a unified structure with consistent fields. Complete associated metadata; next, the system combines and encapsulates the trusted data fingerprint generated in step 002 with the organized associated metadata according to the data encapsulation format agreed upon by the consortium blockchain network. First, the two types of data are format-verified separately to ensure no fields are missing and no format errors occur. Then, they are packaged into a unified structured data packet for verification. The packet header contains control information such as data length and checksum to ensure the integrity and verifiability of the data packet during transmission and storage. Afterward, the system broadcasts the data packet to be verified to the entire consortium blockchain network through a dedicated communication node. All consensus nodes in the consortium blockchain network synchronously receive the data packet. Upon receiving the data packet, each consensus node immediately initiates a multi-dimensional verification process according to the preset consensus algorithm. First, it verifies the digital signature in the trusted data fingerprint by decrypting the digital signature using the corresponding public key published in the consortium blockchain network to obtain a data digest. Then, it re-performs the digest operation on the data hash value in the data packet and compares the two data digests to verify the validity of the digital signature. Second, it verifies the rationality of the data hash value by checking whether its length and format conform to the output standard of the preset hash algorithm to ensure the standardization of the hash operation process.Finally, the integrity of the associated metadata is verified, checking whether key fields such as identity identifier, data type, and project number are complete and whether the format is compliant. After all consensus nodes complete the verification and reach a consensus, the verified data packets to be stored are uniformly sorted according to the trusted timestamp order of the data packets and the sorting rules agreed upon by the consensus algorithm. This clarifies the storage order of each data packet in the distributed ledger. Finally, the system writes the sorted data packets to be stored in batches into new blocks of the distributed ledger. Each new block contains the data packets to be stored and also records the hash value of the previous block. All blocks are linked together in chronological order using hash pointers to form a chain structure. At the same time, all consensus nodes synchronously update their locally stored distributed ledgers to ensure the consistency of the ledger data of each node. Ultimately, an on-chain evidence record with a clear time sequence, endorsed by all consensus nodes in the network, and linked in a chain is formed, technically ensuring the immutability, full traceability, and multi-party verifiability of the evidence data.

[0031] This embodiment, through the isolation and protection of a trusted execution environment and technologies such as hash operations and digital signatures, ensures that the original business data is not tampered with throughout the entire process from data collection to fingerprint generation, providing a reliable data foundation for cross-departmental approvals and avoiding approval errors caused by data falsification. The digital signature in the trusted data fingerprint is bound to a hardware key, and the associated metadata clearly identifies key information such as the data source. Combined with the time sequence of on-chain evidence records, the origin and flow path of the data can be clearly traced. The distributed storage and consensus verification mechanism of the consortium blockchain ensures that the evidence data is stored across multiple nodes, and the anomaly of a single node will not affect the overall data security. Simultaneously, the multiple verifications by consensus nodes further guarantee the validity and immutability of the evidence data. The on-chain evidence records possess consensus endorsement and immutability, allowing participating departments to query and verify the evidence data through the consortium blockchain, eliminating doubts between departments regarding data credibility and building a trust bridge for cross-departmental collaborative approval and supervision.

[0032] In a preferred embodiment of the present invention, based on on-chain evidence records, a smart contract deployed on the consortium blockchain is triggered to generate an approval event. Then, based on the data integrity, process sequence, and operational behavior characteristics of the approval process event, a preset risk model quantifies each behavioral characteristic into corresponding risk indicators for each dimension. The set of risk indicators for each dimension constitutes a multi-dimensional vector, including:

[0033] Step 100: Extract the business type identifier and project stage identifier from the associated metadata of the on-chain evidence storage record. Based on the combination key formed by the business type identifier and project stage identifier, match and call the smart contract pre-deployed on the consortium blockchain for the corresponding business scenario. Execute the smart contract. The smart contract, based on a built-in rule base associated with the corresponding combination key, performs logical judgment and state deduction on the data content of the on-chain evidence storage record to obtain a structured approval process event containing the current approval stage name, responsible department code, approval status identifier, and event occurrence timestamp. Specifically, the system first starts the on-chain evidence storage record parsing program, accesses the distributed ledger through the consortium blockchain node interface, locates the target on-chain evidence storage record, and accurately extracts the business type identifier and project stage identifier from the associated metadata fields of the record. The business type identifier clearly defines the specific business scope corresponding to the current data, such as construction permit application, quality... The data includes quantity acceptance and filing, fund disbursement review, and planning scheme approval. The project stage identifier strictly defines the life cycle stage of the industry project to which the data belongs, covering core links such as the project initiation stage, construction stage, acceptance stage, and operation stage, ensuring that the two identifiers can fully lock the business scenario attributes. After extraction, the system concatenates the business type identifier and the project stage identifier into a string in a fixed format of business type-project stage to form a unique combination key. This combination key serves as a dedicated index for the business scenario and corresponds one-to-one with the smart contracts pre-deployed on the consortium blockchain. During the deployment stage, the consortium blockchain has customized dedicated smart contracts for various business scenarios and recorded the combination key corresponding to each contract in the smart contract registry. The system performs a precise matching query in the registry using the combination key to quickly locate the smart contract corresponding to the current business scenario, and then sends a contract call request to the consortium blockchain node, along with the core data address of the on-chain evidence record.

[0034] After a smart contract is successfully invoked, it automatically loads a built-in, proprietary rule base. This rule base, bound to a key combination, contains complete approval logic for the corresponding business scenario, such as the order of approval steps, core review points for each step, functional division standards for responsible departments, and pre-defined rules for determining approval status. Next, the smart contract reads the complete data content of the on-chain evidence record through the data address and processes it sequentially according to the logic in the rule base. Based on the approval step order rules and the current data submission progress, it determines the name of the current approval step, such as the initial material review step for a construction permit application or the on-site verification step. Then, based on the business responsibility division rules, it matches the current... The code of the responsible department corresponding to the pre-approval stage ensures accurate identification of the responsible entity; the approval status is determined by comparing the approval status judgment conditions with information such as data submission status and review operation records, including specific statuses such as pending review, under review, approved, rejected, and requiring supplementary materials; at the same time, the trusted timestamp generated by the trusted execution environment in the on-chain evidence storage record is directly extracted as the occurrence timestamp of the current approval process event; finally, the smart contract integrates the current approval stage name, responsible department code, approval status identifier and event occurrence timestamp in a structured manner according to the preset data structure specifications to generate a structured approval process event with unified fields and standard format.

[0035] Step 101: Perform structured analysis on the approval process events, extracting data integrity features reflecting the completeness and format standardization of data items; process sequence features reflecting the processing time of this step and the schedule deviation relative to the total project duration; and operational behavior features reflecting the matching degree between the operation instruction sequence and the preset standard workflow template. Input the data integrity features into the first evaluation sub-model of the preset risk model, trained based on historical data integrity status, and output a data authenticity index. Input the process sequence features into the second evaluation sub-model of the preset risk model, trained based on historical process timeliness data, and output a process timeliness index. Input the operational behavior features into the third evaluation sub-model of the preset risk model, trained based on historical compliant operation samples, and output a behavioral compliance index, specifically including:

[0036] The first step involves the system initiating a structured analysis process for the received structured approval workflow events. This process extracts three core features: data integrity, workflow sequence, and operational behavior. When extracting data integrity features, the system first retrieves a list of required data items from a pre-defined business standard database based on the business scenario corresponding to the event. This list clearly specifies all the core data items required to complete the approval process in that business scenario. For example, a construction permit application scenario requires a project feasibility study report, enterprise qualification certificate, and site use right certificate. Subsequently, the system uses the data index of the on-chain evidence storage records to query all related stored data for the current event. The system verifies the data, counts the actual number of required data items that are complete, and calculates the data item completeness (calculated as: actual number of complete data items ÷ total number of required data items × 100%). Simultaneously, the system checks the file format, field length, encoding method, etc., of each piece of evidence data against the preset data format standards for this business scenario. It counts the number of compliant data items and calculates the format compliance (calculated as: number of compliant data items ÷ total number of submitted data items × 100%). Data item completeness and format compliance together constitute the data integrity feature. When extracting process sequence features, the system obtains this information from structured approval process events. The system calculates the processing time for this stage by combining the start timestamp of the previous stage (automatically recorded upon completion of the previous stage's approval) with the current event's occurrence timestamp (the formula is: event occurrence timestamp value - start timestamp value of this stage). Simultaneously, the system retrieves the total planned duration and preset processing times for each stage of the industry project from the project management database, calculating the progress deviation of this stage relative to the planned duration (the formula is: (actual processing time of this stage - preset processing time of this stage) ÷ total planned project duration × 100%). The processing time of this stage and the progress deviation together constitute the process sequence characteristics. When extracting operational behavior characteristics, the system... The system obtains the complete sequence of operation instructions corresponding to the current approval process through the operation log interface of the consortium blockchain, including the instruction code and execution order of each step of the operation such as data submission, review initiation, opinion entry, and status change. Then, it retrieves the standard workflow template corresponding to the business scenario from the system's preset standard workflow template library. The template clearly defines the instruction sequence specifications for compliant operations. The system uses a sequence comparison algorithm to compare the actual operation instruction sequence with the standard template step by step and calculate the matching degree (the calculation formula is: number of matching operation steps ÷ total number of operation steps in the standard template × 100%). This matching degree is the operation behavior feature.

[0037] The second step involves the system constructing a pre-defined risk model. This model consists of three independent assessment sub-models, each corresponding to one of three risk quantification needs. When constructing the first assessment sub-model (used to output data authenticity indicators), the system collects historical approval process event data from the historical approval database for the past three years within this business area. It extracts historical data integrity characteristics (including the completeness of historical data items and standardized format records). Simultaneously, a triple verification mechanism is used to determine the authenticity of each piece of historical data: first, the hash value stored on the blockchain is compared with the recalculated hash value of the original data; if they match, it is preliminarily determined that the data has not been tampered with; second, [the system then] adjusts... The process involves three steps: First, cross-validation records generated during cross-departmental collaboration are retrieved. If the data copies retained by multiple departments are consistent, further confirmation is performed. Second, a manual verification process is initiated for disputed data. Professional auditors make judgments based on business rules and actual scenarios, and finally, labels are assigned to the data based on the comprehensive verification results, forming a labeled training dataset. The two dimensions of historical data integrity features are used as input variables, and the corresponding true situation labels are used as output labels. A logistic regression algorithm is used to construct the model framework. During training, the gradient descent method is used to minimize the logarithmic loss function between the model's predicted values ​​and the true labels, iteratively adjusting the model's weight parameters and bias terms. Regarding the initial weight settings, considering that complete data items are a fundamental prerequisite for data authenticity, and missing core data items directly affect data credibility, the initial weight of data item completeness is set to 0.6, and the initial weight of format standardization, as an auxiliary verification dimension, is set to 0.4. The initial value of the bias term is set to 0.1 to avoid the model output becoming too extreme when the feature data approaches 0. The model prediction accuracy is calculated every 100 iterations. Training stops when the prediction accuracy consistently reaches 90% or higher (preset threshold) for three consecutive iterations. The optimal weights for data item completeness and format normalization are determined to be 0.62 and 0.38, respectively. This is because during training, it was found that data item completeness contributed slightly more to the accurate prediction than initially set, while format normalization contributed slightly less. Adjusting these weights resulted in a better model fit. The bias term was ultimately set to 0.08 to correct the overall prediction bias of the model, making the prediction results closer to the actual verification situation, thus completing the construction of the first evaluation sub-model.

[0038] When constructing the second evaluation sub-model (used to output process timeliness indicators), the system collects historical approval process data from the past three years, extracts process timing features (processing time and progress deviation of each historical stage), and labels the process timeliness evaluation results based on preset timeliness judgment rules. The preset processing time is precisely set according to different approval stage types: the preset processing time for the initial review of construction permits is 5 working days, for the quality acceptance filing stage it is 3 working days, and for the fund disbursement review stage it is 4 working days. These values ​​are based on the standard cycle of the approval service guidelines issued by the industry's competent authority and calibrated in conjunction with the average processing time of historical approvals in this business area over the past three years, thus meeting both official requirements and the actual pace of business processing. The 1.5 in the timeliness judgment rules is a delay ratio threshold set based on the conventional flexible time standard of the industrial project approval industry, allowing for slight delays within 1.5 times the preset time in the actual processing time. This threshold has been verified through statistical analysis of a large amount of historical approval data. The system can accommodate reasonable fluctuations in business processing (such as communication for supplementary materials, and coordination among multiple departments) while effectively distinguishing between normal efficiency and inefficient delays. The specific judgment rules are as follows: if the actual processing time of this step is less than or equal to the preset processing time, it is marked as completed on time; if the preset processing time is less than the actual processing time but less than or equal to the preset processing time × 1.5, it is marked as slightly delayed; if the actual processing time is greater than or equal to the preset processing time × 1.5, it is marked as severely delayed. This forms a training dataset with three types of labels. Using two dimensions of process time sequence characteristics as input and the timeliness evaluation results as output labels, a support vector machine algorithm is used to construct the model. A grid search method is used to traverse preset kernel functions (linear kernel, polynomial kernel, Gaussian kernel) and penalty coefficients (ranging from 1 to 10). A 5-fold cross-validation method is used to evaluate the model performance of each parameter group. Finally, the Gaussian kernel (radial basis function kernel, RBF kernel) is determined as the optimal kernel function, with the formula: K(x, xi) = exp(-γ ), where x and xi are the process time sequence feature vectors of the two samples (each containing two dimensions: processing time and progress offset). The Euclidean distance between two feature vectors is represented by γ, which is the bandwidth parameter of the kernel function (γ=0.2 in this training by grid search). exp is the natural exponential function. The reason for choosing this kernel function is that the relationship between processing time and progress offset in the process sequence features is not a simple linear one. The Gaussian kernel can project feature vectors into a high-dimensional feature space through nonlinear mapping, accurately capturing the complex correlation between features, thereby improving the model classification accuracy. The penalty coefficient is set to 5 because this value achieves the best balance between avoiding model overfitting and ensuring classification accuracy. It will not cause the model to be sensitive to outliers due to too light a penalty, nor will it cause the model to be underfitting due to too heavy a penalty. At this time, the model classification accuracy reaches more than 88% (preset requirement), and the training of the second evaluation sub-model is completed.

[0039] When constructing the third assessment sub-model (used to output behavioral compliance indicators), the system collects data from a historical compliant operation sample library, extracts operational behavior features (matching degree data between historical operation instruction sequences and standard workflow templates), and labels the operational behavior compliance results according to preset compliance judgment rules. If the matching degree between the operation instruction sequence and the standard workflow template is ≥90%, and there are no non-compliant operation instructions (such as unauthorized modification, skipping key approval steps, etc.), it is labeled as compliant; if the matching degree is <90%, or there is any non-compliant operation instruction, it is labeled as non-compliant, forming a labeled training dataset. The operational behavior feature data is used as input, and the compliance result labels are used as output. The random forest algorithm is used to build the model. Initially, the number of decision trees is set to 100 and the tree depth to 10 layers. During training, the number of decision trees (from 50 to 200) and the tree depth (from 5 to 15 layers) are adjusted iteratively. After each iteration, the prediction accuracy of the model on the test set is calculated. Finally, the number of decision trees is adjusted to 150 because increasing the number of decision trees can improve the model's stability and generalization ability. The tree depth is adjusted to 12 layers because this depth can capture deep features of the samples while avoiding overfitting caused by excessive tree depth. At this point, the model's prediction accuracy reaches more than 92% (preset standard) and the overfitting coefficient is less than 0.1. The iteration is stopped, and the construction of the third evaluation sub-model is completed.

[0040] Third, the system inputs the data integrity features (data item completeness and format standardization) extracted in the first step into the trained first evaluation sub-model. The model uses a built-in logistic regression algorithm to perform weighted calculations on the feature data (the weight parameters are the optimal values ​​determined during training, i.e., data item completeness 0.62 and format standardization 0.38), combined with a bias term of 0.08, and outputs the original value of the data authenticity index through Sigmoid function mapping. The process timing features (processing time of this stage and progress offset) are input into the second evaluation sub-model, and feature space mapping is performed through Gaussian kernel function, combined with a penalty... Coefficient 5 completes the classification calculation and outputs the original value of the process timeliness index. The operation behavior characteristics (operation instruction sequence matching degree) are input into the third evaluation sub-model, and predictions are made through 150 decision trees. The voting results are statistically analyzed, and the original value of the behavior compliance index is output. Then, the system standardizes the original values ​​of the three indicators (using the Min-Max standardization method, the calculation formula is: standardized value = (original value - historical minimum value of the indicator) ÷ (historical maximum value of the indicator - historical minimum value of the indicator) × 100), and uniformly maps the indicator values ​​to the range of 0 to 100 to ensure that the dimensions of each indicator are consistent.

[0041] Step 102: Combine the data authenticity indicator, process timeliness indicator, and behavioral compliance indicator in this fixed order to form a three-dimensional multi-dimensional vector. Specifically, after the system completes the standardization of the three indicators, it initiates the vector construction process. Following the fixed order of data authenticity, process timeliness, and behavioral compliance, the system systematically integrates the standardized indicator values. During the combination process, the original quantitative value of each indicator remains unchanged; only the sequential arrangement forms a three-dimensional multi-dimensional vector. For example, if the data authenticity indicator is 85, the process timeliness indicator is 92, and the behavioral compliance indicator is 88, then the constructed three-dimensional multi-dimensional vector is (…). (85, 92, 88) This vector fully carries all risk-related information for the current approval process event in the dimensions of data authenticity, process timeliness, and behavioral compliance. The value of each dimension is inversely related to the risk level of the corresponding dimension. That is, the higher the value of the data authenticity index, the more reliable the data source of the current approval process event is, the greater the probability that it has not been tampered with, and the lower the risk at the data level. The higher the value of the process timeliness index, the more the approval process is in line with the preset timeliness requirements, and the lower the risk of progress delays. The higher the value of the behavioral compliance index, the higher the degree of fit between the operation instruction sequence and the standard workflow template, the greater the possibility of no violations, and the lower the risk at the behavioral level.

[0042] This embodiment uses key-based matching to invoke a dedicated smart contract, and completes logical judgments and state deductions based on a preset rule base. This ensures the accuracy and standardization of key information such as approval processes and responsible departments, providing reliable basic data for subsequent risk assessments. A specialized risk assessment sub-model is constructed and trained specifically for different feature dimensions, improving the scientific rigor and accuracy of risk indicator quantification. This comprehensively and objectively reflects the risk status of the approval process in terms of data, timeliness, and behavior. By integrating multi-dimensional risk indicators through three-dimensional multi-dimensional vectors, the dispersed risk information is systematized and structured, providing clear and intuitive data support for risk identification and hierarchical management, and improving the accuracy and effectiveness of cross-departmental collaborative approval and supervision.

[0043] In a preferred embodiment of the present invention, the multi-dimensional vector set corresponding to historical normal approval events is defined as the normal event vector set; a vector space is constructed using risk indicators of each dimension as coordinate axes; and a benchmark hypersurface is fitted and generated based on the distribution of the normal event vector set in the vector space, including:

[0044] Step 200: From the historical on-chain evidence records stored in the consortium blockchain network, filter approval process events with the approval status marked as "final approval passed". For each selected approval process event, generate a three-dimensional multi-dimensional vector based on the extracted features and the steps quantified by the preset risk model. Specifically, the system first starts the historical data filtering process, accesses all historical on-chain evidence records stored in the distributed ledger through the query interface of the consortium blockchain node, traverses the structured approval process events associated with each record, and performs precise filtering based on the approval status mark, retaining only the approval process events with the approval status marked as "final approval passed". The core basis of this screening logic is that events that have passed final review have undergone full-process compliance verification, and their data characteristics, process timeliness, and operational behavior all conform to business specifications, thus serving as a sample basis for normal events. For each final-approved approval process event selected, the system strictly reproduces the complete process from steps 100 to 102, and performs feature extraction and quantification. First, it extracts the business type identifier and project stage identifier from the associated metadata of the on-chain evidence record related to the event, matches and calls the corresponding smart contract, and generates a standardized approval process event. Then, it performs structured analysis on the event, extracting data integrity features, process timing features, and operational behavior features, which are then input into a preset risk model. The system employs three sub-models for evaluation, outputting raw values ​​for data authenticity, process timeliness, and behavioral compliance indicators. Subsequently, the Min-Max standardization method is used to process these raw values. The calculation formula is: the standardized value equals the raw value minus the historical minimum value of the indicator, then divided by the difference between the historical maximum and historical minimum values ​​of the indicator, and finally multiplied by 100, mapping the three indicator values ​​uniformly to the range of 0 to 100. Finally, following a fixed order, the data authenticity, process timeliness, and behavioral compliance indicators are combined to form a three-dimensional multi-dimensional vector. Each final approved approval process event corresponds to a unique three-dimensional multi-dimensional vector.

[0045] Step 201: A normal event vector set is constructed from all three-dimensional multidimensional vectors, and a three-dimensional vector space is built using data authenticity indicators, process timeliness indicators, and behavior compliance indicators as three orthogonal dimensions. Each three-dimensional multidimensional vector in the normal event vector set is mapped to a coordinate point in the three-dimensional vector space according to the values ​​of the three indicators it contains. Specifically, the system summarizes all the three-dimensional multidimensional vectors generated in step 200 to form a normal event vector set, which contains risk characteristic data of all normal approval events that comply with business specifications. Subsequently, the system constructs a three-dimensional vector space using data authenticity indicators, process timeliness indicators, and behavioral compliance indicators as three mutually perpendicular orthogonal dimensions. These three dimensions correspond to the x-axis, y-axis, and z-axis of a three-dimensional Cartesian coordinate system, respectively. The x-axis represents the data authenticity indicator, the y-axis represents the process timeliness indicator, and the z-axis represents the behavioral compliance indicator. The value range of each dimension is consistent with the standardized value range of the indicators, i.e., 0 to 100, ensuring that the dimensional range of the vector space matches the indicator values. For each three-dimensional multi-dimensional vector in the normal event vector set, the system determines the specific position of the vector in the three-dimensional vector space based on the standardized values ​​of the three indicators it contains. The specific mapping rule is as follows: the standardized value of the data authenticity indicator in the vector is used as the x-axis coordinate value, the standardized value of the process timeliness indicator is used as the y-axis coordinate value, and the standardized value of the behavioral compliance indicator is used as the z-axis coordinate value. These three together constitute a three-dimensional coordinate point. Through this mapping method, each vector in the normal event vector set is accurately transformed into a coordinate point in the three-dimensional vector space. The set of all coordinate points intuitively presents the distribution pattern of normal approval events across the three risk characteristic dimensions.

[0046] Step 202: Based on the spatial positions of all coordinate points mapped to the three-dimensional vector space, a continuous smooth surface is fitted using the least squares method that minimizes the sum of squared distances from all coordinate points to the reference hypersurface. This surface is the reference hypersurface. Specifically, the system first clarifies the fitting objective, namely, constructing a continuous smooth surface that minimizes the sum of squared distances from all coordinate points mapped from the normal event vector set to the three-dimensional vector space to this surface. This surface is the reference hypersurface, used to define the risk characteristic distribution boundary of normal approval events. Since the distribution of normal event coordinate points in the three-dimensional vector space, consisting of three orthogonal dimensions, conforms to the distribution law of a quadratic surface, a quadratic surface is selected as the fitting object. Its general equation is: Where a, b, c, d, e, f, g, h, i, and j are coefficients to be determined; next, the system uses the least squares method for surface fitting. The specific calculation process is as follows: obtain the three-dimensional coordinate values ​​of all coordinate points, and let the coordinates of the k-th coordinate point be xk, yk, and zk, where k is the index of the coordinate point, from 1 to n (n is the total number of vectors in the normal event vector set); calculate the perpendicular distance from each coordinate point to the candidate quadratic surface. The distance calculation formula is the absolute value obtained by substituting the coordinate point into the left side of the surface equation, divided by the magnitude of the surface normal vector at that point; square the distance of each coordinate point to obtain the squared distance value of each point, and then add the squared distance values ​​of all coordinate points to obtain the total sum of squared distances; use the gradient descent method as a numerical optimization algorithm to adjust the coefficients a, b, c, d, e, f, g, h, i, and j in the surface equation. The specific adjustment process is as follows: First, all coefficients are initialized: a, b, and c are initialized to 0.01; d, e, and f to 0.005; g, h, and i to 0.002; and j to 0.001. The initial learning rate is set to 0.0001 (this learning rate is determined through small-scale trial and error to ensure convergence speed while avoiding iterative oscillations). Next, the partial derivative of the total squared distance with respect to each coefficient is calculated. The partial derivative reflects the trend of the total squared distance when the coefficient changes slightly. Then, the coefficients are updated according to the direction of the partial derivative. The update formula is: the new coefficient equals the original coefficient minus the learning rate multiplied by the corresponding partial derivative. This method adjusts the coefficients in the direction of decreasing total squared distance. Afterward, the total squared distance corresponding to the updated coefficients is repeatedly calculated. The difference between the current total squared distance and the previous one is compared. If the absolute value of the difference is greater than the preset convergence threshold (set as...), the coefficients are considered for further analysis. If the absolute value of the difference is less than or equal to the convergence threshold, or if the number of iterations reaches the preset maximum number of iterations (set to 10,000), then stop iterating. The corresponding coefficient at this time is the optimal coefficient. Substitute the optimal coefficient into the general equation of the quadratic surface to obtain the final continuous smooth surface, which is the reference hypersurface.

[0047] This embodiment uses normal approval events that have passed final review as the sample basis to ensure that the generated normal event vector set can truly reflect the risk characteristics of the compliant approval process. It constructs a three-dimensional vector space and maps coordinate points to transform abstract multi-dimensional risk indicators into intuitive spatial positional relationships, clearly presenting the risk characteristic distribution pattern of normal events and providing clear data support for fitting the benchmark hypersurface. The benchmark hypersurface is fitted using the least squares method, and rigorous mathematical calculations ensure that the surface can fit the distribution of normal event coordinate points to the greatest extent, so that the benchmark hypersurface can define the risk boundary of normal approval events and improve the accuracy and reliability of risk identification in cross-departmental collaborative approval.

[0048] In a preferred embodiment of the present invention, calculating the shortest projection distance from the multidimensional vector corresponding to the current approval event to the reference hypersurface, and using the shortest projection distance as a comprehensive risk metric, includes:

[0049] Step 300: Obtain the multi-dimensional vector corresponding to the current approval event, and map the multi-dimensional vector corresponding to the current approval event into a three-dimensional vector space to obtain the coordinate point of the current event. Specifically, the system first obtains the three-dimensional multi-dimensional vector corresponding to the current approval event. This vector is a standardized result generated by the complete process from steps 100 to 102. That is, after feature extraction, preset risk model quantification, and Min-Max standardization, it is a vector formed by combining data authenticity indicators, process timeliness indicators, and behavioral compliance indicators in a fixed order. The values ​​of the three indicators are all within the range of 0 to 100, and the dimensions are uniform and the format is standard. Subsequently, the system follows the steps... The 201-constructed three-dimensional vector space and mapping rules map the three-dimensional multi-dimensional vector of the current approval event to this space, generating the coordinate point of the current event. The specific mapping logic is as follows: the x-axis of the three-dimensional vector space corresponds to the data authenticity index, the y-axis corresponds to the process timeliness index, and the z-axis corresponds to the behavior compliance index. The standardized value of the data authenticity index in the current vector is directly used as the x-axis coordinate value, the standardized value of the process timeliness index is used as the y-axis coordinate value, and the standardized value of the behavior compliance index is used as the z-axis coordinate value. The three together constitute the unique coordinate point of the current event in the three-dimensional vector space, accurately locating the risk characteristics of the current approval event in the space.

[0050] Step 301: Calculate the geometric distance from the current event coordinate point to the reference hypersurface. Select the smallest value from all calculated geometric distances as the shortest projected distance, and use this shortest projected distance as the comprehensive risk metric. Specifically, this includes: First, calculating the geometric distance from the current event coordinate point to the reference hypersurface, which is the quadratic surface fitted in step 202. When calculating the geometric distance, first obtain the three-dimensional coordinates of the current event coordinate point, denoted as x0 (data authenticity index value), y0 (process timeliness index value), and z0 (behavioral compliance index value). Then, calculate the numerator of the distance by substituting x0, y0, and z0 into the left side of the reference hypersurface equation and taking the absolute value of the result as the numerator. Finally, calculate the denominator of the distance, i.e., the distance calculated using the reference hypersurface method at the current coordinate point. The first step is to determine the magnitude of the vector. Finally, divide the numerator by the denominator to obtain the geometric distance from the current event coordinate point to the reference hypersurface. The second step is to determine the shortest projected distance and use it as the comprehensive risk metric. Since the geometric distance from the current event coordinate point to the reference hypersurface is essentially the projection distance of that point onto the surface's normal vector direction, and the normal vector direction is the shortest path direction from the point to the surface, the calculated geometric distance is the shortest projected distance from the current event coordinate point to the reference hypersurface. The system directly uses this shortest projected distance value as the comprehensive risk metric for the current approval event. The larger the value, the further the risk characteristics of the current approval event deviate from the risk characteristic distribution boundary of normal approval events, and the higher the risk level. The smaller the value, the closer the current approval event is to the characteristic patterns of normal approval events, and the lower the risk level.

[0051] In this embodiment, the coordinate point mapping process strictly follows the established three-dimensional vector space rules to ensure that the risk characteristics of the current approval event and the characteristics of normal event samples are on the same evaluation dimension, providing a fair and unified reference basis for risk comparison. The geometric distance calculation is based on precise quadratic surface equations and mathematical formulas, transforming abstract multi-dimensional risk characteristics into intuitive quantitative values, realizing an objective measurement of the risk level of the current approval event, and avoiding the subjectivity and ambiguity of manual assessment. Using the shortest projection distance as the comprehensive risk metric, it can accurately reflect the degree of deviation between the risk boundary of the current event and the normal event, helping to improve the accuracy of risk identification and supervision efficiency in cross-departmental collaborative approval.

[0052] In a preferred embodiment of the present invention, task planning is performed through a supervision strategy engine to generate a sequence of supervision tasks sorted by comprehensive risk metric values ​​and assigned to predefined gridded supervision nodes, including:

[0053] Step 400: Compare the comprehensive risk metric with the preset first-level risk threshold. Mark approval process events with a comprehensive risk metric greater than or equal to the first-level risk threshold as high-risk events requiring supervision. For each approved process event marked as a high-risk event requiring supervision, generate a supervision task record containing a unique identifier for the corresponding event and a comprehensive risk metric. Specifically, the system first clarifies the setting logic, calculation process, and specific value of the first-level risk threshold. This threshold must take into account both historical risk patterns and the current capacity of supervision resources. Specifically, the system first statistically analyzes the approval events from the past three years... Verify the comprehensive risk metric values ​​of high-risk events with issues such as violations and omissions, and extract the median of these values ​​as the basic threshold, assumed to be 0.35. Then, calculate the ratio of the actual carrying capacity of supervisory resources to the theoretical carrying capacity of supervisory resources (actual carrying capacity = current number of available supervisory personnel × average daily task volume per person; theoretical carrying capacity = historical average number of supervisory personnel × average daily standard task volume per person) to obtain the resource matching coefficient. Assume the current number of available supervisory personnel is 50, with an average daily task volume of 8 per person, and the historical average number of supervisory personnel is 45, with an average daily task volume of 8 per person. The average daily standard processing volume is 8 tasks, so the resource adaptation coefficient = (50 × 8) ÷ (45 × 8) ≈ 1.11; the final first-level risk threshold = basic threshold × resource adaptation coefficient, so the first-level risk threshold is 0.39. This value not only conforms to the historical risk distribution characteristics, but also adapts to the current supervision capability, avoiding task overload or insufficient supervision; subsequently, the system calls the comprehensive risk measurement value of the current approval event and compares it with the calculated first-level risk threshold (0.39). If the comprehensive risk measurement value of the current approval event is greater than or equal to 0.39, then the event is judged to have a high risk of violation or non-compliance. These events are marked as high-risk events requiring supervision. Finally, a unique supervision task record is generated for each marked high-risk event. The unique identifier for each event is generated using a combined coding rule: a unique project number (assigned by the industry regulatory authority), an approval process code, an event timestamp (accurate to milliseconds), and a random three-digit check digit. This combination ensures that each high-risk event has a unique and non-repeating identifier. The record also includes the complete value of the comprehensive risk measurement, as well as auxiliary information such as the project name and approval process name associated with the event, forming a complete and well-informed supervision task record.

[0054] Step 401: Sort all generated supervision task records in descending order based on their comprehensive risk metric values ​​to form a supervision task sequence. Specifically, the system first collects all generated supervision task records, constructs a temporary task dataset to ensure no records are missing or duplicated, and then initiates a descending sorting process. The dataset is sorted using a quicksort algorithm. The core logic is to use the comprehensive risk metric value in the supervision task records as the primary sorting criterion, arranging all records in descending order of comprehensive risk metric value. If two or more records have completely equal comprehensive risk metric values, then the timestamp of the event is used as the sorting criterion. The magnitude of the timestamp value serves as a secondary sorting criterion (the larger the timestamp value, the later the event occurred, and the higher it ranks). The specific sorting process is as follows: First, select the comprehensive risk metric value of one record from the temporary task dataset as the benchmark value, and divide all records into a high-value group (greater than the benchmark value) and a low-value group (less than or equal to the benchmark value). Then, repeat the above grouping operation for the high-value group and the low-value group respectively, until each group contains only one record. Finally, concatenate all groups in the order of high-value group first and low-value group last to form the final supervision task sequence, ensuring that tasks with higher risk levels are placed earlier in the sequence and are processed first.

[0055] Step 402: Based on the information of the responsible department and the project location recorded in the high-risk events to be monitored, query the preset grid responsibility mapping relationship, determine the corresponding grid-based supervision nodes, and assign the task records in the supervision task sequence to the determined grid-based supervision nodes in sequence. Specifically, the system first retrieves the preset grid responsibility mapping relationship table. This table is a standardized data table constructed based on the administrative division level and the functional classification of government departments. The table contains four core fields: the responsible department code (using a five-digit code, the first two digits are the department category code, and the last three digits are the specific department sub-code, for example, the housing and construction department category code is 01, and the construction permit approval department code is 01003), the project location administrative... The system includes: administrative division code (strictly following the six-digit national standard coding rules), grid-based supervision node number (using a combination of administrative division code and supervision grid number, e.g., the third supervision grid in a certain county is numbered 130523-003), and node details (including the name, contact information, affiliated unit, and scope of supervision authority of the supervisors). Each grid-based supervision node is bound to 3 to 5 fixed supervisors (covering professional positions such as business review, on-site inspection, and data verification). The jurisdiction is clearly defined as specific industrial project types within the corresponding administrative division, such as industrial projects, livelihood projects, and infrastructure projects, and work permissions are limited (including querying on-chain evidence records, accessing approval process data, initiating on-site inspection instructions, and providing feedback on supervision). Results, etc.), ensuring that supervisory responsibilities are accurately assigned to individuals and that rights and responsibilities are clearly defined; then, the system extracts the responsible department code from the responsible entity information field of the structured approval process event corresponding to the high-risk supervised event. This code is consistent with the coding rules of the responsible department code in the grid responsibility mapping table and can be directly associated with the corresponding functional department; the system extracts the project's local administrative division code from the project's basic information field. This code is automatically generated by matching the registered address filled in during project application, ensuring complete consistency with the national standard administrative division code. Subsequently, the system concatenates the two codes according to a fixed format of responsible department code - project local administrative division code to form a unique query key (e.g., 01003-130523), ensuring accurate and unambiguous queries; then The system initiates a query process for the grid responsibility mapping table. First, it performs a primary filter using the responsible department code to extract all administrative division-related records corresponding to that department. Then, it performs a secondary precise match using the administrative division code of the project's location to pinpoint the unique corresponding grid-based supervision node number from the filtered results. This allows the system to obtain complete information such as the supervisory personnel and jurisdiction bound to the node, clarifying the specific supervisory responsibility entity. Finally, the system initiates a task allocation process according to the sequence of supervision tasks. During allocation, the system sends a task allocation instruction to the terminal system of the target grid-based supervision node through an internal RESTful communication interface. The instruction contains core information such as the supervision task record ID, node number, and task priority.Simultaneously, the complete monitoring task record (including unique event identifier, comprehensive risk metric, project name, approval process, risk characteristic description, etc.) is written into the distributed message queue of the node (using the FIFO first-in-first-out principle), and the task status in the system is updated to pending. If the same grid-based monitoring node needs to receive multiple task records, they are appended to the end of the queue in the order of the monitoring task sequence to avoid task confusion. After task allocation, the system monitors the node terminal's reception feedback in real time. If no confirmation is received within 5 minutes, the allocation instruction is automatically resent to ensure successful task delivery. The entire process achieves precise docking between monitoring tasks and monitoring nodes, ensuring the orderly conduct of monitoring work.

[0056] In this embodiment, the setting of the first-level risk threshold combines historical data with the actual situation of supervision resources to ensure the accuracy of high-risk event marking. This avoids missing truly high-risk events while also preventing low-risk events from being included in the supervision scope, thus reducing the waste of supervision resources. Supervision tasks are arranged in descending order of comprehensive risk measurement value, clarifying task processing priorities and ensuring that high-risk events are dealt with first, effectively reducing the probability of risk spread and improving the pertinence of supervision work and the efficiency of emergency risk response. Based on the grid responsibility mapping relationship between responsible departments and project locations, tasks are accurately allocated, clarifying the supervisory responsibility entities, avoiding supervision blind spots and shirking of responsibility, ensuring that supervision tasks are implemented, and improving the execution and management efficiency of cross-departmental collaborative supervision.

[0057] like Figure 2 As shown, in another preferred embodiment of the present invention, an on-chain audit trail is constructed, and based on the data in the on-chain audit trail, a dynamically updated credit evaluation result is generated through a preset credit evaluation model, including:

[0058] Step 500: In chronological order, aggregate on-chain evidence records, approval process events, three-dimensional multi-dimensional vectors, comprehensive risk metrics, and the handling conclusions fed back by grid-based monitoring nodes to form a structured on-chain audit trail. Specifically, the system first starts the full-process data aggregation engine, clarifies the scope of aggregated data to cover five types of core data generated throughout the entire lifecycle of the approval process, and defines the specific field specifications for each type of data to ensure that the aggregated information is complete and traceable. The on-chain evidence records must fully include the hash value of the original data file, the digital signature of the submitter, the trusted timestamp of the consortium blockchain, the associated business metadata (including business type identifier, project stage identifier, and project unique number), and the data submission node information. Approval process events must include the name of the approval stage, the code of the responsible department, the approval status indicator (pending review / under review / approved / rejected / finally approved), the event timestamp, the employee number of the person handling the event, and a summary of the operation log; the three-dimensional multi-dimensional vector must clearly mark the unique identifier of the corresponding approval event, as well as the standardized values ​​(0 to 100) of the data authenticity indicator, process timeliness indicator, and behavior compliance indicator; the comprehensive risk metric must include the calculation basis (coordinates of the current event coordinate point, parameters of the baseline hypersurface equation), the calculation timestamp, and the risk level determination result; the handling conclusion of the grid-based supervision node must include the handling node number, the name of the supervisor, the verification time, the hash value of the on-site verification photo, and the question. The system includes a list of issues, rectification requirements, rectification deadlines, review results, and final compliance judgment opinions. It employs a dual aggregation logic of timestamp association and unique event identifier binding, integrating data according to its chronological order. The specific workflow involves extracting core association fields from each data category: the unique project ID and data submission timestamp of the on-chain evidence record; the unique project ID and event occurrence timestamp of the approval process event; the unique identifier of the corresponding approval event in the three-dimensional multi-dimensional vector; the unique identifier of the corresponding approval event in the comprehensive risk metric; and the ID of the corresponding supervision task record for the handling conclusion. Using the unique project ID and event occurrence timestamp of the approval process event as the core association key, the chains corresponding to the same approval event are linked. The system binds the evidence records (matched by the project's unique number, with timestamp errors controlled within 10 seconds), three-dimensional multi-dimensional vectors (accurately matched by the unique identifier of the approval event), and comprehensive risk measurement values ​​(matched by the unique identifier of the approval event). It also links the corresponding handling conclusions to the supervision task record IDs to ensure that the handling conclusions accurately correspond to specific high-risk approval events. The bound data is integrated into a structured record, with each record containing fixed fields: the main timestamp (the earliest timestamp of the data generated for the approval event), data type code (evidence record / approval event / vector data / risk value / handling conclusion), core data content, a list of associated data IDs, and data generation node / subject information.All structured records of approval events are arranged in ascending order by the master timestamp, forming a complete on-chain audit trail. The trail is stored in blocks, with each block containing a fixed number of structured records (100 by default). The block header includes the block number, the block generation timestamp, and the hash value of the previous block, ensuring the trail cannot be tampered with. Each structured record is assigned a unique identifier in the format of project unique number-approval stage code-timestamp (accurate to milliseconds). This identifier allows for quick tracing of all related data for the same approval event at different stages, enabling cross-validation of various data types and full-process traceability.

[0059] Step 501: Using the project participant's identity identifier as the key, extract all on-chain evidence records, all approval process events, all multi-dimensional vectors, all comprehensive risk metrics, and all supervisory task handling feedback associated with the project participant's identity identifier from the on-chain audit trajectory. This constitutes the participant's historical behavior dataset. Specifically, the system first clarifies the unified coding rules for the project participant's identity identifier. This identifier is a unique and tamper-proof code generated after the participant completes real-name authentication during registration on the consortium blockchain. The coding format is participant type code (2 digits) + administrative division code (6 digits) + unique entity number (8 digits), where the participant type code clearly defines the entity attribute (01=applicant...). (02 = reporting enterprise, 03 = approval department, 04 = construction unit, 05 = supervision unit, 06 = third-party auditing institution, etc.); the administrative division code follows the national standard six-digit coding rule; the unique entity number is assigned by the industry competent authority according to the filing order to ensure that each participant's identity is unique and its attributes can be accurately identified; using this identity identifier as the core query key, the system initiates a full traversal and precise filtering process of the on-chain audit trajectory. The filtering logic is classified and matched according to the participant's role. If the participant is the reporting enterprise (type code 01), then all on-chain evidence records containing this identity identifier as the data submitter code, all approval process events as the reporting entity code, and the corresponding approval events are filtered. The system includes three-dimensional multidimensional vectors, comprehensive risk metrics, and conclusions regarding the handling of supervisory tasks involving the entity (including feedback information where the enterprise is the responsible party for rectification). If the participant is an approval department (type code 02), the system filters all approval process events containing that identifier as the responsible department code, operation log related data as the approval entity code, vector data and risk values ​​of the corresponding approval events, and the handling conclusions of the department as the responsible supervisory entity. For other types of participants, the system filters the corresponding related data according to their role in the approval process. After filtering, the system classifies, organizes, and cleans the data, dividing it into subsets of evidence records and subsets of approval events. The dataset is divided into three subsets: a set of data, a vector data subset, a risk value subset, and a disposal conclusion subset. Within each subset, the data is sorted in ascending order by the timestamp of its generation to facilitate the tracing of the behavior sequence. Data cleaning operations are performed to remove duplicate data (using data hash values ​​for deduplication), eliminate invalid data (such as records with a field missing rate exceeding 30% or records with abnormal timestamps), and complete related fields (for records with missing association identifiers, they are completed by reverse matching using the project's unique number and timestamp). Finally, a historical behavior dataset of the participating party is constructed. The dataset is accompanied by a data description document, which includes the data time range, data category statistics, explanations of missing data, and explanations of filtering rules to ensure the completeness and standardization of the dataset.

[0060] Step 502: Input the historical behavior dataset into the preset credit assessment model to calculate the average data authenticity index, process timeliness index compliance rate, number of violations of the behavior compliance index, and the frequency of exceeding the threshold of the comprehensive risk measurement value for the participants within the preset period, including:

[0061] This process involves: 1) Collecting all approval process events generated by the participating party within a preset period; 2) Extracting the data authenticity index for each approval process event; 3) Calculating the arithmetic mean of all data authenticity indices; 4) Collecting all approval process events generated by the participating party within the preset period; 5) Extracting the process timeliness index for each approval process event; 6) Comparing each process timeliness index with a preset timeliness compliance threshold; 7) Counting the number of process timeliness indices that meet or exceed the timeliness compliance threshold; 8) Dividing the number of compliant indices by the total number of process timeliness indices to obtain the process timeliness compliance rate; and 9) Collecting all approval process events generated by the participating party within the preset period. The process involves identifying approval process events and extracting the corresponding behavioral compliance indicators for each event. Each indicator is compared to a preset compliance threshold, and the number of indicators falling below this threshold is counted as the number of violations. The process also includes counting all approval process events generated by the participating party within a preset period and extracting the comprehensive risk metric for each event. Each comprehensive risk metric is compared to a first-level risk threshold, and the number of values ​​exceeding this threshold is counted. This number is then divided by the total number of approval process events to obtain the comprehensive risk metric threshold exceedance frequency, which includes:

[0062] The credit assessment model constructed by the system is a multi-input, single-output weighted scoring model. Its core is to automatically determine the weights of each assessment indicator, the calculation logic, and the derivation rules of the final credit score through a data-driven approach. The specific construction and training process is as follows: First, the system collects historical behavior datasets of all project participants from the past three years as the foundational data for model construction. Then, preprocessing is performed on the dataset. Besides removing invalid records with a missing rate exceeding 30%, outliers are removed using the Z-score method. This method calculates a single data value by subtracting the mean of the indicator from its value and then dividing by the standard deviation. When the absolute value of the result is greater than 3, the data is considered an outlier and removed. After preprocessing, using the historical violation rate and rectification completion rate as core objective features, the distribution of these two features for all participants is first statistically analyzed. Then, the K-means clustering algorithm is used to divide the data into clusters, i.e., the elbow rule is used to determine the clusters first. The cluster number is 4. The calculation method is to statistically analyze the total squared error under different cluster numbers. The total squared error is the sum of the squares of the differences between the feature values ​​of each sample and the feature values ​​of the corresponding cluster centers. The cluster number corresponding to the point where the rate of decrease of the total squared error decreases sharply is selected as the final cluster number. Then, 4 sample feature vectors are randomly selected as the initial cluster centers. The Euclidean distance from each sample to each cluster center is calculated by taking the square root of the sum of the squares of the differences between the sample and each feature value of the cluster center. The sample is assigned to the nearest cluster. Subsequently, the cluster centers are iteratively updated, and the mean of the feature values ​​of all samples in each cluster is taken as the new cluster center. The iteration stops when the change in the cluster center is less than 0.001 or the number of iterations reaches 1000. After the clustering is completed, based on the objective risk level of each cluster, such as the high or low rate of violation and the good or bad rate of rectification completion, it is automatically mapped to four credit rating labels: excellent, good, qualified, and unqualified. The entire label mapping process is completely driven by the data distribution law.

[0063] Next, the system automatically selects input indicators for the model using the information gain criterion. The core logic is to select core indicators by calculating the discriminative power of each potential indicator on credit rating labels. First, the initial entropy of the overall credit rating labels is calculated. This initial entropy reflects the uncertainty of the labels. The calculation method is to take the logarithm of the sample proportion of each type of credit rating label, multiply it by the sample proportion, and then sum all the results and take the negative number. Here, the sample proportion is the number of samples for that type of label divided by the total number of samples. Next, the conditional entropy of each potential indicator on the label is calculated. First, the sample proportion of each indicator for different values ​​is calculated, then the entropy of the credit rating label for each value of the indicator is calculated, using the same logic as the initial entropy. Then, the sample proportion of each value is multiplied by the label entropy for the corresponding value, and finally, all the products are summed to obtain the conditional entropy of the indicator. The information gain value is obtained by the difference between the initial entropy and the conditional entropy. A higher information gain value indicates a stronger discriminative power of the indicator. Finally, the top four indicators with the highest information gain values ​​are selected as model inputs: the mean of the data authenticity indicator, the compliance rate of the process timeliness indicator, the number of violations of the behavior compliance indicator, and the frequency of exceeding the threshold of the comprehensive risk measurement value. The model output is then set. The system uses a credit score range of 0 to 100. It employs a combined algorithm of Pearson correlation coefficient and stepwise regression to calculate indicator weights. Specifically, it quantifies four credit rating labels into standard scores: Excellent (90 points), Good (80 points), Satisfactory (60 points), and Unsatisfactory (40 points). The quantification rules are automatically derived from the mean of the core features of each cluster. The system then calculates the Pearson correlation coefficient between each input indicator and the quantified label score, initially screening indicators with an absolute correlation coefficient greater than 0.5 to ensure a strong correlation between the indicators and credit performance. Finally, it uses the credit score as the dependent variable and the selected indicators as the independent variable. A linear regression model is constructed using variables. The variance contribution of each indicator to the scoring results is analyzed iteratively using stepwise regression. The variance contribution is the difference in the total variance explained by the model before and after the introduction of the indicator. The final weights are automatically determined by dividing the variance contribution of each indicator by the total variance contribution of all indicators. Assuming that the final data authenticity indicator has a mean of 0.35, the process timeliness indicator has a compliance rate of 0.3, the behavior compliance indicator has a violation frequency of 0.2, and the comprehensive risk measure has an over-threshold frequency of 0.15, the sum of the weights of the four indicators is 1. The weight allocation perfectly matches the inherent correlation of the data.

[0064] Finally, the system automatically divides the preprocessed dataset labeled with credit rating tags into training and test sets in a 7:3 ratio using a random number generator to ensure consistent data distribution and avoid data bias affecting model performance. After inputting the training set into the model, the system uses the mean squared error between the predicted credit score and the quantified label value as the optimization objective and automatically adjusts the weight parameters using gradient descent. The mean squared error is calculated as the sum of the squares of the differences between the predicted score and the quantified label value in all samples divided by the total number of samples. Gradient descent updates the weights by subtracting the product of the learning rate and the partial derivative of the mean squared error with respect to the old weights from the old weights. The learning rate is automatically set to 0.001 based on the data standardization range. During model training, the system automatically calculates the accuracy of the test set every 50 iterations. The accuracy is calculated as the number of samples whose predicted credit rating matches the actual credit rating divided by the total number of samples in the test set. When the accuracy remains stable above 85% for three consecutive iterations, the system automatically stops training, locks the final weight parameters and calculation logic, and completes the construction of the credit assessment model. At this point, the model has the complete ability to automatically calculate credit scores by inputting four core indicators.

[0065] Once the model is built and trained, it can be used to calculate core indicators and derive credit scores. The calculation of core indicators requires the system to automatically determine a preset period and key thresholds through historical data statistics. Specifically, the preset period is set to 12 months, which covers the complete approval process for most projects while avoiding data lag due to excessively long periods. The system statistically analyzes standardized values ​​of process timeliness indicators for normal approval events over the past three years, sorts all values ​​in ascending order, and then calculates the 90th percentile. The quantile position is calculated by multiplying the total number of samples by 90%. If the position is not an integer, it is rounded up. The numerical value corresponding to this position is assumed to be 80, which means the timeliness compliance threshold is 80. Statistically, 90% of normal approval events have indicators that are not lower than this value, which is consistent with the natural distribution of process timeliness. The system statistically analyzes the behavioral compliance indicator values ​​of compliant approval events in the past three years, sorts them in ascending order, and takes the 10th percentile. The calculation logic is the same as the 90th percentile. The numerical value corresponding to this position is assumed to be 70, which means the compliance baseline threshold is 70. Data shows that the violation rate of events below this value exceeds 80%, which can accurately define the compliance boundary. The first-level risk threshold uses the value determined in step 400.

[0066] When calculating the average data authenticity index, the system first automatically counts the total number of approval process events for the participant within 12 months, then extracts the standardized data authenticity index value corresponding to each event, sums all index values, and divides the sum by the total number of events to obtain the average data authenticity index. The calculation formula is: Average data authenticity index = Sum of all data authenticity index values ​​÷ Total number of approval process events. This index reflects the overall authenticity of the data submitted by the participant; the higher the value, the better the authenticity. When calculating the process timeliness index compliance rate, the system automatically extracts the process timeliness index values ​​for all approval process events for the participant within 12 months, compares each value with the timeliness compliance threshold of 80, and counts the number of compliant values ​​(i.e., the number of index values ​​greater than or equal to 80). The number of compliant values ​​is divided by the total number of approval process events, and then multiplied by 100% to obtain the process timeliness index compliance rate. The calculation formula is: Process timeliness index compliance rate = Number of compliant values ​​÷ Total number of approval process events × 100%. A higher percentage indicates better efficiency in the participant's approval process. When calculating the number of violations for the behavioral compliance indicator, the system automatically extracts the behavioral compliance indicator values ​​for all approval process events within the participant's 12-month period, compares each value with the compliance baseline threshold of 70, and counts the number of indicators below 70. This number represents the number of violations for the behavioral compliance indicator. This indicator is negative; a higher value indicates a lower creditworthiness of the participant. When calculating the frequency of exceeding the threshold for the comprehensive risk metric, the system automatically extracts the comprehensive risk metric values ​​for all approval process events within the participant's 12-month period, compares each value with the first-level risk threshold, and counts the number of values ​​exceeding the threshold. The number of values ​​exceeding the threshold is divided by the total number of approval process events, and then multiplied by 100% to obtain the frequency of exceeding the threshold for the comprehensive risk metric. The formula is: Frequency of exceeding the threshold for comprehensive risk metric = Number of values ​​exceeding the threshold ÷ Total number of approval process events × 100%. This indicator is negative; a higher percentage indicates a higher overall risk for the participant's approval events.

[0067] After the core indicators are calculated, the system automatically inputs the results of the four indicators into the trained credit assessment model and derives the final credit score according to the preset algorithm logic. The specific operation is as follows: First, the system performs positive conversion on the negative indicators. To ensure that all input indicators are consistent in direction, and that higher values ​​indicate better credit, the system automatically performs positive conversion on two negative indicators. The positive conversion value of the behavioral compliance indicator = (maximum number of violations by similar participants in the industry - number of violations by this participant) ÷ maximum number of violations by similar participants in the industry × 100. The maximum number of violations by similar participants in the industry is obtained by the system automatically calculating the number of violations by similar participants in the industry over the past three years. After conversion, the value ranges from 0 to 100, and higher values ​​indicate better compliance. The positive conversion value of the comprehensive risk measurement value exceeding the threshold frequency = 100 - comprehensive risk measurement value exceeding the threshold frequency. After conversion, the value ranges from 0 to 100, and higher values ​​indicate lower overall risk of the participant's approval events. The system then performs a weighted summation calculation on all indicators. The initial scoring automatically multiplies the two positively evaluated indicators by two other positively evaluated indicators: the average of the data authenticity indicator and the compliance rate of the process timeliness indicator, each multiplied by the final weights locked during model training. The sum of all products yields the initial credit score, calculated as: Initial Credit Score = Average of Data Authenticity Indicators × 0.35 + Compliance Rate of Process Timeliness Indicators × 0.3 + Positively Evaluated Value of Behavioral Compliance Indicators × 0.2 + Positively Evaluated Value of Comprehensive Risk Measurement Value Exceeding Threshold Frequency × 0.15. Finally, the system normalizes the initial score to ensure the final credit score remains strictly within the standard range of 0 to 100. The formula is: Final Credit Score = (Initial Credit Score - Minimum Initial Score of All Samples) ÷ (Maximum Initial Score of All Samples - Minimum Initial Score of All Samples) × 100. This normalization maps the initial scores of different participants to a standardized range, ensuring comparability and standardization of the scores.

[0068] Step 503: The system calculates a credit score for the participant by weighting the average data authenticity indicator, the compliance rate of the process timeliness indicator, the number of violations of the behavioral compliance indicator, and the frequency of exceeding the threshold of the comprehensive risk measurement value, based on preset weights. This credit score serves as a dynamically updated credit evaluation result. Specifically, the system calculates the credit score for the participant by weighting the four core indicators obtained in Step 502 according to preset weights. The specific calculation process involves positively converting the number of violations of the behavioral compliance indicator (because a higher number of violations indicates better credit, it needs to be converted into a positive indicator). The formula is: Positively converted number of violations = (Maximum number of violations by similar participants in the participant's industry - Number of violations by this participant) ÷ Maximum number of violations by similar participants in the industry × 100, ensuring that the value range of this indicator is consistent with other indicators. The system performs a positive conversion process on the frequency of exceeding the threshold for comprehensive risk metrics (0 to 100). The higher the frequency, the worse the credit score. The formula is: Positive Over-Threshold Frequency = 100 - Over-Threshold Frequency, converting it into a positive indicator (0 to 100). A weighted credit score is calculated using the formula: Credit Score = Average Data Authenticity Indicator × 0.35 + Compliance Rate of Process Timeliness Indicator × 0.3 + Positive Violation Count × 0.2 + Positive Over-Threshold Frequency × 0.15. The calculated credit score is then normalized to ensure the final score falls within the range of 0 to 100. This score is the dynamically updated credit evaluation result. After participating parties generate new approval events and update the historical behavior dataset, the system will recalculate the credit score, achieving dynamic updates and continuously providing accurate and real-time credit data for various business decisions.

[0069] In this embodiment, the on-chain audit trajectory integrates data from the entire process, ensuring that the behavior of participants is traceable and the data is verifiable. This provides an objective and complete data source for credit assessment, preventing assessment results from deviating from reality. The credit assessment model is built based on historical data training, with scientific and reasonable weight allocation and rigorous calculation logic for core indicators. It can comprehensively and objectively reflect the compliance level and credit status of participants, improving the credibility of credit evaluation. The credit score is dynamically updated, which can respond to changes in the behavior of participants in real time. This provides more convenient approval services for participants with good compliance performance, while strengthening supervision of participants with poor credit, thereby improving the overall compliance and efficiency of cross-departmental collaborative approval.

[0070] In a preferred embodiment of the present invention, the dynamic credit evaluation result is converted into approval rule adjustment parameters and risk monitoring threshold adjustment parameters, and the adjustment parameters are fed back to the smart contract's preset rule base and supervision strategy engine to dynamically optimize approval conditions and risk monitoring strategies, forming a closed-loop approval supervision and control mechanism, including:

[0071] Step 600: Using the credit score as input, a standard credit coefficient is obtained through linear normalization. This standard credit coefficient is then input into the first linear transformation function to obtain the approval acceleration coefficient. Specifically, the credit score is calculated and normalized by weighting four core indicators: the average of data authenticity indicators, the compliance rate of process timeliness indicators, the number of violations in the behavior compliance indicator after positive processing, and the frequency of exceeding the threshold in the comprehensive risk measurement value after positive processing. The value ranges from 0 to 100, with higher values ​​indicating better creditworthiness of the participant. The system first collects the credit scores of all current project participants, determines the global maximum and minimum values ​​of all participant credit scores, and then calculates the standard credit score for each participant through linear normalization. The coefficient is calculated by subtracting the global minimum of all participants' credit scores from the participant's credit score, and then dividing the difference by the difference between the global maximum and minimum of all participants' credit scores. This calculation maps the credit score to a range of 0 to 1, and the result is the standard credit coefficient. The closer the standard credit coefficient is to 1, the higher the participant's credit level; the closer it is to 0, the lower the participant's credit level. The system inputs the calculated standard credit coefficient into a preset first linear transformation function to calculate the approval acceleration coefficient. The formula for the first linear transformation function is: Approval Acceleration Coefficient = Preset Slope 1 × Standard Credit Coefficient + Preset Intercept 1, where the preset slope 1 is 2 and the preset intercept 1 is 0. The following logic was derived through iterative fitting of historical approval efficiency data: First, the system statistically analyzes the full approval efficiency data of participants with different credit levels over the past three years. Using the participant's credit score as the independent variable and the approval efficiency improvement rate as the dependent variable, a linear regression model is constructed. The core objective of model optimization is to minimize the mean squared error between the predicted and actual improvement rates. Through iterative fitting, it was found that the participant with the highest credit score (100 points) consistently achieves a 100% improvement in approval efficiency (i.e., the actual efficiency reaches twice the baseline efficiency); the participant with the lowest credit score (0 points) shows no improvement in approval efficiency (maintaining only one time the baseline efficiency). Considering that the standard credit coefficient is mapped to the 0-1 range, an acceleration coefficient needs to be matched synchronously. The derivation logic takes into account that the core definition of the acceleration coefficient is the proportion of approval efficiency adjustment, with a baseline value of 1 representing the maintenance of the original efficiency. Therefore, after optimizing the initial derivation logic, further calculations are performed. When the standard credit coefficient = 1 (corresponding to a credit score of 100), the approval acceleration coefficient needs to be 2; when the standard credit coefficient = 0 (corresponding to a credit score of 0), the approval acceleration coefficient needs to be 1. Substituting the two sets of correspondences into the linear equation for solution, the preset slope is determined to be 1 and the preset intercept is determined to be 1. The range of the approval acceleration coefficient calculated in this way is 1 to 2, which not only strictly conforms to the efficiency improvement law of participants with different credit levels, but also ensures that the coefficient is positively correlated with the standard credit coefficient. This coefficient will be directly used for the timeliness adjustment of the subsequent approval process.

[0072] Step 601: Input the standard credit coefficient into the second linear transformation function to obtain the review intensity coefficient. The approval acceleration coefficient and the review intensity coefficient together constitute the approval rule adjustment parameter. Input the standard credit coefficient and the preset benchmark risk threshold into the multiplication function to obtain the new first-level risk threshold. The standard credit coefficient is the risk monitoring threshold adjustment parameter. Specifically, the system inputs the standard credit coefficient obtained in step 600 into the preset second linear transformation function to calculate the review intensity coefficient. The calculation formula of the second linear transformation function is: Review Intensity Coefficient = Preset Slope 2 × (1 - Standard Credit Coefficient) + Preset Intercept 2. The values ​​of the preset slope 2 and the preset intercept 2 are derived based on historical review data and core risk control requirements. That is, the system first statistically analyzes the approval violation rate data of participants with different credit levels in the past three years, and clarifies the correspondence between credit scores and approval violation rates through structured data correlation analysis. The specific analysis process is as follows: Align the credit score data and approval violation records of all participants in the past three years, and sort them into credit score ranges (0 points, 1 to 2...). Credit scores (0, 21-40, 41-60, 61-80, 81-100) were divided into six uniform groups to ensure that the sample size of each group met the statistical validity requirements (no less than 50 samples per group). The approval violation rate for each group was calculated by dividing the number of approval violations within each group by the total number of approval events in that group. Abnormal samples with fewer than three approvals within each group were removed to avoid distortion of the violation rate due to a small number of approvals. The correlation between credit score grouping and violation rate was verified using a chi-square test. A contingency table was constructed using grouping as the independent variable and violation status as the dependent variable. The chi-square statistic was calculated and compared to the critical value (significance level set at 0.05). The results showed that the chi-square statistic was greater than the critical value, indicating a significant correlation between credit score and approval violation rate, and not a random occurrence. This association analysis revealed that the violation rate of participants in the group with a credit score of 100 was less than 1%, requiring no full review; while the violation rate of participants in the group with a credit score of 0 exceeded 30%, necessitating a full review to mitigate risk. To quantify review intensity, the system defined a benchmark: a review intensity coefficient of 1 represents full review (covering all review items), and a coefficient of 0 represents streamlined review (retaining only core and necessary review items). Based on this benchmark, the correspondence between credit level and review intensity is substituted into the linear equation for derivation. When the standard credit coefficient = 1 (high credit), the review intensity coefficient must be 0; when the standard credit coefficient = 0 (low credit), the review intensity coefficient must be 1. By solving the equation, the preset slope 2 is determined to be 1 and the preset intercept 2 is determined to be 0. The range of the review intensity coefficient calculated is 0 to 1, which is negatively correlated with the standard credit coefficient. The smaller the value, the greater the simplification of the approval review items. The approval acceleration coefficient and the review intensity coefficient together constitute the approval rule adjustment parameters.

[0073] The system retrieves a preset baseline risk threshold, which is derived through statistical analysis of historical high-risk event data. The specific process is as follows: First, the system comprehensively collects high-risk events identified in all approval processes over the past three years and extracts the comprehensive risk metric for each event. Then, all metrics are sorted in ascending order, and the core threshold is determined using a median calculation rule (if the number of high-risk event samples is odd, the value in the middle position after sorting is taken; if it is even, the average of the two middle values ​​is taken). Finally, the baseline risk threshold is assumed to be 50, which accurately matches the basic needs of risk monitoring. Subsequently, the system inputs the standard credit coefficient and the preset baseline risk threshold into a multiplication function to calculate a new first-level risk threshold. Specifically, the new first-level risk threshold = standard credit coefficient × preset baseline risk threshold. The resulting new first-level risk threshold ranges from 0 to 50, where the standard credit coefficient is the risk monitoring threshold adjustment parameter. Through this dynamic calculation logic, the risk threshold is more lenient for participants with higher credit levels and more stringent for participants with lower credit levels, accurately matching the risk monitoring needs of participants with different credit levels.

[0074] Step 602: Write the approval rule adjustment parameters into the smart contract's preset rule base and send the new first-level risk threshold to the supervision strategy engine; the smart contract executes the subsequent approval process according to the approval rule adjustment parameters in the preset rule base; the supervision strategy engine executes the subsequent supervision task planning according to the new first-level risk threshold. Specifically, this includes: the smart contract's preset rule base is systematically constructed through a complete process of standardization, data verification, algorithm optimization, and solidification to ensure the objectivity, compliance, and practicality of the rules. The specific construction process involves: comprehensively reviewing industry-standard approval norms and regulatory requirements for approval supervision, and converting mandatory clauses, process node requirements, compliance bottom lines, etc., into standardized initial rule entries; collecting the best practice data of approval supervision over the past three years, which is clearly defined as a high-quality approval case dataset in the past three years with an approval timeliness improvement of more than 30% compared to the benchmark timeliness and a compliance rate of 100%, and extracting its... The key logic of efficient approval and compliance control includes streamlined review processes for high-credit participants (clearly defining the scope of simplification as two types of unnecessary steps, such as verification of non-core supporting materials and duplicate information verification, while retaining three types of core steps, such as verification of qualification authenticity and compliance review of core processes), and time-efficiency optimization nodes (focusing on four key nodes that account for more than 60% of the time consumption, such as material submission review and cross-departmental transfer, and extracting optimization strategies such as parallel review and pre-review within nodes). These concrete logics are transformed into standardized rule clauses to supplement the initial rule entries, enriching the practical dimensions and coverage scenarios of the rules. On this basis, the mapping relationship between approval rule adjustment parameters and approval effects (including approval efficiency, compliance rate, error rate, etc.) is analyzed through correlation algorithms to optimize the standardization of rule expression and eliminate redundant logic and conflicting clauses. Finally, the optimized rule set is solidified into smart contracts, relying on blockchain technology to ensure the objectivity, immutability, and traceability of the rule execution process.

[0075] The core of the rule base is the precise mapping between approval rule adjustment parameters and approval process adjustment logic. Specifically, this includes the correspondence between the approval acceleration coefficient and the reduction ratio of approval time, and the correspondence between the review intensity coefficient and the simplification ratio of review items in the approval process. The system writes the approval rule adjustment parameters obtained in step 601 into the smart contract's preset rule base. The smart contract reads the approval acceleration coefficient and review intensity coefficient from the base in real time and automatically executes subsequent approval processes according to the preset mapping relationship. Specifically, the approval acceleration coefficient directly corresponds to the adjustment ratio of approval time; the larger the coefficient, the higher the reduction ratio of processing time in the approval process, thus significantly improving the approval efficiency for high-credit participants. The coefficient corresponds to the adjustment ratio of the number of review items in the approval process. The smaller the coefficient, the higher the reduction ratio of the number of review items in the approval process, effectively reducing redundant approval steps for high-credit participants and achieving intelligent and precise control of the approval process. Synchronized with the smart contract rule update, the system sends the new first-level risk threshold obtained in step 601 to the supervision strategy engine. After receiving the new threshold, the supervision strategy engine immediately updates its internal risk monitoring rules, redefines the risk triggering conditions, and executes subsequent supervision task planning based on the updated rules. Specifically, the new first-level risk threshold directly serves as the core triggering condition for the supervision task; the more lenient the threshold, the lower the frequency of triggering the supervision task; the more stringent the threshold, the lower the frequency of triggering the supervision task. The higher the frequency of triggering monitoring tasks, the more dynamically the coverage of these tasks is optimized according to threshold grading and range matching logic. The division of the three threshold intervals is derived from historical risk event data statistics. Specifically, the division rule is as follows: combining the new first-level risk threshold range of 0 to 50, the system statistically analyzes the risk threshold distribution corresponding to all high-risk events in the past three years, calculating the 33rd percentile (approximately 17) and 67th percentile (approximately 33). These are used as boundaries to divide the three intervals: a lenient interval of 33 to 50, a medium interval of 17 to 33, and a strict interval of 0 to 17. These three intervals correspond to three distinct monitoring coverage areas. The lenient interval matches key node sampling monitoring, where key... The nodes are clearly defined as core nodes in the approval process with a risk occurrence rate exceeding 40% (including three nodes: final review of material authenticity, cross-departmental approval, and final result review). Sampling supervision specifically involves randomly selecting 20% ​​of the approval records from the above nodes for verification. Medium-range matching provides full coverage supervision of important links, which are defined as core process segments in the entire approval process excluding basic material entry (including four links: initial material review, qualification verification, risk assessment, and result announcement), achieving full coverage verification of all approval behaviors within this scope. Strict range matching provides refined supervision of the entire process, covering the entire approval process from material submission and review at each stage to final issuance, including detailed verification of all nodes and stages.Supervisory resources are precisely allocated through a priority scheduling algorithm, ensuring that over 70% of these resources are directed towards participants with strict risk thresholds and low credit ratings. This achieves rational allocation and efficient utilization of supervisory resources, improving the overall accuracy of risk management.

[0076] Step 603: New event data generated by subsequent approval processes and supervision task planning triggers another cycle of credit evaluation results updates, forming a closed-loop approval supervision and control mechanism. Specifically, this includes: During the execution of approval processes and supervision tasks, multi-dimensional and concrete new event data will be continuously generated. This data can be divided into two categories: approval event data and supervision event data. Approval event data generated by the approval process includes actual time consumption and overdue records for each approval stage, approval result data such as approval / rejection results and specific reasons for rejection (e.g., missing materials, non-compliance), as well as completion time, responsible person, and materials for each node. The system collects data on process nodes such as material submission versions; it also collects data on supervisory events generated by the supervisory task planning, including risk monitoring data such as records of exceeding the comprehensive risk metric value and details of abnormal fluctuations in indicators discovered during risk monitoring; specific types of violations, such as falsification of materials, process violations, violation levels, investigation basis and rectification requirements; and supervisory result feedback data such as rectification completion deadlines, rectification acceptance results, and follow-up handling suggestions for non-compliant rectification. This new event data is collected through the system's preset real-time data collection interface. During the collection process, data verification (verifying data integrity and format specifications) and timestamp marking are performed simultaneously to ensure data accuracy. Based on verifiable data, the historical behavior dataset of project participants is subsequently incorporated through a real-time database synchronization mechanism. Once the dataset is updated, the system automatically triggers an update cycle for the credit evaluation results. The specific execution logic involves preprocessing the updated historical data, completing data cleaning (removing invalid and duplicate data) and standardization (unifying indicator dimensions); recalculating four core indicators, including the mean of data authenticity indicators and the compliance rate of process timeliness indicators; substituting these core indicators into the established credit assessment model, and deriving the latest credit score through weighted summation and normalization; and regenerating standard credit coefficients and approval acceleration coefficients based on the new credit score. The review intensity coefficient and the new first-level risk threshold, along with other adjustment parameters for the approval rules (approval acceleration coefficient, review intensity coefficient) and risk monitoring threshold, which are adapted to the latest data, will be simultaneously pushed to the smart contract and the supervision strategy engine. The smart contract updates the approval process rules based on the new parameters, adjusting the duration of each stage and the configuration of review items. The supervision strategy engine optimizes the frequency and coverage of supervision triggers based on the new risk threshold, realizing the dynamic optimization of the approval process and supervision tasks. During the execution of the optimized approval and supervision process, new event data will be generated. This data will be collected again, incorporated into the historical dataset, and trigger the next round of update cycle.Through a closed-loop logic—generating concrete data during the approval / supervision process, synchronously incorporating data verification into historical datasets, triggering full-process updates to credit evaluation, generating new control parameters to optimize the process, and then generating new data again after optimization—a closed-loop approval, supervision, and control mechanism is formed, deeply linking approval, supervision, and credit evaluation. This ensures the entire system can accurately adapt to changes in the credit status of participants and business process iterations, continuously maintaining a balance between approval efficiency and risk control, and improving the system's dynamic adaptability and continuous optimization capabilities.

[0077] This embodiment matches different approval efficiencies and review intensities based on the credit levels of participating parties. This not only improves the approval experience and efficiency for high-credit participants but also strengthens the rigor of approvals for low-credit participants, thereby improving overall approval efficiency while ensuring approval quality. By dynamically adjusting risk thresholds, it guides supervisory resources towards high-risk participants, avoiding ineffective consumption of supervisory resources, improving the execution efficiency and risk identification capabilities of supervisory tasks, and reducing overall supervisory costs. It constructs a closed-loop linkage control between approval and supervision. New data generated by approval and supervision continuously feeds back into the credit evaluation model, driving continuous iteration and optimization of the model, improving the accuracy and timeliness of credit evaluation results. At the same time, the control parameters output by the model can optimize approval and supervision strategies, forming a virtuous cycle of mutual support and promotion among the three. The entire process relies on data-driven and algorithmic logic to achieve automated control, reducing subjective bias caused by human intervention.

[0078] Embodiments of the present invention also provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the system as described above. All implementations in the above system embodiments are applicable to this embodiment and can achieve the same technical effects.

[0079] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A system for cross-departmental collaborative examination and supervision of industrial projects based on trusted computing, characterized in that, include: The extraction module is used to trigger smart contracts deployed on the consortium blockchain based on on-chain evidence records, generate approval events, and quantify each behavioral feature into corresponding risk indicators in each dimension through a preset risk model based on the data integrity, process sequence and operation behavior characteristics in the approval process events. The set of risk indicators in each dimension constitutes a multi-dimensional vector. The construction module is used to filter approval process events with the approval status marked as final approval from the historical on-chain evidence records stored in the consortium blockchain network. For each selected approval process event, a three-dimensional multidimensional vector is generated based on the extracted features and the steps quantified by the preset risk model. The normal event vector set is composed of all three-dimensional and multi-dimensional vectors, and a three-dimensional vector space is constructed with data authenticity indicators, process timeliness indicators and behavior compliance indicators as three orthogonal dimensions. Each three-dimensional multidimensional vector in the normal event vector set is mapped to a coordinate point in the three-dimensional vector space according to the values ​​of the three indicators it contains. Based on the spatial position of all coordinate points mapped to the three-dimensional vector space, a continuous smooth surface that minimizes the sum of squared distances from all coordinate points to the reference hypersurface is fitted using the least squares method. This surface is the reference hypersurface. Specifically, it includes: setting a general equation for the quadratic surface, taking the minimization of the sum of squared vertical distances from all coordinate points to the surface as the optimization objective, iteratively updating the coefficients using the gradient descent method until the change in the total sum of squared distances is less than the convergence threshold or the maximum number of iterations is reached, to obtain the corresponding reference hypersurface, which is used to define the risk characteristic distribution boundary of normal approval events. The measurement module is used to obtain the multi-dimensional vector corresponding to the current approval event, map the multi-dimensional vector corresponding to the current approval event to the three-dimensional vector space to obtain the coordinate point of the current event; calculate the geometric distance from the current event coordinate point to the reference hypersurface, select the smallest value from all the calculated geometric distance values ​​as the shortest projection distance, and use the value of the shortest projection distance as the comprehensive risk measurement value. The scheduling module compares the comprehensive risk metric with a preset first-level risk threshold, marks approval process events with comprehensive risk metric values ​​greater than or equal to the first-level risk threshold as high-risk events to be supervised; generates a supervision task record containing a unique identifier for the corresponding event and a comprehensive risk metric for each approval process event marked as a high-risk event to be supervised; and sorts all generated supervision task records in descending order according to their comprehensive risk metric values ​​to form a supervision task sequence. The assessment module is used to construct on-chain audit trails and generate dynamically updated credit evaluation results based on the data in the on-chain audit trails through a preset credit assessment model. The feedback module is used to convert dynamic credit evaluation results into approval rule adjustment parameters and risk monitoring threshold adjustment parameters, and feed the adjustment parameters back to the smart contract's preset rule base and supervision strategy engine to dynamically optimize approval conditions and risk monitoring strategies, forming a closed-loop approval supervision and control mechanism.

2. The trusted computing-based industry project cross-departmental collaborative examination and supervision system according to claim 1, characterized in that, The process of obtaining on-chain evidence records is as follows: Collect raw business data generated during cross-departmental collaboration of industrial projects. The raw business data includes application documents, approval documents, on-site inspection records and progress report documents. In the Trusted Execution Environment deployed on the business terminal, the original business data is hashed to obtain the data hash value. The data hash value is digitally signed using the hardware key embedded in the Trusted Execution Environment, and the current trusted timestamp obtained by the Trusted Execution Environment is attached to generate a trusted data fingerprint containing the data hash value, digital signature and timestamp. The trusted data fingerprint is encapsulated with associated metadata describing the identity of the data source, the business data type, and the associated project number to generate a data packet to be stored. This data packet is then broadcast to the consortium blockchain network, where consensus nodes verify and sort the data packet according to the consensus algorithm and record it in a new block of the distributed ledger, forming an on-chain evidence record with time sequence and consensus endorsement.

3. The trusted computing-based industry project cross-departmental collaborative examination and supervision system according to claim 2, characterized in that, Based on on-chain evidence records, a smart contract deployed on the consortium blockchain is triggered to generate an approval event. Then, based on the data integrity, process sequence, and operational behavior characteristics within the approval process event, a pre-defined risk model quantifies each behavioral characteristic into corresponding risk indicators across various dimensions. The set of risk indicators constitutes a multi-dimensional vector, including: Extract the business type identifier and project stage identifier from the associated metadata of the on-chain evidence storage record, and match and call the smart contract pre-deployed on the consortium chain for the corresponding business scenario based on the combination key composed of the business type identifier and the project stage identifier; execute the smart contract, which performs logical judgment and state inference on the data content of the on-chain evidence storage record based on the built-in rule base associated with the corresponding combination key, to obtain a structured approval process event containing the name of the current approval stage, the code of the responsible department, the approval status identifier and the event occurrence timestamp; The approval process events are analyzed in a structured manner to extract data integrity features reflecting the completeness and format standardization of data items, process sequence features reflecting the processing time of this step and the schedule deviation from the total project schedule, and operational behavior features reflecting the matching degree of operation instruction sequence with the preset standard workflow template. The data integrity features are input into the first evaluation sub-model of the preset risk model, which is trained based on historical data integrity status, and outputs a data authenticity index. The process sequence features are input into the second evaluation sub-model of the preset risk model, which is trained based on historical process timeliness data, and outputs a process timeliness index. The operational behavior features are input into the third evaluation sub-model of the preset risk model, which is trained based on historical compliant operation samples, and outputs a behavior compliance index. By combining data authenticity indicators, process timeliness indicators, and behavioral compliance indicators in this fixed order, a three-dimensional multidimensional vector is formed.

4. The cross-departmental collaborative approval and supervision system for industrial projects based on trusted computing as described in claim 3, characterized in that, Construct an on-chain audit trail, and based on the data in the on-chain audit trail, generate dynamically updated credit evaluation results through a pre-set credit assessment model, including: Based on the chronological order of occurrence, the aggregated on-chain evidence records, approval process events, three-dimensional multi-dimensional vectors, comprehensive risk metrics, and the handling conclusions fed back after the execution of the grid-based supervision nodes form a structured on-chain audit trajectory. Using the identity identifier of the project participant as the key, extract all on-chain evidence records, all approval process events, all multi-dimensional vectors, all comprehensive risk metrics, and all supervision task handling feedback associated with the identity identifier of the project participant from the on-chain audit trajectory to form the historical behavior dataset of the participant. Input the historical behavior dataset into the preset credit assessment model to calculate the average data authenticity index, the compliance rate of the process timeliness index, the number of violations of the behavior compliance index, and the frequency of exceeding the threshold of the comprehensive risk measurement value for the participants within the preset period. The credit score of the participants is calculated by weighting the average value of data authenticity indicators, the compliance rate of process timeliness indicators, the number of violations of behavior compliance indicators, and the frequency of exceeding the threshold of comprehensive risk measurement value according to preset weights. The credit score serves as a dynamically updated credit evaluation result.

5. The cross-departmental collaborative approval and supervision system for industrial projects based on trusted computing as described in claim 4, characterized in that, Inputting historical behavior datasets into a pre-defined credit assessment model calculates the average data authenticity index, process timeliness compliance rate, number of violations of behavioral compliance index, and frequency of exceeding the comprehensive risk metric threshold for each participant within a pre-defined period, including: The system collects all approval process events generated by the participant within a preset period, extracts the data authenticity index corresponding to each approval process event, and calculates the arithmetic mean of all data authenticity indicators to obtain the average value of the data authenticity index. The system counts all approval process events generated by the participant within a preset period and extracts the process timeliness indicators corresponding to each approval process event. Each process timeliness indicator is compared with a preset timeliness compliance threshold. The system counts the number of process timeliness indicators that meet or exceed the timeliness compliance threshold. The system divides the number of compliant indicators by the total number of process timeliness indicators to obtain the process timeliness indicator compliance rate. The system counts all approval process events generated by the participant within a preset period, extracts the behavioral compliance indicators corresponding to each approval process event, compares each behavioral compliance indicator with a preset compliance baseline threshold, and counts the number of behavioral compliance indicators that are below the compliance baseline threshold. This number is the number of violations of the behavioral compliance indicator. The system counts all approval process events generated by the participant within a preset period and extracts the comprehensive risk metric value corresponding to each approval process event. Each comprehensive risk metric value is compared with the first-level risk threshold, and the number of comprehensive risk metric values ​​exceeding the first-level risk threshold is counted. The number of exceeding the threshold is divided by the total number of approval process events to obtain the comprehensive risk metric value threshold exceeding frequency.

6. The cross-departmental collaborative approval and supervision system for industrial projects based on trusted computing as described in claim 5, characterized in that, The dynamic credit evaluation results are converted into approval rule adjustment parameters and risk monitoring threshold adjustment parameters, and these adjustment parameters are fed back to the smart contract's preset rule base and supervision strategy engine to dynamically optimize approval conditions and risk monitoring strategies, forming a closed-loop approval supervision and control mechanism, including: Using credit scores as input, a standard credit coefficient is obtained through linear normalization. The standard credit coefficient is then input into the first linear transformation function to obtain the approval acceleration coefficient. The standard credit coefficient is input into the second linear transformation function to obtain the review intensity coefficient. The approval acceleration coefficient and the review intensity coefficient together constitute the approval rule adjustment parameter. The standard credit coefficient and the preset benchmark risk threshold are input into the multiplication function to obtain the new first-level risk threshold. The standard credit coefficient is the risk monitoring threshold adjustment parameter. The approval rule adjustment parameters are written into the smart contract's preset rule base, and the new first-level risk threshold is sent to the supervision strategy engine; the smart contract executes the subsequent approval process according to the approval rule adjustment parameters in the preset rule base; the supervision strategy engine executes the subsequent supervision task planning according to the new first-level risk threshold. New event data generated by subsequent approval processes and supervision task planning triggers a cycle of updating credit rating results, forming a closed-loop approval, supervision and control mechanism.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program for executing the system as described in any one of claims 1 to 6.

Images