A whole-process operation management and control system for an e-commerce platform

Abstract

The application relates to the technical field of electronic commerce, and discloses a full-process operation management and control system for an e-commerce platform, which constructs a constraint propagation graph through an operating object topology modeling module, establishes a propagation relationship for operating objects such as goods, orders, inventory, warehouse distribution and customer service in the platform, generates action objects through an operation action vectorization packaging module, determines the propagation influence range of operation actions and calculates the comprehensive risk token demand through a risk token budget allocation module, determines the root cause action set corresponding to the abnormal node through a root cause reverse positioning module, and updates the propagation parameters and action object parameters through a parameter online correction module. The application constructs a constraint propagation graph and combines a risk token budget mechanism to evaluate the propagation influence of operation actions on multiple business nodes before the operation actions are executed, so that the problem that each operation link independently operates and chain risks are difficult to be identified in a timely manner in the prior art is solved.

Description

Technical Field

[0001] This invention relates to the field of e-commerce technology, and in particular to a full-process operation and management system for e-commerce platforms. Background Technology

[0002] With the rapid development of e-commerce platforms, the scale of platform business continues to expand, and the variety of goods, the number of orders, and user traffic continue to grow. The operation and management of e-commerce platforms are gradually showing a trend of more complex processes and more collaborative systems.

[0003] In existing technologies, e-commerce platforms typically manage different operational stages through multiple business subsystems. For example, a marketing system manages promotional activities, a traffic distribution system adjusts resource placement exposure, an inventory system controls product inventory status, and a fulfillment system schedules warehousing and distribution strategies. These systems usually execute operational actions using independent rule configurations, such as setting traffic thresholds, inventory thresholds, or order processing strategies. In practical applications, these operational subsystems often collaborate in a loosely coupled manner. When an operational action is triggered in one subsystem, its impact on other business stages is usually identified through post-event monitoring or manual analysis.

[0004] However, the inventors of this application discovered in the process of implementing the technical solution of this application that the above-mentioned prior art has at least the following technical problems: the existing e-commerce platform operation system lacks a unified modeling and quantitative evaluation mechanism for the propagation of operational actions among multiple business nodes, which makes it difficult to identify chain load transmission in a timely manner when multiple operational actions are executed in combination, thus easily causing problems such as local overload or fluctuation in operating status of the system. Summary of the Invention

[0005] To overcome the above shortcomings, this invention provides a full-process operation and control system for e-commerce platforms, aiming to improve the lack of a unified modeling and quantitative evaluation mechanism for the propagation and impact of operational actions across multiple business nodes in the existing technology, which easily leads to local overload or fluctuations in the system's operating status.

[0006] This invention provides the following technical solution: a full-process operation and management system for e-commerce platforms, comprising: The business object topology modeling module is used to acquire product objects, store objects, activity objects, traffic entry objects, inventory objects, order objects, warehousing and distribution objects, after-sales objects, customer service objects, merchant fulfillment objects, and risk control objects in the e-commerce platform, and convert the business objects into nodes. Based on the business relationships between the business objects, directed connections are established between the nodes to generate a constraint propagation graph. The operation action vectorization encapsulation module is used to receive operation action data and generate action objects based on the operation action data. The action objects include the target, action type, revenue driver, load injection, risk disturbance, reversibility level, and compensation template identifier. The risk token budget allocation module is used to read the node status data in the constraint propagation graph, generate node risk token budgets based on the node status data, determine the propagation impact range of the operation action based on the action object and the constraint propagation graph, and calculate the risk token requirements corresponding to each node within the propagation impact range of the operation action to generate the comprehensive risk token requirements of the operation action. The pre-conflict adjudication module is used to read the comprehensive risk token requirement, node risk token budget, and target relationships and propagation path relationships between multiple operational actions, and to adjudicate the operational actions based on the target relationships, propagation path relationships, and comprehensive risk token requirement; The reversible compensation orchestration module is used to read node status data after the execution of operational actions and generate a compensation action sequence based on the compensation template identifier; The root cause reverse location module is used to read the constraint propagation graph when an abnormality occurs in the node status, and to backtrack the executed operational actions according to the propagation path to determine the root cause action set. The online parameter correction module is used to update the propagation parameters in the constraint propagation graph and the parameters in the action object based on the node status changes after the operation action is executed.

[0007] Preferably, in the business object topology modeling module, the step of generating the constraint propagation graph includes: Acquire product objects, store objects, activity objects, traffic entry objects, inventory objects, order objects, warehousing and distribution objects, after-sales objects, customer service objects, merchant fulfillment objects, and risk control objects from the e-commerce platform; Convert each business entity into a corresponding node; Establish directed connections between nodes based on the business transmission relationships between business entities; For each directed connection, record the propagation weight, propagation delay, channel limit, aberration amplification factor, and compensation priority factor; A constraint propagation graph is generated based on the nodes and the directed connection relationships.

[0008] Preferably, in the operational action vectorization encapsulation module, the step of generating an action object based on the operational action data includes: Receive operational data; Read the set of target nodes corresponding to the operational action; Determine the action type of the operational action; Revenue-driven data is generated based on the business rules of the aforementioned operational actions; Load injection data is generated based on the impact of the operational actions on the target node's business. Risk disturbance data is generated based on the impact of the operational actions on node stability. Reversible level data is generated based on the rollback rules of the aforementioned operational actions; Generate a compensation template identifier based on the compensation rules for the aforementioned operational actions; The action object is formed by combining the target, action type, profit driver, load injection, risk disturbance, reversibility level, and compensation template identifier.

[0009] Preferably, in the risk token budget allocation module, the step of generating a node risk token budget based on the node status data includes: Read the current load status data of each node; Read the remaining capacity data of each node; Read the risk exposure status data of each node; Read the service quality status data of each node; Calculate the node risk token budget based on the current load status data, remaining capacity data, risk exposure status data, and quality of service status data. The node risk token budget is recorded as node available risk token data.

[0010] Preferably, in the risk token budget allocation module, the step of determining the propagation scope of the operational action includes: Read the target data from the action object; The target node is determined in the constraint propagation graph based on the stated objective. The propagation path is searched based on the directed connections between the target node and the constraint propagation graph. Identify the set of nodes from which operational actions can transmit their influence based on the propagation path; The set of nodes is defined as the scope of the propagation and impact of operational actions.

[0011] Preferably, in the risk token budget allocation module, the step of generating the comprehensive risk token requirement for operational actions includes: Read the load injection data and risk disturbance data from the action object; Initial perturbation data for the target node is generated based on the load injection data; The propagation calculation is performed on the initial disturbance data based on the propagation weight, propagation delay, and channel upper limit in the constrained propagation graph. Generate propagation perturbation data corresponding to each propagation node; Based on the propagation disturbance data, generate the risk token requirements for each node; The risk token requirements of each node are aggregated to form the comprehensive risk token requirements for operational actions.

[0012] Preferably, in the pre-conflict adjudication module, the steps for adjudicating operational actions include: Read the action objects corresponding to multiple operational actions; Determine the target overlap relationship between operational actions based on the target of each action object; The overlapping relationships of propagation paths between operational actions are determined based on the constraint propagation diagram. Read the comprehensive risk token requirements corresponding to each operational action; Determine whether the overall risk token demand exceeds the node risk token budget of the corresponding node based on the node risk token budget; The operational action decision is generated based on the overlapping relationships of the objectives, the overlapping relationships of the propagation paths, and the comprehensive risk token requirements.

[0013] Preferably, in the reversible compensation orchestration module, the step of generating the compensation action sequence includes: Read the compensation template identifier corresponding to the executed operational action; Read the compensation template data according to the compensation template identifier; Generate a set of compensation actions based on the compensation template data; Compensation priorities are determined based on node risk token data, risk exposure status data, and service quality status data. Sort the set of compensation actions according to their compensation priority; Generate a sequence of compensation actions based on the sorting results.

[0014] Preferably, in the root cause reverse localization module, the step of determining the root cause action set includes: Read the data from the node that encountered the error; The propagation path pointing to the abnormal node is obtained based on the constraint propagation graph; Retrieve executed operational actions within a preset time window; Based on the propagation path, select operational actions that have a propagation relationship with the abnormal nodes; A set of candidate operational actions is determined based on the risk disturbance data and propagation path data of the aforementioned operational actions; The root cause action set is determined from the candidate operational action set.

[0015] Preferably, in the online parameter correction module, the update processing steps include: Read node status data after the execution of operational actions; Read the predicted propagation results obtained based on the constraint propagation graph before the execution of operational actions; Compare the node state data with the predicted propagation results; Update the propagation weights, propagation delays, channel limits, and anomalous amplification coefficients in the constraint propagation graph based on the comparison results. Update the load injection data and risk disturbance data in the action object according to the node state changes.

[0016] The present invention has the following beneficial effects: 1. This invention constructs a constraint propagation graph and combines it with a risk token budget mechanism to assess the propagation impact of operational actions on multiple business nodes before execution, thereby solving the problem in the prior art that each operational link operates independently and it is difficult to identify chain risks in a timely manner.

[0017] 2. This invention uses a pre-conflict adjudication module to uniformly analyze and adjudicate the target relationships, propagation path relationships, and risk token requirements among multiple operational actions, enabling the system to coordinate and process before the execution of operational actions, thereby reducing the concentrated load pressure on key business nodes caused by the superposition of multiple operational strategies.

[0018] 3. This invention uses reversible compensation orchestration, root cause reverse localization, and online parameter correction mechanisms to continuously monitor and correct the node status after the execution of operational actions, enabling the system to adaptively adjust according to changes in operating status, thereby improving the continuous stability of operation management. Attached Figure Description

[0019] Figure 1 This is an architecture diagram of a full-process operation and management system for e-commerce platforms proposed in this invention. Detailed Implementation

[0020] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Reference Figure 1 In the first embodiment of the present invention, the present invention provides a full-process operation and management system for e-commerce platforms, comprising: The business object topology modeling module is used to acquire product objects, store objects, activity objects, traffic entry objects, inventory objects, order objects, warehousing and distribution objects, after-sales objects, customer service objects, merchant fulfillment objects, and risk control objects in the e-commerce platform, and convert business objects into nodes. Based on the business relationships between business objects, directed connections are established between nodes to generate a constraint propagation graph. Preferably, in the topology modeling module for the operating object, the steps for generating the constraint propagation graph include: Acquire product objects, store objects, activity objects, traffic entry objects, inventory objects, order objects, warehousing and distribution objects, after-sales objects, customer service objects, merchant fulfillment objects, and risk control objects from the e-commerce platform; Convert each business entity into a corresponding node; Establish directed connections between nodes based on the business transmission relationships between business entities; For each directed connection, record the propagation weight, propagation delay, channel limit, aberration amplification factor, and compensation priority factor; Generate a constraint propagation graph based on the nodes and directed connections.

[0022] Specifically, the process begins by collecting multi-source business data from the e-commerce platform's database, such as product information tables, store information tables, order record tables, inventory record tables, logistics fulfillment record tables, after-sales service record tables, and risk control monitoring data. The core business entities within this data are then abstracted into a set of business objects. Subsequently, each business object in this set is node-based, ensuring that each business object corresponds to a unique node in the system. For example, each product corresponds to a product node, each store to a store node, and each activity to an activity node. Warehousing and distribution centers, customer service systems, and risk control systems correspond to warehousing and distribution nodes, customer service nodes, and risk control nodes, respectively.

[0023] After completing the node construction, it is necessary to further determine the business transmission relationships between the nodes. By analyzing the data dependencies and business process relationships between various business modules in the e-commerce platform, directed connections between nodes are established. For example, traffic entry nodes can transmit exposure traffic to product nodes, so a directed connection is established between traffic entry nodes and product nodes; sales activities at product nodes generate orders, so a directed connection is established between product nodes and order nodes; the generation of order nodes triggers inventory deductions and logistics fulfillment, so directed connections are established between order nodes and inventory nodes, and between order nodes and warehousing and distribution nodes. Through the above methods, a node connection structure covering the main operational links of the e-commerce platform can be gradually formed.

[0024] To quantify the impact of operational actions propagating between nodes, propagation parameters need to be configured for each directed connection. These parameters include: propagation weight (representing the strength of the influence transmission between nodes), propagation delay (representing the time delay required for the influence to propagate from an upstream node to a downstream node), channel limit (representing the maximum carrying capacity of the propagated influence between nodes), anomaly amplification factor (describing the degree to which anomalies occur during propagation when an upstream node experiences an anomaly), and compensation priority factor (determining the priority propagation path for subsequent compensation processing).

[0025] During the calculation process, the topological structure of the business objects can be represented as a directed graph structure, as follows: ; in, Represents the constraint propagation graph; Represents a set of nodes; This represents a set of directed connections.

[0026] For any two nodes and If there exists a slave node Pointing to node If the business transmission relationship is such that a directed connection is established in set E, then... Record the propagation parameters on this connection, where the propagation weight is denoted as... The propagation time delay is denoted as The upper limit of the channel is denoted as The abnormal amplification factor is denoted as .

[0027] When a node experiences a service disturbance, the disturbance can be represented during its propagation as follows: ; in, Indicates from node propagation to nodes The amount of disturbance; Represents a node The current intensity of the disturbance; Indicates propagation weight; Indicates the amplification factor; This indicates the channel upper limit, used to limit the propagation disturbance from not exceeding the maximum carrying capacity between nodes.

[0028] The aforementioned propagation parameters can be initialized based on historical operational data. For example, by statistically analyzing the impact of order growth during historical promotional events on warehousing and distribution fulfillment timeliness, the propagation weight between the product node and the warehousing and distribution node can be determined; by analyzing the average time between order generation and shipment completion, the propagation lag parameter can be determined; and by statistically analyzing the number of orders that a warehousing and distribution center can process per unit time, the channel upper limit parameter can be determined. By initializing and configuring these parameters, the constraint propagation graph can be made to more closely reflect the actual business operations of the e-commerce platform.

[0029] After the constraint propagation graph is constructed, the system stores all nodes and their connections in a graph structure database or in-memory graph structure for rapid querying by subsequent modules. For example, during subsequent operational action analysis, a graph traversal algorithm can be used to search for propagation paths, thereby quickly determining the propagation impact range of operational actions within the system. Simultaneously, by recording propagation weights and channel limits, the potential system pressure from operational actions can be estimated at the system level.

[0030] The constraint propagation diagram constructed using the above method can comprehensively depict the influence transmission relationships among various business entities within an e-commerce platform. This allows the impact of operational actions to extend beyond a single business module, enabling system-level modeling and analysis of the full-process impact of operational actions. This provides foundational data support for subsequent risk token budget calculations, pre-conflict adjudication, and compensation orchestration. This not only enhances the overall controllability of e-commerce platform operations management but also identifies potential chain-effect paths before operational actions are executed, thus preventing localized operational strategies from impacting the overall stability of the platform.

[0031] The operational action vectorization encapsulation module is used to receive operational action data and generate action objects based on the operational action data. The action objects include the target, action type, revenue driver, load injection, risk disturbance, reversibility level, and compensation template identifier. In the operational action vectorization encapsulation module, the steps for generating action objects based on operational action data include: Receive operational data; Read the set of target nodes corresponding to the operational actions; Determine the action type of the operational action; Generate revenue-driven data based on the business rules of operational actions; Load injection data is generated based on the impact of operational actions on the target node's business. Risk disturbance data is generated based on the impact of operational actions on node stability. Reversible level data is generated based on the rollback rules of operational actions; Generate compensation template identifiers based on the compensation rules for operational actions; The action object is formed by combining the target, action type, profit driver, load injection, risk disturbance, reversibility level, and compensation template identifier.

[0032] Specifically, in the daily operation of e-commerce platforms, platform operators or automated operation systems constantly generate various operational actions, such as launching product promotions, adjusting traffic resource positions, adjusting pricing strategies, changing inventory scheduling strategies, switching order fulfillment strategies, and adjusting risk control strategies. These operational actions are often distributed across different business systems, such as marketing systems, traffic distribution systems, inventory management systems, fulfillment management systems, and risk control systems. Treating these operational actions directly as discrete events can easily lead to a lack of a unified management perspective across different systems. Therefore, in this embodiment, an operational action vectorization encapsulation module is used to uniformly model operational actions, enabling operational actions from different sources to be expressed using a unified data structure, thereby facilitating unified analysis and control of operational actions by subsequent modules.

[0033] In practice, operational action data typically originates from multiple business systems within an e-commerce platform. These include activity configuration data in the marketing system, traffic allocation rules in the traffic scheduling system, replenishment or limited-sale strategy data in the inventory system, and delivery priority rules in the fulfillment system. The operational action vectorization encapsulation module first receives operational action data from these systems and performs unified parsing, extracting information such as operational action identifiers, action trigger times, the scope of products or stores involved, and action execution rules.

[0034] Next, the system needs to determine the target of the operational action. This is done by reading the business object identifiers from the operational action data, such as product IDs, store IDs, or activity IDs, and then searching for the corresponding nodes in the constraint propagation graph, thus forming a target node set. This target node set represents the direct objects affected by the operational action within the system. For example, when a promotional activity affects multiple products, these product nodes constitute the target set of the operational action.

[0035] After determining the target, it is necessary to further identify the action types of the operational actions. In this embodiment, action type is used to describe the basic way in which operational actions affect the system state. Common action types include boosting actions, suppressing actions, restricting actions, and switching actions. For example, traffic weighting allocation is a boosting action, product delisting is a suppressing action, inventory sales restriction is a restricting action, and fulfillment strategy switching is a switching action. By classifying operational actions, different impact propagation models can be used in subsequent processing.

[0036] In generating revenue-driven data, it's necessary to analyze the business objectives of operational actions. For example, when an operational action involves launching a promotional campaign, its primary business objective might be to increase product sales or boost the platform's overall transaction volume; when an operational action involves adjusting inventory management strategies, its business objective might be to optimize inventory turnover efficiency. To quantify revenue drivers, revenue-driven parameters can be defined. It represents the driving force of the k-th operational action on the platform's operating metrics: ; in, This indicates the revenue-driving strength of operational actions; n represents the number of operational indicators included in the calculation. This represents the change in the i-th operating indicator, such as the change in transaction volume or the change in click-through rate; This represents the weighting coefficient of the corresponding business indicator, used to reflect the importance of that indicator to the overall business objectives.

[0037] When generating load injection data, it is necessary to analyze the impact of operational actions on the system's business load. For example, launching a promotional campaign typically leads to an increase in order volume, which in turn increases the business load of inventory deduction, warehousing and distribution processing, and customer service inquiries. Therefore, load injection can be quantified by statistically analyzing the changes in business requests after an operational action is triggered. In this embodiment, load injection strength can be expressed as: ; in, This indicates the intensity of load injection generated by operational actions; m represents the number of business load types. This represents the change in the workload of the j-th type of business, such as changes in order requests or customer service inquiries. This indicates the impact weight of the corresponding business load type.

[0038] During the generation of risk disturbance data, it is necessary to assess the potential impact of operational actions on system stability. For example, when an operational action introduces a large number of order requests in a short period of time, it may increase the processing pressure on the warehousing and distribution system or cause delays in the customer service system, thereby triggering system risks. In this embodiment, risk disturbance parameters are generated by comprehensively considering node load levels, historical anomaly records, and system stability indicators. : ; in, This indicates the intensity of the risk disturbance caused by operational actions; This indicates the degree to which operational actions affect the stability of node load; Indicates the frequency of abnormal triggers in the history of operational actions; and This represents the risk impact weighting coefficient.

[0039] When determining the reversibility level, it's necessary to analyze whether the operational action can be rolled back after execution. Therefore, the reversibility level can be calculated based on the business attributes of the operational action and the system's rollback rules. Generally, a higher reversibility level indicates that the operational action is more easily corrected through compensation mechanisms when an anomaly occurs. When generating compensation template identifiers, corresponding compensation strategies need to be matched according to the type of operational action. For example, when the operational action is a traffic boosting action, its compensation strategy might include traffic reduction or exposure weight restoration; when the operational action is a promotional activity, its compensation strategy might include activity suspension or discount ratio adjustment. The compensation template identifier is used to quickly match the corresponding set of compensation actions in the subsequent compensation orchestration module.

[0040] After generating the above parameters, the system combines the target, action type, revenue driver, load injection, risk disturbance, reversibility level, and compensation template identifier according to a unified data structure to form a complete action object. This action object serves as a unified representation of operational actions within the system and can be transferred and processed between different modules.

[0041] Through the aforementioned process of vectorizing and encapsulating operational actions, operational actions that were originally scattered across different business systems can be uniformly transformed into structured action objects, enabling the system to accurately describe the impact characteristics of these actions. Furthermore, these action objects not only contain the business objective information of the operational actions but also parameters regarding their impact on system load and risk. This provides fundamental data support for subsequent calculations of the scope of impact, risk token budget assessments, and conflict resolution, thereby enhancing the predictability and controllability of the entire e-commerce platform's operational management.

[0042] The risk token budget allocation module is used to read the node status data in the constraint propagation graph, generate node risk token budgets based on the node status data, determine the propagation impact range of the operational action based on the action object and the constraint propagation graph, and calculate the risk token requirements corresponding to each node within the propagation impact range of the operational action to generate the comprehensive risk token requirements of the operational action. Preferably, in the risk token budget allocation module, the steps for generating a node risk token budget based on node status data include: Read the current load status data of each node; Read the remaining capacity data of each node; Read the risk exposure status data of each node; Read the service quality status data of each node; Calculate the node risk token budget based on the current load status data, remaining capacity data, risk exposure status data, and service quality status data; Record the node risk token budget as node available risk token data.

[0043] Preferably, in the risk token budget allocation module, the steps for determining the propagation scope of operational actions include: Read the target data from the action object; Determine the target node in the constraint propagation diagram based on the objective. The propagation path is searched based on the directed connections between the target node and the constraint propagation graph. Identify the set of nodes from which operational actions can transmit their influence based on the propagation path; The set of nodes is defined as the scope of the propagation and impact of operational actions.

[0044] Preferably, in the risk token budget allocation module, the steps for generating comprehensive risk token requirements for operational actions include: Read the load injection data and risk disturbance data from the action object; Initial perturbation data for the target node is generated based on the load injection data; The propagation calculation is performed on the initial disturbance data based on the propagation weights, propagation delays, and channel limits in the constrained propagation graph. Generate propagation perturbation data corresponding to each propagation node; Generate risk token requirements for each node based on propagation disturbance data; The risk token requirements of each node are aggregated to form the comprehensive risk token requirements for operational actions.

[0045] Specifically, in the operation and management of e-commerce platforms, there are significant differences in the carrying capacity, operational stability, and risk tolerance of different business nodes. For example, some warehousing and distribution nodes can handle a high volume of orders during peak periods, while some customer service nodes can handle a relatively limited number of inquiries within the same time period. If these differences are not considered during the operational decision-making process, it may lead to overload pressure on some business nodes after the operational actions are executed. Therefore, in this embodiment, a risk token budget mechanism is used to quantify the tolerable operational disturbances of each node, so that the impact of operational actions on system stability can be assessed before execution.

[0046] During the generation of the node risk token budget, the system first reads the status information of each node from the constraint propagation graph. Node status information is typically provided in real time by multiple business monitoring systems. For example, the order processing system provides node load status data, the inventory system provides inventory capacity data, the risk control system provides risk exposure status data, and the customer service or fulfillment system provides service quality status data. By integrating this data, the current operational status of the nodes can be comprehensively reflected.

[0047] To quantify a node's risk-bearing capacity, a node risk token budget parameter is introduced. , which represents a node The amount of operational disruption that can be tolerated within the current time period. The node risk token budget can be calculated as follows: ; in, Represents a node Risk token budget; This represents the node type coefficient, used to reflect the basic bearing capacity of different node types; This indicates the remaining capacity of a node, such as the remaining processing capacity of a warehousing and distribution node or the remaining service capacity of a customer service node. Indicators representing the service quality status of nodes, such as on-time delivery rate or customer service response success rate; This data represents the current load status of the node, indicating the current business pressure on the node. This indicates the node's risk exposure status data, such as the proportion of abnormal orders or the probability of historical failures.

[0048] Using the above calculation method, when the node has high remaining capacity and stable service quality, the node risk token budget will be relatively high; while when the node has high load pressure or high risk exposure, the node risk token budget will be reduced accordingly, thereby limiting the impact of new operational actions on the node.

[0049] After calculating the node risk token budget, it is necessary to further determine the propagation impact range of operational actions within the system. In this embodiment, the system first reads the target data of the action object and locates the corresponding target node in the constraint propagation graph. For example, when an operational action acts on a specific product node, that product node serves as the starting node for propagation calculation. Subsequently, by performing a path search on the constraint propagation graph, all possible paths propagating from the target node to downstream nodes can be identified. The path search can employ graph traversal methods, such as breadth-first search or depth-first search, and the propagation paths are filtered based on propagation delay and channel upper limit during the search process.

[0050] During the path search process, the propagation path expansion can be terminated when any of the following conditions are met: 1) the propagation path exceeds a preset propagation depth threshold; 2) the propagation disturbance decays to below a preset threshold; or 3) the node channel upper limit reaches a limiting condition. This strategy effectively controls the computational complexity of propagation path search while ensuring that the propagation impact covers the main impact links of operational actions.

[0051] After determining the scope of the propagation impact, it is necessary to further calculate the risk token requirements of the operational action at each node. First, the initial perturbation of the target node is generated based on the load injection data in the action object. For example, when the operational action is the launch of a promotional activity, its load injection might manifest as an increase in the number of order requests. The initial perturbation can be represented as: ;in, Represents the target node The initial disturbance intensity; This represents the load injection data for operational action k.

[0052] Subsequently, the system performs propagation calculations on the initial disturbance based on the propagation parameters in the constraint propagation graph. For slave nodes... To the node The propagation process, and its propagation disturbance, can be expressed as: ; in, Indicates propagation to nodes The amount of disturbance; Represents a node To the node The propagation weight; Indicates the amplification factor; This indicates the upper limit of the propagation channel, used to limit the maximum value of propagation disturbances.

[0053] After obtaining the propagation perturbation data of each node, the risk token requirement for each node can be further calculated. In this embodiment, the node risk token requirement can be expressed as: ; in, Represents a node Risk token requirements; Indicates propagation to nodes The amount of disturbance; Data representing risk disturbances in operational activities; Indicates the node load mapping coefficient; This represents the node risk mapping coefficient.

[0054] Through the aforementioned risk token budget allocation and propagation impact analysis mechanism, the potential impact of operational actions can be systematically assessed before execution. This enables the operational system to identify operational strategies that may lead to node overload or increased risk, and provides quantitative evidence for subsequent pre-emptive conflict adjudication. This not only reduces system load anomalies caused by overlapping operational strategies but also improves the overall stability and controllability of e-commerce platforms in complex operational scenarios.

[0055] The pre-conflict adjudication module is used to read the overall risk token requirement, node risk token budget, and the target relationship and propagation path relationship between multiple operational actions, and to adjudicate the operational actions based on the target relationship, propagation path relationship, and overall risk token requirement; Preferably, in the pre-conflict adjudication module, the steps for adjudicating operational actions include: Read the action objects corresponding to multiple operational actions; Determine the target overlap relationship between operational actions based on the target of each action object; Determine the overlapping relationships of propagation paths between operational actions based on the constraint propagation diagram; Read the comprehensive risk token requirements corresponding to each operational action; Determine whether the overall risk token demand exceeds the node risk token budget of the corresponding node based on the node risk token budget; Operational action decisions are generated based on overlapping objectives, overlapping propagation paths, and comprehensive risk token requirements.

[0056] Specifically, in the actual operation of e-commerce platforms, operations personnel typically configure multiple operational actions within the same timeframe. These actions might include launching multiple promotional activities simultaneously, overlaying traffic resource allocation strategies, updating inventory scheduling strategies, and changing fulfillment priority strategies. Although these actions are triggered by different business systems, they can have a cumulative effect at the system level. For example, two different promotional activities might simultaneously apply to the same type of product, leading to a concentrated increase in order requests; or a traffic weighting strategy might be in effect simultaneously with an inventory release strategy, causing a sharp increase in processing pressure on warehousing and distribution nodes within a short period. Therefore, before officially executing any operational action, it is necessary to uniformly resolve any potential conflicts between these actions.

[0057] In this embodiment, the pre-conflict adjudication module reads the action objects corresponding to multiple operational actions and analyzes the relationships between these actions in conjunction with a constraint propagation graph. First, it identifies whether there is target overlap between different operational actions by using the target information in the action objects. For example, when two operational actions both act on the same product node or the same store node, it is considered that there is target overlap between these two operational actions. To quantify the target overlap relationship, a target overlap parameter can be defined. : ; in, This represents the set of objectives for the operational action p; This represents the set of objectives for the operational action q. Indicates the size of the intersection of two sets of targets; This represents the size of the union of two sets of targets.

[0058] When target overlap A higher value indicates that the two operational actions are more likely to affect the same business object, which may lead to conflict.

[0059] Beyond the overlap of objectives, further analysis of the propagation path relationships between operational actions is needed. Specifically, the system tracks the propagation impact range of each operational action through a constrained propagation graph and records its propagation path. For example, an operational action might propagate from the product node, and its impact could sequentially reach the order node, warehousing and distribution node, and customer service node. If another operational action also propagates along a similar path, the two operational actions may have overlapping effects on the propagation chain. In this embodiment, the degree of propagation path overlap can be determined by statistically analyzing overlapping nodes in the propagation path. For example, when two operational actions intersect at the same warehousing and distribution node or the same customer service node, an overlapping propagation path relationship is considered to exist.

[0060] After completing the analysis of target relationships and propagation paths, the system needs to read the comprehensive risk token requirements corresponding to each operational action and compare them with the node's risk token budget. If the risk token requirement for a certain operational action on a certain node exceeds the node's risk token budget, it indicates that the operational action may cause overload pressure on that node under the current system state. To uniformly assess the degree of conflict between multiple operational actions, a conflict intensity index can be defined. : ; in, This indicates the intensity of the conflict between operational action p and operational action q; Indicates the degree of overlap between targets; Indicates the degree of overlap in propagation paths, used to describe the degree to which two operational actions intersect in the propagation chain; This indicates the degree of overlap in demand for comprehensive risk tokens; , and This represents the weighting coefficients of different factors.

[0061] When the conflict intensity exceeds a preset threshold, the system considers there to be a significant conflict between the two operational actions and requires adjudication. Adjudication can include various methods, such as delaying the execution time of one operational action, reducing the impact intensity of another, or restricting certain target nodes. For example, when two operational actions simultaneously affect the same warehousing and distribution node and may cause warehousing and distribution pressure overload, the system can prioritize the operational action with higher business priority and delay the other operational action.

[0062] During the adjudication process, the system can also make a comprehensive judgment based on the business priority of the operational action, its historical execution success rate, and its reversibility level. For example, for operational actions with a high reversibility level, even if there is some conflict, adjustments can be made after execution through a compensation mechanism, so their adjudication priority can be appropriately increased; while for operational actions with a high irreversibility level, their execution conditions need to be controlled more strictly.

[0063] Through the aforementioned pre-emptive conflict resolution mechanism, the system can identify the potential cumulative effects between multiple operational actions before execution and make unified decisions based on the system's current risk token budget and propagation path relationships. This not only avoids system overload caused by the simultaneous execution of multiple operational strategies but also enables e-commerce platforms to maintain stable business operations in complex environments, thereby improving the reliability and predictability of end-to-end operational control.

[0064] The reversible compensation orchestration module is used to read node status data after the execution of operational actions and generate a sequence of compensation actions based on the compensation template identifier. Preferably, in the reversible compensation orchestration module, the steps for generating the compensation action sequence include: Read the compensation template identifier corresponding to the executed operational action; Read the compensation template data based on the compensation template identifier; Generate a set of compensation actions based on the compensation template data; Compensation priorities are determined based on node risk token data, risk exposure status data, and service quality status data. Sort the set of compensation actions according to their compensation priority; Generate a sequence of compensation actions based on the sorting results.

[0065] Specifically, in the actual operation of e-commerce platforms, certain operational actions may have a delayed impact on the system after execution. For example, after a promotional activity goes live, the number of order requests may increase rapidly in a short period of time, leading to increased processing pressure on warehousing and distribution nodes, increased inquiries at customer service nodes, and even a decrease in fulfillment timeliness. These impacts usually only gradually become apparent after the operational actions have been executed. Therefore, in this embodiment, a reversible compensation orchestration module is set up to dynamically monitor the executed operational actions and generate corresponding compensation action sequences when abnormal node status or abnormal risk token consumption is detected, thereby adjusting the system state.

[0066] The system first reads the compensation template identifier corresponding to the executed operational action. The compensation template identifier is used to mark the type of compensation strategy corresponding to the operational action. For example, for promotional operational actions, the compensation template may include reducing exposure weight, lowering the activity discount ratio, or suspending the activity; for traffic distribution operational actions, the compensation template may include traffic reallocation or restricting high-traffic entry points. By reading the compensation template identifier, the system can quickly match the preset compensation template data.

[0067] Subsequently, a set of compensation actions is generated based on the compensation template data. This set typically includes multiple possible compensation strategies, such as reducing traffic weight, restricting inventory release, delaying fulfillment, or increasing customer service resources. Different compensation actions have varying degrees of impact on system nodes, therefore, they need to be prioritized.

[0068] In this embodiment, a compensation priority parameter is introduced to determine the execution order of the compensation actions. , is used to represent the system stability recovery capability of compensation action k, and its calculation method is as follows: ; in, Indicates the priority value of the compensation action; This indicates the number of risk tokens expected to be released after the compensation action is executed; This indicates the degree to which the compensation action improves the service quality. Indicates the current node's risk exposure status; , and This represents the weighting coefficients of different factors.

[0069] By calculating the priority parameters of each compensation action, the set of compensation actions can be sorted, and a sequence of compensation actions can be generated based on the sorting result. Subsequently, the system executes the compensation actions step by step according to the sequence, and rereads the node status data after each execution to determine whether to continue with subsequent compensation actions. If the node risk token recovers to a safe range or the service quality indicator recovers to a preset threshold, the execution of the compensation sequence can be terminated.

[0070] Through the aforementioned reversible compensation orchestration mechanism, the system's operating status can be dynamically adjusted after operational actions are executed, enabling the operating system to have adaptive repair capabilities. This reduces system instability caused by fluctuations in operational strategies and improves the reliability of e-commerce platform operation and management.

[0071] The root cause reverse location module is used to read the constraint propagation graph when an abnormal node status occurs, and to backtrack the executed operational actions according to the propagation path to determine the root cause action set. Preferably, in the root cause reverse localization module, the steps for determining the root cause action set include: Read the data from the node that encountered the error; Obtain the propagation path pointing to the abnormal node based on the constraint propagation graph; Retrieve executed operational actions within a preset time window; Based on the propagation path, select operational actions that have a propagation relationship with abnormal nodes; A set of candidate operational actions is determined based on risk disturbance data and propagation path data of operational actions; Identify the root cause action set from the candidate operational action set.

[0072] Specifically, in the operational environment of an e-commerce platform, when a node experiences an anomaly—such as a decrease in the processing capacity of a warehousing and distribution node or a significant extension of the response time of a customer service node—it is often not directly caused by a single operational action, but rather the result of the cumulative effect of multiple operational actions. Therefore, in this embodiment, a root cause analysis module is used to trace the source of system anomalies, thereby identifying the key operational actions that led to the node anomalies.

[0073] The system first checks whether node status indicators exceed preset thresholds, such as node risk exposure exceeding a risk threshold or service quality falling below a quality threshold. Upon detecting an abnormal node, the system retrieves all propagation paths pointing to that node from the constraint propagation graph. These propagation paths allow tracing the upstream nodes affecting the node and their corresponding operational actions. Subsequently, the system retrieves all executed operational actions within a preset time window and filters them based on the propagation paths to identify those actions that have a propagation relationship with the abnormal node. For example, when an operational action affects the order node through the product node and ultimately propagates to the warehousing and distribution node, this operational action is considered a candidate action affecting the abnormal node.

[0074] To further determine the impact of each candidate operational action on the abnormal node, the propagation contribution of the operational action to the abnormal node can be calculated. In this embodiment, the propagation contribution... It can be represented as: ; in, This represents the contribution of operational action k to the propagation of abnormal node i; This indicates the propagation weight from the target node of the operational action to the abnormal node; Indicates the intensity of risk disturbances to operational activities; Indicates the propagation path length or propagation delay; This represents the propagation attenuation coefficient.

[0075] By calculating the contribution of each candidate operational action to the propagation of the anomalous node, the influence of each action in the candidate operational action set can be obtained. The system then sorts the candidate operational actions according to their propagation contribution and selects the set of operational actions with the highest contribution as the root cause action set. This root cause action set represents the key operational actions most likely to cause node anomalousness.

[0076] After identifying the root cause action set, the system can pass relevant information to the reversible compensation orchestration module to execute targeted compensation actions. For example, if the operational action in the root cause action set is a promotional activity, the system can prioritize reducing the traffic weight of that activity or suspending the activity to minimize the impact on abnormal nodes.

[0077] Through the aforementioned root cause reverse localization mechanism, the system can quickly identify potential operational root causes after a node anomaly occurs, and make targeted adjustments in conjunction with the compensation mechanism, thereby improving the e-commerce platform's anomaly diagnosis capabilities and system recovery capabilities in complex operating environments.

[0078] The online parameter correction module is used to update the propagation parameters in the constraint propagation graph and the parameters in the action object based on the changes in node status after the execution of operational actions.

[0079] In the online parameter calibration module, the update processing steps include: Read node status data after the execution of operational actions; Read the predicted propagation results obtained based on the constraint propagation graph before the execution of operational actions; Compare node status data with predicted propagation results; Update the propagation weights, propagation delays, channel limits, and anomalous amplification coefficients in the constraint propagation graph based on the comparison results. Update the load injection data and risk disturbance data in the action object according to the node status changes.

[0080] Specifically, in the actual operating environment of e-commerce platforms, the impact of different operational actions on system nodes exhibits significant dynamic characteristics. For example, in the early stages of a promotional campaign, order growth may be relatively slow, while as user attention increases, order growth may accelerate rapidly. Simultaneously, the processing capacity of the warehousing and distribution system may also change over different time periods. Therefore, if the propagation parameters in the constraint propagation graph remain fixed for an extended period, they may not accurately reflect the actual propagation effect of operational actions within the system. To address this issue, this embodiment uses an online parameter correction module to dynamically update the propagation parameters, enabling the propagation model to continuously adapt to changes in the platform's business environment.

[0081] The system first reads node status data after the operational action is executed. Node status data can come from multiple business monitoring systems, such as the number of orders generated in the order system, the number of fulfillment processed in the warehousing and distribution system, the number of inquiries handled in the customer service system, and the proportion of abnormal orders in the risk control system. This data can reflect the actual operating status of each node after the operational action is executed.

[0082] Meanwhile, before an operational action is executed, the system predicts the propagation outcome of that action based on the constraint propagation graph. For example, when calculating the propagation impact range and risk token requirements, the system predicts the potential disturbance a given operational action might cause to each node. This predicted propagation result is typically stored in the form of node disturbance intensity or node load change.

[0083] During online parameter calibration, it is necessary to compare the predicted propagation results with the actual node state data to identify model prediction errors. Let the nodes... The actual disturbance after the execution of the operational action is The perturbation predicted by the model is Then the node disturbance error can be expressed as: ; in, Represents a node The propagation prediction error; Indicates the node after the execution of the operational action. The actual amount of disturbance, such as order growth or system load change; This represents the node perturbation amount predicted based on the constraint propagation graph.

[0084] When error A large value indicates that the current propagation model fails to accurately reflect the actual business propagation situation, and the propagation parameters need to be adjusted. First, update the propagation weight parameters. Propagation Weights Represents a node To the node The influence of the conduction strength can be corrected based on the prediction error. For example: ; in, This indicates the updated propagation weight; Indicates the original propagation weights; This represents the learning coefficient, used to control the magnitude of parameter updates; Represents a node The prediction error; Represents a node The predicted disturbance amount.

[0085] Using the above method, when the actual disturbance of a certain propagation path is higher than the predicted value, the corresponding propagation weight will be increased appropriately; conversely, when the actual disturbance is lower than the predicted value, the propagation weight will be decreased appropriately.

[0086] During the update of the propagation delay parameter, the propagation delay can be adjusted by comparing the difference between the predicted propagation time and the actual propagation time. For example, when the actual propagation delay time is... The predicted propagation delay time is At that time, the propagation delay update can be expressed as: ; in, Indicates the updated propagation delay; Indicates the original propagation time delay; This represents the time-delay update coefficient.

[0087] In addition, regarding the channel upper limit parameter The system can dynamically adjust based on the maximum processing capacity achieved by each node during actual operation. For example, when a warehousing and distribution node is able to handle more orders during a promotional period, its channel limit parameter can be appropriately increased, thereby making the propagation model more consistent with actual business capabilities.

[0088] Regarding the update of the anomaly amplification factor, the system will make adjustments based on the frequency of anomaly nodes and the impact of anomaly propagation paths. When a propagation path is associated with system anomalies multiple times in the historical record, the system can increase the anomaly amplification factor of that path, making subsequent risk assessments more cautious.

[0089] In addition to updating the propagation graph parameters, the system also corrects the parameters in the action objects. For example, if an operational action consistently generates high system load during historical executions, its load injection parameters need to be adjusted. The update of the load injection parameters can be expressed as: ; in, This indicates the updated load injection parameters; Indicates the original load injection parameters; Indicates the update coefficients; This represents the actual change in node load. This indicates the predicted load change.

[0090] Risk disturbance parameters can also be dynamically adjusted based on the frequency of abnormal events. For example, when an operational action triggers node anomalies multiple times during its historical execution, its risk disturbance parameters will be appropriately increased, thereby increasing its risk weight in subsequent risk assessments.

[0091] After updating the propagation parameters and action object parameters, the system rewrites the updated parameters into the constraint propagation graph and action object model, and uses them for risk assessment and conflict resolution in subsequent operational actions. By continuously repeating this online calibration process, the system can gradually improve the prediction accuracy of the propagation model, making the model more closely resemble the real business environment of the e-commerce platform.

[0092] Through the above-mentioned online parameter correction mechanism, the e-commerce platform's operation and management system can acquire self-learning capabilities, continuously correct the propagation model and action impact parameters during long-term operation, thereby improving the accuracy of operational risk assessment and enabling the system to maintain stable operation and efficient decision-making capabilities when facing complex operational scenarios.

[0093] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A full-process operation and control system for e-commerce platforms, characterized in that, include: The business object topology modeling module is used to acquire product objects, store objects, activity objects, traffic entry objects, inventory objects, order objects, warehousing and distribution objects, after-sales objects, customer service objects, merchant fulfillment objects, and risk control objects in the e-commerce platform, and convert the business objects into nodes. Based on the business relationships between the business objects, directed connections are established between the nodes to generate a constraint propagation graph. The operation action vectorization encapsulation module is used to receive operation action data and generate action objects based on the operation action data. The action objects include the target, action type, revenue driver, load injection, risk disturbance, reversibility level, and compensation template identifier. The risk token budget allocation module is used to read the node status data in the constraint propagation graph, generate node risk token budgets based on the node status data, determine the propagation impact range of the operation action based on the action object and the constraint propagation graph, and calculate the risk token requirements corresponding to each node within the propagation impact range of the operation action to generate the comprehensive risk token requirements of the operation action. The pre-conflict adjudication module is used to read the comprehensive risk token requirement, node risk token budget, and target relationships and propagation path relationships between multiple operational actions, and to adjudicate the operational actions based on the target relationships, propagation path relationships, and comprehensive risk token requirement; The reversible compensation orchestration module is used to read node status data after the execution of operational actions and generate a compensation action sequence based on the compensation template identifier; The root cause reverse location module is used to read the constraint propagation graph when an abnormality occurs in the node status, and to backtrack the executed operational actions according to the propagation path to determine the root cause action set. The online parameter correction module is used to update the propagation parameters in the constraint propagation graph and the parameters in the action object based on the node status changes after the operation action is executed.

2. The full-process operation and control system for e-commerce platforms according to claim 1, characterized in that, In the topology modeling module for the business object, the step of generating the constraint propagation graph includes: Acquire product objects, store objects, activity objects, traffic entry objects, inventory objects, order objects, warehousing and distribution objects, after-sales objects, customer service objects, merchant fulfillment objects, and risk control objects from the e-commerce platform; Convert each business entity into a corresponding node; Establish directed connections between nodes based on the business transmission relationships between business entities; For each directed connection, record the propagation weight, propagation delay, channel limit, aberration amplification factor, and compensation priority factor; A constraint propagation graph is generated based on the nodes and the directed connection relationships.

3. The full-process operation and control system for e-commerce platforms according to claim 1, characterized in that, In the operational action vectorization encapsulation module, the step of generating action objects based on the operational action data includes: Receive operational data; Read the set of target nodes corresponding to the operational action; Determine the action type of the operational action; Revenue-driven data is generated based on the business rules of the aforementioned operational actions; Load injection data is generated based on the impact of the operational actions on the target node's business. Risk disturbance data is generated based on the impact of the operational actions on node stability. Reversible level data is generated based on the rollback rules of the aforementioned operational actions; Generate a compensation template identifier based on the compensation rules for the aforementioned operational actions; The action object is formed by combining the target, action type, profit driver, load injection, risk disturbance, reversibility level, and compensation template identifier.

4. The full-process operation and control system for e-commerce platforms according to claim 1, characterized in that, In the risk token budget allocation module, the step of generating a node risk token budget based on the node status data includes: Read the current load status data of each node; Read the remaining capacity data of each node; Read the risk exposure status data of each node; Read the service quality status data of each node; Calculate the node risk token budget based on the current load status data, remaining capacity data, risk exposure status data, and quality of service status data. The node risk token budget is recorded as node available risk token data.

5. The full-process operation and control system for e-commerce platforms according to claim 1, characterized in that, In the risk token budget allocation module, the step of determining the propagation scope of operational actions includes: Read the target data from the action object; The target node is determined in the constraint propagation graph based on the stated objective. The propagation path is searched based on the directed connections between the target node and the constraint propagation graph. Identify the set of nodes from which operational actions can transmit their influence based on the propagation path; The set of nodes is defined as the scope of the propagation and impact of operational actions.

6. The full-process operation and control system for e-commerce platforms according to claim 1, characterized in that, In the risk token budget allocation module, the step of generating the comprehensive risk token requirement for operational actions includes: Read the load injection data and risk disturbance data from the action object; Initial perturbation data for the target node is generated based on the load injection data; The propagation calculation is performed on the initial disturbance data based on the propagation weight, propagation delay, and channel upper limit in the constrained propagation graph. Generate propagation perturbation data corresponding to each propagation node; Based on the propagation disturbance data, generate the risk token requirements for each node; The risk token requirements of each node are aggregated to form the comprehensive risk token requirements for operational actions.

7. The full-process operation and control system for e-commerce platforms according to claim 1, characterized in that, In the aforementioned pre-conflict adjudication module, the steps for adjudicating operational actions include: Read the action objects corresponding to multiple operational actions; Determine the target overlap relationship between operational actions based on the target of each action object; The overlapping relationships of propagation paths between operational actions are determined based on the constraint propagation diagram. Read the comprehensive risk token requirements corresponding to each operational action; Determine whether the overall risk token demand exceeds the node risk token budget of the corresponding node based on the node risk token budget; The operational action decision is generated based on the overlapping relationships of the objectives, the overlapping relationships of the propagation paths, and the comprehensive risk token requirements.

8. The full-process operation and control system for e-commerce platforms according to claim 1, characterized in that, In the reversible compensation orchestration module, the step of generating the compensation action sequence includes: Read the compensation template identifier corresponding to the executed operational action; Read the compensation template data according to the compensation template identifier; Generate a set of compensation actions based on the compensation template data; Compensation priorities are determined based on node risk token data, risk exposure status data, and service quality status data. Sort the set of compensation actions according to their compensation priority; Generate a sequence of compensation actions based on the sorting results.

9. A full-process operation and control system for e-commerce platforms according to claim 1, characterized in that, In the root cause reverse localization module, the step of determining the root cause action set includes: Read the data from the node that encountered the error; The propagation path pointing to the abnormal node is obtained based on the constraint propagation graph; Retrieve executed operational actions within a preset time window; Based on the propagation path, select operational actions that have a propagation relationship with the abnormal nodes; A set of candidate operational actions is determined based on the risk disturbance data and propagation path data of the aforementioned operational actions; The root cause action set is determined from the candidate operational action set.

10. A full-process operation and control system for e-commerce platforms according to claim 1, characterized in that, In the online parameter correction module, the update process includes the following steps: Read node status data after the execution of operational actions; Read the predicted propagation results obtained based on the constraint propagation graph before the execution of operational actions; Compare the node state data with the predicted propagation results; Update the propagation weights, propagation delays, channel limits, and anomalous amplification coefficients in the constraint propagation graph based on the comparison results. Update the load injection data and risk disturbance data in the action object according to the node state changes.

Images