A data processing method, apparatus and electronic device for the insurance industry

Abstract

This application provides a data processing method, apparatus, and electronic device for the insurance industry, relating to the field of data processing. In this method, an indicator graph is constructed to uniformly manage indicators from multiple insurance business systems. An indicator perturbation potential function is established based on historical field fluctuations and real-time update status. Potentially unstable indicator nodes are identified, and inverse dependency inference is performed to generate a set of unstable paths. These paths are then extracted from the original write process and sent to a push channel to generate a pre-written data snapshot. Upon data arrival, a corrective write operation is performed, and the identification threshold and channel resource configuration are dynamically adjusted to ensure the closure of the causal structure and the consistency of the write order. Implementing the technical solution provided in this application facilitates improvements in the stability of data processing in the insurance industry.

Description

Technical Field

[0001] This application relates to the technical field of data processing, specifically to a data processing method, apparatus, and electronic device for the insurance industry. Background Technology

[0002] In the actual operation of the insurance industry, the various indicator systems constructed for premium structure indicators, claims data indicators, policy activity indicators, and customer-related indicators often rely on asynchronous data streams from multiple heterogeneous business systems, including payment systems, policy management systems, claims systems, and customer relationship systems. To support the accurate depiction of complex business behaviors, indicator calculations typically involve highly coupled logical paths across systems, fields, and time windows.

[0003] However, existing data processing mechanisms mostly rely on explicit state characteristics such as data arrival, load balancing, or task backlog to execute scheduling or write-back strategies. They lack systematic modeling and proactive control capabilities regarding the integrity, stability, and future disturbance trends of the causal chains in the indicator graph structure. Especially in scenarios with disordered update sequences of multi-source data, lagging field states, or frequent adjustments to business logic, situations often arise where key indicators fail to be updated in a timely manner, leading to failed triggering of indicator nodes in the entire dependency path, broken causal relationships, or even batch out-of-order writing of indicators. This results in chain-like write-back crashes, severely impacting the stability of data processing in the insurance industry.

[0004] Therefore, there is an urgent need for a data processing method, device, and electronic equipment for the insurance industry. Summary of the Invention

[0005] This application provides a data processing method, apparatus, and electronic device for the insurance industry, which facilitates the improvement of the stability of data processing in the insurance industry.

[0006] The first aspect of this application provides a data processing method for the insurance industry. The method includes: acquiring premium structure indicators, claims data indicators, policy activity indicators, and customer dimension indicators from multiple insurance business systems as indicator nodes; acquiring the field dependencies, indicator calculation logic, and temporal order among the indicators to establish indicator dependency paths, forming an indicator graph; acquiring the field change frequency, update delay characteristics, and dependency strength parameters of the data sources upon which the indicator nodes depend within historical periods, and combining this with the update status of each field in the current data stream to establish an indicator perturbation potential function; and identifying the indicator perturbation potential in the indicator graph. Indicator nodes with a potential function greater than a preset threshold are identified as potential unstable indicator nodes. Inverse dependency inference is performed based on the indicator dependency paths of these potential unstable indicator nodes to construct a set of potential unstable paths. The potential unstable indicator nodes in this set are then removed from the original writing process and incorporated into the potential unstable indicator push channel, generating corresponding pre-written data snapshots. If the actual data required by the potential unstable indicator node is determined to have arrived, a corrective writing process is performed on the pre-written data snapshot. Simultaneously, the identification threshold and channel resource configuration are dynamically adjusted to maintain the causal structure closure of the indicator graph and the consistency of the indicator writing order.

[0007] Optionally, the step of obtaining premium structure indicators, claims data indicators, policy activity indicators, and customer dimension indicators from multiple insurance business systems as indicator nodes, obtaining the field dependencies, calculation logic, and time sequence of the indicators to establish indicator dependency paths, and forming an indicator graph, specifically includes: obtaining the structured definition information of premium structure indicators, claims data indicators, policy activity indicators, and customer dimension indicators from the payment system, policy system, claims system, and customer service system respectively; parsing the original data fields that each indicator depends on based on its calculation formula, and establishing the dependency mapping relationship between indicator nodes and fields; for indicator nodes that have field sharing or formula derivation relationships, constructing the indicator dependency path based on the intersection of field dependency paths; constructing the indicator nodes and the indicator dependency paths into a directional graph structure, and performing a time sequence labeling operation in conjunction with the calculation cycle information of each indicator node to form an indicator graph with field dependency structure and time logic constraints.

[0008] Optionally, the step of obtaining the field change frequency, update delay characteristics, and dependency strength parameters of the data source upon which the indicator node depends in the historical period, and establishing an indicator perturbation potential function in conjunction with the update status of each field in the current data stream, specifically includes: extracting the original data field upon which each indicator node depends; obtaining the field change frequency of the original data field in the historical period, wherein the field change frequency is used to characterize the fluctuation intensity of the field value; obtaining the update delay characteristics of the original data field in the historical period, wherein the update delay characteristics include the mean, maximum, and standard deviation of the time interval from field generation to data entry, wherein the update delay characteristics are used to characterize the timeliness uncertainty of field updates; calculating the dependency strength parameters between the original data field and the indicator node; and, in conjunction with the real-time update status of each of the original data fields in the current data stream, constructing a nonlinear weighted model based on the field change frequency, the update delay characteristics, and the dependency strength parameters to generate an indicator perturbation potential function characterizing the local structural instability of the indicator node.

[0009] Optionally, the step of identifying index nodes in the index graph whose index perturbation potential function is greater than a preset threshold as potential unstable index nodes, and performing inverse dependency deduction based on the index dependency path where the potential unstable index node is located to construct a set of potential unstable paths, specifically includes: traversing the index nodes in the index graph, obtaining the index perturbation potential function value corresponding to each index node, and identifying index nodes with values ​​greater than the preset threshold as potential unstable index nodes; taking each potential unstable index node as a starting point, performing inverse dependency deduction upwards along the index dependency path in the index graph, recursively tracing the upstream index nodes that the potential unstable index node depends on, recording the formed dependency paths and forming a path set; summarizing the path set to obtain the set of potential unstable paths, which is used to characterize the index dependency structure region where structural cascade instability is caused by the abnormality of the index perturbation potential function.

[0010] Optionally, the step of stripping the potential instability indicator nodes in the potential instability path set from the original write process and assigning them to the potential instability indicator push channel to generate corresponding pre-write data snapshots specifically includes: identifying each potential instability indicator node in the potential instability path set, determining whether each potential instability indicator node is in a regular write process triggered by data arrival; if it is in the regular write process, then stripping the potential instability indicator node from the regular write process and deregistering the status record of the potential instability indicator node in the regular scheduling queue; allocating the potential instability indicator push channel to each stripped potential instability indicator node, and establishing a scheduling context corresponding to the potential instability indicator push channel in the scheduling control structure; generating the pre-write data snapshot based on the indicator dependency path, the arrived original data fields, and the indicator calculation logic corresponding to each potential instability indicator node in the indicator graph, wherein the pre-write data snapshot includes the fill value of the currently available fields, the indicator calculation logic path identifier, and the indicator node structure status information; writing the pre-write data snapshot into the indicator cache structure, and marking the pre-write data snapshot as being in a future mapping pending correction state.

[0011] Optionally, if the actual data required for the potential unstable indicator node is determined to have arrived, a correction write is performed on the pre-written data snapshot, and the identification threshold and channel resource configuration are dynamically adjusted. Specifically, this includes: monitoring the arrival status of the original data field corresponding to the potential unstable indicator node in the current scheduling period; if the original data field has arrived and the field value is valid, the potential unstable indicator node is marked as correctable; calling the indicator calculation logic corresponding to the potential unstable indicator node in the indicator graph to perform structural consistency verification and numerical correction operations on the pre-written data snapshot stored in the indicator cache structure to generate the corrected indicator result; writing the corrected indicator result into the indicator storage structure and updating the writing status of the potential unstable indicator node in the indicator graph to "structure closure completed"; dynamically adjusting the identification threshold of the potential unstable indicator node according to the changing trend of the disturbance potential function in the continuous scheduling period, and dynamically adjusting the scheduling concurrency, cache capacity, and priority weight of the potential unstable indicator push channel according to the number of potential unstable indicator nodes and the degree of disturbance concentration.

[0012] Optionally, after the indicator graph is constructed, the calculation cycle of each indicator node is standardized; the daily calculation cycle, weekly calculation cycle, monthly calculation cycle and quarterly calculation cycle are mapped to a unified time dimension benchmark; the time sequence of each indicator node in the indicator dependency path is marked based on the time dimension benchmark to ensure the time consistency of the causal path in the indicator graph and the coordination of the calculation scheduling cycle.

[0013] A second aspect of this application provides a data processing apparatus for the insurance industry. The apparatus includes an acquisition module and a processing module. The acquisition module is used to acquire premium structure indicators, claims data indicators, policy activity indicators, and customer dimension indicators from multiple insurance business systems as indicator nodes. It acquires the field dependencies, calculation logic, and temporal order between the indicators to establish indicator dependency paths, forming an indicator graph. The acquisition module is also used to acquire the field change frequency, update delay characteristics, and dependency strength parameters of the data sources upon which the indicator nodes depend within historical periods, and, combined with the update status of each field in the current data stream, establish an indicator perturbation potential function. The processing module is used to process the indicator graph... The processing module identifies indicator nodes whose perturbation potential function is greater than a preset threshold as potential unstable indicator nodes, and performs inverse dependency inference based on the indicator dependency path where the potential unstable indicator node is located to construct a set of potential unstable paths. The processing module is also used to separate the potential unstable indicator nodes in the set of potential unstable paths from the original writing process and assign them to the potential unstable indicator push channel to generate corresponding pre-written data snapshots. The processing module is also used to perform corrective writing on the pre-written data snapshots if it is determined that the actual data required for the potential unstable indicator node has arrived, and dynamically adjust the identification threshold and channel resource configuration to maintain the causal structure closure of the indicator graph and the consistency of the indicator writing order.

[0014] A third aspect of this application provides an electronic device including a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, and both the user interface and the network interface are used to communicate with other devices. The processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method described above.

[0015] A fourth aspect of this application provides a computer-readable storage medium storing instructions that, when executed, perform the method described above.

[0016] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages:

[0017] 1. An indicator graph structure is introduced to accommodate field dependencies and temporal logic between highly coupled indicators; a perturbation potential function is constructed to achieve a forward-looking assessment of future structural stability; potential instability paths are identified through inverse dependency deduction and indicators are pushed in advance, breaking the traditional scheduling paradigm; pre-writing, future mapping, and structural closure maintenance are achieved in the case of data not yet arriving. Therefore, this facilitates the improvement of the stability of data processing in the insurance industry.

[0018] 2. The dimensions of the perturbation potential function include field volatility, update delay and dependency strength. The nonlinear weighted modeling mechanism helps to highlight the accuracy and predictive power of the perturbation quantification model and enhance the effectiveness of identifying the risk of indicator instability. Attached Figure Description

[0019] Figure 1 A flowchart illustrating an insurance industry data processing method provided in this application embodiment;

[0020] Figure 2 A schematic diagram of a data processing device for the insurance industry provided in this application embodiment;

[0021] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0022] Explanation of reference numerals in the attached figures: 21. Acquisition module; 22. Processing module; 31. Processor; 32. Communication bus; 33. User interface; 34. Network interface; 35. Memory. Detailed Implementation

[0023] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0024] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0025] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0026] To address the aforementioned technical problems, this application provides a data processing method for the insurance industry, referring to... Figure 1 , Figure 1 This is a flowchart illustrating a data processing method for the insurance industry provided in an embodiment of this application. The method is applied to a server and includes steps S110 to S150, as follows:

[0027] S110. Obtain premium structure indicators, claims data indicators, policy activity indicators, and customer dimension indicators from multiple insurance business systems as indicator nodes. Obtain the field dependencies between indicators, indicator calculation logic, and time sequence to establish indicator dependency paths and form an indicator graph.

[0028] Specifically, a server refers to a data processing node or scheduling engine that undertakes the task of constructing the indicator graph. It is typically deployed in a distributed data platform or cloud computing environment and possesses the ability to access multiple business systems, parse data structures, and construct logical relationships. In this scenario, the server is responsible for obtaining indicator structure definitions and related dependency information from various insurance business systems and completing the indicator graph construction. Multiple insurance business systems refer to the collection of data systems that constitute the core business processes of an insurance company. Typical examples include: a payment and collection system (recording premium collection and claims payment data); a policy management system (managing policy issuance, cancellation, renewal, etc.); a claims processing system (recording various claims cases and their progress); and a customer service system (recording customer basic information, contact information, and interaction behavior). Each of these systems generates asynchronous, structured, or semi-structured data sets, which are cross-referenced at the indicator layer.

[0029] Premium structure indicators are descriptive statistical indicators built upon premium income, used to reflect the premium composition characteristics of different products, channels, or policy types. Examples include: the percentage of annual premiums paid by channel; the ratio of first-year premiums to renewal premiums; and monthly premium income categorized by insurance type. Claims data indicators are dynamic indicators built with claims amount, number of claims, or claims cycle as core variables, reflecting the time evolution characteristics of claims business. Examples include: monthly claims amount for the past 12 months; average claims cycle; and average payout ratio for critical illness insurance. Policy activity indicators are indicators built upon behavioral events such as policy status changes, payment frequency, and policy maintenance actions, used to measure the frequency of policy use and its lifespan. Examples include: frequency of policy status changes within a quarter; average payment interval; and the percentage of active policies. Customer dimension indicators are statistical indicators built based on customer attributes and behavior, used to identify customer group characteristics and operational risks. Examples include: the number of policies held by customers in different age groups; customer contact success rate; and customer churn warning score.

[0030] Indicator nodes refer to structural nodes built in an indicator graph, each with its own independently defined indicator. Each indicator node corresponds to a specific set of calculation logic, a set of dependent fields, and a set of time attributes, serving as the basic unit of the graph. For example, "Monthly Channel Premium Growth Rate" is an indicator node. Its calculation logic is the difference between this month's channel premium and last month's premium divided by last month's premium. Dependent fields include premium amount, payment date, and channel code. Field dependencies refer to the mapping relationship between the raw data fields required by an indicator node during its calculation process and its data source fields. This relationship determines which underlying data the indicator node depends on, thus establishing the connection path between nodes. For example, if the "loss ratio" indicator depends on the fields "claims amount" and "effective premium," and the "claims amount" field is provided by the claims system, while the "effective premium" field is provided by the payment system, then this indicator node forms a field dependency relationship with these two fields. Indicator calculation logic refers to the specific calculation formula, aggregation method, and dimensional constraints that each indicator node needs to execute during its generation. For example, the calculation logic for the "average monthly payment amount per customer" indicator is as follows: for a specific customer, sum all payment records within the month and divide by the monthly time span. The calculation logic defines the processing rules for the indicator nodes, determining their data aggregation methods and processing conditions.

[0031] The temporal order refers to the order in which the calculations of various indicator nodes depend on each other over time, reflecting the periodic sequential relationship in the calculation scheduling. For example, "monthly loss ratio" depends on "monthly loss amount" and "monthly effective premium," while "quarterly loss data" depends on the "monthly loss ratio" for three consecutive months, thus exhibiting a temporal dependency. Indicator dependency path refers to the path structure formed between indicator nodes due to field sharing, computational logic referencing, or temporal convergence relationships, used to characterize the complete chain of dependencies required for the generation of a certain indicator. For example, the "quarterly customer renewal premium growth rate" node depends on the "monthly customer renewal premium" node, which in turn depends on the "policy renewal amount" field, thus forming a dependency path from the field layer to the indicator layer. Indicator graph refers to a graph structure with causal relationships, directionality, and temporal logic formed by multiple indicator nodes interconnected through indicator dependency paths, used to express the structural coupling relationship of the indicator system in insurance business. This graph supports path tracing, stability analysis, and push scheduling, serving as the structural foundation for subsequent disturbance identification and indicator write-back scheduling.

[0032] For example, when constructing a graph of "quarterly loss ratio trend", the server extracts the "claims amount" field from the claims system and the "effective premium" field from the payment system. It uses "loss ratio" as an indicator node, indicating that its calculation logic is the claim amount divided by the effective premium. Then, it aggregates the "monthly loss ratio" nodes in chronological order to form the "quarterly loss ratio" node and establishes a path connection in the graph. If a "customer risk score" node is then constructed, and its calculation logic references the "quarterly loss ratio" and the "customer age group dimension indicator", then this node forms a multi-layered nested dependency path with all the aforementioned indicator nodes, and the whole is incorporated into the indicator graph structure.

[0033] Through the above definitions and examples, this paragraph describes a data structure centered on indicator graphs, which constructs a structured indicator system with field dependencies, calculation logic, and time sequence in the multi-source data environment of the insurance industry.

[0034] In one possible implementation, premium structure indicators, claims data indicators, policy activity indicators, and customer dimension indicators from multiple insurance business systems are obtained as indicator nodes. Field dependencies, calculation logic, and temporal order among these indicators are then identified to establish indicator dependency paths, forming an indicator graph. Specifically, this involves: obtaining structured definitions of premium structure indicators, claims data indicators, policy activity indicators, and customer dimension indicators from the payment system, policy system, claims system, and customer service system, respectively; parsing the raw data fields that each indicator depends on based on its calculation formula; establishing dependency mapping relationships between indicator nodes and fields; constructing indicator dependency paths based on the intersection of field dependency paths for indicator nodes with shared fields or formula derivation relationships; and constructing a directional graph structure from the indicator nodes and their dependency paths. Finally, combining the calculation cycle information of each indicator node, a time-sequence labeling operation is performed to form an indicator graph with field dependency structure and temporal logic constraints.

[0035] Specifically, the structured definition information of various indicators is first extracted from the payment system, policy system, claims system, and customer service system. Premium structure indicators, claims data indicators, policy activity indicators, and customer-related indicators are extracted as indicator nodes. Each indicator node corresponds to a structured definition unit, which includes the indicator's calculation formula, calculation period, list of dependent fields, and data domain identifier. For example, for the premium structure indicator "year-on-year growth rate of renewal premiums," its structured definition information includes: the calculation formula is "the difference between the current period's renewal premium and the renewal premium of the same period in the same period divided by the renewal premium of the same period in the same period," the calculation period is monthly, the dependent fields include "renewal premium amount" and "policy payment date," and the data domain identifier is "payment system."

[0036] Secondly, for each indicator node, the calculation formula recorded in its structured definition unit is parsed to determine the set of original data fields that the indicator node depends on. A one-to-one mapping relationship between the indicator node and the original data fields is established, forming an indicator field dependency mapping structure. This dependency mapping relationship can be represented as:

[0037]

[0038] in, Indicator nodes The set of fields that it depends on This represents the various raw data fields of the indicator, such as "renewal premium amount," "payment timestamp," and "currency." This structure is used to support subsequent cross-analysis of fields between indicator nodes.

[0039] Subsequently, the field dependencies between multiple indicator nodes are cross-checked. If two or more indicator nodes depend on the same original data field, or if the calculation formula of one indicator node references the output result of another indicator node, then a field sharing or formula derivation relationship is determined to exist between them. Based on this, the system connects these dependency paths between indicator nodes according to the intersection of field sharing, constructing an indicator dependency path set. Let the indicator nodes... With indicator nodes Dependency on field collections and If the following conditions are met:

[0040]

[0041] Or it may exist:

[0042]

[0043] Then establish from the indicator node Pointing to indicator nodes The metric depends on the path, indicating The generation depends on The calculation result or field content.

[0044] After constructing the metric dependency paths, all metric nodes and their dependency paths are organized into a directional graph structure, namely the metric graph. In this graph, nodes are metric nodes, edges are metric dependency paths, and directions indicate the flow of dependency. Each edge in the graph structure points from a dependent node to a dependent node, forming a directed graph with logical structure and direction. ,in For the set of all indicator nodes, This is the set of paths that all metrics depend on.

[0045] Finally, combining the calculation cycle information of each indicator node, the system performs a time-sequence labeling operation on the indicator graph, that is, positioning each node relative to the time axis according to its minimum calculation cycle. For example, the calculation cycle of the "Monthly Payout Rate" node is 30 days, while the calculation cycle of the "Quarterly Payout Data" node is 90 days. Therefore, the system marks "Monthly Payout Rate" as a preceding node on the time axis, with the latter serving as a dependent node for aggregation. This time-sequence labeling mechanism maintains the causal logic consistency of all indicator nodes in the indicator graph, ensuring that time reversal or path misalignment does not occur during subsequent scheduling and push operations, thus forming an indicator graph with field dependency structure and time logic constraints.

[0046] S120. Obtain the frequency of field changes, update delay characteristics, and dependency strength parameters of the data source on which the indicator node depends within the historical period, and establish the indicator perturbation potential function in combination with the update status of each field in the current data stream.

[0047] Specifically, the historical period refers to the time period selected for statistical modeling and status assessment, typically 30 days, 90 days, 180 days, or other whole-cycle units, used to quantify field fluctuation behavior and system update characteristics. For example, when analyzing the "monthly loss ratio" indicator, the system might select claims and premium data from the past 12 months as the historical period to extract the fluctuation and latency patterns of the fields on which the indicator depends. The data source refers to the business system or database table structure to which the original fields on which the indicator nodes depend belong. Common data sources in the insurance industry include payment record tables in payment systems, policy status tables in policy systems, and case registration tables in claims systems.

[0048] Field change frequency refers to the number of times a raw data field changes its value within a historical period, used to measure the field's volatility and input instability. The frequency of field changes affects the continuity and consistency of indicator calculations. For example, if the "compensation amount" field is updated three times a day, while the "customer tag level" field is updated once a week, the former has a higher change frequency and is more sensitive. Update latency characteristics refer to the time delay experienced by a raw data field from the occurrence of a real business event to its recording in the database, used to characterize the field's timeliness reliability. Update latency characteristics include: average update latency: the average time lag for the field to be recorded in the database across multiple events; maximum update latency: the latest time lag that has occurred; and update latency standard deviation: used to measure update volatility. For example, in a claims system, the "compensation settlement date" field may experience significant delays due to manual processing, while the "compensation amount" field is usually generated earlier, showing a clear difference in their latency characteristics.

[0049] The dependency strength parameter refers to the degree to which the original data field affects the calculation result of a certain indicator node, reflecting whether changes in this field will significantly alter the indicator output. The dependency strength parameter can be obtained through sensitivity analysis or structural regression modeling. If an indicator is highly dependent on the "payment amount" field but insensitive to the "payment method" field, then the former has a high dependency strength. For example, in the indicator "annual payment growth rate," changes in the payment amount directly affect the indicator output, and its dependency strength is much higher than that of payment channels or payment frequency. The update status of each field in the current data stream refers to information such as whether the original data field has been updated, whether the updated value is valid, and whether there is a sudden change trend within the current scheduling period, used to dynamically assess the real-time availability of the field. For example, if the "policy status" field is covered multiple times in the current period, it indicates that the field is experiencing a period of instability, which will affect the accuracy of indicators that depend on this field. The indicator perturbation potential function refers to a function expression constructed by modeling factors such as the frequency of field changes, update delay characteristics, and dependency strength parameters as function variables to characterize the risk of calculation failure or path misordering of a certain indicator node within a future time window due to input anomalies, time delay fluctuations, or structural instability. Its essence is a comprehensive index of stability quantification, used to identify potential unstable nodes in the graph.

[0050] For example, when assessing the disturbance potential of the "Monthly Customer Renewal Rate" indicator node, the server will analyze the historical data of its dependent fields: "Policy Renewal Status," "Customer Payment Time," and "Renewal Amount." If, within the past 90 days, the "Policy Renewal Status" field has changed daily with high fluctuation frequency and an average 3-day delay in data entry, and this field is a decision branch variable in the indicator formula with high dependency strength; and if, in the current period, this field has not been updated for two consecutive days, triggering a field inconsistency state, then the system will input the above factors into the disturbance potential function. The result indicates that this indicator node is in a high-disturbance-risk state and requires subsequent pre-push mechanisms to maintain structural closure.

[0051] Therefore, the above content is based on the historical statistics and real-time updates of the original fields to establish a quantitative prediction model for future uncertainties and instability trends at the indicator level, forming the core input quantities in the indicator map for scheduling, ranking, and structural intervention.

[0052] In one possible implementation, the frequency of field changes, update delay characteristics, and dependency strength parameters of the data source upon which the indicator node depends in the historical period are obtained. Combined with the update status of each field in the current data stream, an indicator perturbation potential function is established. Specifically, this includes: extracting the original data field upon which each indicator node depends; obtaining the frequency of field changes in the original data field in the historical period, where the frequency of changes characterizes the volatility of the field value; obtaining the update delay characteristics of the original data field in the historical period, including the mean, maximum, and standard deviation of the time interval from field generation to data entry, where the update delay characteristics characterize the timeliness uncertainty of field updates; calculating the dependency strength parameters between the original data field and the indicator node; and constructing a nonlinear weighted model based on the field change frequency, update delay characteristics, and dependency strength parameters, combined with the real-time update status of each original data field in the current data stream, to generate an indicator perturbation potential function characterizing the local structural instability of the indicator node.

[0053] Specifically, the server first iterates through each indicator node in the indicator graph, extracting all the original data fields recorded in the structured definition of that indicator node to form a set of field dependencies. Taking the "quarterly loss ratio fluctuation" indicator node as an example, its original data fields include "claims amount", "premium amount", "claims confirmation time", "policy status code", etc. The server uses these original data fields as the basis for modeling input and retrieves all records within a selected historical period (such as the past 90 days).

[0054] Subsequently, the frequency of field changes is calculated for each original data field to measure the degree of fluctuation in the field value over a historical period. The server sorts the historical values ​​of each field by time series and counts the number of times its value has changed. The frequency of field changes is defined as:

[0055]

[0056] in, Represents the original data field Frequency of changes within historical cycles Indicates the total length of the time series. Representation field At the point of time The value, This is a logical judgment function; if the values ​​before and after are not equal, it returns 1, indicating a fluctuation. The higher the frequency of field changes, the more susceptible the corresponding indicator node is to input disturbances.

[0057] Next, the server statistically analyzes the update latency characteristics of the raw data fields to characterize the timeliness and uncertainty of the fields in the data chain. The update latency of each raw data field is defined as the interval from the time the business event occurs (the time the field is generated) to the time it is written to the database. The latency characteristics include the following three statistics:

[0058]

[0059] in, For fields The set of all historical delay values, For average delay, The standard deviation of the delay. The maximum latency is determined by the combination of these three factors, which constitute the update latency feature of the field and are used to quantify the stability and lag of the field's data entry.

[0060] Next, the dependency strength parameter between each original data field and its corresponding indicator node is calculated, representing the degree of impact of changes in that field on the indicator value. This parameter is obtained through sensitivity analysis modeling of historical data and is defined as follows:

[0061]

[0062] in, Representation field For indicator nodes The sensitivity of the index is equivalent to the partial derivative of the index value with respect to that field, reflecting the magnitude of change in the index output caused by a unit disturbance in the field. If the field As a multiplication weight term or factor affecting the denominator of the calculation, its dependence strength is generally high.

[0063] Based on the aforementioned static features, the server further obtains the update status of each field within the current scheduling period, including whether it has been updated, whether the update was successful, and whether the field value is stable, and constructs a dynamic state vector. Defined as:

[0064]

[0065] in, Representation field Whether there is a new value in the current period, the value can be 0 or 1; This indicates whether the field value has changed abruptly compared to the previous period within the current period, and can be either 0 or 1. This state vector is used to dynamically adjust the perturbation assessment results.

[0066] Ultimately, the server will determine the frequency of field changes. Update delay features Dependency strength parameter With the current data stream state vector A nonlinear weighted model is jointly input to generate an index perturbation potential function. This function is used to assess the risk level of structural instability of a given index node within the current scheduling period and future time windows, and is defined as follows:

[0067]

[0068] in, Indicator Node The value of the perturbation potential function; For fields Weights in the indicator formula; This is an empirical adjustment coefficient used to balance the effects of volatility, lag, and dependence strength. This is a dynamic adjustment factor that applies sensitive weighting to the current periodic state. The larger the function value, the higher the risk of input disturbance to the current indicator node, and it should be prioritized in the pre-scheduling process.

[0069] Through the above steps, the system can comprehensively quantify the potential future instability of indicator nodes and identify indicator regions that may experience structural cascading instability at the graph level, providing accurate input for subsequent push channel allocation and structural closure control.

[0070] S130. Identify indicator nodes in the indicator graph whose indicator perturbation potential function is greater than a preset threshold as potential unstable indicator nodes, and perform reverse dependency inference based on the indicator dependency path where the potential unstable indicator node is located to construct a set of potential unstable paths.

[0071] Specifically, the preset threshold refers to the risk tolerance boundary determined by the system through experience or historical training. It is used to determine whether the perturbation potential function of a certain indicator has reached the instability critical value. If the function value exceeds the threshold, it indicates that the current structural state may trigger indicator calculation failure, result misalignment, or path breakage in future cycles. For example, if the system sets the threshold to 0.65, and the calculated perturbation potential function value of a certain indicator node is 0.78, then that node is marked as a potential instability indicator node.

[0072] Potentially unstable indicator nodes refer to those identified as having high structural risks in the current scheduling cycle based on the evaluation results of the indicator perturbation potential function. These nodes may fail to complete normal calculations due to unreachable upstream fields, incomplete dependency paths, or disordered temporal logic, and are instability triggers in the graph structure. For example, the "Monthly High Payout Alert Index" node depends on input fields from multiple systems. If any of these fields are not updated in a timely manner, the indicator will fail, and because its perturbation potential function remains consistently above the threshold, it will be identified as a potentially unstable indicator node.

[0073] A dependency path refers to the path structure that constitutes the relationships between nodes in a metric graph. Each dependency path consists of a starting metric node, an ending metric node, and logical connections along the path. The path direction expresses the dependency flow, and the path structure reflects the calculation process, field references, and temporal aggregation relationships. For example, if the metric node "Customer Activity Score" depends on "Monthly Login Count," which in turn depends on the "Login Event" field in the "Interaction Record Table," then the path is: Login Event → Monthly Login Count → Customer Activity Score. Reverse dependency deduction refers to starting with a potentially unstable metric node and recursively tracing all its upstream metric nodes along the dependency path to identify which node changes might be the source of the current node's instability, thereby restoring the complete dependency chain of that node in the graph. Reverse deduction not only includes path traversal operations but also requires recording the path structure for subsequent structural intervention operations. For example, after identifying the "quarterly risk score" node as a potential unstable indicator node, the system deduces upwards along its path and finds that it depends on two intermediate indicator nodes: "monthly payout rate" and "customer contact success rate". The "customer contact success rate" in turn depends on "contact record update time", ultimately forming a complete set of reverse paths.

[0074] The potential instability path set refers to the set of paths formed by performing inverse dependency deduction on all potential instability indicator nodes. It characterizes path regions in the indicator graph that have logically transmissive instability risks during the current scheduling cycle. The paths covered by this set are the key targets for subsequent scheduling, pushing, and structural correction. For example, if three potential instability indicator nodes involve the claims indicator chain, customer indicator chain, and policy status chain respectively, inverse dependency deduction yields nine paths, forming a potential instability path set. This set is used to identify high-risk structural regions that require pre-scheduling.

[0075] In summary, the server dynamically identifies high-risk indicator nodes in the indicator graph based on the indicator perturbation potential function. Starting from these nodes, it performs reverse recursive tracing of indicator dependency paths to construct a set of path structures from the source of high perturbation to each root cause of instability. This supports subsequent scheduling priority reordering and structural stability repair, and is the logical entry point and key identification process of the entire perturbation control mechanism.

[0076] In one possible implementation, index nodes in the index graph whose index perturbation potential function is greater than a preset threshold are identified as potential unstable index nodes. Inverse dependency deduction is then performed based on the index dependency paths of these potential unstable index nodes to construct a set of potential unstable paths. Specifically, this includes: traversing the index nodes in the index graph, obtaining the index perturbation potential function value corresponding to each index node, and identifying index nodes with values ​​greater than the preset threshold as potential unstable index nodes; starting from each potential unstable index node, performing inverse dependency deduction upwards along the index dependency paths in the index graph, recursively tracing the upstream index nodes that the potential unstable index nodes depend on, recording the formed dependency paths, and constructing a path set; summarizing the path sets to obtain a set of potential unstable paths. This set of potential unstable paths is used to characterize the index-dependent structural regions where structural cascading instability is caused by abnormal index perturbation potential functions.

[0077] Specifically, the server first performs a traversal operation on all indicator nodes in the indicator graph, retrieving the indicator perturbation potential function value for each indicator node within the current scheduling period. This indicator perturbation potential function is a nonlinear comprehensive function constructed based on field change frequency, field update delay characteristics, the dependency strength parameter between the field and the indicator, and the current field update state. A higher value indicates a greater risk of instability for the indicator node in the current structure. The server compares the perturbation potential function value extracted for each indicator node during the traversal with a system preset threshold. If the perturbation potential function value corresponding to a certain indicator node satisfies:

[0078]

[0079] Then the indicator node Nodes marked as potential instability indicators, among which Indicator nodes The value of the perturbation potential function. The global threshold used for structural stability assessment.

[0080] Subsequently, starting with each identified potentially unstable indicator node, the server performs a reverse dependency inference operation within the indicator graph based on its established indicator dependency paths. This involves recursively tracing upstream indicator nodes along the dependency path, starting from the current indicator node. This tracing process proceeds in the reverse direction of the directed edges in the graph structure. Each upstream indicator node in the path exerts a conductive influence on the current potentially unstable indicator node through field dependencies or formula calls. For each potentially unstable indicator node… The following path deduction logic will be executed:

[0081]

[0082] in Indicates from potential instability indicator nodes A complete dependency path is obtained by tracing upwards, with each node in the path... satisfy And there are directed edges. ,in This represents the set of indicator nodes in the graph. This represents the set of paths that the metric depends on.

[0083] During the path deduction process, the server records each successfully established dependency path and aggregates all paths into a set of paths:

[0084]

[0085] in, This represents the set of upstream dependency paths corresponding to all potentially unstable indicator nodes. This represents the total number of potentially unstable indicator nodes identified during the current scheduling cycle.

[0086] Finally, the server performs structural merging and path consolidation operations on this path set, eliminating overlapping segments and unifying them into a set of potentially unstable paths. This set of potentially unstable paths constitutes the most vulnerable highly coupled dependency segment in the current indicator graph, representing a cascading instability region that may be triggered by abnormally high values ​​of the perturbation potential function of multiple indicator nodes. This set will provide crucial input in subsequent scheduling priority adjustments, push channel reconstruction, and indicator write control mechanisms, serving as the foundation for the path-level data structure supporting feedforward stability maintenance.

[0087] S140. Remove the potential instability indicator nodes from the original write process in the potential instability path set and assign them to the potential instability indicator push channel to generate the corresponding pre-write data snapshot.

[0088] Specifically, the original write process refers to the standard write-back process followed by indicator nodes under normal conditions. This process typically triggers writes based on data arrival status, the readiness flags of dependent fields, and computation completion flags. In this process, all indicator nodes are written to the database or indicator cache sequentially according to the time-series path in the graph, ensuring strict order control and data integrity. Stripping refers to removing a potentially unstable indicator node from its original write process, preventing it from participating in passive scheduling writes based on data readiness status. Instead, it is transferred to an independently controlled push mechanism, avoiding cascading failures in the graph path structure caused by data not arriving, logical mismatches, or time-series imbalances. Potentially unstable indicator push channel: This is an independent scheduling channel specifically designed to handle potentially unstable indicator nodes. This channel bypasses the original state-based write-back triggering mechanism and uses a perturbation priority-driven scheduling method. Its design goal is to pre-occupy the scheduling window, ensuring the causal closure and path integrity of the indicator graph structure. The push channel has higher resource priority, caching capabilities, and a write-ahead protection mechanism.

[0089] A pre-write data snapshot refers to an intermediate state of indicator result storage generated based on ready fields and structural paths when a potentially unstable indicator node has not yet met the conditions for complete writing (such as missing data fields or incomplete dependency paths). This snapshot is used for placeholder pre-writing, waiting for subsequent data to arrive before structural completion and result correction. It is an important intermediate object for breakpoint compensation mechanisms and push channel write-back closure. The pre-write data snapshot includes the following: the populated values ​​of currently available fields; the calculation formula identifier of the indicator node; the structural placeholder markers of unready fields; the structural hash of the current indicator dependency path; and a logical label indicating "future mapping pending correction state".

[0090] For example, during a certain scheduling cycle, the server identifies the "Customer-Dimensional Claims Frequency Index" as a potentially unstable indicator node because its dependent field, "Claims Occurrence Date," experiences continuous delays, resulting in a perturbation potential function value exceeding a threshold. The server removes this node from the conventional "data ready → calculation → write-back" write process and assigns it to the potential unstable indicator push channel. Since some of its fields have not yet been updated, the system constructs a pre-write data snapshot based on currently available fields such as "Customer Number," "Policy Number," and some time-series information. This snapshot is written to the indicator cache structure and marked as "pending correction," awaiting subsequent field data completion before logical closure and formal write operations.

[0091] In summary, after identifying the risk of structural instability in the graph, the server proactively transfers high-risk indicator nodes to independent channels under the structural defense mechanism and performs partial write snapshot generation to ensure the overall path continuity and causal closure of the indicator graph, thereby avoiding structural transmission failure and result cascading disorder.

[0092] In one possible implementation, potential unstable indicator nodes in the potential unstable path set are stripped from the original write process and assigned to a potential unstable indicator push channel, generating corresponding pre-write data snapshots. Specifically, this includes: identifying each potential unstable indicator node in the potential unstable path set; determining whether each potential unstable indicator node is in a regular write process triggered by data arrival; if in a regular write process, stripping the potential unstable indicator node from the regular write process and deregistering its status record in the regular scheduling queue; allocating a potential unstable indicator push channel to each stripped potential unstable indicator node and establishing a scheduling context corresponding to the potential unstable indicator push channel in the scheduling control structure; generating a pre-write data snapshot based on the indicator dependency path, arrived original data fields, and indicator calculation logic corresponding to each potential unstable indicator node in the indicator graph, the pre-write data snapshot including the currently available field fill values, indicator calculation logic path identifiers, and indicator node structure status information; writing the pre-write data snapshot to the indicator cache structure and marking it as being in a future mapping pending correction state.

[0093] Specifically, the server first traverses the set of potential instability paths obtained from the preceding deduction, identifying each potential instability indicator node contained in the path set. Based on the unique identifier of each node in the indicator graph, the server checks the current scheduling status of each potential instability indicator node and determines whether it is still in a regular write process triggered by data arrival. The judgment criteria are: whether the indicator node is already attached to the data-ready-driven scheduling queue, and whether it is under a standard scheduling path that waits for all dependent fields to be complete before triggering the write operation.

[0094] If a potentially unstable indicator node is determined to be still in the regular write process, the server immediately removes it from the process. The specific operations include: canceling the ready flag of the indicator node in the scheduler controller, canceling its queuing position in the current periodic scheduling task table, and releasing its original write-back lock resources, thereby removing the node from the data arrival-driven write process.

[0095] Next, the server allocates an independent potential instability indicator push channel to each stripped potential instability indicator node. The push channel is a reserved channel resource within the scheduling control structure, possessing high priority, feedforward triggering, and structural closure control capabilities. Simultaneously with channel allocation, the server creates a dedicated scheduling context for that indicator node within the scheduling control structure. This scheduling context records the following: indicator node number, indicator dependency path hash, currently reached field set, missing field list, path depth, and upstream state mapping structure.

[0096] After the push channel is configured, the server generates a pre-write data snapshot based on the metric dependency path structure corresponding to the potentially unstable metric node in the metric graph, combined with the currently arrived data fields and the calculation formula of the metric node. This pre-write data snapshot consists of the following three main components: the populated values ​​of currently available fields: refers to the set of field data that has been successfully pulled from the data source and cleaned and standardized within the current scheduling period.

[0097] Indicator calculation logic path identifier: This refers to the formula structure upon which the indicator node calculation depends and its upstream node dependency path, represented by a hash structure, denoted as:

[0098]

[0099] in Indicator Node The computational logical expression, This is its dependency path in the graph.

[0100] Indicator node structure state information: Records the current computational state of the indicator node in the graph structure, including the status of dependent fields, the readiness flag of upstream indicators, and the timing closure status, defined as a state tuple:

[0101]

[0102] in, For fields Available status, upstream indicator nodes The completion marker, This is the current timestamp.

[0103] The server writes the completed pre-write data snapshot to the metric cache structure. The metric cache structure is an intermediate storage component that performs parallel writing of multiple versions, used to persist intermediate metric results that have not yet completed structural closure. The server logically marks this snapshot as "future mapping pending correction state." This marking will trigger a backfill calculation mechanism and correction writing process during subsequent data arrival and structural closure determination.

[0104] Through the above steps, the server achieves structural isolation, resource redirection, and data pre-writing of potentially unstable indicator nodes without interrupting the overall indicator graph writing and scheduling process. This placeholder approach ensures the integrity of the indicator graph path and lays a stable structural foundation for subsequent causal closure and temporal consistency.

[0105] S150. If the actual data required to determine the potential unstable indicator node has arrived, perform a correction write to the pre-written data snapshot, and dynamically adjust the identification threshold and channel resource configuration to maintain the causal structure closure of the indicator graph and the consistency of the indicator writing order.

[0106] Specifically, "actual data arrival" refers to the successful synchronization of all original data fields relied upon by potential unstable indicator nodes from various business systems to the current scheduling cycle, and their availability for computation through data cleaning, standardization, and time-series alignment. Judgment criteria include field existence, value validity, and consistency between field timestamps and the current cycle window. "Pre-written data snapshot" refers to the intermediate indicator result structure generated by the server before fields are fully available, used as a placeholder for subsequent structural closure calculations. Its content includes the filled values ​​for arrived fields, calculation logic path identifiers, and structural status markers. The core function of a snapshot is to maintain the continuity of the path structure and provide a basis for subsequent corrections. For example, in a snapshot structure generated when the "policy status code" field is missing, this field is marked as empty and controlled by the "future mapping pending correction" status.

[0107] Correction writing refers to the process where, after the actual data arrives, the server performs structural completion and result update operations on the pre-written data snapshot based on the calculation logic recorded in the indicator graph, and then formally writes the calculated values ​​into the indicator storage structure. Correction writing consists of two parts: a closed-loop update of the calculation and a state synchronization write. The execution logic is as follows: overwrite empty spaces in the snapshot with actual field values; call the indicator node calculation logic to re-execute the indicator function; replace the old values ​​in the snapshot; and mark the indicator node as "write complete". The identification threshold refers to the critical value of the perturbation potential function used to determine whether an indicator node belongs to a potentially unstable node. This threshold affects the granularity of server identification; a threshold that is too low will cause too many indicators to be stripped, while a threshold that is too high will miss nodes with potential structural breakage risks. Dynamically adjusting the identification threshold means that the server adjusts the threshold appropriately based on the system load and the frequency of graph instability to improve the system's adaptability. For example, if the system detects that the push channel load is too high for three consecutive periods, the server can appropriately increase the identification threshold θ, thereby shrinking the set of indicator nodes identified as potentially unstable.

[0108] Channel resource configuration refers to the system resources allocated to the push channel for potentially unstable indicators, such as the number of concurrent schedulers, cache capacity, and priority queue weights. Dynamic adjustment of channel resource configuration means that the server adjusts relevant parameters in real time based on the current number of potentially unstable indicator nodes, the degree of scheduling conflicts, and the number of snapshots accumulated, to avoid channel resource bottlenecks or scheduling delays. For example, if a large number of potentially unstable indicator nodes are concentrated on the client-level path within the current period, the server can increase the concurrency of the push channel for that path from 3 to 6, while simultaneously increasing its priority in the write queue to accelerate closure. The causal structure closure of the indicator graph means that in the indicator graph, each indicator node on a dependent path can complete its own calculation based on the calculation results and time sequence of its upstream nodes, forming a logically complete chain from top to bottom, without any nodes with broken dependencies, suspended paths, or failed closures. Corrective write operations ensure that nodes stripped from the push channel in the path structure are reintegrated into the causal chain of the graph, ensuring that their output can be used for downstream indicator calculations. Consistent indicator write order refers to the system strictly adhering to the dependency order and time period defined in the indicator graph during the multi-indicator write process, avoiding timing disorder phenomena such as downstream indicators being written prematurely and upstream indicators being written late. After correction, indicator nodes need to synchronize their timestamps with the graph scheduling sequence to ensure that the indicator results across the entire graph are completely consistent in semantics, time, and logic.

[0109] For example: In scheduling period T, the server identifies "Quarterly Payout Rate Risk Score" as a potentially unstable indicator node. The "Payout Amount" field is delayed. The server generates a pre-write data snapshot for this node and transfers it to the push channel. By period T+2, the data for this field arrives. The server immediately calls the indicator formula to recalculate the indicator value, updates the snapshot structure to the official result, and writes it to the indicator storage structure. At the same time, the node is marked as "Structure Closure Completed". Due to the decrease in the processing rate of the push channel during this period, the server automatically increases the concurrency of the push channel from 5 to 8 and increases the disturbance identification threshold from 0.65 to 0.72 to narrow the identification range and alleviate resource pressure, thereby maintaining the causal structure closure of the indicator graph and the consistency of the entire path write order.

[0110] In summary, after the data is completed, the server performs a closed-loop correction of the pre-written data snapshot and dynamically adjusts the identification and scheduling strategies according to the scheduling status to ensure the continuity of all dependent paths in the graph and the global consistency of the indicator output. This is the core mechanism for achieving structural stability and logical controllability.

[0111] In one possible implementation, if the actual data required for a potential unstable indicator node to arrive is determined, a correction write is performed on the pre-written data snapshot. Simultaneously, the identification threshold and channel resource configuration are dynamically adjusted. Specifically, this includes: monitoring the arrival status of the original data field corresponding to the potential unstable indicator node within the current scheduling cycle; if the original data field has arrived and its value is valid, the potential unstable indicator node is marked as correctable; invoking the indicator calculation logic corresponding to the potential unstable indicator node in the indicator graph, performing structural consistency verification and numerical correction operations on the pre-written data snapshot stored in the indicator cache structure, and generating a corrected indicator result; writing the corrected indicator result into the indicator storage structure and updating the write status of the potential unstable indicator node in the indicator graph to indicate that structural closure is complete; dynamically adjusting the identification threshold of the potential unstable indicator node based on the changing trend of the disturbance potential function within continuous scheduling cycles, and dynamically adjusting the scheduling concurrency, cache capacity, and priority weight of the potential unstable indicator push channel based on the number of potential unstable indicator nodes and the degree of disturbance concentration.

[0112] Specifically, firstly, the server continuously monitors the arrival status of all raw data fields upon which each potentially unstable indicator node depends in the current scheduling cycle. This includes whether the data fields have been stored in the database, whether the field values ​​conform to the field definition domain, and whether they have valid timestamps that fall within the allowable range of the scheduling cycle. Only when all raw data fields meet the above conditions does the server mark the potentially unstable indicator node as correctable. This marking signifies that the indicator node has the conditions to complete the calculation and execution of corrective writes, and can transition from a write-ahead state to a structurally closed state.

[0113] Secondly, the server invokes the indicator calculation logic recorded in the indicator graph to perform structural consistency checks and numerical correction operations on the pre-written data snapshot stored in the indicator cache structure. The structural consistency check includes verifying whether the field structure in the pre-written data snapshot matches the field dependencies in the indicator calculation logic, whether the field values ​​are complete, and whether the formula structure is correctly parsed. If the check passes, the correction calculation operation is performed, that is, the field values ​​are re-substituted into the indicator function for calculation, replacing the temporary calculated values ​​in the snapshot, and generating the corrected indicator result. The indicator result is represented in the following form:

[0114]

[0115] in, Indicator Node The final calculation results, This is the calculation logic function for the indicator node. This refers to the original data fields that this node depends on.

[0116] Furthermore, the server writes the corrected metric result to the metric storage structure. The metric storage structure is a structured storage area in a persistent database, possessing multi-dimensional attributes such as metric value, write time, calculation status, and field version. After the write is complete, the server updates the write status of the potentially unstable metric node in the metric graph, changing its status from "future mapping pending correction" to "structure closure completed," and releases its cache resources and scheduling context in the push channel.

[0117] Subsequently, the server dynamically adjusts the identification threshold based on the changing trend of the perturbation potential function over consecutive scheduling periods. The definition of the perturbation potential function is as follows:

[0118]

[0119] in, Indicator Node The value of the perturbation potential function. For fields Frequency of change For fields The update delay feature, The strength of the dependency between fields and metrics. , , These are non-linear weighting coefficients.

[0120] If the number of potentially unstable indicator nodes identified in multiple consecutive scheduling cycles continues to rise, it indicates that the identification mechanism is too sensitive, and the server will appropriately increase the threshold to reduce false judgments; conversely, if the number of identified nodes is too small, the threshold will be lowered to improve the identification coverage.

[0121] Finally, the server dynamically adjusts the scheduling concurrency, cache capacity, and priority weight of the potential instability indicator push channel based on the number of potentially unstable indicator nodes in the current period and their clustering degree on the paths in the graph. If multiple potentially unstable indicator nodes are found to be concentrated on a certain dependency path, the server will prioritize increasing the concurrency and resource allocation weight of the channel to which that path belongs to ensure the closure priority of that path, thereby avoiding the formation of cascading collapses within the path.

[0122] The above steps form a closed-loop processing mechanism, ensuring that data can be corrected and written immediately once the data conditions are met. At the same time, dynamic parameter adjustment ensures the stability of the overall graph structure and optimal resource allocation, providing stable operation guarantee for the complex, highly asynchronous, and highly dependent indicator calculation environment of the insurance industry.

[0123] In one possible implementation, after the indicator graph is constructed, the calculation cycle of each indicator node is standardized and uniformly processed; the daily calculation cycle, weekly calculation cycle, monthly calculation cycle and quarterly calculation cycle are mapped to a unified time dimension benchmark; the time sequence of each indicator node in the indicator dependency path is marked based on the time dimension benchmark to ensure the time consistency of the causal path in the indicator graph and the coordination of the calculation scheduling cycle.

[0124] Specifically, after the indicator graph is constructed, the server first needs to standardize the calculation periods of all indicator nodes in the graph to eliminate time scale differences caused by different indicator calculation frequencies. Specifically, the server extracts the calculation period attribute marked in the original definition for each indicator node. Common period types include daily, weekly, monthly, and quarterly calculation periods. These discrete period attributes are mapped to a unified time dimension benchmark, constructing a time scale system with strong comparability and hierarchical division capabilities. For example, all calculation period units are uniformly converted to the smallest time unit, "day," and an integer multiple of the benchmark scale weight is assigned to each period type: the daily calculation period is set to... The weekly calculation period is set to The monthly calculation period is set to The quarterly calculation period is set to The aforementioned cycle transformation enables linear comparison and sequential sorting of the time granularity of all indicator nodes within a unified dimension, providing a foundation for subsequent scheduling control and causal path tracing.

[0125] Subsequently, based on this time dimension benchmark, the server labels the time sequence of each indicator node in the indicator dependency path. Taking each indicator dependency path as a unit, the standardized period scale values ​​of all nodes on the path are extracted and sorted in ascending order of period scale values ​​to determine the temporal causal order along each path in the indicator graph. For example, if indicator node A in the path has a daily calculation period, node B has a weekly calculation period, and node C has a monthly calculation period, then according to the above period weights:

[0126]

[0127] The time sequence of the path that this indicator depends on is A→B→C. The server will mark the scheduling order and time index of the nodes in sequence, constructing the following identifier vector:

[0128]

[0129] in This indicates the index node X at the th th digit after the current period t. The time should be scheduled and calculated, and i is obtained by accumulating the period difference.

[0130] By using the above time sequence annotation, the server can explicitly distinguish the time sequence constraints between different indicator nodes. Even if there is a field dependency relationship between two nodes, as long as the time sequence is inconsistent (such as the downstream indicator node's calculation cycle being earlier than the upstream node), the system can also determine that it is a non-closed path through annotation, thereby avoiding structural errors caused by early scheduling.

[0131] Finally, the server performs a consistency check on the entire indicator graph to ensure that the indicator nodes involved in each indicator dependency path in the graph are reconcilable under the time dimension benchmark, that is, the time annotations of all indicator nodes will not backtrack or overlap. If it is found that multiple nodes in a path share fields but the calculation period is seriously misaligned (such as a daily indicator depending on a quarterly indicator), the system will issue a period conflict alarm and automatically adjust the node scheduling order or request an adjustment of the indicator definition to achieve period reconciliation.

[0132] In summary, establishing a unified time dimension benchmark, marking the execution time sequence, and verifying the consistency of calculation cycles are key steps to achieve stable operation of the indicator graph. Avoiding scheduling chaos, data misalignment, and disordered causal logic is an important guarantee for building a graph structure with cross-cycle computing capabilities and scheduling security.

[0133] This application also provides a data processing device for the insurance industry, referring to... Figure 2 , Figure 2 This is a schematic diagram of a data processing device for the insurance industry provided in an embodiment of this application. The device is a server, comprising an acquisition module 21 and a processing module 22. The acquisition module 21 acquires premium structure indicators, claims data indicators, policy activity indicators, and customer dimension indicators from multiple insurance business systems as indicator nodes. It acquires the field dependencies between indicators, the indicator calculation logic, and the temporal order to establish indicator dependency paths, forming an indicator graph. The acquisition module 21 acquires the frequency of field changes, update delay characteristics, and dependency strength parameters of the data sources upon which the indicator nodes depend within historical periods, and, combined with the update status of each field in the current data stream, establishes an indicator perturbation potential function. The processing module 22 identifies indicators in the indicator graph. Indicator nodes with a perturbation potential function greater than a preset threshold are designated as potential unstable indicator nodes. Based on the indicator dependency path where the potential unstable indicator node is located, inverse dependency inference is performed to construct a set of potential unstable paths. The processing module 22 separates the potential unstable indicator nodes in the set of potential unstable paths from the original writing process and assigns them to the potential unstable indicator push channel, generating corresponding pre-written data snapshots. If the processing module 22 determines that the actual data required by the potential unstable indicator node has arrived, it performs corrective writing on the pre-written data snapshot, and dynamically adjusts the identification threshold and channel resource configuration to maintain the causal structure closure of the indicator graph and the consistency of the indicator writing order.

[0134] It should be noted that the above embodiments of the apparatus are only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0135] This application also provides an electronic device, with reference to... Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include: at least one processor 31, at least one network interface 34, a user interface 33, a memory 35, and at least one communication bus 32.

[0136] The communication bus 32 is used to enable communication between these components.

[0137] The user interface 33 may include a display screen and a camera. Optionally, the user interface 33 may also include a standard wired interface and a wireless interface.

[0138] The network interface 34 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0139] The processor 31 may include one or more processing cores. The processor 31 connects to various parts of the server via various interfaces and lines, executing instructions, programs, code sets, or instruction sets stored in the memory 35, and calling data stored in the memory 35 to perform various server functions and process data. Optionally, the processor 31 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 31 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 31 and may be implemented as a separate chip.

[0140] The memory 35 may include random access memory (RAM) or read-only memory. Optionally, the memory 35 may include a non-transitory computer-readable storage medium. The memory 35 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 35 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 35 may also be at least one storage device located remotely from the aforementioned processor 31. Figure 3 As shown, the memory 35, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program for an insurance industry data processing method.

[0141] exist Figure 3In the electronic device shown, the user interface 33 is mainly used to provide an input interface for the user and to obtain the user input data; while the processor 31 can be used to call an application program stored in the memory 35 for an insurance industry data processing method. When executed by one or more processors, the electronic device executes one or more methods as described in the above embodiments.

[0142] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0143] This application also provides a computer-readable storage medium storing instructions. When executed by one or more processors, these instructions cause an electronic device to perform one or more of the methods described in the above embodiments.

[0144] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0145] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some service interfaces; indirect couplings or communication connections between apparatuses or units may be electrical or other forms.

[0146] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0147] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0148] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0149] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the specification and the disclosure of practical truth. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A data processing method for the insurance industry, characterized in that, The method includes: The premium structure indicators, claims data indicators, policy activity indicators, and customer dimension indicators involved in multiple insurance business systems are obtained as indicator nodes. The field dependencies between indicators, indicator calculation logic, and time sequence are obtained to establish indicator dependency paths and form an indicator graph. The frequency of field changes, update delay characteristics, and dependency strength parameters of the data source on which the indicator node depends within the historical period are obtained, and an indicator perturbation potential function is established by combining the update status of each field in the current data stream. In the index graph, index nodes whose index perturbation potential function is greater than a preset threshold are identified as potential unstable index nodes, and inverse dependency inference is performed based on the index dependency path where the potential unstable index node is located to construct a set of potential unstable paths. The potential instability index nodes in the potential instability path set are separated from the original writing process and assigned to the potential instability index push channel to generate corresponding pre-written data snapshots. If the actual data required for the potential unstable indicator node is determined to arrive, a correction write is performed on the pre-written data snapshot, and the identification threshold and channel resource configuration are dynamically adjusted to maintain the causal structure closure of the indicator graph and the consistency of the indicator writing order. The process involves obtaining the frequency of field changes, update latency characteristics, and dependency strength parameters of the data source upon which the indicator node depends during the historical period, and combining this with the update status of each field in the current data stream to establish an indicator perturbation potential function. Specifically, this includes: Extract the original data fields that each indicator node depends on, and obtain the frequency of field changes of the original data fields within the historical period. The frequency of field changes is used to characterize the fluctuation intensity of field values. The update delay characteristics of the original data field within the historical period are obtained. The update delay characteristics include the mean, maximum, and standard deviation of the time interval from field generation to data entry. The update delay characteristics are used to characterize the timeliness uncertainty of field updates. Calculate the dependency strength parameter between the original data field and the indicator node; By combining the real-time update status of each of the original data fields in the current data stream, a nonlinear weighted model is constructed based on the field change frequency, the update delay characteristics, and the dependency strength parameter to generate an index perturbation potential function that characterizes the local structural instability of the index node.

2. The insurance industry data processing method according to claim 1, characterized in that, The process involves acquiring premium structure indicators, claims data indicators, policy activity indicators, and customer-level indicators from multiple insurance business systems as indicator nodes. It then establishes indicator dependency paths by obtaining the field dependencies, calculation logic, and temporal order of these indicators, forming an indicator graph. Specifically, this includes: Structured definition information of premium structure indicators, claims data indicators, policy activity indicators, and customer dimension indicators are obtained from the payment system, policy system, claims system, and customer service system, respectively. Based on the calculation formula of each indicator, the original data fields on which it depends are analyzed, and the dependency mapping relationship between indicator nodes and fields is established. For indicator nodes that have field sharing or formula derivation relationships with each other, the indicator dependency path is constructed based on the intersection of field dependency paths; The indicator nodes and the indicator dependency paths are constructed into a directional graph structure. Combined with the calculation cycle information of each indicator node, a time sequence labeling operation is performed to form an indicator graph with field dependency structure and time logic constraints.

3. The insurance industry data processing method according to claim 1, characterized in that, The step involves identifying indicator nodes in the indicator graph whose indicator perturbation potential function is greater than a preset threshold as potential unstable indicator nodes, and performing inverse dependency inference based on the indicator dependency path where the potential unstable indicator nodes are located to construct a set of potential unstable paths, specifically including: Traverse the indicator nodes in the indicator graph, obtain the indicator perturbation potential function value corresponding to each indicator node, and identify the indicator nodes that are greater than the preset threshold as the potential unstable indicator nodes. Starting from each of the potential instability index nodes, reverse dependency deduction is performed upward along the index dependency path in the index graph. The upstream index nodes on which the potential instability index node depends are recursively traced, and the resulting dependency paths are recorded and constituted as a path set. The set of paths is summarized to obtain the set of potential instability paths, which is used to characterize the index-dependent structural regions where structural cascade instability is caused by the abnormality of the index perturbation potential function.

4. The insurance industry data processing method according to claim 1, characterized in that, The step of separating the potential instability indicator nodes from the potential instability path set from the original writing process and assigning them to the potential instability indicator push channel, and generating corresponding pre-write data snapshots, specifically includes: Identify each potential instability indicator node in the potential instability path set, and determine whether each potential instability indicator node is in a regular write process triggered by data arrival; If it is in the regular write process, then the potential instability indicator node is removed from the regular write process and the status record of the potential instability indicator node in the regular scheduling queue is cancelled. Assign the potential instability index push channel to each stripped potential instability index node, and establish a scheduling context corresponding to the potential instability index push channel in the scheduling control structure; The pre-written data snapshot is generated based on the indicator dependency path, the original data fields that have been reached, and the indicator calculation logic corresponding to each potential unstable indicator node in the indicator graph. The pre-written data snapshot includes the fill value of the currently available fields, the indicator calculation logic path identifier, and the indicator node structure status information. Write the pre-written data snapshot to the metrics cache structure and mark the pre-written data snapshot as being in a future mapping pending correction state.

5. The insurance industry data processing method according to claim 1, characterized in that, If the actual data required to determine the potential instability indicator node arrives, a corrective write is performed on the pre-written data snapshot, and the identification threshold and channel resource configuration are dynamically adjusted, specifically including: Monitor the arrival status of the original data field corresponding to the potential instability indicator node within the current scheduling cycle. If the original data field has arrived and the field value is valid, mark the potential instability indicator node as a correctable state. The indicator calculation logic corresponding to the potential unstable indicator node in the indicator graph is invoked to perform structural consistency verification and numerical correction operations on the pre-written data snapshot stored in the indicator cache structure, and generate the corrected indicator result. Write the corrected index results into the index storage structure, and update the writing status of the potential unstable index nodes in the index graph to "structure closure completed". Based on the changing trend of the disturbance potential function within a continuous scheduling period, the identification threshold of the potential instability indicator node is dynamically adjusted, and the scheduling concurrency, cache capacity, and priority weight of the potential instability indicator push channel are dynamically adjusted based on the number of potential instability indicator nodes and the degree of disturbance concentration.

6. The insurance industry data processing method according to claim 1, characterized in that, The method further includes: After the indicator map is constructed, the calculation cycle of each indicator node is standardized. Map daily, weekly, monthly, and quarterly calculation cycles to a unified time dimension benchmark; Based on the time dimension benchmark, the temporal order of each indicator node in the indicator dependency path is marked to ensure the temporal consistency of the causal path in the indicator graph and the periodicity of the computation scheduling.

7. A data processing device for the insurance industry, characterized in that, The apparatus is used to perform the insurance industry data processing method as described in any one of claims 1 to 6, the apparatus comprising an acquisition module (21) and a processing module (22), wherein, The acquisition module (21) is used to acquire premium structure indicators, claims data indicators, policy activity indicators and customer dimension indicators involved in multiple insurance business systems as indicator nodes, acquire field dependency relationships between indicators, indicator calculation logic and time sequence to establish indicator dependency paths, and form an indicator map. The acquisition module (21) is also used to acquire the frequency of field changes, update delay characteristics and dependency strength parameters of the data source on which the indicator node depends in the historical period, and to establish an indicator disturbance potential function in combination with the update status of each field in the current data stream. The processing module (22) is used to identify index nodes in the index graph whose index perturbation potential function is greater than a preset threshold as potential unstable index nodes, and to perform reverse dependency inference based on the index dependency path where the potential unstable index node is located, and to construct a set of potential unstable paths. The processing module (22) is also used to separate the potential instability index nodes in the potential instability path set from the original writing process and assign them to the potential instability index push channel to generate corresponding pre-written data snapshots. The processing module (22) is also used to perform corrective writing on the pre-written data snapshot if the actual data required to determine the potential unstable index node arrives, and dynamically adjust the identification threshold and channel resource configuration to maintain the causal structure closure of the index map and the consistency of the index writing order.

8. An electronic device, characterized in that, The electronic device includes a processor (31), a memory (35), a user interface (33), and a network interface (34). The memory (35) is used to store instructions. The user interface (33) and the network interface (34) are both used to communicate with other devices. The processor (31) is used to execute the instructions stored in the memory (35) to cause the electronic device to perform the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1 to 6.

Images