A three-layer decoupling configuration method for quantitative strategy based on financial heterogeneous logic

Abstract

The present application relates to the technical field of computer data processing, and particularly relates to a three-layer decoupling configuration method of a quantitative strategy based on financial heterogeneous logic. The method comprises the following steps: obtaining quantitative strategy configuration data, and performing multi-source configuration analysis according to the quantitative strategy configuration data to obtain strategy configuration analysis data; performing configuration field identification according to the strategy configuration analysis data to obtain heterogeneous configuration classification data; performing three-layer decoupling configuration according to the heterogeneous configuration classification data to obtain three-layer strategy configuration data; performing intermediate representation construction according to the three-layer strategy configuration data to obtain strategy intermediate representation data; performing dependency verification on the strategy intermediate representation data to obtain strategy program data; and performing strategy configuration verification on the strategy program data to obtain decoupling configuration results. The present application reduces field ambiguity, variable disconnection, port mismatch and execution sequence conflict, and improves the accuracy of strategy program generation and the stability of deployment.

Description

Technical Field

[0001] This invention relates to the field of computer data processing technology, and in particular to a three-layer decoupling configuration method for quantitative strategies based on heterogeneous financial logic. Background Technology

[0002] With the development of fintech and quantitative trading tools, low-code platforms are increasingly being applied to quantitative strategy development. Users can input strategy intent via natural language, select strategy modules through visual components, or configure variable parameters and function interfaces in a low-code manner, thereby lowering the barrier to entry for strategy program development. Compared to the traditional method that relies entirely on manual coding, low-code platforms can improve the efficiency of strategy building and enable non-professional programming users to complete a certain level of strategy configuration.

[0003] However, existing low-code quantitative trading platforms in the financial sector often suffer from issues such as high coupling of configuration data, unclear field sources, and insufficient stability in program generation when handling various input formats. Natural language policy text focuses on expressing policy conditions and trigger constraints, visualization components focus on expressing node structures and port connections, and low-code parameter configuration focuses on expressing variables, function interfaces, and parameter values. These three types of configuration data differ in data format, semantic granularity, invocation methods, and execution locations. If they are directly mixed and written into the same policy template, it can easily lead to problems such as inconsistent field meanings, component port mismatches, unbound code variables, and abnormal function interface calls. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention proposes a three-layer decoupling configuration method for quantitative strategies based on heterogeneous financial logic, thereby resolving at least one of the aforementioned technical issues.

[0005] This application provides a three-layer decoupling configuration method for quantitative strategies based on financial heterogeneous logic, the method comprising:

[0006] S1. Obtain the quantitative strategy configuration data, and perform multi-source configuration parsing based on the quantitative strategy configuration data to obtain the strategy configuration parsing data;

[0007] S2. Based on the strategy configuration parsing data, identify the configuration fields to obtain heterogeneous configuration classification data;

[0008] S3. Perform three-layer decoupling configuration based on heterogeneous configuration classification data to obtain three-layer strategy configuration data, which includes language strategy configuration, component decoupling configuration and code parameter configuration.

[0009] S4. Construct intermediate representations based on the three-layer strategy configuration data to obtain the strategy intermediate representation data;

[0010] S5. Perform dependency validation on the intermediate representation data of the strategy to obtain the strategy program data;

[0011] S6. Perform policy configuration verification on the policy program data to obtain the decoupled configuration result.

[0012] This invention utilizes multi-source parsing of quantized strategy configuration data to uniformly convert natural language text, component selection information, and low-code parameters into recognizable structured configuration data, reducing format differences between various input formats. Through heterogeneous configuration classification and three-layer decoupling configuration, language strategy configuration, component decoupling configuration, and code parameter configuration are managed separately, making the source of fields, component relationships, and code variables clearer during strategy construction. Intermediate representation construction transforms the three types of configurations into a unified data expression structure. Dependency validation and strategy configuration validation can proactively identify issues such as missing variables, port mismatches, call order conflicts, and incomplete parameter configurations, thereby improving the accuracy, executability, and cross-environment deployment stability of the low-code platform's automatically generated strategy programs.

[0013] Optionally, S1 includes:

[0014] The input source of the quantization strategy configuration data is identified to obtain configuration source data; semantic field extraction, component structure parsing, and code parameter parsing are performed on the configuration source data to obtain text strategy data, component structure data, and code parameter data, respectively; field standardization mapping is performed on the text strategy data, component structure data, and code parameter data to obtain standard configuration field data; the parsing results are encapsulated based on the standard configuration field data to obtain strategy configuration parsing data.

[0015] This invention identifies the input source, enabling the system to distinguish between different configuration entry points such as natural language text, visual components, and low-code parameters, thus preventing field mismatches caused by mixing multiple types of data in the same parsing process. Through semantic field extraction, component structure parsing, and code parameter parsing, text conditions, component node relationships, and code variable parameters can be extracted respectively, providing a computable and mappable data foundation for different forms of strategy configuration. Field standardization mapping converts fields with different expressions but consistent meanings into unified field identifiers, reducing variable ambiguity in decoupled configuration and program generation. Encapsulation of parsing results forms a complete data package containing configuration sources, standard fields, and parameter information, improving the traceability, reusability, and system processing stability of the strategy configuration parsing results.

[0016] Optionally, S2 includes:

[0017] The strategy configuration parsing data is indexed to obtain configuration field index data; configuration form recognition is performed based on the configuration field index data to obtain configuration form recognition data, which includes text field recognition, component field recognition, and code field recognition; field function attribution is labeled based on the configuration form recognition data to obtain field function labeling data; heterogeneous logical category matching is performed based on the field function labeling data to obtain logical category matching data, which includes language strategy category matching, component node category matching, and code parameter category matching; cross-source field association is performed based on the logical category matching data to obtain heterogeneous configuration classification data.

[0018] This invention utilizes field indexing to establish a unified retrieval entry point for text fields, component fields, and code fields in strategy configuration parsing data, preventing omissions in subsequent processing due to the dispersed sources of fields. By configuring morphological recognition and field function attribution labeling, it can distinguish the data form of fields and their roles in the strategy program, such as condition, parameter, trigger, input, output, or call fields, making the field classification results more suitable for programmatic processing. Through heterogeneous logical category matching, fields from different sources can be categorized into corresponding categories of language strategy, component nodes, and code parameters, enhancing the accuracy of the three-layer decoupling. Through cross-source field association, the correspondence between text descriptions, component nodes, and code variables can be identified.

[0019] Optionally, S3 includes:

[0020] The heterogeneous configuration classification data is read by configuration category to obtain configuration category read data; based on the configuration category read data, language strategy configuration decoupling, component node configuration decoupling, and code parameter configuration decoupling are performed to obtain language strategy configuration data, component decoupling configuration data, and code parameter configuration data, respectively; cross-layer association marking is performed based on the language strategy configuration data, component decoupling configuration data, and code parameter configuration data to obtain three-layer associated configuration data; the three-layer associated configuration data is then encapsulated hierarchically to obtain three-layer strategy configuration data.

[0021] In this invention, by reading configuration categories, the system can accurately determine the processing level of each configuration field based on the preceding classification results, avoiding the mixing and stacking of language descriptions, component nodes, and code parameters in the same configuration structure. Through decoupling of language strategy configuration, component node configuration, and code parameter configuration, independent configuration data for semantic fields, component port relationships, and code variable interfaces can be formed respectively, giving different configuration forms clear data boundaries. Through cross-layer association tags, the calling, mapping, and transmission relationships between the three types of configurations can be preserved, avoiding data isolation after decoupling. Through hierarchical encapsulation, a unified and clearly defined three-layer strategy configuration data structure can be formed.

[0022] Optionally, S4 includes:

[0023] The three-layer policy configuration data is extracted into configuration units to obtain policy configuration unit data; unified node abstraction is performed based on the policy configuration unit data to obtain policy intermediate node data; input and output port mapping is performed based on the policy intermediate node data to obtain node port mapping data; variable binding is performed based on the node port mapping data to obtain node variable binding data; execution relationship generation is performed based on the node variable binding data to obtain policy execution relationship data; and intermediate representation encapsulation is performed based on the policy execution relationship data to obtain policy intermediate representation data.

[0024] This invention extracts configuration units, breaking down the three-layer strategy configuration data into the smallest independently processable configuration units, reducing the coupling between language fields, component nodes, and code parameters. Through unified node abstraction, configuration units from different sources and in different formats can be converted into a consistent node representation, eliminating reliance on the original input format for subsequent program generation. Input / output port mapping and variable binding clarify the data input, output, and variable passing relationships between nodes, reducing issues such as port misconnections, variable ambiguity, and broken call chains. Finally, through execution relationship generation and intermediate representation encapsulation, a unified strategy intermediate representation is formed, encompassing node structure, variable binding, and execution order.

[0025] Optionally, S5 includes:

[0026] Node dependencies are extracted from the intermediate representation data of the strategy to obtain node dependency data; variable call chain verification is performed based on the node dependency data to obtain variable dependency verification data; interface matching verification is performed based on the variable dependency verification data to obtain interface dependency verification data; execution order verification is performed based on the interface dependency verification data to obtain execution order verification data; and program structure is generated based on the execution order verification data to obtain strategy program data.

[0027] This invention utilizes node dependency extraction to clearly define the sequential call relationships, constraint relationships, and data transmission relationships among nodes in the intermediate representation data of the strategy, avoiding simple concatenation based solely on the node arrangement order during program generation. Variable call chain verification detects whether variables have clear sources, transmission paths, and valid reference relationships, reducing issues such as missing variables, out-of-domain calls, and broken call chains. Interface matching and execution order verification identify inconsistencies between component interfaces, function parameters, return fields, and node triggering order in advance, lowering the error rate of automatically generated programs. Generating strategy program data based on the verified execution order gives the generated program better structural integrity, executability, and cross-execution environment adaptability.

[0028] Optionally, variable call chain verification includes:

[0029] Based on node dependency data, cross-morphological variable source point identification is performed to obtain variable source point data; based on the variable source point data, variable semantic fingerprint generation is performed to obtain variable semantic fingerprint data; based on the variable semantic fingerprint data, cross-layer variable binding is performed to obtain variable binding data; based on the variable binding data, variable call chain skeleton is constructed to obtain variable call chain skeleton data; variable path reachability is verified on the variable call chain skeleton data to obtain variable path verification data; based on the variable path verification data, variable morphological transformation verification is performed to obtain variable morphological verification data; based on the variable morphological verification data, variable scope penetration verification is performed to obtain variable scope verification data; based on the variable scope verification data, variable chain closure is determined to obtain variable dependency verification data.

[0030] This invention identifies the source of variables across different forms, clearly identifying their initial origin from language fields, component ports, or code parameters, thus preventing errors in subsequent calls due to unclear variable sources. Through variable semantic fingerprint generation and cross-layer variable binding, a unified correspondence can be established between field variables, component variables, and code variables with different names but consistent semantics, reducing variable ambiguity in cross-layer configurations. By constructing a variable call chain skeleton and verifying path reachability, it can be determined whether variables can be effectively passed to the target call location along node dependencies. Through variable form conversion consistency verification and scope penetration verification, program generation risks such as data type mismatches and out-of-scope calls of local variables can be detected in advance. By determining variable chain closure, the completeness, accuracy, and executable stability of policy program variable calls are improved.

[0031] Optionally, the variable call chain skeleton construction includes:

[0032] Based on the variable binding data, the source end of the bound variable is located to obtain the variable source end data; based on the variable source end data, the target end of the variable is identified to obtain the variable target end data; based on the variable source end data and the variable target end data, cross-morphological call edge is generated to obtain the variable call edge data; based on the variable call edge data, variable relay nodes are completed to obtain the variable relay path data; based on the variable relay path data, the call chain skeleton is encapsulated to obtain the variable call chain skeleton data.

[0033] This invention, by binding variable source-end location and variable target-end identification, clearly defines the generation and consumption positions of each variable in the strategy program, avoiding misjudgments of call relationships caused by rough matching based solely on variable names. Through cross-morphological call edge generation, the variable flow relationships between language fields, component ports, and code parameters can be converted into computable directed links, making the variable transmission direction and call boundaries clearer. By completing variable relay nodes, field conversion, port adaptation, parameter mapping, or return encapsulation nodes can be automatically added between the source and target ends, reducing cross-layer call breakpoints. Through call chain skeleton encapsulation, a complete variable chain structure containing the source, target, call edge, and relay path is formed, improving the accuracy and stability of subsequent path verification, interface matching, and program generation.

[0034] Optionally, S6 includes:

[0035] The strategy program data is processed by extracting program configuration items to obtain program configuration item data; the configuration source is verified based on the program configuration item data to obtain source verification data; the configuration parameters are verified based on the source verification data to obtain parameter verification data; the execution environment is verified based on the parameter integrity verification data to obtain environment adaptation verification data; configuration conflicts are reviewed based on the environment adaptation verification data to obtain configuration conflict review data; and the decoupling results are encapsulated based on the configuration conflict review data to obtain decoupled configuration results.

[0036] This invention extracts program configuration items, allowing the entry points, variables, parameters, interfaces, return fields, and exception handling items in the strategy program to be broken down into verifiable objects, facilitating structured checks on the generated program. Configuration source verification confirms that each program configuration item can be traced back to language strategy configuration, component decoupling configuration, or code parameter configuration, avoiding fields with no source or incorrect binding. Configuration parameter verification identifies issues such as missing parameters, unassigned variables, and incomplete interface parameters. Execution environment adaptation verification determines whether the data format and interface calls match between the strategy program and the backtesting engine, simulation execution engine, or live execution environment. Configuration conflict review and decoupling result encapsulation improve the traceability, deployment stability, and cross-environment execution consistency of the generated program.

[0037] The purpose of this invention is to convert user-input natural language policy text, visual component selection information, and low-code parameter configurations into unified and recognizable structured data through multi-source configuration parsing of quantitative strategy configuration data. This avoids field mixing and semantic ambiguity caused by different input forms during the same strategy construction process. By identifying configuration fields and classifying heterogeneous configurations, the source, function, and corresponding category of text fields, component fields, and code fields can be clearly defined. Through three-layer decoupling of language policy configuration, component decoupling configuration, and code parameter configuration, semantic rules, node structures, and variable interfaces can be managed separately, while cross-layer relationships preserve the calling logic between the three, preventing data fragmentation after decoupling. Through intermediate representation construction, the three-layer configuration can be uniformly abstracted into nodes, ports, variables, and execution relationships, providing a stable data structure for automatically generated strategy programs. Through dependency verification and strategy configuration verification, issues such as missing variables, port mismatches, abnormal interface calls, execution order conflicts, and environment adaptation errors can be detected in advance, thereby improving the accuracy, executability, traceability, and cross-execution environment deployment stability of the generated strategy program. Attached Figure Description

[0038] Other features, objects, and advantages of this application will become more apparent from the following detailed description of the non-limiting embodiments, taken with reference to the accompanying drawings:

[0039] Figure 1 A flowchart illustrating the steps of a three-layer decoupling configuration method for quantitative strategies based on financial heterogeneous logic is shown in one embodiment.

[0040] Figure 2 A flowchart illustrating the steps of a multi-source configuration resolution method according to an embodiment is shown.

[0041] Figure 3 A flowchart illustrating the steps of a configuration field identification method according to an embodiment is shown.

[0042] Figure 4 A flowchart illustrating the steps of a three-layer decoupling configuration method according to one embodiment is shown.

[0043] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0044] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0045] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. Functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0046] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0047] Current quantitative strategy configurations are typically scattered across scripts, parameter tables, component configuration files, and backtesting platform configurations. This leads to issues such as inconsistent field naming, difficulty in tracing component call relationships, parameter modifications affecting code structure, and a lack of dependency validation before strategy program generation. Consequently, updates to the strategy software system configuration can easily result in broken field chains, missing component calls, and incorrect parameter types. Before launching a multi-factor rotation strategy for a stock, the system acquires the quantitative strategy configuration data for that strategy. This data includes the strategy script, Excel parameter table, factor component configuration table, risk control configuration file, and backtesting platform runtime configuration. The system parses these multi-source configurations to obtain strategy configuration parsing data containing unified field names, field values, field types, field paths, source identifiers, version identifiers, and conflict identifiers. For example, "lookback period=20" in the parameter table and "lookback=20" in the script are unified into the same "lookback period" field, and MomentumFactor.calculate in the component configuration table is identified as the entry point for the momentum factor component.

[0048] The system categorizes strategy configuration parsing data based on a configuration field identification rule table. If the field is "Buy Condition," "Sell Condition," or "Positioning Rule," it is identified as a language strategy configuration; if the field is "Factor Component," "Risk Control Module," or "Backtesting Engine," it is identified as a component decoupling configuration; if the field is "Review Period," "Maximum Position Ratio," or "Stop-Loss Threshold," it is identified as a code parameter configuration. Based on this, the system generates heterogeneous configuration classification data and distributes it into a three-layer configuration structure: the language strategy configuration layer forms a rule that "generates a buy signal when the momentum factor ranking enters the top 20% and the moving average trend is upward"; the component decoupling configuration layer forms a call chain of "Market Data Source—Momentum Factor Component—Risk Control Component—Execution Component—Backtesting Component"; and the code parameter configuration layer forms a parameter table with "Review Period = 20, Maximum Position Ratio = 0.1, Stop-Loss Threshold = 0.05."

[0049] The system constructs the three-layer strategy configuration data into intermediate strategy representation data IR=(N,Port,B,E), where N is a set of nodes, including buy rule nodes, sell rule nodes, risk control rule nodes, market data source nodes, momentum factor component nodes, risk control component nodes, execution component nodes, and parameter nodes; Port is a set of port mappings used to record the input ports, output ports, and port types of each node; B is a set of variable bindings used to represent the binding relationship between parameter nodes such as review period, position ratio, and stop-loss threshold and their corresponding rule nodes or component nodes; and E is a set of execution relationships used to represent the data dependency, parameter dependency, or call dependency between rule nodes, component nodes, and parameter nodes. The system performs dependency validation on the intermediate strategy representation data. If the momentum factor component node that the buy rule node depends on has a call entry point, the risk control rule node has a bound threshold parameter, and the execution component node has an order placement interface, then strategy program data is generated; if a component call entry point is missing, a parameter node is not bound, or a parameter value is out of bounds, then an exception pending confirmation item is written.

[0050] During the strategy configuration verification phase, the system verifies the consistency of the strategy program data, the integrity of the calls, and the validity of the parameters. For example, the system confirms that "Market Data Acquisition" precedes "Factor Calculation," "Risk Control Verification" precedes "Trade Execution," and the maximum position ratio is between 0 and 1. After successful verification, the system outputs the decoupled configuration result, which includes an executable configuration summary, component call sequence, parameter assignment table, source version record, and verification pass indicator.

[0051] Through the above embodiments, this application can decompose the quantitative strategy logic, which was originally mixed in scripts, parameter tables, and component configurations, into a three-layer structure: language strategy configuration, component decoupling configuration, and code parameter configuration. This allows for separate management and unified verification of strategy rules, component calls, and executable parameters. Taking a multi-factor strategy with approximately 120 configuration fields as an example, using this method, the system can identify field conflicts, component chain breaks, and parameter out-of-bounds issues before the strategy goes live, reducing the workload of manually checking each configuration item. When only the review period or position ratio is adjusted, there is no need to modify the strategy script and component call relationships; only the code parameter configuration layer needs to be updated to complete the strategy reconfiguration, thereby improving the reusability of quantitative strategy configuration, online stability, and anomaly tracing efficiency. This application, through multi-source configuration parsing, configuration field identification, three-layer decoupling configuration, and intermediate representation construction, transforms heterogeneous quantitative strategy configurations into a verifiable strategy program configuration structure. This allows rule nodes, component nodes, dependency edges, and parameter binding relationships to be uniformly verified before program generation, thereby reducing configuration field ambiguity, component call chain breaks, and parameter binding errors, and improving the configuration generation stability and maintainability of the quantitative strategy software system.

[0052] Please see Figures 1 to 4 This application provides a three-layer decoupling configuration method for quantitative strategies based on financial heterogeneous logic, the method comprising:

[0053] S1. Obtain the quantitative strategy configuration data, and perform multi-source configuration parsing based on the quantitative strategy configuration data to obtain the strategy configuration parsing data;

[0054] In one embodiment, the system obtains quantitative strategy configuration data from the strategy management terminal, backtesting platform, code repository, and parameter configuration library. This data includes strategy scripts, parameter tables, trading target configurations, factor configurations, and risk control configurations. The system first generates a source identifier (source_i), a format identifier (format_type), and a version identifier (version_i) for each configuration file. Then, it performs split parsing based on the format_type: extracting field paths, field names, and field values ​​from JSON / YAML files; extracting header fields, row and column positions, and cell values ​​from Excel / CSV files; and extracting variable assignment statements, function parameters, and comment configuration items from script files. The system represents each parsed item as c_i=(k_i,v_i,t_i,p_i,source_i,version_i), where k_i is the field name, v_i is the field value, t_i is the field type, p_i is the field path or code location, source_i is the source identifier, and version_i is the version identifier. The system normalizes fields based on a preset field alias table. For example, it normalizes symbol / ticker / instrument as a trading target field, and window / lookback / period as a lookback period field. It also performs type validation on field values, ensuring that period fields are positive integers, ratio fields are between 0 and 1, and time fields are converted to a unified trading day format. Based on this, it obtains the normalized field names. If the same normalized field has different values ​​from different sources, a conflict flag is generated; if the values ​​are the same, the source references are merged. The system obtains strategy configuration parsing data, which includes the normalized field name, field value, field type, field path, source flag, version flag, and conflict flag.

[0055] The preset field alias table is generated by the system during the initialization phase based on the quantitative strategy configuration template, historical strategy configuration samples, and manually confirmed field mapping rules. The system first reads the field names from the historical quantitative strategy configuration data and counts fields with the same meaning but different names from different sources. For example, symbol, ticker, and instrument are all used to represent trading targets, while window, lookback, and period are used to represent the review period. Then, consistency is checked based on the field's path, value type, comment content, and usage location. If multiple fields correspond to the same configuration purpose in different configuration files and have the same value type, they are written into the same alias group. Each alias group includes a unified field name, an alias field name, the applicable configuration source, and field type constraints. After manual review or system rule confirmation, a preset field alias table is formed and called during multi-source configuration parsing to map heteronymous fields to unified fields.

[0056] S2. Based on the strategy configuration parsing data, identify the configuration fields to obtain heterogeneous configuration classification data;

[0057] In one embodiment, the system receives policy configuration parsing data and reads the normalized field name, field value, field type, field path, source identifier, version identifier, and conflict identifier. The system pre-establishes a configuration field identification rule table, which is generated based on the quantitative strategy configuration template and historical strategy configuration samples. This table includes a strategy logic field set, a component field set, a code parameter field set, field path characteristics, and field type constraints. The strategy logic field set stores field names related to trading conditions, signal generation, buy / sell rules, and position holding rules. The component field set stores field names related to factor components, data source components, risk control components, execution components, and backtesting components. Factor components are used to calculate strategy factors, data source components provide strategy execution data, risk control components enforce risk constraints, execution components generate or issue trading instructions, and backtesting components verify the strategy configuration effect based on historical data. The code parameter field set stores field names related to thresholds, periods, ratios, quantities, switches, and time windows. Field path characteristics characterize the field's hierarchical position, directory position, or function call position in the configuration file or script. Field type constraints limit the data type that field values ​​should satisfy: numeric, character, boolean, time, or list. The system represents each strategy configuration parsing item as r_i=(K_i,v_i,t_i,p_i,source_i,version_i,conflict_i), where K_i is the normalized field name. If K_i belongs to the strategy logic field set, or the field path p_i is located in the strategy conditions, signal generation, or trading rules directory, then the parsing item is identified as a language strategy configuration field. If K_i belongs to the field set such as factor name, data source, execution component, risk control module, or backtesting engine, or the field value v_i points to a component name, interface name, or module path, then the parsing item is identified as a component decoupling configuration field. If K_i belongs to the field set such as threshold, period, ratio, switch, quantity, or time window, and the field type t_i is numeric, boolean, or time-based, then the parsing item is identified as a code parameter configuration field. For parsing items with the conflict identifier conflict_i, the system retains its original classification result and adds a conflict pending verification status. The system generates a field category identifier class_i for each parsing item based on the field recognition result. The value of class_i includes language strategy configuration, component decoupling configuration, and code parameter configuration. The field category identifier class_i is bound to the corresponding parsing item r_i to form heterogeneous configuration classification data. The heterogeneous configuration classification data includes normalized field name, field value, field type, field path, source identifier, version identifier, conflict identifier, and field category identifier.

[0058] S3. Perform three-layer decoupling configuration based on heterogeneous configuration classification data to obtain three-layer strategy configuration data, which includes language strategy configuration, component decoupling configuration and code parameter configuration.

[0059] In one embodiment, the system receives heterogeneous configuration classification data and reads the parsing item r_i and field category identifier class_i, where r_i includes the normalized field name K_i, field value v_i, field type t_i, field path p_i, source identifier source_i, version identifier version_i, and conflict identifier conflict_i. The system performs three-layer routing for each parsing item based on class_i: when class_i is a language strategy configuration, the corresponding parsing item is written to the language strategy configuration layer to form strategy intent, trading conditions, signal generation rules, buy / sell rules, and position rules; when class_i is a component decoupling configuration, the corresponding parsing item is written to the component decoupling configuration layer, and the calling relationship between factor components, data source components, risk control components, execution components, and backtesting components is determined based on the module level in field path p_i and the component name or interface path in field value v_i; when class_i is a code parameter configuration, the corresponding parsing item is written to the code parameter configuration layer to form executable parameters such as review period, threshold, ratio, quantity, switch, and time window. The system represents the three-layer configuration as D=(L,C,P,R), where L is the language strategy configuration data, C is the component decoupling configuration data, P is the code parameter configuration data, and R is the cross-layer association tag set, which does not constitute the fourth layer configuration but is only used to record the correspondence between the language strategy configuration, component decoupling configuration, and code parameter configuration. For parsed items with the conflict flag conflict_i, the system retains the conflict pending verification state in the corresponding layer and does not directly overwrite the field value. The system encapsulates L, C, P, R, and the source flag, version flag, and conflict flag inherited from each layer's parsed items to obtain the three-layer strategy configuration data.

[0060] In one embodiment, if the heterogeneous configuration classification data contains a parsing item r_1=(“lookback period”,20,“numerical type”,“strategy.signal.lookback”,“parameter table V1”,“2026-01”,false), where false indicates that the parsing item does not have a conflict flag and its field category flag class_1 is a code parameter configuration, then the system writes the parsing item into the code parameter configuration layer according to the normalized field name and field value in r_1, and forms the executable parameter “lookback period=20”. If a parser r_2 = (“Buy Condition”, “MA5>MA20”, “Character”, “strategy.rule.buy_condition”, “Strategy Script V1”, “2026-01”, false) exists, and class_2 is a language strategy configuration, then the system writes this parser to the language strategy configuration layer based on the field path strategy.rule.buy_condition and the field value MA5>MA20, and forms the buy rule “Trigger a buy signal when the 5-day moving average crosses above the 20-day moving average”. If a parser r_3 = (“Factor Component”, “MomentumFactor.calculate”, “Character”, “components.factor.momentum”, “Component Configuration Table V1”, “2026-01”, false) exists, and class_3 is a component decoupling configuration, then the system determines that it belongs to a factor component based on components.factor in the field path, and determines the component call entry point based on MomentumFactor.calculate in the field value. The system encapsulates the above three types of parsing items into language strategy configuration data, component decoupling configuration data, and code parameter configuration data, respectively.

[0061] S4. Construct intermediate representations based on the three-layer strategy configuration data to obtain the strategy intermediate representation data;

[0062] In one embodiment, the system receives three-layer strategy configuration data D=(L,C,P,R), where L is language strategy configuration data, C is component decoupling configuration data, P is code parameter configuration data, and R is a cross-layer association tag set. The system extracts strategy intent, trading conditions, signal generation rules, buy / sell rules, and position holding rules from L and converts them into rule nodes. It extracts factor components, data source components, risk control components, execution components, and backtesting components from C and converts them into component nodes. It extracts backtesting period, threshold, ratio, quantity, switch, and time window from P and converts them into parameter nodes. All rule nodes, component nodes, and parameter nodes form a node set N. The system configures input and output ports for each node based on node type, field path, configuration unit binding key, and component call entry point, forming a port mapping set Port. The system generates a variable binding set B based on the binding key matching relationship between the parameter node output port and the rule node or component node input port, as well as the field path prefix relationship. The system generates directed execution edges based on the variable binding set B, the cross-layer association tag set R, and the component call entry point, forming an execution relationship set E. The system determines the direction of data dependencies between nodes based on the variable transit relationships in the variable binding set B. For each variable binding relationship in the variable binding set B, b_i = (from_node, to_node, bind_key_i, var_value_i), where b_i is the variable binding relationship data item; from_node is the source node, used to represent the node that outputs variables, parameters, or component results; to_node is the target node, used to represent the rule node or component node that receives variables, parameters, or component results; bind_key_i is the variable binding key, used to represent the matching identifier between the output content of the source node and the input port of the target node; var_value_i is the variable binding value, used to represent the parameter value, component calculation result, or rule output result output by the source node and passed to the target node. If from_node provides parameter values, factor results, or rule outputs to to_node, then a directed execution edge from from_node to to_node is established. The system then supplements the association edges between language strategy configuration, component decoupling configuration, and code parameter configuration based on the cross-layer association tag set R. For example, when a rule node and a factor component have a rule-component association identifier, a call dependency edge is established from the component node to the rule node; when a parameter node and a rule node have a rule-parameter association identifier, a parameter dependency edge is established from the parameter node to the rule node. For a component node, the system reads its component call entry point. If the output of a component call entry point is referenced by another component or rule node, a call dependency edge is established from the calling component to the node receiving the called result.The system uniformly represents the above dependencies as e_i=(from_node,to_node,dep_type_i), where dep_type_i includes data dependencies, parameter dependencies, and call dependencies, forming an execution relationship set E.

[0063] The system defines the intermediate policy representation data as IR=(N,Port,B,E), where N is the node set, Port is the port mapping set, B is the variable binding set, and E is the execution relationship set. For fields that inherit the conflict identifier conflict_i, the system writes a conflict pending verification status into the corresponding node, port, variable binding relationship, or execution edge. The system encapsulates the IR and the source identifier, version identifier, and conflict identifier inherited from the original parsing item to obtain the intermediate policy representation data.

[0064] S5. Perform dependency validation on the intermediate representation data of the strategy to obtain the strategy program data;

[0065] In one embodiment, the system receives intermediate policy representation data IR=(N,Port,B,E), where N is a node set, Port is a port mapping set, B is a variable binding set, and E is an execution relationship set. The system first performs node integrity verification on the node set N: for rule nodes, it checks whether they contain a rule name, trigger condition, action type, and associated field path; for component nodes, it checks whether they contain a component name, component type, call entry point, and input / output fields; for parameter nodes, it checks whether they contain a parameter name, parameter value, and field type. The system then performs port integrity verification based on the port mapping set Port, checking whether there are missing or inconsistent port types for each node's input and output ports. The system checks whether parameter nodes are bound to corresponding rule nodes or component nodes based on the variable binding set B, and determines whether the variable binding values ​​meet the data type requirements of the target input port. The system checks whether there are broken links between nodes based on the execution relationship set E. If a rule node depends on a component node that does not exist, a component node call entry point is missing, or a parameter node is not connected to the target node, a dependency missing flag is generated and written into the exception pending confirmation item. For nodes, ports, variable binding relationships, or execution edges carrying a conflict pending verification status, the system writes an exception pending confirmation item. After verification, the system performs topological sorting based on the directed execution edges in the execution relationship set E to obtain the node execution sequence. Then, it generates the rule execution order, component call sequence, and parameter assignment table from the node execution sequence, and encapsulates them with the source version record to obtain the strategy program data.

[0066] The system performs topological sorting based on the execution relationship set E. This involves first treating each node in the node set N as a graph node, and then treating the directed execution edges e_i=(from_node, to_node, dep_type_i) in the execution relationship set E as graph edges, constructing a directed dependency graph G=(N,E), where from_node represents the dependent output node and to_node represents the dependent receiving node. The system counts the in-degree of each node, which represents the number of upstream dependencies pointing to that node. Nodes with an in-degree of 0 are added to the execution queue, indicating that the node has no incomplete preceding dependencies. The system sequentially retrieves nodes from the execution queue and writes them into the node execution sequence, simultaneously deleting the execution edges pointing to downstream nodes from that node and updating the in-degree of the downstream nodes. When the in-degree of a downstream node is updated to 0, it is added to the execution queue. This process is repeated until all nodes are written into the node execution sequence. If there are still nodes that have not been written after sorting, it is determined that there is a circular dependency in the execution relationship set, and an order error flag order_error_i is generated; if all nodes have been sorted, the obtained node execution sequence is used as the basis for generating the rule execution order, component call sequence and parameter assignment table.

[0067] S6. Perform policy configuration verification on the policy program data to obtain the decoupled configuration result.

[0068] In one embodiment, the system receives strategy program data, which includes rule execution order, component call sequence, parameter assignment table, pending anomaly confirmation items, and source version records. The system first performs a process consistency check based on the rule execution order, determining whether the signal generation rule precedes the buy / sell rule and whether the risk control rule precedes the transaction execution. Then, it performs a call integrity check based on the component call sequence, determining whether the factor component, data source component, risk control component, execution component, and backtesting component all have corresponding call entry points. The system performs parameter validity checks based on the parameter assignment table and parameter constraint table. The parameter constraint table is generated from field type constraints in the code parameter configuration layer, strategy configuration templates, and system-preset running constraints, used to limit the value range of the review period, threshold, ratio, quantity, switch, and time window. If the pending anomaly confirmation items are empty, and the process consistency, call integrity, and parameter validity all pass, a verification pass flag is generated; if there are missing dependencies, pending conflicts, or out-of-bounds parameters, a verification failure flag and corresponding exception reason are generated. The system encapsulates the verification pass or fail flag, the reason for the exception, the source version record, and the executable configuration summary extracted from the rule execution order, component call sequence, and parameter assignment table to obtain the decoupled configuration result.

[0069] Optionally, S1 includes:

[0070] S11. Identify the input source of the quantization strategy configuration data to obtain the configuration source data;

[0071] In one embodiment, the system receives quantization strategy configuration data and identifies its source type, file format, and version information. If the data comes from a strategy script, the script path and code version are recorded; if it comes from a parameter table, the table name and worksheet location are recorded; if it comes from a component configuration file, the component configuration source is recorded. The system represents each source as q_i=(source_i,format_i,version_i,path_i), thus obtaining the configuration source data.

[0072] S12. Based on the configuration source data, perform semantic field extraction, component structure parsing, and code parameter parsing to obtain text strategy data, component structure data, and code parameter data, respectively.

[0073] In one embodiment, the system performs split parsing based on format_i and path_i in the configuration source data: extracting buy conditions, sell conditions, and holding rules from strategy descriptions, comments, or rule texts to obtain text strategy data; extracting component names, component types, and call entry points from component configuration files to obtain component structure data; and extracting variable names, variable values, and data types from scripts or parameter tables to obtain code parameter data.

[0074] S13. Perform field standardization mapping on text strategy data, component structure data, and code parameter data to obtain standard configuration field data;

[0075] In one embodiment, the system calls a field mapping table to uniformly map field names in text strategy data, component structure data, and code parameter data. For example, symbol / ticker (representing the code for trading objects such as securities, futures, funds, or digital assets) is mapped to "trading target," lookback / window (representing the period length for backtracking to historical data when calculating indicators, such as calculating the past 20-day moving average or the past 60-day volatility) is mapped to "lookback period," and factor_func / component_entry (representing the factor calculation function, such as the entry point for the calculation function corresponding to momentum factor, volatility factor, and mean reversion factor) is mapped to "component call entry point." The system represents standard fields as f_i=(K_i,v_i,t_i,p_i,source_i,version_i), where K_i is the normalized field name, v_i is the field value, t_i is the field type, p_i is the field path or code location, and source_i and version_i are inherited from the configuration source data to obtain standard configuration field data.

[0076] S14. Based on the standard configuration field data, the parsing results are encapsulated to obtain the strategy configuration parsing data.

[0077] In one embodiment, the system performs conflict detection and source binding on standard configuration field data. If the same standard field K_i has different values ​​v_i under different sources, a conflict identifier conflict_i is generated; if the values ​​are the same, the source references are merged. The system encapsulates K_i, v_i, t_i, p_i, source_i, version_i, and conflict_i into policy configuration parsing data.

[0078] Optionally, S2 includes:

[0079] S21. Construct field indexes on the strategy configuration parsing data to obtain configuration field index data;

[0080] In one embodiment, the system reads the normalized field name, field value, field type, field path, source identifier, version identifier, and conflict identifier from the policy configuration parsing data. Using the normalized field name and field path as a composite index key, it establishes a field index item: g_i=(K_i,p_i,source_i,version_i,v_i,t_i,conflict_i), where K_i is the normalized field name, p_i is the field path, source_i is the source identifier, version_i is the version identifier, v_i is the field value, t_i is the field type, and conflict_i is the conflict identifier. The system organizes each field index item according to the source identifier, path hierarchy, and field type to obtain the configuration field index data.

[0081] S22. Perform configuration form recognition based on the configuration field index data to obtain configuration form recognition data, wherein configuration form recognition includes text field recognition, component field recognition and code field recognition.

[0082] In one embodiment, the system identifies the configuration form based on the field path p_i, field type t_i, source identifier source_i, and field value v_i in the field index item g_i. If the source identifier source_i points to strategy text, or the field path p_i contains path markers such as rule, signal, and condition, where rule represents a strategy rule path marker, signal represents a signal generation path marker, and condition represents a trigger condition path marker, then a text field form identifier is generated. If the field path p_i contains path markers such as component, factor, risk, and engine, or the field value v_i points to a component call entry point, where component represents a functional component path marker, factor represents a factor component path marker, risk represents a risk control component path marker, and engine represents an execution engine or backtesting engine path marker, then a component field form identifier is generated. If the field type t_i is numeric, boolean, or time-based, and the normalized field name K_i belongs to a threshold, period, ratio, quantity, or switch type field, then a code field form identifier is generated. The system binds the field index item g_i with the configuration shape identifier shape_i to obtain the configuration shape identification data.

[0083] S23. Based on the configuration form recognition data, the field function is labeled to obtain the field function label data;

[0084] In one embodiment, the system assigns a functional affixation to each field index item based on the configuration form identifier `shape_i` in the configuration form identification data. When `shape_i` is a text field form identifier, the system labels the corresponding field as a trading condition, signal rule, buy / sell rule, or position rule; when `shape_i` is a component field form identifier, the system labels the corresponding field as a factor component, data source component, risk control component, execution component, or backtesting component; when `shape_i` is a code field form identifier, the system labels the corresponding field as a period parameter, threshold parameter, ratio parameter, quantity parameter, or switch parameter. The system writes the functional affixation identifier `func_i` into the corresponding field index item to obtain the field functional labeling data.

[0085] S24. Perform heterogeneous logical category matching based on the field function annotation data to obtain logical category matching data, including language strategy category matching, component node category matching, and code parameter category matching.

[0086] In one embodiment, the system performs heterogeneous logical category matching based on the function attribution identifier `func_i` in the field function annotation data. If `func_i` belongs to trading conditions, signal rules, buy / sell rules, or position rules, the corresponding field is matched as a language strategy category; if `func_i` belongs to factor components, data source components, risk control components, execution components, or backtesting components, the corresponding field is matched as a component node category; if `func_i` belongs to period parameters, threshold parameters, ratio parameters, quantity parameters, or switch parameters, the corresponding field is matched as a code parameter category. The system generates a logical category identifier `logic_i` and binds the logical category identifier `logic_i` to the corresponding field index item to obtain logical category matching data.

[0087] S25. Based on the logical category matching data, perform cross-source field association to obtain heterogeneous configuration classification data.

[0088] In one embodiment, the system performs cross-source field associations based on the normalized field name K_i, field path p_i, source identifier source_i, and logical category identifier logic_i in the logical category matching data. If different source fields have the same normalized field name K_i, or field paths p_i have the same path prefix, or are located under the same policy module path, a source association relationship is established. If the associated fields have inconsistent field values ​​v_i, the corresponding conflict identifier conflict_i is retained; if the field values ​​are consistent, their source identifiers and version identifiers are merged. The system encapsulates K_i, v_i, t_i, p_i, source_i, version_i, conflict_i, shape_i, func_i, logic_i, and source association relationships to obtain heterogeneous configuration classification data.

[0089] Optionally, S3 includes:

[0090] S31. Read the configuration category from the heterogeneous configuration classification data to obtain the configuration category read data;

[0091] In one embodiment, the system reads the normalized field name K_i, field value v_i, field type t_i, field path p_i, configuration shape identifier shape_i, function affiliation identifier func_i, logical category identifier logic_i, source identifier source_i, version identifier version_i, and conflict identifier conflict_i from the heterogeneous configuration classification data. The system forms a configuration category read item h_i=(K_i,v_i,t_i,p_i,shape_i,func_i,logic_i,source_i,version_i,conflict_i) for each field, thus obtaining the configuration category read data.

[0092] S32. Based on the configuration category, read the data to decouple the language strategy configuration, component node configuration, and code parameter configuration, and obtain the language strategy configuration data, component decoupling configuration data, and code parameter configuration data, respectively.

[0093] In one embodiment, the system performs traffic splitting based on the logical category identifier `logic_i` in the configuration category read item `h_i`. If `logic_i` is a language strategy category, then the trading conditions, signal rules, buy / sell rules, and position rules are extracted to form language strategy configuration data `L`; if `logic_i` is a component node category, then the component name, component type, and call entry point are extracted to form component decoupling configuration data `C`; if `logic_i` is a code parameter category, then the period, threshold, ratio, quantity, and switch parameters are extracted to form code parameter configuration data `P`.

[0094] S33. Perform cross-layer association marking based on language strategy configuration data, component decoupling configuration data, and code parameter configuration data to obtain three-layer association configuration data;

[0095] In one embodiment, the system performs cross-layer associations based on the field paths p_i inherited by each field in L, C, and P, the normalized field name K_i, and the source association relationships. If the language policy configuration field and the component decoupling configuration field have the same path prefix, or if they have established a source association relationship in cross-source field association, a rule-component association identifier is generated; if the code parameter configuration field and the language policy configuration field have the same path prefix, or if the normalized field name belongs to the parameter field required by the rule, a rule-parameter association identifier is generated, resulting in three-layer association configuration data.

[0096] S34. Perform hierarchical encapsulation based on the three-layer association configuration data to obtain the three-layer strategy configuration data.

[0097] In one embodiment, the system encapsulates the three-layer associated configuration data into a language strategy configuration layer, a component decoupling configuration layer, and a code parameter configuration layer, and retains the source identifier, version identifier, conflict identifier, and cross-layer association identifier corresponding to the fields of each layer. The system represents the three-layer strategy configuration data as D=(L,C,P,R), where L is the language strategy configuration data, C is the component decoupling configuration data, P is the code parameter configuration data, and R is the set of cross-layer association markers used to record the correspondence between the three layers of configuration.

[0098] Optionally, S4 includes:

[0099] S41. Extract configuration units from the three-layer strategy configuration data to obtain strategy configuration unit data;

[0100] In one embodiment, the system reads three-layer strategy configuration data D=(L,C,P,R), where L is language strategy configuration data, C is component decoupling configuration data, P is code parameter configuration data, and R is a set of cross-layer association tags. The system extracts trading conditions, signal rules, buy / sell rules, and position rules from L to form rule units; extracts component names, component types, and call entry points from C to form component units; and extracts period, threshold, ratio, quantity, and switch parameters from P to form parameter units. The system represents each configuration unit as u_i=(unit_id_i,unit_type_i,unit_name_i,unit_value_i,p_i,bind_key_i,source_i,version_i,conflict_i), where unit_type_i includes rule units, component units, and parameter units, and bind_key_i is generated from the normalized field name K_i or field path p_i, used for node port mapping and variable binding, thus obtaining strategy configuration unit data.

[0101] The system generates a binding key `bind_key_i` synchronously when extracting the configuration unit `u_i`. For parameter units, the system generates a binding key based on its normalized field name `K_i`, for example, "lookback period", "stop-loss threshold", and "maximum position ratio" generate corresponding parameter binding keys respectively. For rule units, the system generates a binding key based on the strategy module prefix in its field path `p_i` and the required parameter type, for example, a moving average signal rule with the field path `strategy.signal.ma_cross` generates a binding key of "moving average signal - lookback period". For component units, the system generates a binding key based on the component type, call entry point, and field path, for example, `components.factor.momentum` generates a binding key of "momentum factor component - input parameter". If a cross-layer association marker `R` already exists in the three-layer strategy configuration data, the system preferentially inherits the association key in `R` as `bind_key_i`; if it does not exist, `bind_key_i` is generated based on the path prefix relationship between the normalized field name `K_i` and the field path `p_i`.

[0102] S42. Based on the strategy configuration unit data, perform unified node abstraction to obtain the strategy intermediate node data;

[0103] In one embodiment, the system reads the configuration unit u_i from the policy configuration unit data and performs unified node abstraction based on the configuration unit type unit_type_i. If unit_type_i is a rule unit, a rule node is generated; if unit_type_i is a component unit, a component node is generated; if unit_type_i is a parameter unit, a parameter node is generated. The system represents nodes as: node_i=(node_id_i,node_type_i,unit_name_i,unit_value_i,p_i,bind_key_i), where node_id_i is the node identifier, used to uniquely identify the current node, generated by the configuration unit identifier unit_id_i; node_type_i is the node type, used to indicate whether the current node belongs to a rule node, component node, or parameter node, determined by the configuration unit type unit_type_i; unit_name_i is the configuration unit name, used to represent the rule name, component name, or parameter name corresponding to the node; unit_value_i is the configuration unit value, used to represent the rule content, component call entry point, or parameter value; p_i is the field path, used to represent the path location of the configuration item corresponding to this node in the configuration file or script; and bind_key_i is the configuration unit binding key, used for port mapping and variable binding; thus, the intermediate node data of the policy is obtained.

[0104] S43. Map the input and output ports according to the intermediate node data of the strategy to obtain the node port mapping data;

[0105] In one embodiment, the system generates input and output ports based on the node type `node_type_i` and the binding key `bind_key_i`. If the node is a rule node, condition input ports, parameter input ports, and signal output ports are configured; if the node is a component node, data input ports, parameter input ports, and result output ports are configured; if the node is a parameter node, parameter output ports are configured. The system represents the port mapping as: `port_i = (node_id_i, in_i, out_i)`, where `in_i` is the set of input ports and `out_i` is the set of output ports, thus obtaining the node port mapping data.

[0106] S44. Perform variable binding processing based on the node port mapping data to obtain the node variable binding data;

[0107] In one embodiment, the system reads the input port set in_i and the output port set out_i from the node port mapping data, and reads the field path p_i, configuration unit binding key bind_key_i, and configuration unit value unit_value_i inherited by each node. When the output port out_i of the parameter node has the same configuration unit binding key bind_key_i as the input port in_i of the rule node or component node, or when the field path of the parameter node has the same path prefix as the field path of the rule node or component node, the system establishes a variable binding relationship. The system determines the node providing the variable or parameter as the source node from_node, the rule node or component node receiving the variable or parameter as the target node to_node, the configuration unit binding key that matches successfully between the two nodes as bind_key_i, and the configuration unit value unit_value_i of the parameter node as the variable binding value var_value_i. The system represents the binding relationship as b_i=(from_node,to_node,bind_key_i,var_value_i), thus obtaining the node variable binding data.

[0108] S45. Generate execution relationships based on node variable binding data to obtain strategy execution relationship data;

[0109] In one embodiment, the system generates execution relationships based on the binding relationship b_i in the node variable binding data, the cross-layer association tag set R, and the call entry point inherited by the component node. If the rule node requires the factor result output by the component node, a directed execution edge of call dependency type is established; if the component node requires the parameter node to provide running parameters, a directed execution edge of parameter dependency type is established; if the rule node receives the upstream data source or component calculation result, a directed execution edge of data dependency type is established. The system represents each execution edge as e_i=(from_node,to_node,dep_type_i), where from_node is the dependency output node, to_node is the dependency receiving node, and dep_type_i is the dependency type identifier, including data dependency, parameter dependency, and call dependency. The data source component corresponds to the data input stage, the factor component corresponds to the component calculation stage, the signal rule node corresponds to the signal generation stage, the risk control component or risk control rule node corresponds to the risk control verification stage, and the execution component corresponds to the transaction execution stage. The system organizes all execution edges e_i in the order of data input, component calculation, signal generation, risk control verification, and transaction execution to form the execution relationship set E, thus obtaining the strategy execution relationship data.

[0110] S46. Encapsulate the intermediate representation based on the strategy execution relationship data to obtain the strategy intermediate representation data.

[0111] In one embodiment, after obtaining the policy execution relationship data, the system reads the policy intermediate node data, node port mapping data, node variable binding data, and policy execution relationship data generated in the preceding steps, and forms a node set N, a port mapping set Port, a variable binding set B, and an execution relationship set E, respectively. N consists of all nodes node_i, Port consists of all port mappings port_i, B consists of all variable binding relationships b_i, and E consists of all execution edges e_i. The system encapsulates these sets into policy intermediate representation data IR=(N,Port,B,E), and writes the source identifier, version identifier, and conflict identifier corresponding to each node, port, binding relationship, and execution edge into the policy intermediate representation data.

[0112] Optionally, S5 includes:

[0113] S51. Extract node dependencies from the intermediate representation data of the strategy to obtain node dependency data;

[0114] In one embodiment, the system reads the intermediate representation data IR=(N,Port,B,E), where N is the node set, Port is the port mapping set, B is the variable binding set, and E is the execution relationship set. The system traverses the execution edges e_i=(from_node,to_node,dep_type_i) in the execution relationship set E, and searches for binding relationships b_i with the same source node and target node in the variable binding set B, extracting the corresponding configuration unit binding key bind_key_i and variable binding value var_value_i. The system represents the node dependency as d_i=(from_node,to_node,dep_type_i,bind_key_i,var_value_i), thus obtaining the node dependency data.

[0115] S52. Perform variable call chain verification based on node dependency data to obtain variable dependency verification data;

[0116] In one embodiment, the system performs variable call chain verification based on node dependency data, the port mapping set Port, and the variable binding set B. The system reads the input port set of the target node to_node and the output port set of the source node from_node. If the required binding key of the target node is consistent with bind_key_i in the node dependency, and the variable binding value var_value_i exists, then the variable call chain is considered to be successful. If no corresponding binding key is found or the variable binding value is empty, a variable missing identifier var_lack_i is generated, and variable dependency verification data is obtained.

[0117] S53. Perform interface matching and verification based on variable dependency verification data to obtain interface dependency verification data;

[0118] In one embodiment, the system reads variable dependency verification data and obtains the call entry point inherited by the component node from the node set N, and obtains the corresponding input port and output port from the port mapping set Port. If the call entry point of the component node is empty, or the input port type is inconsistent with the upstream output port type, or the component output port cannot be received by the downstream node, an interface error flag api_error_i is generated; otherwise, an interface pass flag is generated, and interface dependency verification data is obtained.

[0119] S54. Perform execution order verification based on interface dependency verification data to obtain execution order verification data;

[0120] In one embodiment, the system performs execution order verification based on interface dependency verification data and the execution relationship set E. The system performs topological sorting of nodes according to the direction of execution edges to obtain candidate execution sequences; if the source node from_node in each execution edge is located before the target node to_node, the order passes; if the target node executes before the source node, or if there is a circular dependency, an order error flag order_error_i is generated, and execution order verification data is obtained.

[0121] S55. Generate program structure based on execution order verification data to obtain strategy program data.

[0122] In one embodiment, the system reads execution order verification data. If there are no missing variable flags (var_lack_i), interface exception flags (api_error_i), and order exception flags (order_error_i), the system generates a strategy program structure according to the verified candidate execution sequence. The system converts rule nodes into rule execution blocks, component nodes into component call blocks, and parameter nodes into parameter assignment blocks, and generates a rule execution order, component call sequence, and parameter assignment table. If there are exception flags, the exception flags are written into the exception confirmation item. The system encapsulates the rule execution order, component call sequence, parameter assignment table, exception confirmation item, and source version record to obtain strategy program data. After the execution order verification passes, the system performs topological sorting on the nodes according to the directed execution edges e_i=(from_node,to_node,dep_type_i) in the execution relationship set E to obtain a node execution sequence; then, it filters rule nodes from the node execution sequence and generates a rule execution order according to the order of the rule nodes in the node execution sequence. If there are dependency edges between rule nodes, the dependent output rule precedes the dependent receiving rule. If there are no direct dependencies between rule nodes, they are sorted according to the execution stage corresponding to their node type; for example, signal rules precede buy / sell rules, and risk control rules precede transaction execution-related rules. The system filters component nodes from the node execution sequence and reads the component name, component type, and call entry point inherited by the component node. Component nodes on the same execution path are arranged according to the direction of the execution edge to generate a component call sequence. For example, the data source component precedes the factor component, the factor component precedes the risk control component, and the risk control component precedes the execution component. If there are call dependencies between component nodes, the call output component precedes the receiving input component. The system filters parameter nodes from the node execution sequence and generates a parameter assignment table by combining the variable binding set B. For each variable binding relationship b_i=(from_node,to_node,bind_key_i,var_value_i), if from_node is a parameter node, bind_key_i is used as the parameter name or parameter key, var_value_i is used as the parameter value, and its target node to_node is recorded to form a parameter assignment item. The system merges all parameter assignment items according to the target node and the source version to obtain the parameter assignment table.

[0123] Optionally, variable call chain verification includes:

[0124] S521. Identify cross-morphological variable source points based on node dependency data to obtain variable source point data;

[0125] In one embodiment, the system reads node dependency data d_i=(from_node,to_node,dep_type_i,bind_key_i,var_value_i) and identifies the variable source point based on the node type of the source node from_node. If from_node is a parameter node, it is identified as a parameter source point; if from_node is a component node, it is identified as a component computation source point; if from_node is a rule node, it is identified as a rule result source point. The system represents the variable source point as s_i=(src_node_i,src_type_i,to_node_i,bind_key_i,var_value_i), where src_node_i corresponds to from_node, src_type_i is the source of the node type of from_node, and to_node_i corresponds to the target node receiving the variable, thus obtaining the variable source point data.

[0126] S522. Generate variable semantic fingerprints based on variable source point data to obtain variable semantic fingerprint data;

[0127] In one embodiment, the system generates a variable semantic fingerprint based on the source node src_node_i, target node to_node_i, binding key bind_key_i, and variable binding value var_value_i in the variable source node data. The system reads the field path p_i inherited from the source node from the node set N, and generates a path tag path_tag_i based on the field path prefix; it also generates a value type value_type_i based on the data type of var_value_i. The system represents the variable semantic fingerprint as fp_i=(bind_key_i,src_type_i,value_type_i,path_tag_i,to_node_i), thus obtaining the variable semantic fingerprint data.

[0128] S523. Perform cross-layer variable binding based on variable semantic fingerprint data to obtain variable binding data;

[0129] In one embodiment, the system performs cross-layer variable binding based on variable semantic fingerprint data and the port mapping set Port. The system reads the input port requirements of the target node to_node_i. If the binding key bind_key_i in the variable semantic fingerprint is consistent with the target input port requirements, and the value type value_type_i meets the target port type requirements, then a cross-layer variable binding relationship is established. The system represents the binding relationship as vb_i=(src_node_i,to_node_i,bind_key_i,value_type_i,var_value_i), obtaining variable binding data. Here, src_node_i is the variable source node, representing the parameter node, component node, or rule node that outputs the variable; to_node_i is the variable target node, representing the rule node or component node that receives the variable; bind_key_i is the variable binding key, representing the matching identifier between the source node's output variable and the target node's input port; value_type_i is the variable value type, representing the data type of the bound variable value, including numeric, character, boolean, time, or list types; and var_value_i is the variable binding value, representing the specific parameter value, component calculation result, or rule output result output by the variable source node and passed to the variable target node.

[0130] S524. Construct the variable call chain skeleton based on the variable binding data to obtain the variable call chain skeleton data;

[0131] In one embodiment, the system constructs a variable call chain skeleton based on the variable binding data vb_i and the execution edge directions in the execution relationship set E. If a variable is output from a parameter node, processed by a component node, and then passed to a rule node, the system connects the source node, intermediate component node, and target node sequentially according to the execution edge directions. The system represents the variable call chain skeleton as chain_i=(src_node_i,mid_node_i,to_node_i,bind_key_i), where mid_node_i is an optional intermediate node, thus obtaining the variable call chain skeleton data.

[0132] S525. Perform variable path reachability verification on the variable call chain skeleton data to obtain variable path verification data;

[0133] In one embodiment, the system reads the execution relationship set E from the intermediate representation data of the strategy and performs reachability verification on the variable call chain skeleton according to the direction of the execution edge. If the target node to_node_i can be reached from the variable source node src_node_i along the execution edge, a path reachability identifier is generated; if the link is interrupted, an intermediate node is missing, or the execution edge direction is reversed, a path unreachability identifier path_fail_i is generated, and variable path verification data is obtained.

[0134] S526. Perform variable form conversion verification based on variable path verification data to obtain variable form verification data;

[0135] In one embodiment, the system performs variable form conversion verification on the variable call chain reachable by the path. The system determines whether the variable form matches the value type (value_type_i) in the variable semantic fingerprint and the input port type of the target node; if a numeric variable is passed to a numeric port, or a list variable is passed to a list port, the conversion passes; if a numeric variable is passed to a boolean port, or a list result is passed to a single-value port, a form anomaly identifier (type_fail_i) is generated, and variable form verification data is obtained.

[0136] S527. Perform variable scope penetration verification on the variable form verification data to obtain variable scope verification data.

[0137] In one embodiment, the system performs scope penetration verification based on the field path p_i inherited by each node in the variable call chain, the path tag path_tag_i, and the cross-layer association identifier inherited by the execution edge. If the variable is passed between nodes with the same policy path prefix, or between nodes on the same component call chain, or between nodes with cross-layer association identifiers, then scope penetration is determined to be successful; if the variable is passed from a module without an associated path to the target node, then a scope exception identifier scope_fail_i is generated, and variable scope verification data is obtained.

[0138] S528. Based on the variable scope verification data, determine the variable chain closure to obtain variable dependency verification data.

[0139] In one embodiment, the system aggregates path reachability results, variable morphology conversion results, and scope penetration results under the same binding key `bind_key_i`. If the variable call chain `chain_i` in the variable call chain skeleton data does not contain the path unreachability identifier `path_fail_i`, the morphology exception identifier `type_fail_i`, and the scope exception identifier `scope_fail_i`, then a variable chain closure identifier is generated; otherwise, a variable exception identifier is generated. The system encapsulates the variable chain closure identifier, the variable exception identifier, and the corresponding variable call chain to obtain variable dependency verification data.

[0140] Optionally, the variable call chain skeleton construction includes:

[0141] a. Locate the source of the bound variables based on the bound variable data to obtain the source data of the variables;

[0142] In one embodiment, the system reads the variable binding data vb_i=(src_node_i,to_node_i,bind_key_i,value_type_i,var_value_i), and determines the src_node_i of the output variable as the source end of the binding variable. The system then searches for the output port in the port mapping set Port based on src_node_i, and determines the output port that matches bind_key_i as src_port_i. The system represents the variable source end as src_i=(src_node_i,src_port_i,bind_key_i,var_value_i,value_type_i), thus obtaining the variable source end data. Wherein, src_i is the variable source data item; src_node_i is the variable source node, used to represent the parameter node, component node, or rule node of the output variable; src_port_i is the variable source port, used to represent the port from which the variable is output from the variable source node; bind_key_i is the variable binding key, used to represent the matching identifier between the variable and the target input port; var_value_i is the variable binding value, used to represent the specific parameter value, component calculation result, or rule output result output by the source node; and value_type_i is the variable value type, used to represent the data type of the variable binding value, including numeric, character, boolean, time, or list types.

[0143] b. Identify the target variables based on the source data to obtain the target data.

[0144] In one embodiment, the system identifies the target endpoint of a variable based on the `to_node_i` in the variable binding data and the port mapping set `Port`. The system reads the input port set of the target node `to_node_i`. If there is an input port requirement consistent with `bind_key_i`, the system identifies that input port as the target port `tgt_port_i` and reads the required data type `required_type_i` for that port. The system represents the target endpoint as `tgt_i = (to_node_i, tgt_port_i, bind_key_i, required_type_i)`, thus obtaining the target endpoint data. Wherein, tgt_i is the target data item of the variable; to_node_i is the target node of the variable, used to represent the rule node or component node that receives the variable; tgt_port_i is the target port of the variable, used to represent the input port in the target node that receives the variable; bind_key_i is the variable binding key, used to represent the matching identifier between the source port and the target port of the variable; required_type_i is the target port requirement type, used to represent the data type requirements of the target port for the input variable, including numeric, character, boolean, time, or list types.

[0145] c. Generate cross-morphological call edges based on the variable source data and variable target data to obtain variable call edge data;

[0146] In one embodiment, the system matches the source data `src_i` and the target data `tgt_i`. If they have the same `bind_key_i`, and the variable value type `value_type_i` satisfies the target's required type `required_type_i`, then a cross-morphological variable call edge is established. The system represents the variable call edge as `ve_i=(src_node_i,to_node_i,bind_key_i,call_type_i)`, where `call_type_i` is the variable call type, thus obtaining the variable call edge data. Wherein, ve_i is the variable call edge data item; src_node_i is the variable source node, used to represent the parameter node, component node, or rule node of the output variable; to_node_i is the variable target node, used to represent the rule node or component node that receives the variable; bind_key_i is the variable binding key, used to represent the matching identifier between the variable source node and the variable target node; call_type_i is the variable call type, used to represent the way the variable is passed between different node forms, including parameter to rule, parameter to component, component to rule, component to component, rule to component, or rule to rule.

[0147] d. Based on the variable call edge data, complete the variable relay node to obtain the variable relay path data;

[0148] In one embodiment, the system reads the execution relationship set E from the intermediate representation data of the strategy, and determines whether there is a direct execution edge between the source node src_node_i and the target node to_node_i based on the variable call edge ve_i. If a direct execution edge exists, the relay node set Mid_i is set to empty; if no direct execution edge exists, but the target node can be reached by traversing one or more component nodes along the execution edge, the traversed component nodes are written into the relay node set Mid_i. The system forms a variable relay path route_i=(src_node_i, Mid_i, to_node_i, bind_key_i), obtaining the variable relay path data. Wherein, route_i is the variable relay path data item; src_node_i is the variable source node, used to represent the parameter node, component node, or rule node of the output variable; Mid_i is the relay node set, used to represent one or more component nodes, rule nodes, or transformation nodes that the variable passes through during the process of being passed from the source node to the target node. If the variable can directly reach the target node, then Mid_i is an empty set; to_node_i is the variable target node, used to represent the rule node or component node that receives the variable; bind_key_i is the variable binding key, used to represent the variable matching identifier corresponding to the variable relay path.

[0149] e. Encapsulate the call chain skeleton based on the variable relay path data to obtain the variable call chain skeleton data.

[0150] In one embodiment, the system encapsulates the variable call chain skeleton based on the variable relay path data. If the relay node set Mid_i is empty, the call chain skeleton is chain_i=(src_node_i,to_node_i,bind_key_i); if the relay node set Mid_i is not empty, the call chain skeleton is chain_i=(src_node_i,Mid_i,to_node_i,bind_key_i). The system encapsulates the variable call chain skeleton, variable call edges, variable binding keys, variable value types, and relay node sets to obtain the variable call chain skeleton data.

[0151] Optionally, S6 includes:

[0152] S61. Extract program configuration items from the strategy program data to obtain program configuration item data;

[0153] In one embodiment, the system reads the rule execution order, component call sequence, parameter assignment table, pending exception items, and source version records from the policy program data, and extracts program configuration items according to their configuration purpose. The system represents each program configuration item as pc_i=(item_id_i,item_type_i,item_value_i,source_i,version_i,conflict_i), thus obtaining the program configuration item data. Wherein, pc_i is the program configuration item data item; item_id_i is the configuration item identifier, used to uniquely identify the current program configuration item, generated by the configuration item sequence number, configuration item type, and source identifier; item_type_i is the configuration item type, used to indicate whether the current program configuration item belongs to a rule item, component item, parameter item, or environment item, including rule items, component items, parameter items, and environment items. Environment items are extracted from the data source interface, backtesting engine, execution interface, and component running version in the component call sequence; item_value_i is the configuration item value, used to represent the rule content, component call entry point, parameter value, or environment configuration content; source_i is the source identifier, used to indicate the original configuration source corresponding to this configuration item; version_i is the version identifier, used to indicate the configuration version to which this configuration item belongs; conflict_i is the conflict identifier, used to indicate whether this configuration item has cross-source value conflicts or unresolved conflicts.

[0154] S62. Perform configuration source verification based on the program configuration item data to obtain source verification data;

[0155] In one embodiment, the system performs source verification based on the source identifier (source_i) and version identifier (version_i) in the program configuration item data. If the program configuration item has a valid source identifier and version identifier, and they are consistent with the source version record in the policy program data, a source pass identifier is generated; if the source is missing, the version is inconsistent, or the conflict identifier corresponding to the source is not resolved, a source error identifier (src_error_i) is generated, and source verification data is obtained.

[0156] S63. Verify the configuration parameters based on the source verification data to obtain parameter verification data;

[0157] In one embodiment, the system reads parameter items from the source verification data and performs parameter verification based on the parameter item's configuration value (item_value_i) and configuration type (item_type_i). If the review period is a positive integer, the ratio parameter is between 0 and 1, the switch parameter is a Boolean value, and the time window conforms to the trading day format, a parameter pass flag is generated; if the parameter is missing, of the wrong type, or out of bounds, a parameter error flag (param_error_i) is generated, and parameter verification data is obtained.

[0158] S64. Perform execution environment adaptation verification based on parameter integrity verification data to obtain environment adaptation verification data;

[0159] In one embodiment, the system reads the environment item from the parameter verification data and program configuration item data to perform adaptation verification between the strategy program and the execution environment. If the data source interface supports the corresponding trading target and time granularity, the component call entry exists, the backtesting engine version meets the configuration requirements, and the execution interface supports the target instruction format, then an environment pass flag is generated; if the component entry is missing, the engine version does not match, the data interface does not support the code, or the execution interface format does not match, then an environment error flag env_error_i is generated, and environment adaptation verification data is obtained.

[0160] S65. Perform configuration conflict verification based on environment adaptation verification data to obtain configuration conflict verification data;

[0161] In one embodiment, the system reads the conflict identifier `conflict_i` from the environment adaptation verification data and program configuration items, and reviews the aforementioned conflict items. If the value of the same configuration item in different sources has been confirmed by the priority source rule, or the conflict item has been marked as an acceptable difference in the abnormal pending confirmation items, a conflict resolution identifier is generated; if there are still inconsistent values ​​under different versions, different sources, or different levels, a conflict retention identifier `conflict_keep_i` is generated, and configuration conflict review data is obtained.

[0162] S66. Based on the configuration conflict review data, encapsulate the decoupling results to obtain the decoupled configuration results.

[0163] In one embodiment, the system summarizes the results of source verification, parameter verification, environment adaptation verification, and configuration conflict review. If src_error_i, param_error_i, env_error_i, and conflict_keep_i do not exist, a verification pass flag is generated; otherwise, a verification failure flag and the reason for the exception are generated. The system encapsulates the verification flag, the reason for the exception, the source version record, the conflict review result, and the executable configuration summary extracted from the execution order of the verified rules, the component call sequence, and the parameter assignment table to obtain the decoupled configuration result.

[0164] Therefore, the embodiments should be regarded as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended application documents rather than the foregoing description. Thus, it is intended that all variations falling within the meaning and scope of the equivalents of the application documents be incorporated into the invention.

[0165] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A three-layer decoupling configuration method for quantitative strategies based on financial heterogeneous logic, characterized in that, The method includes: S1. Obtain the quantitative strategy configuration data, and perform multi-source configuration parsing based on the quantitative strategy configuration data to obtain the strategy configuration parsing data; S2. Construct field indexes on the strategy configuration parsing data to obtain configuration field index data; perform configuration form recognition based on the configuration field index data to obtain configuration form recognition data, wherein configuration form recognition includes text field recognition, component field recognition, and code field recognition; perform field function attribution labeling based on the configuration form recognition data to obtain field function labeling data; perform heterogeneous logical category matching based on the field function labeling data to obtain logical category matching data, wherein heterogeneous logical category matching includes language strategy category matching, component node category matching, and code parameter category matching; perform cross-source field association based on the logical category matching data to obtain heterogeneous configuration classification data. S3. Read the configuration categories from the heterogeneous configuration classification data to obtain configuration category read data; decouple language strategy configuration, component node configuration, and code parameter configuration based on the configuration category read data to obtain language strategy configuration data, component decoupled configuration data, and code parameter configuration data, respectively; perform cross-layer association marking based on the language strategy configuration data, component decoupled configuration data, and code parameter configuration data to obtain three-layer associated configuration data; perform hierarchical encapsulation based on the three-layer associated configuration data to obtain three-layer strategy configuration data. S4. Extract configuration units from the three-layer strategy configuration data to obtain strategy configuration unit data; perform unified node abstraction based on the strategy configuration unit data to obtain strategy intermediate node data; perform input / output port mapping based on the strategy intermediate node data to obtain node port mapping data; perform variable binding processing based on the node port mapping data to obtain node variable binding data; generate execution relationships based on the node variable binding data to obtain strategy execution relationship data; encapsulate intermediate representation based on the strategy execution relationship data to obtain strategy intermediate representation data. S5. Extract node dependencies from the intermediate representation data of the strategy to obtain node dependency data; perform variable call chain verification based on the node dependency data to obtain variable dependency verification data; perform interface matching verification based on the variable dependency verification data to obtain interface dependency verification data; perform execution order verification based on the interface dependency verification data to obtain execution order verification data; and generate the program structure based on the execution order verification data to obtain strategy program data. S6. Perform policy configuration verification on the policy program data to obtain the decoupled configuration result; Variable call chain verification includes: Based on node dependency data, cross-morphological variable source point identification is performed to obtain variable source point data; based on the variable source point data, variable semantic fingerprint generation is performed to obtain variable semantic fingerprint data; based on the variable semantic fingerprint data, cross-layer variable binding is performed to obtain variable binding data; based on the variable binding data, variable call chain skeleton is constructed to obtain variable call chain skeleton data; variable path reachability is verified on the variable call chain skeleton data to obtain variable path verification data; based on the variable path verification data, variable morphological transformation verification is performed to obtain variable morphological verification data; based on the variable morphological verification data, variable scope penetration verification is performed to obtain variable scope verification data; based on the variable scope verification data, variable chain closure is determined to obtain variable dependency verification data.

2. The method according to claim 1, characterized in that, S1 includes: The input source of the quantization strategy configuration data is identified to obtain configuration source data; semantic field extraction, component structure parsing, and code parameter parsing are performed based on the configuration source data to obtain text strategy data, component structure data, and code parameter data, respectively. The text strategy data, component structure data, and code parameter data are standardized and mapped to obtain standard configuration field data; the parsing results are then encapsulated based on the standard configuration field data to obtain strategy configuration parsing data.

3. The method according to claim 1, characterized in that, The variable call chain skeleton construction includes: Based on the variable binding data, the source end of the bound variable is located to obtain the variable source end data; based on the variable source end data, the target end of the variable is identified to obtain the variable target end data; based on the variable source end data and the variable target end data, cross-morphological call edge is generated to obtain the variable call edge data; based on the variable call edge data, variable relay nodes are completed to obtain the variable relay path data; based on the variable relay path data, the call chain skeleton is encapsulated to obtain the variable call chain skeleton data.

4. The method according to claim 1, characterized in that, S6 include: Extract program configuration items from the strategy program data to obtain program configuration item data; perform configuration source verification based on the program configuration item data to obtain source verification data; The configuration parameters are validated based on the source validation data to obtain parameter validation data. Based on the parameter integrity verification data, an execution environment adaptation verification is performed to obtain environment adaptation verification data; Based on the environment adaptation verification data, configuration conflict review is performed to obtain configuration conflict review data; based on the configuration conflict review data, decoupling results are encapsulated to obtain decoupled configuration results.

Images