A verifiable inference workflow generation and deployment method

Abstract

The application discloses a verifiable reasoning workflow generation and deployment method, and relates to the technical field of electric data processing.The intermediate representation with port declaration, resource declaration and minimum operator set version is constructed, the contract derivation function is called to generate and materialize the effective input and output port contract; the engineering snapshot containing the resource path and content digest is generated and recalculated and verified when exported; the output boundary is traversed reversely to cut the necessary deployment subgraph; the highest and lowest operator set version in the cut subgraph is determined as the deployment minimum version; the resource namespace is established according to the node identification, the path is rewritten, the custom operator is packaged, and the deployment package is generated; the minimum operator set version and the port contract are verified when the server loads, only the output reachable operator node is instantiated, and the actual input and output are verified node by node to be consistent with the contract.The application realizes the error interception before the reasoning workflow deployment, the reproducible deployment result and the consistent local and server execution semantics.

Description

Technical Field

[0001] This invention relates to the field of electrical data processing technology, and more specifically to a method for generating and deploying verifiable inference workflows. Background Technology

[0002] With the application of deep learning models in industrial vision inspection, dimensional measurement, robot guidance, and other scenarios, a single model typically cannot directly complete the entire business process. The actual inference process often includes multiple steps such as image decoding, dimensional transformation, normalization, model inference, result filtering, coordinate restoration, geometric calculation, and business decision-making. Existing technologies typically organize these steps into computational graphs or directed acyclic graphs and deploy them through model service systems. Among related technologies, specifications such as ONNX provide representations such as scalable computational graphs, standard data types, and operator set versions; inference servers such as Triton provide organizational methods such as model repositories, version directories, and model configuration files. Furthermore, existing technologies have proposed solutions such as schema compatibility judgment between adjacent operators, static address binding that brings service discovery forward to the construction phase, precise matching based on interface contract hash digests, and generating immutable release artifacts.

[0003] However, the existing technologies mentioned above still have shortcomings in engineering applications for configurable visual inference workflows. The number of ports, port names, data types, or dimensions of some operators are jointly determined by node parameters, model assets, or connected input ports. Using only a fixed port table cannot accurately represent the actual running contract during the editing phase. Delaying the derivation to the runtime phase can easily lead to discovering missing ports, inconsistent types, or mismatched dimensions only after deployment. A complete workflow often contains a formal inference path, debug nodes, preview branches, and backup models simultaneously. Directly packaging these will introduce irrelevant operators and resources, increasing package size, initialization time, and deployment environment requirements. Model paths, template graph paths, and other resource paths in the workflow typically point to the local file system. Simply copying workflow files cannot guarantee the complete transfer of resources and correct path rewriting; resources with the same name on different nodes may also be overwritten. Custom operators imported locally through the development environment may not exist in the deployment environment; simply packaging the model files will cause the server to fail to load them. There is a lack of immutable boundaries between the project editing state and the deployment state. When model files, template files, or node parameters change after verification, the exported results may be inconsistent with the previous verification results, making them difficult to reproduce. The version of the operator set declared in the overall workflow may be raised by nodes that did not participate in the final output. If the version requirements of the complete project are used during deployment, it will unnecessarily restrict the deployment environment. If version verification is not performed at all, semantically incompatible operator implementations may be loaded. Therefore, a method for generating and deploying inference workflows that forms a unified closed loop, integrating port contract derivation, project snapshot, output reachability subgraph pruning, operator version calculation, resource encapsulation, and service runtime generation, is needed. Summary of the Invention

[0004] To create a unified closed-loop inference workflow encompassing port contract derivation, project snapshots, output reachability subgraph pruning, operator version calculation, resource encapsulation, and service runtime generation, this invention proposes a verifiable inference workflow generation and deployment method, including the following steps: S1: Construct an intermediate representation that includes input / output boundaries, operator nodes, and connections. Operator nodes have identifiers, operator types, input / output port declarations, node parameters, resource declarations, custom operator declarations, and minimum operator set versions. S2: Based on the node parameters, resource declarations, port declarations, and connected input ports, call the corresponding contract derivation function to generate valid input / output port contracts and then write them into the intermediate representation; S3: Generates a project snapshot containing the rewritten intermediate representation, the resource paths referenced by the resource declarations, and their content summaries. During export, the resource content summaries are recalculated based on the selected snapshot; if they are inconsistent, the export is prevented. S4: Based on the selected snapshot, traverse the input connections in reverse from the output boundary to determine the set of output reachable nodes, and trim to obtain the necessary deployment subgraph containing only the nodes, connections, resource references and custom operator code of that set; S5: Determine the highest version among the lowest operator subset versions of each operator type in the necessary deployment subgraph as the lowest operator subset version of the deployment workflow; S6: Based on the selected snapshot, establish a resource namespace by node identifier and rewrite the resource path, encapsulate custom operators, and generate a deployment package containing service configuration, runtime entry point, port contract, minimum operator set version, and resource directory; S7: When the server loads the deployment package, it verifies the minimum operator set version and port contract, instantiates only the output reachable operator node, and verifies that the actual input and output are consistent with the port contract before and after execution of each output reachable operator node.

[0005] This invention achieves the following through contract derivation materialization, resource summary snapshot verification, output reachable subgraph pruning, determining the minimum operator set version based on the pruned subgraph, node-level resource namespace and custom operator encapsulation, and server-side node-by-node contract verification. This enables the inference workflow to detect port and resource errors before deployment, ensure consistency between deployment content and verification status, reduce the deployment package size and maintain compatibility with the runtime environment, while maintaining semantic consistency between local and server execution.

[0006] Furthermore, the operator node includes a fixed port operator and a dynamic port operator. In step S2, for the fixed port operator, a predefined contract is output; for the dynamic port operator, an actual port set is generated based on the node parameters, the input and output descriptions in the model file referenced by the resource declaration, the measurement result items configured in the node parameters, or the connected input ports.

[0007] Furthermore, in step S2, when the operator type, node parameters, or resource declaration changes, the corresponding contract derivation function is called again; when the connection changes, at least the input ports of the dynamic port operators affected by the connection are re-derived; the ports that are allowed to be retained in the input / output port declaration are merged with the derivation results according to the preset merging rules.

[0008] Furthermore, in step S2, for ports that cannot be statically determined and belong to the input-output boundary or intermediate results between output reachable nodes, export is prevented and the missing fields and reasons for not being able to be derived are returned; when the data types of the upstream output port and the downstream input port are incompatible but automatic conversion is allowed, a data conversion operator node is inserted, which participates in snapshot saving, contract verification, subgraph pruning and operation.

[0009] Furthermore, in step S3, the resource content digest is calculated using the SHA-256 algorithm; the project snapshot is saved by writing to a temporary file in the same directory, refreshing the data, and replacing it atomically; when exporting, only the project snapshot explicitly selected by the user is accepted, and the intermediate representation of the editing state is not directly read.

[0010] Furthermore, in step S4, when there are multiple output boundaries, multiple necessary deployment subgraphs are generated respectively, or a joint necessary deployment subgraph is generated according to the set of output boundaries selected by the user; a stable topological order is regenerated for the nodes in the set of output reachable nodes.

[0011] Furthermore, in step S6, when establishing a resource namespace by node identifier and rewriting the resource path, the following security constraints are executed: the resource target path is prohibited from escaping the node resource namespace; different resources of the same node are prohibited from being written to the same target path; symbolic links are prohibited from being packaged; for the external data directory of the model referenced in the resource declaration, the main model file is required to be located in the declared external data directory; the export is terminated when the resource does not exist or the type does not match the declaration.

[0012] Furthermore, in step S6, operators in the operator node other than the custom operators corresponding to the custom operator declaration are regarded as built-in operators; for custom operators that are not built-in operators, their module files are extracted and copied to the custom operator directory in the deployment package to generate a unified import entry, so that the server can complete the registration of custom operators before loading the workflow; the target path of the resource includes the node identifier and the resource root directory.

[0013] Further, in step S7, the server starts in the following order: loads the built-in operators and the custom operators in the deployment package; reads the port contract in the deployment package and verifies the minimum operator set version; verifies the port contract; instantiates only the operator nodes in the output reachable nodes and parses the rewritten resource paths; executes the output reachable operator nodes in a stable topology order or a parallel scheduling method that satisfies dependencies; verifies that the actual input data is consistent with the input port contract before each output reachable operator node is executed, and verifies that the actual output data is consistent with the output port contract after execution.

[0014] Furthermore, in step S7, the server compares the lowest operator set version of the deployed workflow with the operator set version supported by the runtime environment. If the operator set version supported by the runtime environment is lower than the lowest operator set version, the workflow will be rejected. If the operator set version declared in the workflow description is lower than the aggregated version of the current operator implementation for the used operators, a non-blocking compatibility warning will be generated.

[0015] Compared with the prior art, the present invention has at least the following beneficial effects: (1) The present invention proposes a verifiable inference workflow generation and deployment method, which statically transforms the port contracts in the inference workflow that were originally determined by node parameters, resource declarations and connection relationships and may only be determined at runtime before exporting by port contract derivation and materialization, resource content summary snapshot, output reachable subgraph pruning, calculation of the lowest subset version based on the pruned subgraph, node-level resource isolation encapsulation and server-side node-by-node contract verification, and binds the verified workflow state with the resource content, so that export and deployment are only based on the selected snapshot; (2) After trimming, only the nodes, connections, resource references and custom operator code that the output truly depends on are retained, avoiding debugging, preview and backup branches from entering the deployment package, and avoiding irrelevant nodes from raising the minimum operator set version; node-level resource namespaces, path rewriting and security constraints can reduce the risk of resource overwriting with the same name, path escape and symbolic links, and unified registration of custom operators can reduce the problem of local operation but lack of modules on the server. (3) When the server loads, it verifies the minimum operator set version and port contract, only instantiates the output reachable operator node, and verifies that the actual input and output are consistent with the contract before and after execution, so as to discover inconsistencies in port, type, dimension and resources before deployment or in the early stage of operation, thereby improving the reproducibility of deployment results and error location capabilities. Attached Figure Description

[0016] Figure 1 This is a step diagram of a verifiable inference workflow generation and deployment method. Detailed Implementation

[0017] The following are specific embodiments of the present invention, which are described in conjunction with the accompanying drawings to further illustrate the technical solutions of the present invention. However, the present invention is not limited to these embodiments.

[0018] In inference applications for industrial vision inspection, dimensional measurement, and robot guidance, a single model typically cannot directly complete the entire business logic. The actual inference process often includes multiple stages such as image decoding, dimensional transformation, normalization, model inference, result filtering, coordinate restoration, geometric calculation, and business logic determination. These stages are usually organized as computational graphs or directed acyclic graphs and deployed through a model service system. However, the number of ports, port names, data types, or dimensions of some operators are jointly determined by node parameters, model assets, or already connected input ports. If only a fixed port table for operator classes is used, the actual execution contract cannot be accurately expressed during the editing phase. If the inference is delayed until runtime, it is easy to discover missing ports, inconsistent data types, or mismatched dimensions only after deployment. In addition, local projects often contain formal inference paths, debugging nodes, preview branches, and backup models simultaneously. Directly packaging the complete workflow will bring irrelevant operators, irrelevant models, and higher version dependencies into the deployment package, increasing the package size, initialization time, and deployment environment requirements. The model paths, template paths, and other resource paths in workflow files typically point to the local file system. Simply copying the workflow file cannot guarantee that resources will be completely carried over, nor can it guarantee that paths will still point to the correct resources after rewriting. Overwriting may also occur when resources with the same name exist on different nodes. Custom operators are imported locally through the development environment, but the corresponding modules may not exist in the deployment environment. Packaging only the model files without packaging the custom operator registration code will result in issues where the program runs locally but fails to load on the server. There is a lack of immutable boundaries between the project editing state and the deployment state. If the model files, template files, or node parameters change after editing, the exported results may be inconsistent with the previously verified results, making it difficult to reproduce. The version of the operator set declared in the overall workflow may be raised by nodes that did not participate in the final output. If the version requirements of the complete project are still used during deployment, it will unnecessarily restrict the deployment environment. If version verification is not performed at all, semantically incompatible operator implementations may be loaded.

[0019] To address the aforementioned issues, this invention establishes a unified closed loop encompassing port contract derivation, project snapshots, output reachable subgraph pruning, minimum operand subset version calculation, resource encapsulation, and service runtime generation. It proposes a verifiable inference workflow generation and deployment method that enables type or dimension errors to be detected before deployment, reducing server startup failures and runtime errors, and improving the reproducibility of deployment results and fault diagnosis efficiency. Figure 1 As shown, the steps include: S1: Construct an intermediate representation that includes input / output boundaries, operator nodes, and connections. Operator nodes have identifiers, operator types, input / output port declarations, node parameters, resource declarations, custom operator declarations, and minimum operator set versions. S2: Based on the node parameters, resource declarations, port declarations, and connected input ports, call the corresponding contract derivation function to generate valid input / output port contracts and then write them into the intermediate representation; S3: Generates a project snapshot containing the rewritten intermediate representation, the resource paths referenced by the resource declarations, and their content summaries. During export, the resource content summaries are recalculated based on the selected snapshot; if they are inconsistent, the export is prevented. S4: Based on the selected snapshot, traverse the input connections in reverse from the output boundary to determine the set of output reachable nodes, and trim to obtain the necessary deployment subgraph containing only the nodes, connections, resource references and custom operator code of that set; S5: Determine the highest version among the lowest operator subset versions of each operator type in the necessary deployment subgraph as the lowest operator subset version of the deployment workflow; S6: Based on the selected snapshot, establish a resource namespace by node identifier and rewrite the resource path, encapsulate custom operators, and generate a deployment package containing service configuration, runtime entry point, port contract, minimum operator set version, and resource directory; S7: When the server loads the deployment package, it verifies the minimum operator set version and port contract, instantiates only the output reachable operator node, and verifies that the actual input and output are consistent with the port contract before and after execution of each output reachable operator node.

[0020] In its specific implementation, the method proposed in this invention can run on a development computer equipped with a central processing unit, memory, and non-volatile storage, and can transmit the generated deployment package to an inference server equipped with a graphics processing unit. The development computer runs a workflow editor, a contract derivation program, a snapshot program, and a deployment compiler, while the inference server runs a workflow service entry point and an operator runtime library. The workflow editor only saves the actual graph data of nodes and connections; the port display, problem prompts, and automatic conversions in the interface are all generated from the actual graph data, and no separate display-only connection relationships are maintained.

[0021] In a typical image detection workflow, the middle section represents the input boundary, output boundary, multiple operator nodes, and the connections between these nodes. Each operator node has a node identifier, operator type, input / output port declarations, node parameters, resource declarations, custom operator declarations, and a minimum operator set version. The input and output boundaries also have node identifiers and port declarations, used to define the workflow's input and output data. Connections between operator nodes indicate the data flow direction, i.e., the output port of an upstream operator node connects to the input port of a downstream operator node. Resource declarations use a mapping between resource keys and resource paths; resources include, but are not limited to, neural network models, external weight directories, template images, configuration files, calibration files, and data files required by custom operators. Custom operator declarations identify whether the operator node belongs to a custom operator and its corresponding module file information. The minimum operator set version indicates the minimum operator set version required for this operator type, so that the overall minimum compatible version can be calculated subsequently in the cropped deployment subgraph.

[0022] After constructing the intermediate representation, the contract derivation function corresponding to its operator type is called for each operator node. The inputs to the contract derivation function include node parameters, resource declarations, input / output port declarations, and connected input ports. For fixed-port operators, the contract derivation function outputs a predefined contract; for dynamic-port operators, it generates the actual port set based on the node parameters, the input / output descriptions in the model file referenced by the resource declaration, the measurement result items configured in the node parameters, or the connected input ports. Specifically, OnnxInference is an operator node used to perform inference on ONNX format neural network models. Its node parameters record the resource declarations of the selected ONNX model file. The contract derivation function determines the actual input and output ports of the operator node by reading the input / output descriptions in the ONNX model file. For example, in an image detection workflow, the ports of the OnnxInference node are not fixed but are parsed from the selected model file. When the user changes the model assets, the contract derivation function rereads the model input / output information and updates the node ports. If the new model requires input dimensions of [1,3,1024,1024], but the upstream node still outputs [1,3,640,640], the subsequent verification process will report dimension incompatibility before export. In the dynamic measurement output embodiment, the workflow includes a configurable dimension measurement node. The user configures three result items in the node parameters: "diameter," "concentricity," and "qualified." The contract derivation function reads the measurement result configuration and generates corresponding output ports. For example, diameter, concentricity, and qualified have corresponding data types and dimensions. When the user deletes the "concentricity" result item, the contract derivation function deletes the corresponding output port. If the port is still referenced by the output boundary, the verification process prompts that the connection references a non-existent port and prevents export. The valid input port contract and valid output port contract generated by the contract derivation function are written into an intermediate representation, so that the deployment phase does not need to guess the port diagram again based on the running data. When the operator type, node parameters, or resource declaration changes, the corresponding contract derivation function is called again; when the connection changes, at least the input ports of the dynamic port operators affected by the connection are re-derived. Ports allowed to be retained in the input / output port declarations are merged with the derivation results according to preset merging rules. For ports that cannot be statically determined and belong to the input / output boundary or intermediate results between output reachable nodes, export is prevented and missing fields and reasons for incomprehension are returned. When the data types of upstream output ports and downstream input ports are incompatible but automatic conversion is allowed, a data conversion operator node is inserted. This data conversion operator node participates in snapshot saving, contract verification, subgraph pruning, and execution, rather than just performing temporary conversions at the interface layer.

[0023] After the contract derivation is completed and the intermediate representation is written, a project snapshot is generated, containing the intermediate representation, the resource paths referenced by the resource declarations, and their content summaries. The resource content summaries are preferably calculated using the SHA-256 algorithm, but SHA-3 or other collision-resistant digest algorithms can also be used. Project snapshots are saved through writing to temporary files in the same directory, data refreshing, and atomic replacement to avoid partially written snapshots due to mid-process exits. Exporting only accepts project snapshots explicitly selected by the user; intermediate representations in the edit state are not directly read. Before exporting, the resource content summaries are recalculated and compared with the snapshot records; when resources are missing or their content changes, export is prevented, and the corresponding nodes and resource keys are indicated. For example, if the workflow references model files and tag files, the relative project paths, existence status, and SHA-256 content summaries are recorded when creating a snapshot. During the formal export, the user selects the snapshot, and the snapshot program recalculates the summaries of both files. If the summaries are identical, the subgraph extraction stage is allowed; if the model file has been overwritten, the resource file content is returned as changed, and the model nodes and resource keys are indicated; if the tag file is missing, the resource file is returned as missing, without using empty tags or other files with the same name as replacements. In this way, project snapshots establish a definite boundary between the verified state and the state to be exported, and can detect changes in models, templates or configuration files after verification, thereby improving the reproducibility of deployment results.

[0024] After selecting a project snapshot, the necessary deployment subgraph is pruned based on the intermediate representation in the selected snapshot. Starting from the output boundary, the upstream dependencies are traversed backward along the input connections to determine the set of output reachable nodes. The necessary deployment subgraph is then pruned to contain only the nodes, connections, resource references, and custom operator code in this set. The set of output reachable nodes can be determined by the reverse reachability function, which is the set of nodes reachable from the specified output boundary node along the reverse dependencies. Only the nodes in this set, the connections between nodes within the set, and the resource references and custom operator code actually referenced by these nodes are retained. A stable topological order is regenerated for the retained nodes. Debug nodes, preview nodes, spare branches, and their resources that are not used in the final output are not included in the production deployment package. When there are multiple output boundaries, multiple necessary deployment subgraphs can be generated separately, or a joint necessary deployment subgraph can be generated according to the set of output boundaries selected by the user. For example, in an image detection workflow, the deployment compiler traverses backward from the output to obtain six nodes in the production path, while the debug and preview nodes do not belong to the output reachable set and therefore are not included in the deployment package, and their dedicated graphics library and preview resources are also not included in the deployment environment.

[0025] After trimming to obtain the necessary deployment subgraph, the minimum operator subset version for the deployment workflow is calculated. The minimum operator subset version declared for each operator type in the necessary deployment subgraph is read, and the highest version is determined as the minimum operator subset version for the deployment workflow. This version is calculated based on the actual deployment nodes after trimming, rather than using the version requirements of irrelevant nodes in the complete project. For example, assuming the minimum operator versions required for retained nodes are 1, 1, 2, 3, 2, and 1, respectively, while the trimmed debug nodes require version 5, then the minimum operator version declared for the deployment workflow is 3, not 5 as in the complete project. The determined minimum operator subset version is written into the corresponding description information in the deployment package so that the server can perform version verification before instantiating any business operator. The server compares the minimum operator subset version of the deployment workflow with the operator subset versions supported by the runtime environment. If the operator subset version supported by the runtime environment is lower than the minimum operator subset version, execution is rejected; if the operator subset version declared in the workflow description is lower than the aggregated version of the operators used by the current operator implementation, a non-blocking compatibility warning is generated. This approach avoids unnecessarily increasing deployment version requirements for irrelevant nodes and prevents older runtime environments from executing new operators with incorrect semantics.

[0026] During the resource encapsulation phase, based on the resources and their content summaries in the selected snapshot, resource namespaces are established by node identifiers and resource paths are rewritten. An independent resource namespace is created for each node under the deployment model version directory. The target path of a resource must at least include the deployment version identifier, the resource root directory, and the node identifier, while preserving the relative directory hierarchy within the node. The resource path in the intermediate representation is rewritten as a path relative to the deployment version directory. Even if different nodes reference files with the same name, they will not be overwritten due to different node identifiers. The resource encapsulation process enforces the following security constraints: resource target paths are prohibited from escaping the node resource namespace; different resources on the same node are prohibited from being written to the same target path; symbolic links are prohibited from being packaged; for external data directories referenced in resource declarations, the main model file must be located in the declared external data directory; export is terminated if a resource does not exist or its type does not match the declaration. For custom operators that are not built-in operators, their module files are extracted and copied to the custom operator directory in the deployment package, generating a unified import entry point so that the server completes custom operator registration before loading the workflow. For example, when model nodes and post-processing nodes reference model files and tag files respectively, even if two nodes reference configuration files with the same name, they are stored in their respective resource directories. If any resource is detected as a symbolic link, the exporter terminates immediately to prevent the link target from being omitted or the link from crossing the project boundary.

[0027] During the deployment package generation phase, an inference service deployment package is generated based on the trimmed necessary deployment subgraph, input / output boundary contracts, and materialized port contracts. The deployment package includes at least a service configuration file describing the service input / output types, dimensions, and batch processing attributes; a workflow service runtime entry point; a workflow description file containing materialized port contracts and the minimum operator subset version; a node-isolated resource directory; a custom operator directory and its unified import entry point; and optional workflow runtime library source code or a dynamic library matching the target Python ABI. Preferably, a directory conforming to the inference server model repository specification is generated and compressed into an archive file. The archive is written to a temporary directory, and after all files are generated and verified, they are atomically moved to the target location. The deployment target can be the Triton inference server or other inference service systems that support model configuration and runtime entry points. Resources can originate from the local file system or object storage, and are converted to a specific relative path within the version directory before entering the deployment package. For multiple output boundaries, deployment packages can be generated separately, or a joint deployment package containing multiple outputs can be generated. Snapshots can be saved as files or in a database, as long as the workflow state can be bound to a resource content summary.

[0028] During the server-side runtime phase, when loading the deployment package, the server verifies the minimum operator set version and port contract, instantiates only output reachable operator nodes, and verifies the consistency of actual input and output with the port contract before and after execution of each output reachable operator node. The server starts in the following order: loads built-in operators and custom operators from the deployment package; reads the port contract from the deployment package and verifies the minimum operator set version; verifies the port contract; instantiates only the operator nodes in the output reachable nodes and parses the rewritten resource paths; executes the output reachable operator nodes according to a stable topology order or a parallel scheduling method that satisfies dependencies; before executing each output reachable operator node, verifies the consistency of actual input data with the input port contract, and after execution, verifies the consistency of actual output data with the output port contract. The local runtime device and the server-side runtime entry point read the same workflow description, using the same contract verification function, operator registration mechanism, and resource interpretation rules, thereby maintaining semantic consistency between local verification and deployment execution. For example, when the inference server loads the deployment package, it first imports the unified import entry in the custom operator directory to complete the registration of custom post-processing operators, and then reads the workflow description. If the server supports operator set version 2, but the workflow requires version 3, the startup will be refused and the minimum required version will be reported before loading model resources. Once the version is met, the runtime will only instantiate the output reachable operator nodes. Upon receiving the encoded image, decoding, preprocessing, model inference, and post-processing are performed sequentially; the actual array type and dimensions are verified at each step. If a model node incorrectly outputs a 64-bit floating-point number while the contract declares a 32-bit floating-point number, the error is located to the specific output port of that node and does not propagate downstream. Through this method, the server verifies the actual input and output against the static contract node by node, enabling the location of the node and port where the error occurred, thus improving fault diagnosis efficiency.

[0029] In another implementation, workflow execution can be performed serially or in parallel, maintaining dependencies between ready nodes; operators declared as serial only are still executed serially. Resources can originate from the local file system or object storage, and are converted to defined relative paths within the version directory before entering the deployment package. For multiple output boundaries, deployment packages can be generated separately, or a joint deployment package containing multiple outputs can be generated. Snapshots can be saved as files or in a database, as long as the workflow state can be bound to the resource content digest. The content digest can use SHA-256, SHA-3, or other collision-resistant digest algorithms. The deployment target can be the Triton inference server or other inference service systems that support model configuration and runtime entry. Through the above specific implementations, a unified closed loop can be formed, integrating port contract derivation, project snapshots, output reachable subgraph pruning, minimum operator set version calculation, resource encapsulation, and service runtime generation. This allows type or dimension errors to be detected before deployment, reducing server startup failures and runtime errors, and improving the reproducibility of deployment results and fault diagnosis efficiency.

[0030] In summary, this invention forms a unified closed loop by deriving and materializing port contracts, taking resource content summary snapshots, pruning output reachable subgraphs, calculating the lowest operator set version, encapsulating node-level resource namespaces, registering custom operators uniformly, and verifying server-side node-by-node contracts. This allows issues such as missing ports, inconsistent data types, and mismatched dimensions, which originally only surfaced at runtime, to be detected and prevented during the editing or exporting phase, thereby reducing server-side startup failures and runtime errors. Furthermore, by verifying project snapshots and resource content summaries, an immutable boundary is established between the verified state and the state to be exported, preventing the replacement of models, templates, or configuration files after verification, which could lead to unreproducible deployment results. Finally, by removing debug, preview, and backup branches through output reverse reachability analysis, the number of operators requiring initialization is reduced. The system addresses the issues of quantity, packaged resource volume, and runtime environment dependencies. By calculating the minimum operator set version based on the pruned subgraph, it avoids unnecessarily raising deployment version requirements due to irrelevant nodes and prevents low-version runtime environments from executing new operators with incorrect semantics. Through node-level resource namespaces, path rewriting, symbolic link prohibition, and a unified import entry point for custom operators, it avoids issues such as resource overwriting with the same name, path escape, and the inability to run locally while lacking modules or resources on the server. By validating the actual input / output and materialized contracts before and after node execution on the server side, errors can be located to specific nodes and ports, improving fault diagnosis efficiency. Furthermore, by sharing the same workflow description, contract verification functions, operator registration mechanism, and resource interpretation rules between the local runtime device and the server runtime entry point, it maintains semantic consistency between local verification and deployment execution.

[0031] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.

[0032] Furthermore, in this invention, descriptions involving terms such as "first," "second," and "a" are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0033] In this invention, unless otherwise explicitly specified and limited, the terms "connection," "fixed," etc., should be interpreted broadly. For example, "fixed" can mean a fixed connection, a detachable connection, or an integral part; it can mean a mechanical connection or an electrical connection; it can mean a direct connection or an indirect connection through an intermediate medium; it can mean the internal communication of two components or the interaction between two components, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0034] Furthermore, the technical solutions of the various embodiments of the present invention can be combined with each other, but only if they are feasible for those skilled in the art. If the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

Claims

1. A method for generating and deploying a verifiable inference workflow, characterized in that, Including the following steps: S1: Construct an intermediate representation that includes input / output boundaries, operator nodes, and connections. Operator nodes have identifiers, operator types, input / output port declarations, node parameters, resource declarations, custom operator declarations, and minimum operator set versions. S2: Based on the node parameters, resource declarations, port declarations, and connected input ports, call the corresponding contract derivation function to generate valid input / output port contracts and then write them into the intermediate representation; S3: Generates a project snapshot containing the rewritten intermediate representation, the resource paths referenced by the resource declarations, and their content summaries. During export, the resource content summaries are recalculated based on the selected snapshot; if they are inconsistent, the export is prevented. S4: Based on the selected snapshot, traverse the input connections in reverse from the output boundary to determine the set of output reachable nodes, and trim to obtain the necessary deployment subgraph containing only the nodes, connections, resource references and custom operator code of that set; S5: Determine the highest version among the lowest operator subset versions of each operator type in the necessary deployment subgraph as the lowest operator subset version of the deployment workflow; S6: Based on the selected snapshot, establish a resource namespace by node identifier and rewrite the resource path, encapsulate custom operators, and generate a deployment package containing service configuration, runtime entry point, port contract, minimum operator set version, and resource directory; S7: When the server loads the deployment package, it verifies the minimum operator set version and port contract, instantiates only the output reachable operator node, and verifies that the actual input and output are consistent with the port contract before and after execution of each output reachable operator node.

2. The verifiable inference workflow generation and deployment method as described in claim 1, characterized in that, The operator node includes fixed port operators and dynamic port operators. In step S2, for fixed port operators, a predefined contract is output. For the dynamic port operator, an actual port set is generated based on the node parameters, the input and output descriptions in the model file referenced by the resource declaration, the measurement result items configured in the node parameters, or the connected input ports.

3. The verifiable inference workflow generation and deployment method as described in claim 1, characterized in that, In step S2, when the operator type, node parameters, or resource declaration changes, the corresponding contract derivation function is called again; when the connection changes, at least the input ports of the dynamic port operators affected by the connection are re-derived. Ports that are allowed to be retained in the input / output port declaration are merged with the derivation results according to the preset merging rules.

4. The verifiable inference workflow generation and deployment method as described in claim 1, characterized in that, In step S2, for ports that cannot be statically determined and belong to the input-output boundary or intermediate results between output reachable nodes, export is prevented and the missing fields and reasons for not being able to be derived are returned; when the data types of the upstream output port and the downstream input port are incompatible but automatic conversion is allowed, a data conversion operator node is inserted, which participates in snapshot saving, contract verification, subgraph pruning and operation.

5. The verifiable inference workflow generation and deployment method as described in claim 1, characterized in that, In step S3, the resource content digest is calculated using the SHA-256 algorithm; the project snapshot is saved by writing to a temporary file in the same directory, refreshing the data, and replacing it atomically; when exporting, only the project snapshot explicitly selected by the user is accepted, and the intermediate representation of the editing state is not directly read.

6. The verifiable inference workflow generation and deployment method as described in claim 1, characterized in that, In step S4, when there are multiple output boundaries, multiple necessary deployment subgraphs are generated respectively, or a joint necessary deployment subgraph is generated according to the set of output boundaries selected by the user; a stable topological order is regenerated for the nodes in the set of output reachable nodes.

7. The verifiable inference workflow generation and deployment method as described in claim 1, characterized in that, In step S6, when establishing a resource namespace by node identifier and rewriting the resource path, the following security constraints are executed: resource target paths are prohibited from escaping the node resource namespace; different resources of the same node are prohibited from being written to the same target path; symbolic links are prohibited from being packaged; for the external data directory of the model referenced in the resource declaration, the main model file is required to be located in the declared external data directory. Export will terminate if the resource does not exist or its type does not match the declaration.

8. The verifiable inference workflow generation and deployment method as described in claim 1, characterized in that, In step S6, operators in the operator node other than the custom operators corresponding to the custom operator declaration are regarded as built-in operators; for custom operators that are not built-in operators, their module files are extracted and copied to the custom operator directory in the deployment package to generate a unified import entry, so that the server can complete the registration of custom operators before loading the workflow; the target path of the resource includes the node identifier and the resource root directory.

9. The verifiable inference workflow generation and deployment method as described in claim 8, characterized in that, In step S7, the server starts in the following order: loads the built-in operators and the custom operators in the deployment package; reads the port contract in the deployment package and verifies the minimum operator set version; verifies the port contract; instantiates only the operator nodes in the output reachable nodes and parses the rewritten resource paths; executes the output reachable operator nodes in a stable topology order or a parallel scheduling method that satisfies dependencies; verifies that the actual input data is consistent with the input port contract before each output reachable operator node is executed, and verifies that the actual output data is consistent with the output port contract after execution.

10. The verifiable inference workflow generation and deployment method as described in claim 1, characterized in that, In step S7, the server compares the minimum operator set version of the deployed workflow with the operator set version supported by the runtime environment. If the operator set version supported by the runtime environment is lower than the minimum operator set version, the workflow will be rejected. If the operator set version declared in the workflow description is lower than the aggregated version of the current operator implementation for the used operators, a non-blocking compatibility warning will be generated.

Images