Construction method for three-party topological relation of supply chain

Abstract

The invention discloses a method for constructing a three-party topological relation of a supply chain, and relates to the technical field of data processing, and the method comprises the steps: obtaining original downlink configuration bit streams of a supplier, a demander and a carrier, and analyzing the original downlink configuration bit streams into entity feature vectors; judging vector isomerism and mapping the vector isomerism into a standard structure entity feature vector; executing three-party hierarchical matching analysis based on the vector, and generating a topological graph representing the interaction relationship of three-party logistics, information flow and fund flow; the node attribute state is monitored in real time, and the network hierarchy is dynamically updated in response to the change. The method adapts to heterogeneous data, deeply depicts three-party hierarchical interaction, dynamically responds to node changes, solves the problems of difficult data adaptation, shallow interaction depiction and update lag in a traditional scheme, and provides reliable support for supply chain collaborative decision-making.

Description

Technical Field

[0001] This application belongs to the field of logistics management and processing technology, and in particular relates to a method for constructing a three-party topology relationship in a supply chain. Background Technology

[0002] With the continuous advancement of industrial digitalization, supply chain collaboration networks, with suppliers, demanders, and carriers as the core participants, have become the core carriers for supply chain management optimization and have been widely applied in areas such as smart logistics, industrial interconnection, and supply chain risk management. To achieve refined management and control across the entire supply chain, efficient collaboration among multiple stakeholders, and optimized scheduling of business processes, the industry is placing increasingly higher demands on the accurate construction of topological relationships among supply chain participants, the full-dimensional representation of these relationships, and dynamic adaptation capabilities.

[0003] In existing supply chain management optimization topology construction schemes, the process typically begins by collecting business documents and transaction data from each participant in the supply chain, extracting basic business attribute information for suppliers, demanders, and carriers. Then, based on the correlation fields in upstream and downstream transaction documents, the business flow links between each pair of entities are matched one by one, clarifying the logistics and capital flow relationships between them. Finally, based on the matched links, a relational topology structure of the supply chain participants is formed, providing fundamental data support for supply chain management optimization.

[0004] In practical applications, the aforementioned existing technical solutions are difficult to adapt to the heterogeneous data environment of multiple distributed organizational nodes in the supply chain. The inconsistent attribute feature formats of different entities lead to poor adaptability of matching analysis between entities. At the same time, the construction method of splicing links in pairs cannot fully cover the full-dimensional interaction relationship of logistics, information flow, and capital flow among the three parties. It lacks the ability to represent the collaborative relationship among the three parties in the supply chain and cannot quickly respond to real-time changes in the attribute status of the entities. The update of the topology structure has a high lag, making it difficult to meet the application requirements for accurate construction and dynamic adaptation of topology relationships in the process of supply chain management optimization. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a method for constructing a three-party supply chain topology, thereby at least alleviating the aforementioned technical problems.

[0006] A method for constructing a three-party topology in a supply chain, the method being used for supply chain management optimization, comprising:

[0007] Step 1: Obtain the original downlink configuration bitstream of each distributed organization node in the target supply chain, including suppliers, demanders and carriers, and perform entity feature parsing on the original downlink configuration bitstream to obtain entity feature vectors that record the role attributes of the three parties. Step 2: Determine whether the entity feature vector is a heterogeneous entity feature vector. If it is determined to be a heterogeneous entity feature vector, then map the entity feature vector to a preset standard feature dimension that includes the three-party interaction dimension based on the preset feature mapping table, so as to convert the entity feature vector into a standard structure entity feature vector. Step 3: Perform a three-party hierarchical matching analysis on the supplier, the demander and the carrier based on the feature vector of the standard structural entity corresponding to each of the distributed organization nodes, so as to generate a supply chain three-party topology map representing the interaction relationship of logistics, information flow and capital flow among the three parties; Step 4: Monitor the attribute status of digital organization nodes corresponding to each of the distributed organization nodes in the supply chain tripartite topology map in real time, and in response to a change in the attribute status of any of the distributed organization nodes, perform dynamic updates of the supply chain network hierarchy for the supply chain tripartite topology map.

[0008] Optionally, the entity feature parsing process performed on the original downlink configuration bitstream in step 1 includes: The original downlink configuration bitstream is subjected to dynamic framing based on protocol features using a bitstream detection operator to identify the role protocol frame headers corresponding to the supplier, the demander, and the carrier. Semantic payload extraction is performed on the original downlink configuration bitstream according to the role protocol frame header to obtain multi-dimensional business components including node fulfillment rate, inventory turnover rate and logistics offset. Each multi-dimensional business component is then structured and encapsulated according to a preset role weight to obtain the entity feature vector.

[0009] Optionally, determining whether the entity feature vector is a heterogeneous entity feature vector in step 2 includes: Extract the feature dimension names of each key-value pair data in the entity feature vector, and calculate the semantic information entropy residual between each feature dimension name and the standard protocol dictionary; If the semantic information entropy residual is determined to exceed a preset distribution threshold, then the entity feature vector is determined to be a heterogeneous entity feature vector.

[0010] Optionally, in step 2, mapping the entity feature vector to a preset standard feature dimension that includes the three-party interaction dimension based on a preset feature mapping table includes: The driving feature projection engine determines role-specific projection matrices for the supplier, the demander, and the carrier based on the preset feature mapping table; The entity feature vector is linearly mapped using the role-specific projection matrix to match multimodal business fields based on the entity feature vector and project them into a unified semantic coordinate system, thereby generating the standard structure entity feature vector.

[0011] Optionally, performing supply chain network hierarchical matching analysis in step 3 includes: Retrieve the feature vectors of the standard structural entities corresponding to each of the distributed organization nodes, and perform contractual constraint membership degree calculation between the supplier and the demander to establish an initial supply and demand cascade relationship; Determine the coupling degree of the logistics routing trajectory between the carrier and the initial supply-demand cascade relationship to assess the logical cascade depth of the supplier, demander, and carrier in the target supply chain.

[0012] Optionally, generating the supply chain network topology map includes: Based on the aforementioned logical cascading depth, multi-dimensional weighted directed edges are constructed between each of the distributed organizational nodes. These multi-dimensional weighted directed edges synchronously record the order response delay, transportation loss rate, and payment settlement cycle generated by the three-party interaction, in order to generate the supply chain network topology graph.

[0013] Optionally, the real-time monitoring of the attribute status between digital organization nodes corresponding to each distributed organization node in the supply chain tripartite topology map in step 4 includes: Configure a state machine snapshot extraction agent for each of the digital organization nodes in the supply chain network topology graph; The state machine snapshot extraction agent uses real-time capture of the production quota and transportation load generated by the corresponding distributed organizational nodes during business interactions, and generates instantaneous jump vectors based on these as the attribute states.

[0014] Optionally, updating the supply chain network hierarchy includes: In response to the instantaneous jump vector of any of the digital organization nodes exceeding a preset steady-state threshold, the affected topological branch nodes are extracted, and the standard structural entity feature vector of the associated nodes is retrieved. The contract constraint membership calculation and the logistics route trajectory coupling degree verification are re-executed to perform incremental calibration on the connection weights of the topology branch nodes, thereby updating the supply chain network hierarchy.

[0015] Optionally, the method further includes: In real time, feature flow data of three-party nodes under the same business path in the supply chain network topology map are extracted, and the consistency consensus judgment of the three-party information is performed; When it is determined that the feature flow data does not meet the three-party closed-loop constraint criterion, a secondary feature parsing is triggered for the entity feature vector of the affected node, and topology connection conflict resolution is performed simultaneously.

[0016] Optionally, the method further includes: The entire hierarchical evolution process in the supply chain network topology is encapsulated into a topology evolution audit payload with logical self-interpretation, and the topology evolution audit payload is synchronized to the distributed ledger to achieve tamper-proof traceability of the topology construction process for the supplier, the demander, and the carrier.

[0017] The advantages of the technical solution provided in this application are as follows: First, this application obtains the original downlink configuration bitstream of each distributed organizational node in the target supply chain, including suppliers, demanders, and carriers, and performs entity feature parsing on the original downlink configuration bitstream to obtain entity feature vectors that record the role attributes of the three parties. Unlike existing technologies that rely on the extraction of main information from business documents, this application can directly obtain the role attribute information of the three parties in the supply chain from the underlying configuration data level, reducing the feature extraction deviation caused by differences in business document formats. It can obtain highly consistent main feature data, providing a reliable foundation for the subsequent construction of the supply chain three-party topology map and adapting to the basic data requirements for supply chain management optimization.

[0018] Secondly, this application determines whether an entity feature vector is a heterogeneous entity feature vector. When it is determined to be a heterogeneous entity feature vector, it maps the entity feature vector to a preset standard feature dimension that includes the three-party interaction dimension based on a preset feature mapping table. This converts the entity feature vector into a standard structure entity feature vector, solving the problem of heterogeneous feature formats and poor matching adaptability of multiple distributed organizational nodes in the prior art. It unifies the features of different subjects under the preset standard feature dimension that includes the three-party interaction dimension, providing a standardized feature benchmark for subsequent unified matching analysis at the three-party level. This can effectively improve the comparison adaptability between features of different subjects and meet the unified processing needs of features of multiple subjects in the process of supply chain management optimization.

[0019] Furthermore, this application performs a three-party hierarchical matching analysis on suppliers, demanders, and carriers based on the standard structural entity feature vectors corresponding to each distributed organizational node. This generates a supply chain three-party topology map that represents the interaction relationships of logistics, information flow, and capital flow among the three parties. Unlike the existing technology that constructs the network by splicing links in pairs, this approach can start from the overall dimension of three-party collaboration and fully cover the three core interaction relationships of logistics, information flow, and capital flow throughout the entire supply chain. This enhances the ability of the supply chain three-party topology map to represent the collaborative relationships among the three parties in the supply chain. It can more comprehensively reflect the real correlation status of the supply chain network and provide more practical business-oriented topology data support for supply chain management optimization.

[0020] Finally, this application addresses the problem of high lag in topology updates in existing technologies by real-time monitoring of the attribute status of digital organization nodes corresponding to each distributed organization node in the supply chain tripartite topology graph. In response to changes in the attribute status of any distributed organization node, it performs dynamic updates of the supply chain network hierarchy for the supply chain tripartite topology graph. This enables rapid adaptation to real-time changes in the main attributes of the supply chain network, improves the dynamic adaptation capability of the supply chain tripartite topology graph, and better meets the application requirements for dynamic updates and real-time adaptation of topology relationships in the process of supply chain management optimization. Attached Figure Description

[0021] Figure 1 This application provides a method for constructing a three-party supply chain topology. Figure 2 This application provides an apparatus for constructing a three-party supply chain topology. Figure 3 This is an electronic device according to an embodiment of the present application. Detailed Implementation

[0022] like Figure 1 As shown, a method for constructing a three-party topology in a supply chain is provided. This method is used for supply chain management optimization and includes: Step 1: Obtain the original downlink configuration bitstream of each distributed organization node in the target supply chain, including suppliers, demanders and carriers, and perform entity feature parsing on the original downlink configuration bitstream to obtain entity feature vectors that record the role attributes of the three parties. Step 2: Determine whether the entity feature vector is a heterogeneous entity feature vector. If it is determined to be a heterogeneous entity feature vector, then map the entity feature vector to a preset standard feature dimension that includes the three-party interaction dimension based on the preset feature mapping table, so as to convert the entity feature vector into a standard structure entity feature vector. Step 3: Perform a three-party hierarchical matching analysis on the supplier, the demander and the carrier based on the feature vector of the standard structural entity corresponding to each of the distributed organization nodes, so as to generate a supply chain three-party topology map representing the interaction relationship of logistics, information flow and capital flow among the three parties; Step 4: Monitor the attribute status of digital organization nodes corresponding to each of the distributed organization nodes in the supply chain tripartite topology map in real time, and in response to a change in the attribute status of any of the distributed organization nodes, perform dynamic updates of the supply chain network hierarchy for the supply chain tripartite topology map.

[0023] Optionally, the entity feature parsing process performed on the original downlink configuration bitstream in step 1 includes: The original downlink configuration bitstream is subjected to dynamic framing based on protocol features using a bitstream detection operator to identify the role protocol frame headers corresponding to the supplier, the demander, and the carrier. Semantic payload extraction is performed on the original downlink configuration bitstream according to the role protocol frame header to obtain multi-dimensional business components including node fulfillment rate, inventory turnover rate and logistics offset. Each multi-dimensional business component is then structured and encapsulated according to a preset role weight to obtain the entity feature vector.

[0024] Preferably, before the entity feature parsing process in step 1 begins, a protocol feature recognition rule base is constructed based on the collaborative scenario of multiple business systems in the pharmaceutical supply chain, relying on the master data construction specifications and data indicator dictionary of the big data system. This rule base integrates the standard protocol frame header features and data interaction specifications of the core business systems corresponding to the three types of entities: suppliers, demanders, and carriers. Specifically, it includes protocol features associated with systems such as production resource management and supplier management for suppliers; protocol features associated with systems such as customer relationship management and channel management for demanders; and protocol features associated with systems such as transportation management and logistics distribution for carriers. This provides a clear execution benchmark for the bitstream detection operator, avoids recognition deviations caused by differences in protocols across different business systems, and provides a standardized judgment basis for subsequent dynamic frame segmentation processing.

[0025] Preferably, in the specific technical implementation of step 1, after the bitstream detection operator loads the protocol feature recognition rule base, it performs dynamic framing processing based on protocol features on the original downlink configuration bitstream. By scanning the continuous original downlink configuration bitstream segment by segment and matching the standard frame boundary identifiers in the protocol feature recognition rule base, the original downlink configuration bitstream is cut into protocol frame sequences corresponding to different interactive entities. At the same time, candidate role protocol frame headers corresponding to the three types of entities—supplier, demander, and carrier—are located in the protocol frame sequences. This process realizes the structured decomposition of the continuous bitstream, clearly delineates the data flow boundaries of different entities, and defines the data range for subsequent accurate identification of valid role protocol frame headers.

[0026] Preferably, in one scenario, when implementing step 1, the candidate role protocol frame headers located after dynamic framing are subjected to consistency verification and role attribution marking in accordance with the data quality inspection and management specifications of the big data system. The feature information of the candidate role protocol frame headers is compared item by item with the standard role protocol frame header features in the protocol feature recognition rule base, and the feature matching degree is calculated. Invalid and abnormal frame headers with a feature matching degree lower than a preset threshold are eliminated. For candidate role protocol frame headers with a feature matching degree that meets the requirements, their corresponding subject role is marked as supplier, demander, or carrier, ultimately generating a valid role protocol frame header with completed role attribution marking. This processing step eliminates the interference of invalid data on subsequent processes, ensures the accuracy of role recognition, and provides accurate positioning identifiers for subsequent semantic payload extraction.

[0027] Preferably, in the specific technical implementation of step 1, the effective role protocol frame header that has completed role attribution is used as the starting identifier for data extraction, and the frame tail identifier in the corresponding protocol frame sequence that matches the effective role protocol frame header is used as the ending boundary for data extraction. Semantic payload extraction is performed on the original downlink configuration bitstream. Full semantic payload data within the corresponding frame segment is extracted from the original downlink configuration bitstream. Simultaneously, in accordance with the channel data cleaning and management specifications of the big data system, the extracted semantic payload data undergoes preliminary standardization processing, including invalid data removal, duplicate data deduplication, and garbled data repair, generating a preliminarily cleaned semantic payload dataset. This step decouples business data from the underlying bitstream, obtaining a standardized basic data source that can be used for business feature extraction, laying the data foundation for subsequent extraction of multi-dimensional business components.

[0028] Preferably, in the specific technical implementation of step 1, the semantic payload dataset that has undergone preliminary cleaning is used to perform business dimension decomposition and multi-dimensional business component extraction, combined with the analysis dimensions and data indicator dictionary of the big data system. According to the core business management dimensions of the three main entities—suppliers, demanders, and carriers—multi-dimensional business components corresponding to node fulfillment rate, inventory turnover rate, and logistics deviation are extracted from the semantic payload dataset. The node fulfillment rate corresponds to the supplier's delivery fulfillment, the demander's procurement fulfillment, and the carrier's delivery fulfillment; the inventory turnover rate corresponds to the supplier's raw material and finished product inventory turnover and the demander's commodity inventory turnover; and the logistics deviation corresponds to the carrier's delivery timeliness deviation and transportation route deviation. Simultaneously, each multi-dimensional business component is defined in a standardized manner according to the specifications of the data indicator dictionary to ensure that the same type of business components from different entities have a unified comparison benchmark. This step accurately extracts feature components that can characterize the core business capabilities of the three main entities from the full volume of business data, achieving a quantitative characterization of the entity's business attributes.

[0029] Preferably, in the specific technical implementation of step 1, for the extracted and standardized multi-dimensional business components, based on the business management priorities of the three types of entities in the big data system, preset role weights are matched and assigned. For the supplier entity, corresponding preset role weights are configured for business components related to inventory turnover rate and node fulfillment rate; for the demand side entity, corresponding preset role weights are configured for business components related to node fulfillment rate and inventory turnover rate; for the carrier entity, corresponding preset role weights are configured for business components related to logistics deviation and node fulfillment rate. The numerical configuration of the preset role weights can be adjusted according to the actual needs of supply chain business management, ultimately generating multi-dimensional business components with assigned weights. Through differentiated weight configuration, the core business characteristics of different entities in the supply chain are highlighted, the ability of feature data to represent the entity's role attributes is strengthened, and a business-discriminatory processing object is provided for subsequent structured encapsulation.

[0030] Preferably, the specific implementation process of step 1 is as follows: For the multi-dimensional business components that have completed weight assignment, structured encapsulation processing is performed in accordance with the master data structured construction specifications of the big data system. According to the preset structured format corresponding to the subject role marked in the effective role protocol frame header, the subject's role attribute information, multi-dimensional business components, and corresponding preset role weight information are fully associated and bound, encapsulated into vector data with a unified data structure. Simultaneously, a format consistency check is performed on the encapsulated vector data to verify whether its data structure, dimension definition, and role association relationships meet the requirements of subsequent processing steps. Finally, an entity feature vector recording the role attributes of the three parties is generated. This step completes the full conversion from underlying bitstream data to standardized subject feature vectors. The generated entity feature vectors can fully represent the role attributes and business capabilities of the three parties in the supply chain, providing reliable basic data support for subsequent heterogeneous feature judgment, feature mapping, and topology relationship construction.

[0031] Optionally, determining whether the entity feature vector is a heterogeneous entity feature vector in step 2 includes: Extract the feature dimension names of each key-value pair data in the entity feature vector, and calculate the semantic information entropy residual between each feature dimension name and the standard protocol dictionary; If the semantic information entropy residual is determined to exceed a preset distribution threshold, then the entity feature vector is determined to be a heterogeneous entity feature vector.

[0032] Preferably, before the heterogeneous entity feature vector judgment processing in step 2 is initiated, a standard protocol dictionary covering all business dimensions of suppliers, demanders, and carriers is constructed based on the business collaboration characteristics of the three types of entities in the supply chain and the master data construction specifications and data indicator dictionary of the big data system. This standard protocol dictionary includes all standard business dimension entries for the three types of entities in the supply chain collaboration scenario. This includes standard dimension names and semantic definitions related to supply fulfillment and inventory turnover for suppliers, standard dimension names and semantic definitions related to procurement fulfillment and inventory management for demanders, and standard dimension names and semantic definitions related to logistics offset and delivery fulfillment for carriers. Furthermore, in accordance with the data quality inspection and management specifications of the big data system, a unique semantic reference and unified dimension coding rules are set for each standard dimension entry, ensuring that the entries in the dictionary are semantically unambiguous in the supply chain business scenario, and providing a standardized comparison benchmark for subsequent semantic information entropy residual calculation.

[0033] Preferably, in the specific technical implementation of step 2, structured parsing is performed on the entity feature vector generated in step 1 to extract the feature dimension names of each key-value pair in the entity feature vector. The key-value pair data of the entity feature vector consists of subject role attribute information, multi-dimensional business components, and corresponding preset role weight information. The key name of each key-value pair is the feature dimension name of the corresponding business dimension. The extracted full set of feature dimension names is formatted to remove redundant symbols, garbled characters, and invalid identifiers. At the same time, according to the subject role identified by the entity feature vector, the feature dimension names are classified and grouped by role to generate a set of feature dimension names to be compared for the corresponding subject, providing a clear and standardized processing object for subsequent semantic information entropy residual calculation.

[0034] Preferably, in one scenario, when implementing step 2, a baseline semantic information entropy calculation is performed on the dimension entries in the standard protocol dictionary corresponding to the subject to which the set of feature dimension names to be compared belongs. Simultaneously, a measured semantic information entropy calculation is performed on each feature dimension name in the set of feature dimension names to be compared. Semantic information entropy is used to characterize the degree of semantic dispersion of feature dimension names in the corresponding supply chain business scenario. The baseline semantic information entropy is the standard semantic dispersion value of each dimension entry in the standard protocol dictionary under a unified supply chain business context, while the measured semantic information entropy is the semantic dispersion value of the extracted feature dimension names under the same business context. During the calculation process, the Chinese word segmentation and semantic parsing technical specifications of the big data system are combined to ensure that the calculation context and calculation rules of the baseline and measured semantic information entropies remain completely consistent, providing a unified basic data for subsequent residual calculations.

[0035] Preferably, in the specific technical implementation of step 2, based on the calculated baseline semantic information entropy and the measured semantic information entropy, the semantic information entropy residuals corresponding to each feature dimension name are calculated. The semantic information entropy residual is the absolute value of the difference between the measured semantic information entropy corresponding to the feature dimension name and the baseline semantic information entropy of the corresponding term in the standard protocol dictionary under the same business dimension. The calculated full set of semantic information entropy residuals is classified and sorted according to the business importance of the feature dimension. At the same time, combined with the data quality inspection specifications of the big data system, abnormal residual data caused by missing dimension names, invalid semantics, and data anomalies are removed, generating a set of valid semantic information entropy residuals after outlier removal, providing reliable calculation results for subsequent heterogeneity judgment.

[0036] Preferably, in the specific technical implementation of step 2, a preset distribution threshold for semantic information entropy residuals is set, combining the heterogeneous data judgment requirements of the supply chain business scenario and the cross-system data interaction specifications of the big data system. The preset distribution threshold is used to define the degree of semantic deviation between the feature dimension name and the standard protocol dictionary. Its value can be flexibly adjusted according to the control precision requirements of different business links in the supply chain. The residual data in the effective semantic information entropy residual set are compared with the preset distribution threshold one by one. The proportion of feature dimension names whose residual values ​​exceed the preset distribution threshold is counted. When the proportion exceeds the preset proportion requirement, it is initially determined that the entity feature vector has heterogeneous characteristics, providing a preliminary judgment basis for the final determination of heterogeneous entity feature vectors.

[0037] Preferably, in a scenario, when implementing step 2, a full-dimensional consistency secondary verification is performed on the entity feature vectors initially determined to have heterogeneous characteristics, to ultimately determine whether the entity feature vector is a heterogeneous entity feature vector. During the secondary verification process, all feature dimension names of the entity feature vector are compared with the corresponding dimension entries in the standard protocol dictionary, and a dimension-by-dimensional semantic matching degree verification is performed. At the same time, the business coverage of its feature dimensions is verified in conjunction with the subject role corresponding to the entity feature vector to see if it is consistent with the subject dimension requirements of the standard protocol dictionary. If, after the secondary verification, it is confirmed that the feature dimension names of the entity feature vector have a stable semantic deviation from the standard protocol dictionary, or that the dimension definitions are inconsistent, and the number of semantic information entropy residuals exceeding the preset distribution threshold meets the judgment requirements, then the entity feature vector is ultimately determined to be a heterogeneous entity feature vector.

[0038] Preferably, the specific implementation process of step 2 is as follows: For the heterogeneous entity feature vectors that have completed the final judgment, the feature dimension names and corresponding semantic information entropy residual data that exceed the preset distribution threshold are simultaneously labeled to generate heterogeneous feature label information, and this heterogeneous feature label information is fully associated and bound with the heterogeneous entity feature vectors. This heterogeneous feature label information can provide clear dimension pointing for subsequent feature mapping processing, helping the feature projection engine to accurately locate the feature data for performing dimension mapping. At the same time, combined with the data full-link management and control specifications of the big data system, the judgment process, judgment basis, and label information of the heterogeneous entity feature vectors are recorded throughout the entire process, providing traceable data support for the full-link audit of subsequent supply chain topology construction, and also providing a complete reference basis for the secondary parsing and standardized transformation of entity feature vectors.

[0039] Optionally, in step 2, mapping the entity feature vector to a preset standard feature dimension that includes the three-party interaction dimension based on a preset feature mapping table includes: The driving feature projection engine determines role-specific projection matrices for the supplier, the demander, and the carrier based on the preset feature mapping table; The entity feature vector is linearly mapped using the role-specific projection matrix to match multimodal business fields based on the entity feature vector and project them into a unified semantic coordinate system, thereby generating the standard structure entity feature vector.

[0040] Preferably, before the feature mapping process in step 2 is initiated, a pre-defined feature mapping table covering all business interaction dimensions of the three main entities in the supply chain—suppliers, demanders, and carriers—is constructed based on the master data construction specifications, data indicator dictionary, and standard protocol dictionary of the big data system. This pre-defined feature mapping table integrates mapping rules for all standard feature dimensions and heterogeneous dimensions in the supply chain collaboration scenario. It includes semantic matching and conversion rules for the supplier's delivery fulfillment and inventory turnover business dimensions, the demander's procurement fulfillment and inventory management business dimensions, and the carrier's logistics offset and delivery fulfillment business dimensions. Furthermore, a unique dimension code, semantic definition, and numerical specification are set for each standard feature dimension to ensure that the mapping rules have a unified execution standard across the entire supply chain business scenario, providing a core rule basis for the subsequent determination of role-specific projection matrices and linear space mapping processing.

[0041] Preferably, in the specific technical implementation of step 2, after the final determination of the heterogeneous entity feature vector, the feature projection engine is driven to synchronously load the preset feature mapping table and the target heterogeneous entity feature vector, while performing pre-parse processing on the heterogeneous entity feature vector. During the pre-parse process, the main role attribute information, heterogeneous feature label information exceeding the preset distribution threshold, and numerical distribution information of all feature dimensions carried by the heterogeneous entity feature vector are extracted. At the same time, combined with the standard dimension requirements of the preset feature mapping table, the dimensional boundaries of the original feature space of the heterogeneous entity feature vector are defined and semantic distribution statistics are performed. This clarifies the semantic deviation between the heterogeneous features and the standard feature dimensions, the dimension missing situation, and the redundant dimension information, providing a clear dimension orientation and data foundation for the accurate generation of the subsequent role-specific projection matrix.

[0042] Preferably, in the specific technical implementation of step 2, the feature projection engine determines the role-specific projection matrix for suppliers, demanders, and carriers based on the dimension mapping rules of the preset feature mapping table and the subject role attribute information obtained from the previous analysis. The role-specific projection matrix is ​​a dimension transformation carrier adapted to the business characteristics of different subjects. The rows of the matrix correspond to the preset standard feature dimensions containing the three-party interaction dimensions, the columns of the matrix correspond to the original feature dimensions of the heterogeneous entity feature vectors, and each element in the matrix corresponds to the mapping weight coefficient and semantic transformation coefficient from the original dimension to the standard dimension. For suppliers, the matrix strengthens the mapping weight of dimensions related to inventory turnover and supply fulfillment; for demanders, the matrix strengthens the mapping weight of dimensions related to procurement fulfillment and demand response; and for carriers, the matrix strengthens the mapping weight of dimensions related to logistics offset and delivery timeliness. This ensures that the generated projection matrix can accurately adapt to the business characteristics and heterogeneous dimension characteristics of different subjects, achieving accurate transformation from the original feature space to the standard feature space.

[0043] Preferably, in the specific technical implementation of step 2, the generated role-specific projection matrix is ​​used to perform linear space mapping processing on the heterogeneous entity feature vectors. Each element of the heterogeneous entity feature vector corresponds to the feature value of different business dimensions of the subject, and together they constitute the original feature space with subject characteristics. The linear space mapping process is to project the heterogeneous original feature space to a unified standard feature space through the transformation operation of the role-specific projection matrix. During the process, redundant dimensions are removed, missing dimensions are filled, and semantic corrections of deviated dimensions are completed simultaneously. At the same time, the core feature information that can represent the subject's business capabilities and role attributes in the original feature vector is retained, avoiding the loss of effective features during the dimension transformation process, realizing the standardized transformation of heterogeneous feature data, and providing a unified spatial benchmark for subsequent multimodal business field matching processing.

[0044] Preferably, in the specific technical implementation of step 2, based on the processing results of linear space mapping and combined with a unified semantic coordinate system, accurate matching and caliber normalization processing are performed on the multimodal business fields in the entity feature vector. Multimodal business fields refer to heterogeneous business fields from different business systems and different data formats, including text-based dimension names, numerical business indicators, and categorized status identifiers, among other modalities. The unified semantic coordinate system uses the standard semantic definition of a preset feature mapping table as a benchmark, setting a unique semantic coordinate for each standard feature dimension. Through this semantic coordinate system, heterogeneous business fields with different names, formats, and calibers are accurately matched to the standard business fields of the corresponding standard feature dimensions. Simultaneously, according to the specifications of the data indicator dictionary, numerical caliber normalization processing is performed on the matched business fields to ensure that the same type of business fields from different entities have unified statistical calibers and calculation rules, thus solving the problem of field incompatibility in multi-source heterogeneous data.

[0045] Preferably, in the specific technical implementation of step 2, the feature data that has completed spatial projection and field matching is subjected to full-dimensional quality verification and structured regularization processing to generate an initial version of the standard structural entity feature vector. In accordance with the data quality inspection and management specifications of the big data system, dimension integrity verification, semantic consistency verification, and numerical validity verification are performed sequentially. Dimension integrity verification confirms that the feature data covers all required fields of the preset standard feature dimensions; semantic consistency verification confirms that the semantics of the feature dimensions fully match the definitions of the standard protocol dictionary; and numerical validity verification confirms that the feature values ​​conform to the reasonable value range of the supply chain business scenario. For missing dimensions and abnormal values ​​discovered during the verification process, completion and correction are performed according to the rules of the preset feature mapping table. Finally, in a unified structured format, the subject role attribute information, all standard dimension feature values, and dimension mapping traceability information are associated and encapsulated to generate an initial version of the standard structural entity feature vector with unified structure, complete dimensions, and consistent semantics.

[0046] Preferably, the specific implementation process of step 2 is as follows: Secondary verification and traceability marking are performed on the initial version of the generated standard structural entity feature vector to generate the final standard structural entity feature vector that can be used for subsequent three-party hierarchical matching analysis. During the secondary verification process, the standard structural entity feature vector is compared item by item with the requirements of the preset standard feature dimensions to confirm its structural standardization, data accuracy, and business adaptability, ensuring that it can meet the usage requirements of subsequent supply chain three-party entity matching analysis. Simultaneously, full-link traceability marking is performed on the standard structural entity feature vector, fully associating and binding the mapping rules used in the feature mapping process, role-specific projection matrix parameters, and the dimensional correspondence between the original heterogeneous feature vector and the standard feature vector with the standard structural entity feature vector. Related records are synchronously included in the full-link log of data processing. This provides a complete reference for possible secondary feature parsing and verifiable data support for the audit and traceability of the entire supply chain topology construction process. Furthermore, combined with the process control specifications of the big data system, the execution efficiency and data integrity of the entire feature mapping process are monitored and recorded to ensure that the entire process is manageable, controllable, and traceable.

[0047] Optionally, performing supply chain network hierarchical matching analysis in step 3 includes: Retrieve the feature vectors of the standard structural entities corresponding to each of the distributed organization nodes, and perform contractual constraint membership degree calculation between the supplier and the demander to establish an initial supply and demand cascade relationship; Determine the coupling degree of the logistics routing trajectory between the carrier and the initial supply-demand cascade relationship to assess the logical cascade depth of the supplier, demander, and carrier in the target supply chain.

[0048] Preferably, before initiating the supply chain network hierarchical matching analysis in step 3, a standardized benchmark system for the three-party hierarchical matching analysis is constructed, taking into account the collaborative business characteristics of the supply chain's suppliers, demanders, and carriers, and relying on the master data construction specifications, data indicator dictionary, and full-link business control rules of the big data system. This benchmark system clarifies three core matching dimensions: supplier fulfillment and inventory turnover capabilities; demander fulfillment and demand response capabilities; and carrier logistics and delivery capabilities and timeliness assurance capabilities. Simultaneously, in accordance with the data quality inspection and management specifications of the big data system, a unified numerical calculation caliber, business weight allocation rules, and matching degree judgment standards are set for each matching dimension. This provides a unified execution benchmark and verification rules for subsequent contract constraint membership calculations and logistics route trajectory coupling degree analysis. Simultaneously, the full retrieval and compliance verification of standard structural entity feature vectors corresponding to all distributed organizational nodes in the target supply chain are completed, eliminating invalid feature vectors with missing dimensions or abnormal values. The effective feature vectors are then classified and collected by role, forming supplier feature sets, demander feature sets, and carrier feature sets, providing standardized and complete basic data support for subsequent hierarchical matching analysis.

[0049] Preferably, in the specific technical implementation of step 3, after completing the classification and aggregation of the standard structural entity feature vectors, deep analysis and feature extraction of contract constraint-related dimensions are performed for the supplier feature set and the demander feature set. Contract constraint membership is used to quantify the supply-demand binding relationship and performance compatibility between the supplier and demander based on the business contract. During the analysis, core feature values ​​related to contract performance, such as supply fulfillment rate, order delivery timeliness, product quality stability, and supply capacity upper limit, are extracted from the supplier's standard structural entity feature vector. Core feature values ​​related to contract execution, such as procurement plan completion rate, order response timeliness, payment settlement cycle, and demand scale, are extracted from the demander's standard structural entity feature vector. Simultaneously, combined with the supplier assessment and screening management rules of the big data system, related feature information such as contract execution records, default situations, and cooperation cycles in the historical cooperation between the supply and demand parties is extracted, providing a full-dimensional feature data foundation for subsequent quantitative calculation of contract constraint membership.

[0050] Preferably, in the specific technical implementation of step 3, based on the extracted feature data related to the contractual constraints of both the supply and demand sides, the membership degree of the contractual constraints between the supply side and the demand side is calculated. During the calculation process, for each supply-demand pairing, based on the weighting rules of the standardized benchmark system, the corresponding feature values ​​of both parties are subjected to adaptation quantification calculation to obtain a single-dimensional contract performance adaptation score. Then, combined with the weighting of historical cooperation features, the contract constraint membership degree value of the supply-demand pairing is comprehensively calculated. The higher the value, the stronger the contract binding relationship between the supply and demand parties and the higher the degree of performance adaptation. After completing the membership degree calculation for all supply-demand pairs, they are sorted from high to low according to the membership degree value. Combining the business scale and supply / demand capacity boundaries of both parties, the optimal matching supplier is matched for each demand party, and demand parties within the corresponding adaptation range are matched for each supplier. This establishes multiple sets of one-to-one or one-to-many supply-demand binding links, ultimately forming an initial supply-demand cascade relationship covering all supply and demand nodes. At the same time, the corresponding contract constraint membership degree value, supply and demand capacity matching boundary, and business cooperation scope are marked for each supply-demand binding link, providing a clear link benchmark for subsequent coupling analysis of carriers.

[0051] Preferably, in the specific technical implementation of step 3, after establishing the initial supply and demand cascade relationship, the initial supply and demand cascade relationship is first subjected to business rationality verification and link integrity verification. Business rationality verification is used to confirm that the supply capacity of the supply and demand binding link matches the demand scale and the delivery time is adapted to the demand time, avoiding invalid links with capacity mismatch. Link integrity verification is used to confirm that each supply and demand link covers the constraints of the entire business process of order delivery, logistics transportation, and payment settlement. After eliminating invalid links that fail the verification, the final valid initial supply and demand cascade relationship is formed. Simultaneously, for the carrier's feature set, feature extraction of logistics routing-related dimensions is performed. From the carrier's standard structural entity feature vector, core feature values ​​related to logistics and distribution, such as logistics offset, delivery on-time rate, transportation loss rate, capacity coverage, route scheduling capability, and special category transportation guarantee capability, are extracted. At the same time, combined with the delivery analysis and management rules of the big data system, related feature information such as the carrier's historical delivery records, route coverage network, and anomaly handling capability are extracted to provide complete feature data support for subsequent logistics route trajectory coupling degree calculation.

[0052] Preferably, in the specific technical implementation of step 3, based on the link demand of the effective initial supply and demand cascade relationship and the logistics routing characteristic data of the carrier, the logistics routing trajectory coupling degree between the carrier and the initial supply and demand cascade relationship is calculated. The logistics routing trajectory coupling degree is used to quantify the degree of adaptation between the carrier's logistics distribution capacity, the route coverage network and the logistics delivery demand of the supply and demand link. In the calculation process, for each link of the initial supply and demand cascade relationship, the core logistics demand parameters such as the origin, destination, delivery timeliness requirements, transportation category characteristics, and order batch size are analyzed to form a logistics routing trajectory demand model for that link. Then, the demand model is used to perform an adaptation degree calculation with the logistics routing characteristic data of each carrier. The carrier's route coverage matching degree, delivery timeliness satisfaction, transportation loss control capability, and capacity scheduling flexibility are comprehensively considered. Finally, the logistics routing trajectory coupling degree value between the carrier and the corresponding supply and demand link is calculated. The higher the value, the higher the degree of adaptation between the carrier's logistics service capability and the logistics demand of the supply and demand link.

[0053] Preferably, in the specific technical implementation of step 3, after completing the coupling degree calculation of all carriers and the supply and demand chain, the logical cascading depth of suppliers, demanders and carriers in the target supply chain is comprehensively evaluated based on the coupling degree value and the contractual constraint membership degree value. Logical cascading depth is used to characterize the binding level and collaboration tightness of three-party nodes in the supply chain collaborative link. During the evaluation process, the contractual constraint membership degree of the supply and demand link is used as the basic weight, and the coupling degree of the logistics route trajectory between the carrier and the link is used as the collaboration weight. The collaborative binding score of the three-party nodes is calculated by comprehensively calculating the collaborative binding score. Different logical cascading levels are then divided according to the collaborative binding score. The higher the score of the three-party node, the deeper the logical cascading depth, which means that its collaborative binding relationship in the supply chain is tighter and its business dependence is higher. At the same time, a complete three-party collaborative link of supplier-demand-carrier is established for each three-party node in the logical cascading level. The collaborative binding score, cascading depth level, business coverage and capability matching boundary of each link are marked to form a three-party hierarchical cascading relationship network covering all nodes in the target supply chain. This provides the core hierarchical and link basis for the subsequent construction of the supply chain three-party topology map.

[0054] Preferably, the specific implementation process of step 3 is as follows: after completing the in-depth evaluation of the three-party hierarchical cascading relationship network and logical cascading, perform full-dimensional consistency verification and business closed-loop verification on the matching analysis results. Full-dimensional consistency verification confirms the accuracy of the correspondence between the feature data of the three-party nodes and the link matching results. The rules for dividing the logical cascading depth are consistent with the standardized benchmark system. Business closed-loop verification confirms that the constructed three-party collaborative link can fully cover the entire business process of order fulfillment, logistics distribution, and fund settlement, meeting the business control requirements of supply chain three-party collaboration. At the same time, the entire process of supply chain network hierarchical matching analysis is traceable and marked. The standardized benchmark rules, contract constraint membership calculation parameters, logistics routing trajectory coupling degree calculation model, and logical cascading depth division standards used in the matching process are fully associated and bound with the final cascading relationship network and logical cascading depth evaluation results. The relevant records are synchronously included in the full-link processing log of the big data system. This can provide a complete link traceability basis for the subsequent construction of the topology map, and also provide verifiable and traceable complete data support for the auditing, optimization, and anomaly tracing of supply chain collaborative business. In addition, combined with the business analysis rules of the big data system, high-fitness collaborative links and low-fitness nodes in the matching analysis results are marked, providing data reference for the subsequent optimization and adjustment of the supply chain network.

[0055] Optionally, generating the supply chain network topology map includes: Based on the aforementioned logical cascading depth, multi-dimensional weighted directed edges are constructed between each of the distributed organizational nodes. These multi-dimensional weighted directed edges synchronously record the order response delay, transportation loss rate, and payment settlement cycle generated by the three-party interaction, in order to generate the supply chain network topology graph.

[0056] Preferably, before the supply chain network topology graph generation and processing begins, a standardized definition system for topology graph nodes and directed edges is constructed based on the business characteristics of supply chain tripartite collaboration and the results of logical cascading depth evaluation, relying on the master data construction specifications, data indicator dictionary, and full-link business control rules of the big data system. This system clarifies the unique identification rules, core attribute mounting standards, and hierarchical mapping rules for nodes of three types of distributed organizations: suppliers, demanders, and carriers. It also defines the business meaning, dimension composition, weight calculation rules, and data mounting specifications for multi-dimensional weighted directed edges between nodes. The core dimensions of the directed edges cover three core supply chain collaboration links: order fulfillment, logistics distribution, and fund settlement, forming a one-to-one correspondence with the evaluation dimensions of logical cascading depth. This provides a unified execution benchmark and verification rules for the subsequent full-process construction of the topology graph. Simultaneously, the compliance verification of all node data, link data, and logical cascading depth evaluation results output from the tripartite hierarchical matching analysis is completed, eliminating invalid data with missing dimensions or logical conflicts, and classifying and collecting valid data to provide standardized and complete basic data support for the construction of the topology graph.

[0057] Preferably, after completing the standardized definition system construction and basic data verification, based on the evaluation results of logical cascading depth, the standardized mapping and hierarchical arrangement of distributed organizational nodes are executed. According to the hierarchical division rules of logical cascading depth, the three types of nodes—supplier, demander, and carrier—are mapped to three logical layers of the topology graph: the core collaboration layer, the secondary collaboration layer, and the peripheral collaboration layer, based on their collaboration binding scores. The core collaboration layer arranges the three-party node combinations with the highest collaboration binding scores and the strongest business dependencies; the secondary collaboration layer arranges stable, regular collaboration nodes; and the peripheral collaboration layer arranges nodes for temporary cooperation and low-frequency collaboration. Simultaneously, standardized attribute mounting is completed for each node, fully associating and binding the core business features, role attribute information, business capability boundary data, and historical performance records from the standard structural entity feature vector corresponding to the node with the node's unique identifier. This ensures that each node can fully represent the business attributes and collaboration capabilities of the corresponding organization in the topology graph, providing clear node anchors and attribute benchmarks for the subsequent construction of directed edges between nodes.

[0058] Preferably, after completing the hierarchical arrangement and attribute mounting of nodes, the weight quantization calculation of multi-dimensional weighted directed edges and the construction of the dimensional system are performed based on the collaborative link relationship and logical cascading depth between nodes. The multi-dimensional weighted directed edges are defined with a strict alignment to the business flow of the three parties in the supply chain. A directed edge from the supplier to the demander represents the supply fulfillment link; a directed edge from the demander to the supplier represents the payment settlement link; a directed edge from both the supplier and demander to the carrier represents the logistics outsourcing link; and a directed edge from the carrier to both the supplier and demander represents the delivery fulfillment link, fully covering the bidirectional business interaction of the three parties. Simultaneously, combining the supplier assessment and screening rules and delivery analysis management specifications of the big data system, business weights are assigned to each dimension of the directed edges. Contractual membership is the core weight for the supply fulfillment and payment settlement dimensions, while logistics routing coupling is the core weight for the logistics outsourcing and delivery fulfillment dimensions. A comprehensive weight value for each directed edge is calculated; a higher weight value indicates a stronger collaborative binding relationship and a higher degree of business compatibility between nodes. This ultimately forms a directed edge weight system that matches the node level, achieving a quantitative representation of the collaborative relationship between nodes.

[0059] Preferably, after completing the weight calculation and direction definition of the multi-dimensional weighted directed edges, the association recording and time-series mounting of the full-dimensional business data of the three-party interaction are completed simultaneously during the construction of the directed edges. For each directed edge, the order response latency, transportation loss rate, and payment settlement cycle core business indicators generated during the three-party interaction are recorded simultaneously. At the same time, combined with the sales analysis, inventory analysis, and delivery analysis dimension specifications of the big data system, the corresponding link's order delivery details, inventory turnover data, logistics route trajectory, settlement flow records, abnormal performance, and other full-volume time-series business data are supplemented and mounted. This ensures that each directed edge can not only quantitatively represent the collaborative association strength between nodes, but also completely restore the full business process details and historical interaction trajectory of the corresponding three-party collaborative link. At the same time, the association mapping relationship between the data mounted on the directed edges and the attribute data of the corresponding nodes is established to ensure that the data source is traceable and the data standard is consistent. This solves the problem of missing three-party interaction information and incomplete representation of collaborative relationships caused by splicing two links in the existing technology, so that the topology graph can fully cover the full-dimensional interaction relationship of logistics, information flow, and capital flow between the three parties.

[0060] Preferably, after completing the hierarchical arrangement of all nodes and the construction of multi-dimensional weighted directed edges, the structured generation and multi-dimensional visualization adaptation of the supply chain tripartite topology graph are performed. Following standardized storage specifications for graph data, the hierarchically arranged set of nodes, the set of directed edges with weights and business data, and the attribute set of all nodes and edges are encapsulated into a standardized topology graph triple structure, completing the basic structured generation of the supply chain network topology graph. Simultaneously, combining relevant specifications for pharmaceutical data visualization, management dashboards, and intelligent analysis reports in big data systems, the topology graph is adapted to multi-dimensional business visualization views, including a global supply chain network topology view, a detailed view of single-link three-party collaboration, a core business indicator monitoring view, and an abnormal collaboration link early warning view. The global view intuitively displays the hierarchical distribution and network relationships of all nodes; the detailed view allows for penetrating and viewing the full business interaction data of a single three-party link; and the indicator monitoring view can be linked with the management dashboard to achieve real-time display of core performance indicators. This allows the generated topology graph to support in-depth analysis of the underlying supply chain network relationships and directly serve collaborative management and operational decision-making at the business layer, significantly improving the business practicality and scenario adaptability of the topology graph.

[0061] Preferably, after the structured generation of the supply chain tripartite topology map is completed, a full-dimensional compliance verification and business closed-loop verification are performed on the topology map. Relying on the single-system and cross-system data quality inspection and management platform of the big data system, four categories of verifications are performed sequentially. The first category is node integrity verification, confirming that the nodes in the topology map cover all valid distributed organizational nodes of the target supply chain, with no missing, duplicate, or attribute-deficient nodes. The second category is edge logical rationality verification, confirming that the direction, weight, attached data of directed edges completely match the actual collaborative links and logical cascading depth evaluation results between nodes, with no invalid edges with logical conflicts or weight mismatches. The third category is associated data consistency verification, confirming that the business data attached to directed edges and the corresponding nodes are consistent. The standard structural entity feature vectors of the points and the basic data caliber of the three-party hierarchical matching analysis are consistent and numerically matched, with no data contradictions; the fourth category is business closed-loop verification, which confirms that the collaborative links of each group of three-party nodes in the topology map can fully cover the entire business closed loop of order fulfillment, logistics distribution, and fund settlement, with no missing links in the business process; for abnormal nodes, invalid edges and contradictory data found during the verification process, corresponding corrections and additions are performed, and invalid data that cannot be corrected is removed to ensure that the final generated topology map can truly, accurately and completely reflect the real state of the three-party collaborative network of the target supply chain.

[0062] Preferably, after completing the compliance verification and business closed-loop verification of the topology graph, the final supply chain tripartite topology graph is subjected to full-link traceability marking and audit information encapsulation. Combining the full-link process control specifications of the big data system and the traceability requirements of the distributed ledger, all information related to the entire generation process of the topology graph, including standardized definition rules, node hierarchical mapping basis, directed edge weight calculation parameters, business data source links, and verification and correction process records, is encapsulated into traceability metadata with logical self-interpretation. This metadata is then fully associated and bound to the final topology graph. Simultaneously, the traceability metadata and the full information of the topology graph are incorporated into the full-link processing log of the big data system, achieving full traceability and verifiability of the generation process. At the same time, the basic information of the topology graph's hierarchical evolution and the initial state data of nodes and edges are encapsulated into the basic data for the topology evolution audit payload. This provides complete benchmark data and traceability basis for subsequent dynamic hierarchical updates of the topology graph, full-process tamper-proof traceability, and tripartite information consistency consensus judgment. It also provides verifiable and traceable complete data support for compliance auditing, risk control, and process optimization of supply chain collaborative business.

[0063] Optionally, the real-time monitoring of the attribute status between digital organization nodes corresponding to each distributed organization node in the supply chain tripartite topology map in step 4 includes: Configure a state machine snapshot extraction agent for each of the digital organization nodes in the supply chain network topology graph; The state machine snapshot extraction agent uses real-time capture of the production quota and transportation load generated by the corresponding distributed organizational nodes during business interactions, and generates instantaneous jump vectors based on these as the attribute states.

[0064] Preferably, before the real-time monitoring and processing of node attributes and status in step 4 is initiated, a standardized functional system for state machine snapshot extraction agents is constructed based on the node characteristics and business monitoring needs of the supply chain tripartite topology map, relying on the master data construction specifications, data indicator dictionary, and cluster performance monitoring and management rules of the big data system. This system clearly defines the agent's core functional modules, execution rules, data collection criteria, lifecycle management specifications, and fault tolerance mechanisms. The core functional modules cover four core units: node status snapshot collection, raw data preprocessing, abnormal data filtering, and collection link heartbeat monitoring. Simultaneously, for digital organization nodes with three different roles—suppliers, demanders, and carriers—differentiated collection rules and functional configuration standards are formulated based on their business attributes and monitoring priorities. Supplier nodes focus on status collection and configuration related to production fulfillment and inventory supply; demander nodes focus on status collection and configuration related to procurement needs and order fulfillment; and carrier nodes focus on status collection and configuration related to transportation capacity scheduling and delivery fulfillment. This provides a unified execution benchmark and verification rules for the subsequent instantiation deployment and standardized operation of the agents, ensuring that each agent can accurately adapt to the attribute and status monitoring needs of the corresponding nodes.

[0065] Preferably, after completing the standardized functional system construction of the state machine snapshot extraction agent, for each digital organization node in the supply chain tripartite topology map, the corresponding agent instantiation configuration and unique binding deployment are executed. Based on the unique identifier, role type, hierarchical affiliation, and business link association of the digital organization nodes in the topology map, a dedicated instantiated agent is generated for each node. The unique identifier of the agent is strongly bound to the unique identifier of the corresponding digital organization node, establishing a one-to-one mapping relationship between the agent and the node, ensuring that the state data collected by the agent can be accurately traced to the corresponding node. At the same time, combined with the rapid deployment specifications and fault tolerance management mechanism of the big data system, each agent is configured with an independent operating environment and resource quota, and breakpoint resume, abnormal restart, and heartbeat monitoring mechanisms are set up for the collection link. When the agent experiences operational abnormalities or collection interruptions, the repair process can be automatically triggered and the operating status can be reported synchronously to avoid the interruption of node status monitoring due to agent abnormalities. The agent's deployment information, configuration rules, binding relationship and node metadata of the topology map are synchronously associated and stored, and incorporated into the full-link management log of the big data system to achieve manageable, controllable, and traceable agent deployment and operation processes.

[0066] Preferably, after the deployment and binding of the state machine snapshot extraction agent corresponding to all digital organization nodes are completed, the state machine snapshot extraction agent is used to capture the core state data generated by the corresponding distributed organization nodes in the business interaction process in real time. For supplier nodes, the agent captures real-time, comprehensive business data related to production quotas, including production plan execution progress, available inventory, order delivery capacity, and supply fulfillment progress, according to a preset collection frequency. Simultaneously, it collects dynamic data such as production quota adjustment records, capacity fluctuations, and inventory turnover changes. For carrier nodes, the agent captures real-time, comprehensive business data related to capacity load, including available transport capacity, in-transit transport load, route scheduling execution, and delivery fulfillment progress. Simultaneously, it collects dynamic data such as capacity quota adjustments, transport loss fluctuations, and delivery timeliness changes. For demand-side nodes, the agent simultaneously captures related business data such as changes in procurement demand, order execution progress, and goods receipt confirmation status, providing data support for the status linkage analysis of the three nodes. During the collection process, the agent strictly adheres to the real-time data collection specifications and data quality inspection rules of the big data system. Preliminary format and integrity checks are performed on the captured raw data, eliminating invalid data with format errors or missing fields to ensure the authenticity and completeness of the captured core status data.

[0067] Preferably, after the state machine snapshot extraction agent completes the real-time capture of core state data, it performs standardized feature extraction and normalization processing on the captured raw state data, providing a feature data foundation with unified caliber and standardized dimensions for the subsequent generation of instantaneous jump vectors. Combining the specifications of the pre-defined standard feature dimensions and data indicator dictionary, the raw state data undergoes dimensional decomposition and feature extraction. From the full volume of raw data, key feature items that can characterize the core state changes of node production quotas and capacity load are extracted, clarifying the business meaning, calculation scope, and numerical range of each feature item. Simultaneously, for heterogeneous feature data from different nodes and different business systems, caliber normalization and numerical standardization are performed to unify the statistical period, calculation rules, and numerical units of feature items, eliminating caliber and format differences between different data sources, and ensuring horizontal comparability of similar feature data from different nodes. During the processing, the channel data cleaning and management specifications of the big data system are simultaneously combined to perform secondary verification on the feature data, removing outliers and missing features, ensuring that the processed feature data is dimensionally complete, numerically valid, and caliber unified, corresponding to the dimensional system of the standard structure entity feature vector in the previous steps, and ensuring the consistency of the entire process data system.

[0068] Preferably, after standardizing the core state feature data of the nodes, the instantaneous jump vector is quantized and structured based on the processed feature data, and the vector is used as the attribute state of the corresponding digital organization node. The instantaneous jump vector is a standardized vector with a fixed-dimensional structure. The rows of the vector correspond to the dimensional classification of the core state characteristics of the node, including three main categories: production quota, capacity load, and fulfillment status. The columns of the vector correspond to specific feature items under each dimension. Each element in the vector corresponds to the change amplitude between the real-time value and the steady-state baseline value of that feature item, i.e., the instantaneous jump amplitude. During vector generation, differentiated weight coefficients are set for feature items of different dimensions based on the node's role type and business weight. In the vector of the supplier node, feature items related to the production quota dimension have higher weights; in the vector of the carrier node, feature items related to the capacity load dimension have higher weights; and in the vector of the demand side node, feature items related to procurement fulfillment dimension have higher weights. This ensures that the generated instantaneous jump vector can accurately represent the real-time changes and fluctuation amplitudes of the corresponding node's core attribute status. Simultaneously, each instantaneous jump vector is marked with a unique node identifier, data collection timestamp, and feature calculation rules to ensure the vector's temporal sequence and traceability, achieving a quantitative and standardized representation of the node's attribute status.

[0069] Preferably, after generating the instantaneous jump vector, a full-dimensional compliance check and validity verification are performed on the generated instantaneous jump vector to complete the final calibration and real-time mounting update of the digital organization node attribute status. Based on the cross-system data quality inspection and management specifications of the big data system, three major categories of verification are performed sequentially. The first category is dimensional integrity verification, which confirms that the feature dimensions of the instantaneous jump vector cover all the mandatory monitoring items of the corresponding role node, with no missing dimensions or feature items. The second category is numerical validity verification, which confirms that the values ​​of each element in the vector are within the reasonable business range of the corresponding feature item, with no abnormal extreme values ​​or invalid values ​​with logical contradictions. The third category is temporal consistency verification, which confirms that the change trend between the vector generated this time and the historical temporal vectors conforms to the business logic, with no jump anomalies or temporal misalignments. For abnormal vectors found during the verification process, the corresponding agent is triggered to carry out a secondary collection and recalculation process. Invalid vectors that cannot be corrected are marked and removed to avoid abnormal data interfering with the node status judgment. The instantaneous jump vector that passes the verification is used as the final attribute status of the corresponding digital organization node and is uploaded and updated in real time to the corresponding node in the supply chain three-party topology map, and synchronously updated to the node's attribute feature library, providing accurate and real-time benchmark data for subsequent steady-state threshold judgment of node status and dynamic updates of the supply chain network hierarchy.

[0070] Preferably, after completing the real-time calibration and update of node attribute status, a closed-loop control and anomaly early warning mechanism for the entire attribute status monitoring process is constructed to achieve continuous and stable operation of node status monitoring and business linkage. Combining the early warning management standards of big data systems with the real-time monitoring requirements of management dashboards, this system performs full-process real-time monitoring of the operational status of state machine snapshot extraction agents, the connectivity of data acquisition links, and the generation quality of instantaneous jump vectors. Multi-dimensional anomaly alarm rules are set up, automatically triggering corresponding alarm notifications when situations such as agent offline, acquisition link interruption, data verification failure, or vector jump anomalies occur, and simultaneously initiating preset anomaly repair processes to ensure the continuity and stability of node attribute status monitoring. Simultaneously, a linkage mechanism is established between node attribute status monitoring and subsequent dynamic updates of the supply chain network hierarchy. Real-time updated node attribute status data is synchronously pushed to the topology graph update module, providing real-time data support for comparing node instantaneous jump vectors with preset steady-state thresholds, extracting topology branch nodes, and incrementally calibrating link weights. This forms a complete business closed loop of "status acquisition - feature processing - vector generation - status calibration - topology update," solving the problem of high lag in topology structure updates in existing technologies and enabling rapid response and dynamic adaptation of the supply chain three-party topology graph to real-time changes in node attribute status.

[0071] Optionally, updating the supply chain network hierarchy includes: In response to the instantaneous jump vector of any of the digital organization nodes exceeding a preset steady-state threshold, the affected topological branch nodes are extracted, and the standard structural entity feature vector of the associated nodes is retrieved. The contract constraint membership calculation and the logistics route trajectory coupling degree verification are re-executed to perform incremental calibration on the connection weights of the topology branch nodes, thereby updating the supply chain network hierarchy.

[0072] Preferably, before the supply chain network hierarchy update process in step 4 is initiated, a preset steady-state threshold system for the instantaneous jump vector of digital organization nodes is constructed by combining the business characteristics of the three nodes in the supply chain with the dynamic management and control requirements of the topology map, and relying on the data indicator dictionary, full-link business management and control rules and data quality inspection and management specifications of the big data system. This system sets differentiated steady-state threshold ranges for nodes in three different roles: suppliers, demanders, and carriers. These ranges are based on their core business dimensions and the importance of their collaborative links. For suppliers, thresholds are set around production quotas, inventory turnover, and delivery fulfillment. For carriers, thresholds are set around capacity load, delivery timeliness, and transportation losses. For demanders, thresholds are set around procurement needs, order fulfillment, and goods receipt confirmation. Furthermore, considering the logical cascading depth of nodes in the topology graph, a tiered threshold sensitivity is set for nodes in the core, secondary, and peripheral collaborative layers. The core collaborative layer nodes have narrower threshold ranges and higher sensitivity, ensuring rapid capture of state changes in the core collaborative links. The threshold ranges for secondary and peripheral collaborative layer nodes can be flexibly adjusted according to business needs, providing a unified and accurate execution benchmark for triggering subsequent node anomalies. In conjunction with the early warning management standards of the big data system, an adaptation interface is reserved for dynamic threshold adjustment. Threshold parameters can be adjusted synchronously based on changes in supply chain business scenarios and updates to node business attributes, ensuring the business adaptability of the threshold system.

[0073] Preferably, in the specific technical implementation of step 4, real-time steady-state threshold comparison and verification is performed on the instantaneous jump vectors of all digital organization nodes in the three-party supply chain topology map. In response to the situation where the value of any core feature dimension in the instantaneous jump vector of any digital organization node exceeds the corresponding preset steady-state threshold range, the node status abnormality alarm and supply chain network level update process are immediately triggered. During the comparison and verification process, the rules of the preset steady-state threshold system are strictly followed. The verification priority of core feature dimensions and non-core feature dimensions is distinguished. When the value of a core feature dimension exceeds the threshold, the update process is triggered immediately. When the value of a non-core feature dimension exceeds the threshold, continuous time-series verification is performed first. When the values ​​of multiple consecutive collection cycles exceed the threshold, the update process is triggered then to avoid invalid updates caused by instantaneous data fluctuations that are not essential to business operations. At the same time, in accordance with the cluster performance monitoring and management specifications of the big data system, the triggered update processes are prioritized. Anomalies of core collaboration layer nodes trigger the highest priority update process, while anomalies of secondary and peripheral collaboration layer nodes trigger the regular priority update process. This ensures that changes in the state of the core supply chain link can be processed first. Simultaneously, the unique identifier of the node that triggers the update, the anomaly dimension information, the magnitude of exceeding the threshold, and the trigger timestamp are all fully recorded and incorporated into the basic data of the topology evolution audit payload, providing a complete basis for subsequent topology evolution tracing.

[0074] Preferably, after the update process is triggered and prioritized, the affected topology branch nodes are accurately located and fully extracted based on the digital organization node that triggered the anomaly. Using the digital organization node that triggered the anomaly as the core anchor point, and based on the multi-dimensional weighted directed edges, logical cascading depth, and business link relationships between nodes in the supply chain tripartite topology graph, all related nodes with direct or indirect business collaboration relationships are traced upstream and downstream in both directions. Specifically, when a supplier node is abnormal, demand-side nodes with supply-demand links and carrier nodes with logistics outsourcing links are extracted simultaneously. When a demand-side node is abnormal, supplier nodes with supply-demand links and carrier nodes with delivery fulfillment links are extracted simultaneously. When a carrier node is abnormal, all supplier and demand-side nodes with logistics service links are extracted simultaneously. Simultaneously, combining the collaboration binding score and logical cascading depth between nodes, the affected topology branch nodes are accurately located and fully extracted. The impact of traced related nodes is graded, distinguishing between directly affected and indirectly affected nodes. Directly affected nodes are those with direct business links to the abnormal node and high collaborative binding scores, while indirectly affected nodes are those indirectly related to other nodes and have lower collaborative binding scores. This results in a list of affected topology branch nodes graded by impact level. Irrelevant nodes that have no actual business connection with the abnormal node and are not affected by state changes are removed to ensure the accuracy of the extracted branch node range and avoid the inefficiency caused by recalculating all nodes. At the same time, the list of affected topology branch nodes is associated with the abnormal node information to provide a clear node range for subsequent retrieval of related feature data.

[0075] Preferably, after extracting and classifying the affected topology branch nodes, the standard structural entity feature vectors of the corresponding associated nodes are accurately retrieved and their compliance is verified based on the list of affected topology branch nodes. Based on the unique identifier of each node in the list, the latest version of the standard structural entity feature vector for the corresponding node is retrieved from the supply chain master database. This vector contains core information such as the node's role attribute information, full standard dimensional business feature data, historical performance records, and business capability boundaries. It maintains a data structure and dimensional specification that is completely consistent with the standard structural entity feature vector used in the topology map construction process. At the same time, in conjunction with the data quality inspection and management specifications of the big data system for single systems and cross systems, compliance verification is performed on the retrieved standard structural entity feature vector. Dimensional integrity verification, numerical validity verification, and temporal consistency verification are performed in sequence. Invalid vector data with missing dimensions, abnormal values, or temporal misalignment are eliminated. For vectors that fail the verification, the entity feature vector of the corresponding node is triggered to perform a secondary parsing process to regenerate a standard structural entity feature vector that conforms to the specifications. This ensures that all retrieved vector data is dimensionally complete, numerically valid, and consistent in definition. This provides reliable and standardized basic data support for subsequent contract constraint membership degree calculation and logistics route trajectory coupling degree verification. At the same time, the retrieved vector data is bound one-to-one with the list of affected topology branch nodes to ensure that the mapping relationship between data and nodes is accurate and to avoid logical problems of data mismatch.

[0076] Preferably, after retrieving and verifying the compliance of the standard structural entity feature vectors of the associated nodes, the contract constraint membership calculation and logistics route trajectory coupling degree verification are re-executed for the affected topology branch nodes. First, for the affected supplier and demand nodes, based on the latest standard structural entity feature vectors and combined with updated core status data such as node production quotas, inventory turnover, procurement needs, and order fulfillment, the quantitative calculation of contract constraint membership is re-executed to update the contract binding relationship and fulfillment suitability between supply and demand nodes, generating the latest supply-demand cascade relationship data and clarifying the latest suitability of the supply-demand link. Then, for the affected carrier nodes and the updated supply-demand cascade relationship, based on the latest standard structural entity feature vectors and combined with updated core status data such as node capacity load, delivery timeliness, transportation losses, and route coverage, the quantitative calculation of logistics route trajectory coupling degree is re-executed. The process involves verifying and updating the logistics service compatibility between carrier nodes and supply and demand links, generating the latest logistics link compatibility data. During the calculation and verification process, the unified calculation rules and weight allocation standards of the topology graph construction stage are strictly followed to ensure that the calculation caliber before and after the update is completely consistent, guaranteeing the horizontal comparability of the data. At the same time, calculations are only performed on the affected topology branch nodes, while the unaffected nodes and links retain their original calculation results, significantly reducing the computational load of the update process and improving the efficiency of the topology graph update. Simultaneously, the latest calculation results are compared with the original results to mark the links and dimensions that have changed significantly, providing a clear adjustment basis for subsequent incremental calibration of connection weights.

[0077] Preferably, after recalculating the contract constraint membership degree and verifying the coupling degree of the logistics route trajectory, incremental calibration is performed on the multi-dimensional weighted directed edges between the affected topology branch nodes based on the latest calculation results. Using the latest contract constraint membership degree value as the core basis, the weights of the directed edges in the supply-demand link and payment settlement link between the supplier and demand party nodes are calibrated. Using the latest logistics route trajectory coupling degree value as the core basis, the weights of the directed edges in the logistics entrustment link and delivery fulfillment link between the carrier and supplier / demand party nodes are calibrated. Simultaneously, combined with the latest business status data of the nodes, the full range of business indicator data attached to the multi-dimensional weighted directed edges are updated synchronously, including the latest order response delay, transportation loss rate, payment settlement cycle generated by the three-party interaction, as well as time-series data such as order delivery details, inventory turnover data, logistics route trajectory, and settlement transaction records. Business data is used to ensure that the weight values ​​of directed edges and the attached business data accurately reflect the latest collaborative relationships and business status between nodes. During the calibration process, incremental updates are used, updating and replacing only the weight values ​​and business data that have changed, while keeping the original data unchanged. This avoids the problem of excessive update resource consumption caused by full replacement. At the same time, the rationality of the weight changes before and after calibration is checked, and abnormal weight values ​​that do not conform to business logic are removed. This ensures that the weights of directed edges after calibration are fully matched with the actual degree of collaboration between nodes, providing an accurate link data foundation for the final update of the supply chain network layer.

[0078] Preferably, after completing the incremental calibration of the multi-dimensional weighted directed edges between the affected topology branch nodes, the supply chain network hierarchy of the three-party supply chain topology graph is dynamically updated, and the entire link audit and traceability record of the update process is completed simultaneously. Based on the calibrated directed edge weights between nodes and the latest logical cascading depth evaluation results, the hierarchical affiliation of the affected topology branch nodes is dynamically adjusted. Nodes with significantly improved collaboration binding scores are adjusted to higher priority collaboration levels, and nodes with significantly decreased collaboration binding scores and insufficient adaptability are adjusted to the corresponding levels. At the same time, the attribute status data of nodes, the link relationships between nodes, and the directed edge mounting data in the topology graph are updated to generate an updated three-party supply chain topology graph. Simultaneously, combined with the management dashboard and intelligent analysis report specifications of the big data system, the updated content of the topology graph is pushed to the business monitoring view to achieve real-time linkage updates of core collaboration links, node status, and business indicators, providing the latest data support for supply chain management decisions. Simultaneously, the supply chain network hierarchy of the affected topology branch nodes is updated. The entire process of updating the chain network hierarchy, including information on nodes that trigger anomalies, a list of affected branch nodes, calculation and verification results, weight calibration details, and hierarchy adjustment content, is encapsulated as incremental data in the topology evolution audit payload and synchronized to the distributed ledger. This enables tamper-proof traceability of the entire topology graph hierarchy evolution process, ensuring that the update process is fully traceable, verifiable, and auditable. After the update is completed, a full-dimensional compliance verification of the updated topology graph is triggered simultaneously, ensuring that the updated topology graph nodes are complete, the link logic is reasonable, and the data standards are consistent. This allows the graph to truly and accurately reflect the latest state of the target supply chain tripartite collaborative network, solving the problem of high lag in topology structure updates in existing technologies and enabling the supply chain topology graph to respond quickly and dynamically adapt to changes in node states.

[0079] Optionally, the method further includes: In real time, feature flow data of three-party nodes under the same business path in the supply chain network topology map are extracted, and the consistency consensus judgment of the three-party information is performed; When it is determined that the feature flow data does not meet the three-party closed-loop constraint criterion, a secondary feature parsing is triggered for the entity feature vector of the affected node, and topology connection conflict resolution is performed simultaneously.

[0080] Preferably, in this application, before performing the three-party information consistency consensus judgment, a three-party closed-loop constraint rule system covering all business dimensions is constructed based on the business logic of supply chain three-party collaboration and the full-link control requirements, relying on the master data construction specifications, data indicator dictionary, and cross-system data quality inspection management specifications of the big data system. This system takes the integration of logistics, information flow, and capital flow among the supplier, demander, and carrier in the same business link as its core principle, and defines consistency constraint rules for the three core business links of order fulfillment, logistics distribution, and capital settlement. Specifically, the constraint rules for order fulfillment clarify the core field matching requirements between the supplier's supply plan, the demander's purchase order, and the carrier's delivery order; the constraint rules for logistics distribution clarify the timeliness, quantity, and category matching requirements between the supplier's outbound order, the carrier's waybill, and the demander's inbound order; and the constraint rules for capital settlement clarify the consistency requirements between the demander's payment order, the supplier's receipt order, and the... The service fee settlement statements of the carriers must match the amounts and periods. Simultaneously, based on the logical cascading depth of nodes in the topology graph, differentiated constraint precision requirements are set for the business links of the core collaboration layer, secondary collaboration layer, and peripheral collaboration layer. The constraint rules of the core collaboration layer have higher precision, ensuring stricter consistency control of the core business links. This provides a unified, clear, and implementable execution benchmark and verification rules for subsequent consensus judgment on the consistency of information among the three parties. Furthermore, combined with the process configuration management specifications of the big data system, adaptation interfaces are reserved for the dynamic adjustment of constraint rules, allowing for synchronous updates of constraint rules according to changes in supply chain business scenarios, ensuring the business adaptability of the criteria system.

[0081] Preferably, after completing the construction of the three-party closed-loop constraint criterion system, based on the node association relationships and multi-dimensional weighted directed edge link data of the supply chain three-party topology graph, the standardized division of the target business path and the real-time extraction of the corresponding three-party node feature flow data are performed. First, taking a complete set of supplier-demand-carrier collaborative links in the topology graph as the basic unit, and combining the business binding relationships between nodes, logistics routing trajectories, and contract performance cycles, multiple independent and clearly defined business paths are divided. A unique link identifier is assigned to each business path, and the unique mapping relationship between the supplier node, demand node, and carrier node under each business path is clarified to avoid data cross-contamination between different business paths. Then, relying on the real-time data collection specifications and full-link data management rules of the big data system, the full amount of feature flow data generated by the three-party nodes in the business interaction process under each business path is extracted in real time at a fixed collection cycle. The feature flow data includes, but is not limited to, the following: The data includes order response latency, delivery completion progress, and category quantity matching data for order fulfillment; transportation loss rate, logistics deviation, and delivery timeliness data for logistics and distribution; and payment settlement cycle, payment and receipt matching data, and settlement completion progress for fund settlement. It also includes full-volume time-series business data with multi-dimensional weighted directed edges between nodes. During the extraction process, the channel data cleaning and management specifications of the big data system are combined to perform format standardization, invalid data removal, and time-series alignment processing on the extracted feature flow data. This ensures that the feature flow data of the three-party nodes are under the same statistical period and the same business caliber, providing a unified, time-series aligned, and dimensionally complete basic data for subsequent consensus judgment on the consistency of information among the three parties.

[0082] Preferably, after real-time extraction and preprocessing of the feature flow data of the three parties under the target business path, a consensus judgment on the consistency of three-party information is performed based on the three-party closed-loop constraint criterion system. The judgment process, according to the priority of business links, sequentially performs item-by-item consistency checks on the order fulfillment dimension, logistics and distribution dimension, and fund settlement dimension. For each business dimension, the feature flow data corresponding to the three parties (supplier, demander, and carrier) under the same business path are cross-checked field by field and indicator by indicator according to the matching rules of the corresponding dimension in the three-party closed-loop constraint criterion. The consistency deviation value between the three parties' data is calculated. Simultaneously, based on the importance of the business dimensions, corresponding weight coefficients are set for the consistency deviation values ​​of different dimensions, and a comprehensive calculation is performed to obtain the overall consistency score of the three-party information under this business path. Then, the overall consistency score is compared with the qualified threshold set in the three-party closed-loop constraint criterion. The comparison is combined with the constraints of single-dimensional deviation values. If the overall consistency score is within the acceptable threshold range and none of the single-dimensional deviation values ​​exceed the constraint limit, the feature flow data under this business path is determined to meet the three-party closed-loop constraint criteria. If the overall consistency score exceeds the acceptable threshold range, or any single-dimensional deviation value exceeds the constraint limit, the feature flow data under this business path is determined to not meet the three-party closed-loop constraint criteria. During the judgment process, each verification result, deviation calculation details, and judgment basis are fully recorded and included in the full-link processing log of the big data system to ensure that the judgment process is traceable and verifiable throughout, and to provide clear and detailed basis for subsequent abnormal node location and handling.

[0083] Preferably, when it is determined that the characteristic flow data under the target business path does not conform to the three-party closed-loop constraint criteria, an abnormal link alarm and accurate location process for affected nodes are immediately triggered. First, based on the deviation details recorded during the three-party information consistency consensus judgment process, the specific business dimension and corresponding data field where the consistency deviation occurs are located, and the core link causing the deviation is identified. Then, using the business dimension where the deviation occurs as the anchor point, based on the node mapping relationship of the business path and the association links between nodes in the topology map, the upstream and downstream are traced bidirectionally to accurately locate the supplier node, demand node, and carrier node affected by the consistency deviation, forming a list of affected nodes. At the same time, based on the magnitude of the deviation value and the importance of the business dimension, the affected nodes are classified into impact levels, distinguishing between core affected nodes and secondary affected nodes. Core affected nodes are those that directly cause data deviation, demand nodes, and carrier nodes. The nodes responsible for fulfilling their obligations in the corresponding business processes are identified, while the secondary affected nodes are those indirectly affected by deviations through related links. Each affected node is marked with its corresponding anomaly type, deviation dimension, impact range, and related business path identifier. Then, relying on the shared trace recording specifications of the big data system, the business data interaction trajectory and feature flow of the affected nodes are traced back to the entire link. The nodes that generated the deviation data, the flow path, and the spread range are recorded to form a complete anomaly tracing record. This provides a clear node range and optimization direction for the secondary feature analysis of the subsequent entity feature vectors, and also provides an accurate processing boundary for resolving topology connection conflicts, avoiding the inefficiency caused by reprocessing all nodes.

[0084] Preferably, after accurately locating and classifying the impact level of the affected nodes, a secondary feature analysis of the corresponding entity feature vector is triggered for all nodes in the affected node list. The secondary feature analysis is based on the technical process of the initial entity feature analysis. For the anomaly type and corresponding dimension of this consistency deviation, targeted deep analysis and data correction are performed. First, the original downlink configuration bitstream corresponding to the affected node is retrieved. Combined with the business protocol features corresponding to the anomaly dimension, the bitstream detection operator is re-driven to perform optimized dynamic framing processing on the original downlink configuration bitstream. This enhances the recognition accuracy of the protocol frame header corresponding to the anomaly dimension, eliminates frame boundary recognition errors and invalid frame data mixing that may occur during the initial analysis, and accurately identifies the valid role protocol frame header of the corresponding node role. Then, based on the re-identified role protocol frame header, targeted semantic payload deep extraction is performed on the original downlink configuration bitstream, focusing on extracting the full amount related to the anomaly dimension. Business data, combined with the channel data cleaning management specifications and data quality inspection management rules of the big data system, undergoes more rigorous deduplication, completion, error correction, and standardization processing on the extracted semantic payload data. This corrects issues such as missing feature data, numerical errors, and heterogeneous standardization that may occur during the initial parsing process. Finally, the corrected full-volume multi-dimensional business components are restructured and encapsulated according to preset role weights to generate updated entity feature vectors. At the same time, compliance verification is performed on the updated entity feature vectors to ensure that their dimensions are complete, their values ​​are valid, their semantics are accurate, and they fully match the preset standard feature dimensions. This provides an accurate and reliable node feature data foundation for subsequent topology connection conflict resolution, fundamentally solving the problem of inconsistency in three-party information caused by deviations in node feature data.

[0085] Preferably, after completing the secondary feature parsing of the entity feature vectors of the affected nodes and generating updated entity feature vectors, topology connection conflict resolution processing is performed simultaneously for the affected business paths and topology-related links. First, based on the deviation details and anomaly tracing records output by the three-party information consistency consensus judgment, the specific types and root causes of topology connection conflicts are analyzed and located. Conflict types include, but are not limited to, deviations in the calculation of contractual constraint membership degrees between supply and demand links, errors in the verification of routing trajectory coupling degrees in logistics links, inaccurate weight calibration of multi-dimensional weighted directed edges, errors in node hierarchical classification, and errors in binding relationships between nodes. Then, for different conflict types, combined with the updated entity feature vectors generated by the secondary feature parsing, corresponding resolution processing is performed. For conflicts involving contractual constraint membership degree deviations, the contractual constraint membership degree calculation between the affected supplier and demand nodes is re-executed, and the supply and demand cascade relationship is updated. For conflicts involving errors in logistics routing coupling degree verification, the calculation of contractual constraint membership degrees between the carrier and corresponding nodes is re-executed. The coupling degree of logistics routing trajectories between supply and demand cascade relationships is verified, and the adaptation relationship of logistics links is updated. For conflicts caused by inaccurate directed edge weights, incremental calibration is performed on the weights of affected multi-dimensional weighted directed edges based on the latest node feature data and link adaptation relationships, and all business data such as order response latency, transportation loss rate, and payment settlement cycle attached to the directed edges are updated simultaneously. For conflicts caused by incorrect node association binding, erroneous topology connections are removed, and correct node association links are established based on the latest node feature data and business collaboration relationships. During the resolution process, only affected topology branches and links are processed, while the unaffected topology structure and node data remain unchanged, ensuring the accuracy and efficiency of the resolution process and avoiding impact on the stability of the overall topology graph.

[0086] Preferably, after resolving topology connection conflicts, a consistency review and full-process audit of the resolution results are performed, while the supply chain tripartite topology map is updated synchronously. First, for the business path where conflict resolution has been completed, the latest feature flow data of the tripartite nodes under that path is extracted again, and a tripartite information consistency consensus judgment is performed again to confirm that the feature flow data under that business path meets the tripartite closed-loop constraint criteria, and that consistency deviations in all dimensions are within the constraint range, ensuring that the topology connection conflict has been completely resolved. Then, the resolved node attribute data, link relationships, and multi-dimensional weighted directed edge data are synchronously updated to the supply chain tripartite topology map. Simultaneously, combined with the big data system's management dashboard and intelligent analysis report specifications, the updated content of the topology map and node anomaly information are synchronously pushed to the business monitoring view, realizing a full-process visual display of anomaly warnings, processing progress, and update results for core business links, providing the latest and most accurate topology data support for supply chain management optimization. At the same time, the consistency judgment and anomaly data of this tripartite information verification are updated. The entire process of regular node location, secondary feature parsing, and topological connection conflict resolution, including discrimination details, anomaly records, parsing process, resolution operations, and verification results, is encapsulated as incremental audit data with logical self-interpretation. This data is added to the topological evolution audit payload and synchronized to the distributed ledger, enabling tamper-proof traceability of the entire topological graph anomaly handling process. Finally, based on the cause and handling results of this anomaly, the detailed rules of the three-party closed-loop constraint criterion system and the processing parameters of entity feature parsing are simultaneously optimized to improve the accuracy of subsequent three-party information consistency control and anomaly prevention capabilities. This forms a complete business closed loop of "discrimination-location-parsing-resolution-verification-optimization," continuously ensuring the accuracy of the three-party topological graph in representing real business collaboration relationships in the supply chain. This provides reliable topological data support for refined management and efficient collaboration among multiple entities across the entire supply chain.

[0087] Optionally, the method further includes: The entire hierarchical evolution process in the supply chain network topology is encapsulated into a topology evolution audit payload with logical self-interpretation, and the topology evolution audit payload is synchronized to the distributed ledger to achieve tamper-proof traceability of the topology construction process for the supplier, the demander, and the carrier.

[0088] Preferably, before the full-process construction and hierarchical dynamic updating of the supply chain tripartite topology map is launched, a standardized data system for topology evolution audit is constructed based on the master data construction specifications, data indicator dictionary, and full-link business control rules in Yabao Pharmaceutical's big data system integration solution, combined with the audit and traceability requirements of supply chain collaborative business. This system clearly defines the scope of data collection, dimensional specifications, time series standards, and structured storage format for audit data throughout the entire topology evolution process. It also sets differentiated audit dimension requirements for nodes in three different roles: suppliers, demanders, and carriers. Supplier nodes primarily cover audit dimensions related to production quotas, supply fulfillment, and contract execution; demander nodes primarily cover audit dimensions related to procurement needs, order fulfillment, and fund settlement; and carrier nodes primarily cover audit dimensions related to capacity load, logistics distribution, and route execution. Furthermore, it standardizes and categorizes various evolution events throughout the topology graph's lifecycle, including four main categories: initial topology construction events, hierarchical update events triggered by changes in node attributes, conflict resolution events triggered by inconsistencies in information among the three parties, and node relationship adjustment events. Mandatory audit fields and data validation rules are set for each category of events to ensure that all audit data has unified standards and business relevance. This provides a unified and clear execution benchmark for the subsequent collection of data across the entire topology evolution chain and the encapsulation of audit payloads, ensuring the integrity, consistency, and traceability of audit data from the source.

[0089] Preferably, during the entire lifecycle of the supply chain tripartite topology map—from initial construction and dynamic hierarchical updates to topology connection conflict resolution—real-time collection and full aggregation of topology hierarchy evolution event data and business data are performed. Whenever a topology evolution event is triggered, the corresponding full-link data collection process is simultaneously initiated. The collected content covers the complete context information of the event trigger, including the reason for the event trigger, details of attribute status changes of the triggering node, preset execution rules and constraints, the entire process of event execution, all input data used in the calculation, the topology change result output by the event execution, the unique identifier and accurate timestamp of the event operation, and the unique identifiers of all nodes and business links involved in the event. The input data includes the standard structural entity feature vector of the corresponding node, the instantaneous jump vector, and the original data for calculating contract constraint membership degrees. The system verifies the coupling degree of logistics routes, outputting data including node level adjustment results, weight calibration details of multi-dimensional weighted directed edges, changes in node relationships, and a full snapshot of the updated topology graph. Simultaneously, it collects full-process records of feature parsing, data cleaning, and rule calculation from the big data system's end-to-end processing logs. All collected data is strongly bound to unique event identifiers and corresponding node identifiers, and linked together according to the event execution timeline to form a complete and traceable full-link dataset of topology evolution. This provides complete and authentic basic data support for the subsequent encapsulation of topology evolution audit payloads.

[0090] Preferably, after completing the collection and time-series concatenation of the full-link dataset for topology hierarchical evolution, a structured encapsulation of the topology evolution audit payload with logical self-interpretation is performed. Logical self-interpretation means that the encapsulated audit payload itself contains the complete business context, execution logic, data relationships, and result details of the corresponding topology evolution event, and can completely and accurately reconstruct the entire process of this topology evolution without relying on additional auxiliary data. During the encapsulation process, the collected full-link dataset is first structured and layered according to the type and data attributes of the evolution event, divided into four interconnected structural layers: event metadata layer, business logic layer, raw data layer, and change result layer. The event metadata layer records basic information such as the unique event identifier, trigger timestamp, list of involved third-party nodes, event type, and operation execution entity. The business logic layer records core logical information used in the execution of this evolution event, such as contract constraint membership calculation rules, logistics routing trajectory coupling verification model, third-party closed-loop constraint criteria, weight allocation parameters, and full-process execution steps. The raw data layer records the... The event execution uses all input feature data and original records of business interactions. The change result layer records the final output topology map change details and the updated topology map snapshot. Then, the data of the four levels are encapsulated according to a preset standardized format. At the same time, corresponding semantic annotations and cross-level association mapping relationships are added to each data segment to ensure that the logical chain between the data at each level is clear and traceable. Finally, a topology evolution audit payload with complete logical self-interpretation is formed. In addition, in conjunction with the security audit specifications of big data systems, the encapsulated payload is format-standardized to ensure that it has the characteristics of being storable, verifiable, parsable, and traceable.

[0091] Preferably, after the structured encapsulation of the topology evolution audit payload is completed, a full-dimensional compliance check and anti-tampering preprocessing are performed on the encapsulated topology evolution audit payload to provide secure, compliant, and tamper-proof basic data for subsequent distributed ledger synchronization. Based on the single-system and cross-system data quality inspection management specifications and security audit rules of the big data system, four categories of compliance checks are performed sequentially: The first category is structural integrity check, confirming that there are no missing fields, no data truncation, and no format errors in the four structural levels of the topology evolution audit payload, and that all required audit fields are fully filled; the second category is logical consistency check, confirming that the logical chain between the original input data, business execution logic, and final change results within the payload is completely closed, with no logical contradictions, calculation errors, or data mismatches; the third category is timing accuracy check, confirming that all timestamps within the payload completely match the timing chain of event execution, with no timing misalignment or time tampering; the fourth category is data authenticity check, confirming that all business data within the payload matches the corresponding nodes. The original downlink configuration bitstream, entity feature vector, and business interaction records are completely consistent, with no data forgery or content tampering. For the verified topology evolution audit payload, anti-tampering preprocessing is performed. A unique hash digest is generated for the full content of the payload through hash operation. The hash digest is strongly bound to the payload's unique event identifier and trigger timestamp. At the same time, the hash digest generated by this payload is linked with the hash digest of the previous topology evolution event audit payload to form a chained hash structure. This ensures that when the content of any topology evolution audit payload is tampered with, its corresponding hash digest will change, thereby destroying the overall hash chain structure. This technically guarantees the immutability of the audit payload and provides a core anti-tampering foundation for subsequent distributed ledger synchronization and evidence storage.

[0092] Preferably, after completing the compliance verification and anti-tampering preprocessing of the topology evolution audit payload, the topology evolution audit payload and the corresponding chain hash digest are synchronized to the distributed ledger to complete the on-chain evidence storage process. The distributed ledger adopts a multi-node peer-to-peer deployment mode, with deployment nodes covering all participating entities in the target supply chain, including suppliers, demanders, and carriers. Simultaneously, it connects to the witness node of the supply chain regulator, ensuring that all supply chain participants can synchronously obtain the evidence storage data and achieve multi-party peer-to-peer witnessing. During the synchronous on-chain process, the event metadata, unique hash digest, and preceding and following chain relationships of the current topology evolution audit payload are first written into the transaction records of the distributed ledger as core on-chain data. Simultaneously, the complete structured topology evolution audit payload is written as off-chain supplementary data, forming a one-to-one mapping with the hash digest stored on-chain. On-chain and off-chain data can only achieve consistency verification through the unique hash digest. The data writing process strictly follows the consensus mechanism of the distributed ledger. After consensus verification by all participating nodes, the formal on-chain writing of the data is completed. At the same time, the block height, transaction hash, and on-chain timestamp after successful on-chain recording are supplemented and recorded in the event metadata layer of the corresponding topology evolution audit payload, forming a complete on-chain evidence storage closed loop. Through the multi-party consensus, chained storage, and tamper-proof technical characteristics of the distributed ledger, the entire process of topology evolution data is ensured to be publicly, transparently, and consistently stored among all supply chain participants, solving the problems of data tampering, data inconsistency among multiple parties, difficulty in tracing and proving the source, and low trust among participants in the traditional centralized storage model.

[0093] Preferably, after the distributed ledger synchronizes the topology evolution audit payload onto the blockchain, a traceability and verification mechanism for the entire topology evolution process based on on-chain evidence data is constructed. This enables traceability, verifiability, and auditability of the entire process of topology construction and evolution for suppliers, demanders, and carriers. When tracing or auditing a specific evolution event in the supply chain's three-party topology graph is required, the corresponding on-chain event metadata, unique hash digest, and chain association information are first retrieved from the distributed ledger using the event's unique identifier, on-chain block height, or transaction hash. Then, the corresponding complete structured topology evolution audit payload is retrieved from off-chain storage. By recalculating the hash digest of the entire payload and comparing it with the unique hash digest stored on-chain, the integrity and immutability of the audit payload can be quickly verified. After the hash verification is successful, based on the logical self-explanatory structure of the topology evolution audit payload, the entire topology evolution can be fully reconstructed without additional auxiliary data. The system details the entire chain of events, including triggering causes, execution processes, calculation rules, input data, and changed results. Through a hash chain structure linking preceding and following events, it traces all related topology evolution events, forming a complete lifecycle traceability chain for topology evolution. Furthermore, by integrating the big data system's management dashboard and intelligent analysis report specifications, it provides supply chain participants and regulators with a visualized traceability query interface and standardized audit report generation function. This ensures that the entire process of topology construction for the three parties in the supply chain is manageable, controllable, auditable, and traceable, providing tamper-proof and authoritative data support for compliance audits, transaction dispute resolution, and performance liability definition in supply chain collaborative business.

[0094] Preferably, during the full lifecycle management of topology evolution audit payloads, combined with the continuous operation of supply chain business and the dynamic updating of the topology map, full-link closed-loop management and continuous optimization of audit payloads are implemented to ensure the long-term effectiveness and business adaptability of the traceability mechanism. Based on the cluster performance monitoring and early warning management specifications of the big data system, real-time monitoring is performed on the entire process of audit payload collection, encapsulation, verification, on-chain, and traceability. Multi-dimensional anomaly early warning rules are set, and when data collection is interrupted, payload encapsulation is abnormal, on-chain consensus fails, or hash verification fails, corresponding level of anomaly alarms and preset repair processes are automatically triggered to ensure the continuity and stability of the entire audit payload management process. Simultaneously, based on changes in supply chain business scenarios, the addition and withdrawal of participating entities, optimization of the three-party closed-loop constraint criteria, and iterative updates to the topology construction process, the data rules for topology evolution auditing are updated synchronously. The system, payload encapsulation structure, and on-chain evidence storage rules ensure that the business adaptability of the audit payload is continuously improved, and it can always fully cover the audit needs of the entire topology evolution process. In addition, the system regularly performs full consistency verification on the on-chain evidence storage data in the distributed ledger and the off-chain topology evolution audit payload to ensure that the mapping relationship between on-chain and off-chain data is accurate and the hash verification is consistent. This ensures the immutability and traceability of the data throughout the entire topology evolution process, provides long-term and stable technical support for the full-process compliance of the construction of the three-party topology relationship in the supply chain, and provides a reliable data foundation for the refined management and efficient collaboration of multiple entities across the entire supply chain.

[0095] like Figure 2 The diagram shows a device for constructing a three-party supply chain topology, comprising: The acquisition module 21 is used to acquire the original downlink configuration bit stream of each distributed organization node in the target supply chain, including the supplier, the demander and the carrier, and to perform entity feature parsing on the original downlink configuration bit stream to obtain an entity feature vector that records the role attributes of the three parties. The judgment module 22 is used to determine whether the entity feature vector is a heterogeneous entity feature vector. If it is determined to be a heterogeneous entity feature vector, the entity feature vector is mapped to a preset standard feature dimension containing the three-party interaction dimension based on the preset feature mapping table, so as to convert the entity feature vector into a standard structure entity feature vector. Analysis module 23 is used to perform a three-party hierarchical matching analysis on the supplier, the demander and the carrier based on the feature vector of the standard structural entity corresponding to each of the distributed organization nodes, so as to generate a supply chain three-party topology map representing the interaction relationship of logistics, information flow and capital flow among the three parties; The monitoring module 24 is used to monitor the attribute status between the digital organization nodes corresponding to each of the distributed organization nodes in the supply chain tripartite topology map in real time, and to perform dynamic updates of the supply chain network hierarchy for the supply chain tripartite topology map in response to a change in the attribute status of any of the distributed organization nodes.

[0096] like Figure 3 As shown, an electronic device includes a processor 301 and a memory 302; The memory 302 is used to store computer programs; When the processor 301 executes the program stored in the memory 302, it implements the functions of each module of the supply chain tripartite topology construction device as described in this application, or implements the steps of the supply chain tripartite topology construction method.

Claims

1. A method for constructing a three-party topology in a supply chain, characterized in that, The method is used for supply chain management optimization, including: Step 1: Obtain the original downlink configuration bitstream of each distributed organization node in the target supply chain, including suppliers, demanders and carriers, and perform entity feature parsing on the original downlink configuration bitstream to obtain entity feature vectors that record the role attributes of the three parties. Step 2: Determine whether the entity feature vector is a heterogeneous entity feature vector. If it is determined to be a heterogeneous entity feature vector, then map the entity feature vector to a preset standard feature dimension that includes the three-party interaction dimension based on the preset feature mapping table, so as to convert the entity feature vector into a standard structure entity feature vector. Step 3: Perform a three-party hierarchical matching analysis on the supplier, the demander and the carrier based on the feature vector of the standard structural entity corresponding to each of the distributed organization nodes, so as to generate a supply chain three-party topology map representing the interaction relationship of logistics, information flow and capital flow among the three parties; Step 4: Monitor the attribute status of digital organization nodes corresponding to each of the distributed organization nodes in the supply chain tripartite topology map in real time. In response to a change in the attribute status of any of the distributed organization nodes, perform dynamic updates of the supply chain network hierarchy for the supply chain tripartite topology map.

2. The method for constructing a three-party supply chain topology according to claim 1, characterized in that, Step 1, which involves performing entity feature parsing on the original downlink configuration bitstream, includes: The original downlink configuration bitstream is subjected to dynamic framing based on protocol features using a bitstream detection operator to identify the role protocol frame headers corresponding to the supplier, the demander, and the carrier. Semantic payload extraction is performed on the original downlink configuration bitstream according to the role protocol frame header to obtain multi-dimensional business components including node fulfillment rate, inventory turnover rate and logistics offset. Each multi-dimensional business component is then structured and encapsulated according to a preset role weight to obtain the entity feature vector.

3. The method for constructing a three-party supply chain topology according to claim 1, characterized in that, Step 2, determining whether the entity feature vector is a heterogeneous entity feature vector, includes: Extract the feature dimension names of each key-value pair data in the entity feature vector, and calculate the semantic information entropy residual between each feature dimension name and the standard protocol dictionary; If the semantic information entropy residual is determined to exceed a preset distribution threshold, then the entity feature vector is determined to be a heterogeneous entity feature vector.

4. The method for constructing a three-party supply chain topology according to claim 1, characterized in that, Step 2, which maps the entity feature vector to a preset standard feature dimension that includes the three-party interaction dimension based on a preset feature mapping table, includes: The driving feature projection engine determines role-specific projection matrices for the supplier, the demander, and the carrier based on the preset feature mapping table; The entity feature vector is mapped linearly using the role-specific projection matrix to match multimodal business fields based on the entity feature vector and project them into a unified semantic coordinate system, thereby generating the standard structure entity feature vector.

5. The method for constructing a three-party supply chain topology according to claim 1, characterized in that, Step 3, which involves performing supply chain network hierarchical matching analysis, includes: Retrieve the feature vectors of the standard structural entities corresponding to each of the distributed organization nodes, and perform contractual constraint membership degree calculation between the supplier and the demander to establish an initial supply and demand cascade relationship; Determine the coupling degree of the logistics routing trajectory between the carrier and the initial supply-demand cascade relationship to assess the logical cascade depth of the supplier, demander, and carrier in the target supply chain.

6. The method for constructing a three-party supply chain topology according to claim 5, characterized in that, Generating the supply chain network topology map includes: Based on the aforementioned logical cascading depth, multi-dimensional weighted directed edges are constructed between each of the distributed organizational nodes. These multi-dimensional weighted directed edges synchronously record the order response delay, transportation loss rate, and payment settlement cycle generated by the three-party interaction, in order to generate the supply chain network topology graph.

7. The method for constructing a three-party supply chain topology according to claim 1, characterized in that, Step 4, which involves real-time monitoring of the attribute status between digital organization nodes corresponding to each distributed organization node in the supply chain tripartite topology map, includes: Configure a state machine snapshot extraction agent for each of the digital organization nodes in the supply chain network topology graph; The state machine snapshot extraction agent uses real-time capture of the production quota and transportation load generated by the corresponding distributed organizational nodes during business interactions, and generates instantaneous jump vectors based on these as the attribute states.

8. The method for constructing a three-party supply chain topology according to claim 7, characterized in that, Updating the supply chain network hierarchy includes: In response to the instantaneous jump vector of any of the digital organization nodes exceeding a preset steady-state threshold, the affected topological branch nodes are extracted, and the standard structural entity feature vector of the associated nodes is retrieved. The contract constraint membership calculation and the logistics route trajectory coupling degree verification are re-executed to perform incremental calibration on the connection weights of the topology branch nodes, thereby updating the supply chain network hierarchy.

9. The method for constructing a three-party supply chain topology according to claim 1, characterized in that, The method further includes: In real time, feature flow data of three-party nodes under the same business path in the supply chain network topology map are extracted, and the consistency consensus judgment of the three-party information is performed; When it is determined that the feature flow data does not meet the three-party closed-loop constraint criterion, a secondary feature parsing is triggered for the entity feature vector of the affected node, and topology connection conflict resolution is performed simultaneously.

10. The method for constructing a three-party supply chain topology according to claim 1, characterized in that, The method further includes: The entire hierarchical evolution process in the supply chain network topology is encapsulated into a topology evolution audit payload with logical self-interpretation, and the topology evolution audit payload is synchronized to the distributed ledger to achieve tamper-proof traceability of the topology construction process for the supplier, the demander, and the carrier.

Images