A knowledge base operation and maintenance work order generation method and device based on a thought tree

Abstract

The application discloses a knowledge base operation and maintenance work order generation method and device based on a thinking tree. Alarm, configuration version, running state and permission boundary are collected and knowledge base version snapshot is locked; the snapshot, node field mode, tool interface mode and forbidden action set input parameter frozen generation model are input, and a candidate work order reasoning node with evidence reference, expected observation and fixed rollback node is generated through constrained decoding. The thinking tree is expanded with success, failure and unobservable exit, and infeasible branches are pruned according to knowledge version, current evidence, parameters, permissions and rollback reachability, and the supplementable node is converted into a read-only diagnosis node. The selected branch is combined through a shared diagnosis node, static checksum and sandbox verification without production side effects to form a structured operation and maintenance work order, and feedback is executed to append a new thinking tree version.

Description

Technical Field

[0001] This invention relates to the fields of knowledge base-enhanced operation and maintenance diagnosis, constrained reasoning, and executable work order generation technology, specifically to a knowledge base operation and maintenance work order generation method and apparatus based on mind tree. Background Technology

[0002] Operations and maintenance personnel typically retrieve knowledge entries from fault descriptions and then manually combine troubleshooting commands and repair actions. Knowledge entries with similar keywords may correspond to different software versions, topologies, and permission boundaries, and directly concatenating them can easily result in inapplicable actions being written into work orders.

[0003] When using a generative model to output work orders in one go, the reasoning process given by the model lacks observable conditions and rollback conditions, making it impossible to determine why a certain step is retained; after the knowledge entries are updated, it is also difficult to trace back to the evidence version used at that time.

[0004] Common knowledge base work order generation solutions directly output disposal text by retrieval-enhanced generation models, or fill work order templates with similar cases; however, they do not incorporate observations to be verified, permission boundaries, rollback accessibility, and knowledge versions into the generation and pruning process of inference branches.

[0005] The alerting platform, configuration management library, knowledge base, and execution agent provide object status, version, evidence, and action results, respectively. If the retrieved text is directly fed into the generation model, resource identifiers, permissions, and rollback parameters may come from different versions, and the success conditions generated by the model may be mistakenly taken as observations that have already occurred.

[0006] This application first locks the fault context and knowledge base version, then uses field syntax and resource identifier sets to limit the range of candidate node generation. The edges of the mind tree are defined by expected observation predicates and can only be activated by actual observations; deterministic pruning is responsible for version, current state, parameters, permissions, and rollback verification, and the model does not directly obtain the production write interface.

[0007] The nodes in the mind tree are not free text paragraphs, but structured objects with preconditions, evidence references, expected observations, permission requirements, and rollback edges. The generative model only proposes candidates that conform to the field pattern; whether a node can enter the work order dependency graph is determined by the knowledge version, current state, sandbox results, and rollback reachability, and execution feedback only appends the new tree version. Summary of the Invention

[0008] When generating natural language work orders directly from a language model, the model may output non-existent resource identifiers, parameters without source, unauthorized commands, or actions without recovery paths. Furthermore, the work order text itself cannot prove that the current state of the target device meets the execution conditions. This invention does not address work order text formatting, but rather transforms alarms, configuration versions, and device states into parsable technical action diagrams for the execution agent. It uses knowledge versions, read-only probes, permission interfaces, sandbox resolution, and fixed rollback edges to prevent non-executable actions from entering the production execution chain.

[0009] The first aspect of this application provides a knowledge base maintenance work order generation method based on a mind tree, characterized by: collecting the original alarm values, configuration item stability identifiers, software versions, running status, and permission boundaries of a faulty object; filtering knowledge entries according to object type, applicable object version, effective time, and permission range; and solidifying the content summary, preconditions, operations, expected observations, evidence sources, and fixed rollback actions of the obtained knowledge entries into a knowledge base version snapshot; using the faulty object's data, the knowledge base version snapshot, the work order inference node field pattern, the allowed tool interface pattern, and the prohibited action set as read-only inputs to a parameter-frozen generation model; generating candidate work order inference nodes containing preconditions, knowledge evidence references, execution interfaces, parameter sources, expected observations, successful exits, failed exits, unobservable exits, permission levels, and rollback nodes through constrained decoding; candidate work order inference nodes whose fields, resource identifiers, or evidence references do not conform to the field pattern are not included in the mind tree; using the faulty object's data as the root node, establishing success, failure, and unobservable branches according to the expected observation predicates of each candidate action; and, during the work order execution phase, only returning data based on the execution agent... The actual observation that satisfies the corresponding expected observation predicate activates the corresponding exit; first, based on the five constraints of knowledge version applicability, current state evidence, action parameters parsable, execution subject having corresponding permissions, and fixed rollback edges for actions with side effects, infeasible branches are pruned; candidate nodes lacking current state evidence but whose evidence can be obtained from predefined side-effect-free probes are converted into read-only diagnostic nodes; then, the target branch is selected from the branches that satisfy the five constraints; the target branch is converted into a work order dependency graph, shared read-only diagnostic nodes are merged, conditional branches for mutually exclusive repair actions are maintained, and for each branch with a sub-function... The action connects the pre-execution state summary, execution observations, and fixed rollback nodes from the knowledge base version snapshot; it performs circular dependency, parameter source, permission range, observation exit, and rollback reachability checks on the work order dependency graph, and parses the execution interface, resource identifier, parameter range, and inter-node variable transfer in a sandbox that is not connected to the production interface. After the checks pass, it outputs a structured operation and maintenance work order; it receives the actual observations returned by the execution agent, and activates the failure exit or unobservable exit when the actual observations do not meet the original expected observation predicates, generating a new version that references the original mind tree version without rewriting the published work order.

[0010] Furthermore, the generative model is a decoder-based Transformer language model with parameters frozen during the operation of the method, including a lexical embedding layer, L sequentially connected causal mask multi-head self-attention and feedforward network modules, residual connections and normalization layers, and an output projection layer. Each self-attention module has H attention heads and a hidden dimension of D. The immutable model inventory records L, H, D, vocabulary and segmenter summary, weight artifact summary, quantization method, maximum context length, maximum output length, and decoded syntax summary.

[0011] Furthermore, the field pattern is converted into a deterministic finite-state grammar, and the knowledge evidence references and resource identifiers are constructed into a prefix trie. For each word output by the generation model, the allowed word set is obtained based on the current grammar state, the allowed enumeration value, and the prefix trie, and the remaining words are masked. When the allowed word set is empty, the maximum output length is reached but the grammar is not in an accepting state, or the output contains natural language outside the field pattern or evidence that the reference does not exist, the corresponding candidate work order inference node is rejected.

[0012] Furthermore, for the branch p that satisfies the five constraints, calculate Q(p) = Cover(p) - λ1Risk(p) - λ2Cost(p) - λ3Unknown(p), where Cover(p) is the proportion of the weight of the fault phenomenon supported by actual observation or valid knowledge evidence to the total weight of all fault phenomena, Risk(p) is the normalized risk formed by the permission level, the number of actions with side effects, and the rollback distance, Cost(p) is the normalized cost formed by the expected downtime, the number of changed objects, and the number of new probes, and Unknown(p) is the proportion of the number of nodes lacking actual observation or valid knowledge evidence to the total number of branch nodes.

[0013] Furthermore, the side-effect-free probe only calls a predefined read-only interface or a recoverable probe and has a predetermined output field and value range. When the output is not within the predetermined value range, it enters an unobservable exit. The sandbox includes at least one of a command parser, an isolation container, or a device emulation interface. It does not carry production credentials or a production management network. The side-effect-free interface cannot be confirmed to perform only syntax and parameter checks in the sandbox without execution.

[0014] Furthermore, when a work order is published, the model version summary, knowledge base version snapshot summary, and work order dependency graph summary are frozen. Actual observations include at least the work order node identifier, actual output, observation interface, observation time interval, and input summary. Only when the input summary and object stability identifier are consistent with the published node are they written into the new mind tree version. Manual modifications are also appended to the new node.

[0015] A second aspect of this application provides a knowledge base maintenance work order generation device based on a mind tree, characterized by comprising a context and knowledge snapshot module, a constrained candidate generation module, a mind tree expansion module, a deterministic pruning module, a work order diagram arrangement module, and a verification and feedback module; the context and knowledge snapshot module is used to collect the status of faulty objects and lock the knowledge base version snapshot; the constrained candidate generation module is used to generate structured candidate work order inference nodes based on field patterns and evidence reference ranges; the mind tree expansion module is used to establish exits with expected observation predicates and activate corresponding child nodes according to actual observations; the deterministic pruning module is used to perform knowledge version, current evidence, parameters, permissions, and fixed rollback edge constraints, and convert nodes that can supplement evidence into read-only diagnostic nodes; the work order diagram arrangement module is used to select branches, merge shared diagnostic nodes, and maintain mutually exclusive repair and fixed rollback relationships; the verification and feedback module is used to perform static verification and sandbox verification without production side effects, output structured maintenance work orders, and write the execution observations into a new mind tree version.

[0016] A third aspect of this application provides an electronic device, characterized in that it includes a processor, a memory, a communication interface, and a computer program stored in the memory and capable of running on the processor, wherein the communication interface is used to connect to an alarm platform, a configuration management library, a knowledge base, a sandbox, or an execution agent, and the computer program, when executed by the processor, implements the method described in any one of claims 1 to 6.

[0017] A fourth aspect of this application provides a non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that the computer program, when executed by a processor, implements the method described in any one of claims 1 to 6.

[0018] A fifth aspect of this application provides a computer program product comprising a computer program, characterized in that, when executed by a processor, the computer program implements the method described in any one of claims 1 to 6.

[0019] Constrained decoding limits model output to structured nodes with evidence references, separating actual observations from expected observations and preventing planned content from being treated as execution facts. Knowledge version, current evidence, parameters, permissions, and fixed rollback edges constitute hard constraints that cannot be compensated by scoring. Shared diagnostic node merging, static verification, and sandboxes without production credentials jointly prevent parameters without origin, unauthorized actions, circular dependencies, and unrecoverable writes from entering the execution agent. Attached Figure Description

[0020] Figure 1This diagram illustrates the generation and pruning of a knowledge base operation and maintenance work order mind tree. It shows how constrained candidate nodes expand according to three exits: observation true, observation false, and unobservable. After pruning based on knowledge version, current evidence, parameters, permissions, and fixed rollback edge constraints, a work order dependency graph is formed.

[0021] Figure 2 This is a schematic diagram of the knowledge base operation and maintenance work order generation device. It shows that the fault context and knowledge snapshot are sequentially processed into constrained candidate generation, mind tree expansion, deterministic pruning and work order diagram arrangement. The verification and feedback module adds the actual execution observation as subsequent evidence of the mind tree.

[0022] Figure labeling: Context and knowledge snapshot module 11, constrained candidate generation module 12, mind tree expansion module 13, deterministic pruning module 14, work order diagram arrangement module 15, verification and feedback module 16. Detailed Implementation

[0023] The following implementation uses knowledge snapshot summary, object stability identifier, and mind tree version as record boundaries to illustrate the implementation process of constrained generation, observation-driven expansion, hard pruning, and fixed rollback.

[0024] Each work order inference node must include at least the following: node identifier, parent node, node type, applicable object, prior state, knowledge evidence version, execution interface, parameter source, expected observation, successful exit, failed exit, unobservable exit, permission level, fixed rollback node, risk level, executable state, and uncertainty. The node type is limited to diagnosis, repair, observation, or rollback; edges indicate that the actual observation of the previous node triggers the subsequent node, and do not represent natural language similarity relationships.

[0025] The knowledge base version snapshot must at least save the entry content summary, validity period, applicable version, preconditions, operations, expected observations, evidence sources, and fixed rollback operations. The model version snapshot must at least save the model type, configuration summary, parameter summary, vocabulary version, and inference / decoding parameters. When a work order is published, the knowledge snapshot summary, model version summary, and work order dependency graph summary are frozen simultaneously; any change to any summary will generate a new version.

[0026] Knowledge retrieval first performs hard filtering based on object type, object software version, entry validity time interval, and the current executing entity's authority scope. For the filtered entry k, the formula Sk = akKkeyword(k) + avVsimilarity(k) + amMversion(k) + atTvalid(k) is calculated, where Kkeyword is the normalized keyword matching score, Vsimilarity is the normalized vector similarity generated from the embedding model summary recorded in the snapshot, Mversion is the object version matching value, Tvalid is the validity time matching value, and ak, av, am, and at are non-negative retrieval weights. The top K items are obtained in descending order of Sk and ascending order of entry stability identifiers. K, weights, embedding model summary, and word segmentation rules are all fixed before retrieval. Knowledge fragments are only truncated as complete entries, not truncated in the middle of the field. When there are no entries after hard filtering, an empty knowledge snapshot is generated, and candidate nodes relying on knowledge evidence remain as having insufficient evidence.

[0027] Candidate nodes sequentially go through the following states: candidate, insufficient evidence, executable, pruned, published, successful execution, failed execution, or unobservable. The generative model is only responsible for generating candidate nodes that conform to the field pattern; if field, reference, or resource identifier verification fails, it enters the pruned state; if there is a lack of current evidence but a predefined read-only probe exists, it enters the insufficient evidence state and becomes a diagnostic node; it only enters the executable state when all five hard constraints—version, current evidence, parameters, permissions, and fixed rollback edges—are met. The parent-child edges in the tree planning phase store the expected observation predicates and their exit identifiers given by the knowledge snapshot, and do not represent the results of actions that have not yet occurred as actual observations; only read-only probe results obtained before generation and consistent in object, interface, and time interval can be used as current evidence.

[0028] Any action with side effects is connected in the work order dependency graph according to the sequence: "Pre-check—Action Invocation—Execution Observation—Success / Failure / Unobservable Exit—Fixed Rollback". After the execution agent writes back the actual output, the predicate evaluator determines the success or failure of the predicate based on the field type, comparison operation, and allowable error. When the interface times out, the field is missing, or the value is incomparable, the unobservable exit is activated, and only the child nodes connected to the activated exit become executable. The rollback parameters directly reference the fixed rollback actions in the state summary and knowledge snapshot saved before the action execution, and are not regenerated by the model after failure. A new tree version is generated when the actual observation does not match the expectation.

[0029] For feasible branch p, calculate Q(p) = Cover(p) - λ1Risk(p) - λ2Cost(p) - λ3Unknown(p). Let the set of normalized fault phenomena be G, the non-negative weight of phenomenon g be wg, and the subset of phenomena that a branch can be explained by actual observation or valid knowledge evidence be Gexplained(p), then Cover(p) = Σg∈Gexplained(p)wg / Σg∈Gwg; let the total number of branch nodes be Nall(p), and the number of nodes without actual observation or valid knowledge evidence be Nunsupported(p), then Unknown(p) = Nunsupported(p) / Nall(p). Risk(p) and Cost(p) are respectively linearly normalized according to the upper and lower bounds of the parameter snapshot, weighted, and truncated to [0, 1], and all four rating components are located in [0, 1].

[0030] Branches are invalid when Σg∈Gwg=0 or Nall(p)=0; when the upper and lower bounds of a normalized component are equal, the original value equal to the boundary is used to set the component to zero, otherwise the branch is invalid. Pruning adopts a two-level process of first hard constraints and then scoring: branches that are not applicable to the knowledge version, do not meet the current state, cannot resolve parameters, cannot obtain permissions, or are unreachable by rollback are directly excluded without compensation with a higher Cover; branches with the same Q are determined in order of smaller Unknown, shorter rollback distance, and smaller node stability identifier. λ1 to λ3, phenomenon weights, normalization boundaries, and tie-breaking rules are written to a read-only parameter snapshot before tree expansion.

[0031] This implementation uses a pre-trained, parameter-frozen decoder-based Transformer language model, without training, fine-tuning, or updating the model online during work order generation. The model consists of a lexical embedding layer, L sequentially connected causal mask multi-head self-attention and feedforward network modules, residual connections and normalization layers, and an output projection layer. Each self-attention module has H attention heads and a hidden dimension of D. An immutable model inventory stores positive integers L, H, and D, a vocabulary and segmenter summary, a weight artifact summary, quantization method, maximum context length, maximum output length, decoded syntax summary, and inference runtime version. Inference nodes only retrieve models consistent with the weight artifact summary from the local model repository, verify the inventory item by item, and then load the model. Missing artifacts, mismatched configurations, or failed summary verification will render the model unusable.

[0032] Input is serialized in a fixed order: fault object field, original alarm value, configuration version, complete knowledge entry with reference identifier, allowed tool interface pattern, node field pattern, and prohibited action set. The segment type and length are written before each segment. Node field patterns are compiled into a deterministic finite-state grammar, and knowledge evidence references and configuration item stability identifiers are compiled into a prefix trie. For each term generated during decoding, the allowed term set is obtained by intersecting the current grammar state, the field enumeration set, and the prefix trie; the probabilities of other terms are set to unselectable. Candidate nodes are rejected entirely if the allowed set is empty, the maximum output length is exceeded but the acceptance state has not been reached, the field type is mismatched, the object does not exist, or the evidence reference is incomplete. Model output always only enters the candidate node storage and is not directly connected to the production write interface.

[0033] The sandbox does not mount production credentials or the production management network. For read-only actions with simulation interfaces, variable passing between nodes can be executed and checked within the sandbox; for kernel, network, or device control interfaces where side effects cannot be confirmed, only commands, resource identifiers, parameter ranges, and permission declarations are parsed, and execution success is not simulated. If subsequent nodes reference variables not generated in the preceding sequence, or if any failure exit does not terminate, provide supplementary evidence, or have a fixed rollback destination, the work order must not be issued.

[0034] Taking database connection pool alerts as an example, the knowledge snapshot simultaneously limits the application version, connection pool implementation, and database master / slave roles. Candidate nodes include expanding the connection pool and releasing leaked connections; the former is hard-pruned because the current evidence of the database connection limit is not met, while the latter is planned with "read-only session check result equal to long-term occupation" as the successful exit predicate connection isolation action, without recording this result as having occurred. The execution agent returns observation records containing node stability identifiers, object stability identifiers, observation interfaces, observation time intervals, output fields, and output summaries. Isolation actions are activated only when the predicate evaluation is true; unobservable exits are activated when there is a timeout or missing output fields. Session and configuration summaries are saved before action execution, and recovery is only performed using fixed rollback nodes from the snapshot in case of failure.

[0035] An acceptable candidate node record includes the following fields in sequence: node_id, node_type, target_id, precondition, evidence_refs, tool_id, parameter_sources, expected_observation, success_exit, failure_exit, unobservable_exit, permission_level, and rollback_node. The node_type can only be diagnostic, repair, observation, or rollback. The target_id must come from the current configuration snapshot. Each identifier in evidence_refs must come from a frozen knowledge entry. The tool_id must come from an allowed tool interface mode. When constrained decoding reaches the end-of-record marker, the parser checks the above source relationships field by field; if any required field is missing, the entire record is rejected.

[0036] The following combination Figure 1 and Figure 2 This explains the relationship between knowledge snapshots, mind tree nodes, deterministic pruning, sandbox validation, and work order updates.

[0037] Figure 1 The mind tree shown is not the inference text freely output by the model, but rather consists of work order inference nodes with field patterns, evidence references, and expected observation predicates. The following processing separates the generation phase from deterministic verification, work order orchestration, and execution feedback.

[0038] Step S100 retrieves the original alarm value, object stability identifier, software version, running status, and permission boundaries from the alarm platform and configuration management library. Knowledge entries are first filtered by object type, version, validity period, and permissions. Then, the entry content summary, preconditions, actions, expected observations, and fixed rollback actions are locked. The retrieval parameters and snapshot summary are saved together; subsequent knowledge updates do not alter the evidentiary meaning of the candidate nodes.

[0039] Step S200 freezes the generative model by inputting the fault context, knowledge snapshot, allowed tool patterns, node field patterns, and prohibited action sets in a fixed order. Field patterns are compiled into finite state syntax, and evidence references and resource identifiers are compiled into prefix trie; decoding only produces allowed terms, and the entire candidate record is rejected if field, enumeration, object, or evidence reference verification fails.

[0040] Step S300 uses the normalized fault context as the root node to establish success, failure, and unobservable exits for each candidate action. During the planning phase, only the expected observation predicates are saved; read-only probe results obtained before generation must be consistent with the object, interface, and observation time interval to serve as current state evidence. During the execution phase, the corresponding child nodes are activated by the actual observed predicate evaluation results.

[0041] Step S400 first checks whether the knowledge version is applicable, whether there is current evidence of the preceding state, whether the parameters can be parsed from the configuration or knowledge entry, whether the execution subject has sufficient permissions, and whether the fixed rollback edge is reachable. If any condition is not met, the repair branch is pruned; if the gap can be filled by a predefined read-only probe, the node is changed to a diagnostic node instead of directly publishing the action.

[0042] Step S500 compares evidence coverage, risk, execution cost, and the proportion of unknown nodes only in branches that pass hard constraints. The selected branch is converted into a work order dependency graph, shared read-only diagnostic nodes are merged into one execution, and mutually exclusive repairs preserve condition exits; each side effect action connects to existing fixed rollback nodes in the pre-execution state summary, execution observations, and knowledge snapshots.

[0043] Step S600 first checks circular dependencies, parameter sources, permission scopes, exit integrity, and rollback reachability. Then, it parses commands, resource identifiers, parameter scopes, and variable passing in a sandbox that is not connected to the production network or production credentials. After verification, the model, knowledge, and work order graph summary are frozen. If the execution observation does not conform to the original predicate, a new tree version is appended, but published nodes are not modified.

[0044] Work order inference nodes are linked by parent version, input summary, and object stability identifier. When a knowledge entry becomes invalid, configuration version changes, or observation is revoked, the dependency index only causes the node referencing that input to re-enter the candidate or pending evidence state; other confirmed diagnostic results continue to use the original evidence reference.

[0045] Furthermore, the knowledge base version snapshot includes a summary of the knowledge entry content, the effective date, the applicable version, and the source of evidence.

[0046] Furthermore, the input to the generative model includes the fault context, knowledge base version snapshot, node field pattern, allowed tool pattern, and prohibited action set, and the output is verified by field type, enumeration value, and evidence reference integrity.

[0047] Furthermore, when expanding the mind tree, three exits are established for candidate actions: success, failure, and unobservable. Child nodes reference the observation results or independent knowledge evidence of the parent node.

[0048] Furthermore, feasibility pruning transforms candidate nodes that lack current evidence but can be supplemented through observations without side effects into diagnostic nodes.

[0049] Furthermore, the work order dependency graph merges diagnostic steps shared by multiple branches, and maintains the conditional branches of mutually exclusive repair actions and their respective action rollback edges.

[0050] Furthermore, when the observed behavior differs from the expected behavior, the corresponding failed branch is activated and a new version of the mind tree is generated, while the original version remains unmodifiable.

[0051] This embodiment incorporates the fault context summary, knowledge base snapshot version, and mind tree node identifier into the work order inference node, ensuring that candidate generation, branch expansion, hard constraint pruning, and execution feedback can all be located to the same evidence version. The structured node pattern first constrains candidate diagnosis or handling nodes to expand the mind tree based on anticipated observations, then prunes it according to knowledge version, current evidence, permissions, and rollback reachability. The minimum dependency graph is extracted and, after static verification and sandbox validation, the work order is published. In this specification, "confirmed" means the existence of direct technical observations or mutually independent indirect observations with consistent input summaries; "unknown" indicates insufficient existing evidence to make a negative judgment.

[0052] In implementation, the input end receives alarm and configuration item context, software and knowledge entry versions, retrieval evidence and source, and node field patterns, respectively. The interface request carries the object stability identifier, expected version, calling permissions, and idempotent key, while the response carries the actual version, collection time interval, quality flag, and content summary. Data from cache, mirror, or inference is stored from its direct source. Fields that cannot be obtained are represented by explicit unknown values, and missing items are kept in an unknown state and are not replaced by zero values ​​or expired records.

[0053] Tree depth, branch limit, scoring weight, decoding length, and sandbox timeout are fixed with the mind tree version. When the sum of coverage weights is zero, the number of branch nodes is zero, or the normalized boundary is invalid, the branch will not participate in the sorting; branches that fail hard constraints cannot re-enter the feasible set by lowering their risk weights.

[0054] After a work order inference node enters the control panel, it first checks the type and enumeration values ​​according to the field pattern. Then, it confirms that the object stability identifier, knowledge snapshot summary, tool interface, and evidence reference can all be parsed, and verifies that the permissions declared by the node do not exceed the permission boundaries in the fault context. Only nodes that pass the checks are sent to the mind tree expansion and pruning. Each stage only adds the exit, score, or rollback edge generated in this stage, and knowledge entries and existing observations remain read-only. When rules, models, or knowledge snapshots change, a new tree version is generated, and only nodes that depend on the changed inputs are re-evaluated.

[0055] Adjacent steps exchange data via structured objects. The previous step outputs candidate inference nodes or mind tree versions, which are written to the parent version field. Before generating an executable maintenance work order, the next step re-verifies that the parent version is still the current valid version. If the model output does not conform to the pattern during this process, only the branches that depend on the failed interface are frozen, while other unrelated branches remain in the confirmed state.

[0056] Knowledge documents, alarms, logs, and work order records are first filtered by object stability identifier, topology period, and effective time, and then segmented into evidence fragments by title, paragraph, and sentence boundaries. Each fragment saves the source document, paragraph position, version, permission tag, and content summary; fragments exceeding the model context length are further segmented by sentence boundaries, and adjacent pointers are retained to prevent loss of source after semantic truncation.

[0057] The retrieval layer simultaneously builds inverted indexes and vector indexes. Queries consist of faulty objects, status fields, error codes, versions, and topological neighbors; hard filtering is first performed based on permissions, versions, and validity periods, then the re-ranking value is calculated based on keyword relevance, vector relevance, topological adjacency, and time decay. All components used in the re-ranking are normalized and their original scores are preserved. When retrieval results are insufficient, a supplementary verification branch is initiated, without filling in missing technical facts with common sense from the model.

[0058] The generative model employs a pre-trained decoder-based Transformer language model with its parameters frozen during the method's execution. The inputs sequentially include the frozen fault context, evidence fragments and their reference identifiers, allowed tool patterns, output field patterns, and a set of prohibited actions. The output is a structured object, including at least candidate node identifiers, preconditions, evidence references, expected observations, successful exits, failed exits, permission levels, rollback actions, and confidence states; outputs that do not conform to the field type or whose references do not exist are rejected entirely.

[0059] This implementation does not perform model training, fine-tuning, or online parameter updates during the work order generation process; the model type, model configuration summary, parameter summary, vocabulary version, and inference decoding parameters are fixed with the knowledge snapshot. The generated model only produces structured candidate nodes, and whether a node can enter into a work order is determined by deterministic verification of current evidence, permissions, parameters, and fixed rollback edges.

[0060] The model inference inputs are arranged in a fixed order, including the fault object field, the original alarm value, the configuration version, the knowledge evidence fragment with a reference identifier, the tool interface pattern, the node field pattern, and the prohibited action set. The model output is verified by field type, enumeration range, object existence, and evidence reference integrity. Candidate nodes that do not meet any of these criteria are rejected as a whole.

[0061] Model output does not directly trigger write operations. Before execution, it sequentially performs object existence verification, current state evidence verification, permission verification, mutual exclusion action verification, rollback reachability verification, and sandbox verification. If any verification fails, the candidate node and the reason for failure are retained, and the process is transferred to a read-only diagnostic or supplementary verification branch. Execution feedback generates a new tree or event slice version, without modifying the already released version in place.

[0062] Candidate processing first performs hard constraint filtering, then sorts within the feasible set: The first layer establishes a hard constraint feasible set based on the following criteria: the retrieval only uses locked knowledge snapshots, the generated output must pass field type and enumeration verification, and repair nodes lacking current evidence cannot be directly published; the second layer sorts only within the feasible set based on risk, latency, resource consumption, or evidence completeness. If the feasible set is empty, conflicting constraints and gaps are returned, without relaxing security conditions.

[0063] Before publishing a work order, the object stability identifier, knowledge snapshot summary, model artifact summary, and work order graph input summary are compared again. If any summary matches a dependency field of the current branch, publishing is stopped and a new tree version is generated. Read-only diagnostic nodes unrelated to changed fields can be reused, but side effect nodes must be revalidated for current state and rollback parameters.

[0064] The published results include a work order graph summary, knowledge evidence path, parameter source for each action, observation exit point, permission requirements, and fixed rollback nodes. Only nodes that pass both static and sandbox validation are marked as executable; nodes awaiting supplementary validation, unobservable, or requiring manual approval will not be issued as automatic write operations.

[0065] The work order reasoning node is a structured record that runs through the processing chain of this invention, and includes at least a node identifier, parent node, knowledge evidence version, applicable conditions, candidate actions, expected observations, failed branches, rollback actions, risk level, executable status, and uncertainty. The executable status is only valid when the applicable conditions are supported by current evidence, the action parameters are resolvable, and the rollback boundary is clear; the uncertainty is used to determine whether to continue expanding, switch to diagnosis, or request manual confirmation.

[0066] In a mind tree, edges represent how the observation of one node triggers the observation of the next node, rather than natural language similarity relationships; mutually exclusive observations form different branches.

[0067] The knowledge snapshot consists of an entry content summary, version number, and validity period. The snapshot is used after the work order is generated to prevent knowledge updates from changing the meaning of the approved work order.

[0068] The device connects to an alarm platform, configuration management library, knowledge base, and work order system. Knowledge base entries include valid version, applicable objects, preconditions, operation, expected observation, and rollback action; the large model is only used to propose candidate nodes within a defined structure and does not directly execute commands.

[0069] In step S100, the fault context and knowledge snapshot are solidified. The device maps volatile identifiers such as hostnames to stable identifiers for configuration items, retains the original alarm values ​​and acquisition time, retrieves the phenomena, topological adjacencies, and version applicability, and returns an entry summary and version.

[0070] In step S200, constrained candidate nodes are generated. The input prompts include permitted knowledge evidence, currently known facts, and prohibited permission boundaries; the output uses fixed JSON fields and undergoes syntax validation, and natural language outside the fields is not included in subsequent execution.

[0071] In step S300, the expanded mind tree is executed. Three exits are established for each action: success, failure, and unobservable; child nodes must reference actual observations or independent knowledge evidence from their parent nodes, and jumping to the repair action without a parent relationship is prohibited.

[0072] In step S400, feasibility pruning is performed. Nodes that do not meet hard constraints are directly removed; nodes with missing evidence but which can be supplemented through observations without side effects are not removed but are converted into diagnostic nodes. Branches with high risk and no verifiable rollback are retained as candidates for manual approval.

[0073] In step S500, the work order dependency graph is orchestrated. Shared diagnostic steps are merged and executed once across multiple branches, while mutually exclusive repair actions maintain conditional branches; each action carries a version of the knowledge evidence and the source of the input parameters.

[0074] In step S600, a verification is performed and the execution result is reported. Static verification checks for circular dependencies, missing parameters, missing rollbacks, and exceeding permissions. If the actual observation after execution does not match the expectation, the corresponding failed branch is activated, and a new tree version is generated without rewriting the original version.

[0075]

[0076] In the formula, p is the candidate tree branch, Cover is the evidence coverage of the input fault phenomenon, Risk is the action risk, Cost is the expected execution cost, and Unknown is the number of nodes not supported by knowledge evidence or diagnostic observations; branches that do not meet hard constraints are not included in the ranking.

[0077] The generative model can be a language model that accepts text and structured input, without requiring a specific training method. The key is that the retrieved knowledge entries are taken as version snapshots as input, the output is limited to node fields, and the executability is determined by deterministic rules.

[0078] The diagnostic node is only allowed to read the status or execute reversible probes, and its output fields and value ranges are predefined; if the diagnostic result is outside the range, it will enter an unknown exit without automatically selecting a repair action.

[0079] In a reproducible implementation, the generative model employs 24 causal masked self-attention modules, each with 16 attention heads, a hidden dimension D of 2048, a maximum context length of 8192 tokens, and a maximum output length of 1024 tokens. The vocabulary, tokenizer, weight artifacts, quantization methods, and finite-state grammar are all summarized and written into the immutable model list. The listed parameters are used to describe the model loading and reproducibility methods, without limiting the equivalent number of layers or dimensions that can be used.

[0080] For domain adaptation, training or efficient parameter fine-tuning is only performed using historical work orders that have been manually verified and have had passwords, personnel information, and network credentials removed before model deployment. After training, the training data version summary, learning rate, epochs, context length, and weight artifact summary are fixed. This method does not train, fine-tune, or update the model online during operation.

[0081] During inference, the model's self-described confidence is not used as a pruning criterion. Node fields must include at least the applicable object, prior state, execution interface, parameter source, expected observation, failure observation, permission level, and rollback node. When the model output contains an unknown resource identifier, an incorrect field type, or an unresolved parameter, the node is directly moved to the set of nodes awaiting further verification.

[0082] The root node of the thought tree represents the normalized fault context. Diagnostic nodes, after generating observations, can expand to include multiple candidate causes, while repair nodes establish three fixed exit points: success, failure, and unobservable. Child nodes must reference observations from their parent node or independent knowledge evidence; they cannot rely solely on inference statements from the generated text as branching conditions.

[0083] Branch costs are comprised of expected downtime, permission level, number of changed objects, rollback distance, and number of new pieces of evidence. Pruning first enforces hard conditions: knowledge version applicable, current state valid, permissions obtainable, parameters resolvable, and rollback reachable; only then are costs compared among feasible branches to avoid selecting low-cost but infeasible branches.

[0084] The work order dependency graph merges read-only diagnostic steps shared by multiple branches into a single node, and mutually exclusive repair actions maintain conditional branches. Any node that changes the external state is connected to pre-checks, execution observations, and rollback edges; the pre-conditions of rollback nodes reference the state summary saved before execution and cannot use approximate parameters rewritten from the generative model.

[0085] Taking database connection pool alerts as an example, the knowledge snapshot includes the application version, connection pool implementation, and database primary / standby roles. When the model proposes two candidates, "expand the connection pool" and "release leaked connections," the former is pruned due to insufficient current database connection limits; the latter first generates read-only session check nodes, and only initiates restart or isolation actions when a specific call stack is observed to be occupied for a long time.

[0086] Sandbox validation parses commands, resource identifiers, parameter ranges, and permission declarations in an environment not connected to the production interface, and simulates variable passing between nodes. If a subsequent node references a variable not generated in the previous node, or if the failed exit has no termination, recertification, or rollback path, the work order cannot be issued. After passing the validation, the system freezes the model version, knowledge snapshot, and work order graph summary.

[0087] When performing observation write-back, the actual output, observation interface, and time interval are recorded. If the observation is inconsistent with the expectation, the original node is not changed to success. Instead, the failure or unobservable exit is activated, forming a new version of the mind tree. Manual modifications are also added as new nodes, so that the changes caused by model candidates, rule pruning, and manual decisions can be traced.

[0088] Data records are based on work order inference nodes. Each record includes at least the preceding state, execution interface, parameter source, expected observation, failure exit, permission level, and rollback node. Business identity and the database's auto-incrementing primary key are stored separately. The business identity is determined by the fault context summary, knowledge snapshot version, and mind tree node identifier, while the auto-incrementing primary key is only used for physical location. Updates use append-only versions, with the previous version recording its termination reason and remaining readable, thus enabling differentiation between object changes, repeated data collection, and reprocessing of the same object.

[0089] After a work order inference node is generated, it becomes a candidate node. If there is a lack of current state that can be obtained from a read-only probe, it becomes a node awaiting verification. If all five hard constraints are met, it is marked as executable; if they are not met and cannot be verified, it is marked as pruned. After completing the sandbox check and freezing the summary, it is considered published. Execution observations then categorize it as successful, failed, or unobservable. Each transformation references the actual observation or rule number. During recovery, it is replayed according to the parent-child summary chain. It is not allowed to create intermediate judgments based on the final work order text.

[0090] Before modifying configurations, restarting services, or isolating resources, the execution agent first saves the target object's current state summary, expected write set, and fixed rollback nodes before calling the tool interface. The action is confirmed when the acknowledgment matches the independent observation; if the acknowledgment times out and the external state is unclear, an unobservable exit is activated to prevent the model from generating new retry parameters.

[0091] An action idempotent key consists of an object stability identifier, a knowledge snapshot version, a mind tree node identifier, and an input summary. When the same key is accessed repeatedly, an existing observation reference is returned; if the summary changes, overwriting is refused. When multiple execution proxies compete for the same node, only the proxies that acquire the conditional write right can call interfaces with side effects.

[0092] The effective time of knowledge entries, the fault observation time, and the work order execution observation time are each stored as an interval. Current evidence must fall within the applicable interval of the entry and be consistent with the object version; late observations are written to the original tree version, and if the predicate evaluation is changed, a successor version is generated, without forcibly reducing time uncertainty to a single point.

[0093] Tree depth and branch limit are used to restrict the number of nodes that can be deployed in a single fault handling operation. The total cost boundary simultaneously constrains downtime, risk, and the amount of new evidence. Decoding length is written to the model manifest, and sandbox timeout is set according to the slowest parsing upper bound allowed by the tool. These values, along with knowledge snapshots, model artifacts, and field syntax, form a read-only inference configuration. Modifying any value generates a new tree version, and published tickets continue to reference the configuration at the time of generation.

[0094] In the event of an interruption or partial failure, the recovery process is limited to: using the state summary saved before the action execution and the fixed rollback edge for recovery, without temporarily rewriting parameters by the generated model. Each rollback request has an independent action number, and upon successful execution, a recovery observation and a post-recovery summary are appended; if a step cannot be recovered, subsequent compensations that depend on that step are discontinued, on-site evidence is preserved, and the object is placed in an isolated state to prevent null values ​​from masquerading as recovery completion.

[0095] The system consists of a knowledge retrieval service, a parameter-frozen generative model, a work order orchestrator, a sandbox, and an execution agent. Nodes are passed between modules using structured objects with schema versions; unknown optional fields can be ignored, while unknown required fields, evidence references, or tool enumerations all result in the node being rejected.

[0096] The validation set includes failures such as knowledge version changes, lack of read-only evidence, insufficient permissions, and non-rollback operations. By comparing solutions that directly generate natural language work orders, only impose field constraints, and use mind tree pruning, each solution is checked for missing parameters, unauthorized actions, non-rollback operations, circular dependencies, and the number of missing failure exits. Additionally, errors that still enter the execution phase after sandbox interception are counted.

[0097] When the control process resumes, it first reads the most recent complete mind tree checkpoint, then scans unconfirmed action preparation and observation records. Confirmation nodes restore the activity index; for side effect actions with only preparation records, it first queries the target object, and based on the query results, confirms, rolls back, or transfers to manual processing, without re-calling the generative model to rewrite the action.

[0098] The knowledge service provides pre-existing states and evidence references, retaining the original text summary. Resource identifiers returned by the configuration management library, parameter patterns given by the tool catalog, and permission levels given by the permission system are converted into node fields according to their respective versions. Content that cannot be converted is marked as unknown and is not supplemented by the generated model. When two sources conflict on the same pre-existing state, two observations are retained, and the relevant branches are converted to pending verification until a verifiable current state is generated by a read-only probe or manual confirmation.

[0099] If feasible branches have the same Q-value, the selection is not directly assigned to the generative model. The system first compares effective observation coverage, then compares risk, rollback distance, and expected downtime, and finally obtains a repeatable order based on node stability. Each comparison value, the knowledge entries used, and the reason for pruning are written to the tree node, so the ranking results can be reproduced within the same context, model inventory, and knowledge snapshot.

[0100] Before nodes are written to the database, fields are encoded according to a fixed pattern: the object stability identifier and knowledge snapshot are located in the header, followed by the previous state, tool interface, parameter source, expected and failure observations, permission level, and fixed rollback node; the numerical values ​​include the unit, and the enumeration includes the model version. The encoded result, together with the model artifact summary, is used to calculate the node summary. The display name is not used for identity verification, thereby avoiding the incorrect reuse of resources with the same name or tools with different versions.

[0101] The node version summary is calculated by encoding the object stability identifier, fault context summary, knowledge snapshot summary, model artifact summary, node input and parameter snapshots by field length. The reading end also compares the field schema versions to prevent the wrong reuse of resources with the same name in different configuration versions.

[0102] The quality of node evidence is recorded in terms of source authenticity, temporal integrity, field integrity, and cross-consistency. Pruning rules declare the quality components required for each precondition; when an observation is updated, only the output and downstream nodes of that observation are re-evaluated.

[0103] If a candidate node lacks a field, the pruner first determines whether that field is involved in the current predicate, permission determination, or rollback reachability. Missing fields without dependencies only leave a quality marker; when the current state, parameter source, or permissions required for modifying configurations, restarting services, or isolating resources are missing, the node becomes a pending verification, and predefined read-only diagnostic nodes are generated first. Restoring observations must be associated with the original fault context summary, knowledge snapshot, and parent node identifier; subsequently, only the corresponding exit point is expanded.

[0104] Each side effect node corresponds to a preparation, tool call, execution observation, and fixed rollback record in the work order directory. If the receipt is lost but the independent observation meets the success predicate, the original node is confirmed without resending; if the observation field is missing or incomparable, the unobservable exit is activated and automatic repair is stopped.

[0105] The mind tree is partitioned according to the stability identifier of the faulty object. Only one orchestrator is allowed to add an exit for the same tree version and node identifier. Different faulty objects can be processed in parallel. When the queue reaches the limit, the results of observation, rollback confirmation and supplementary verification must not be merged. Duplicate alarms can be collapsed into root node inputs with counts when the object version, knowledge snapshot and observation interval are the same. Alarms before and after the work order execution cannot be combined into one.

[0106] During verification, the system should inject duplicate tool receipts, observe out-of-order execution, orchestrator restarts, tool timeouts, knowledge mode switching, and a knowledge entry with an error resource identifier. The system should reject non-existent references, leave actions in the pending verification or manual approval branch when permissions or rollback evidence are incomplete, and activate unobservable exits when receipts are unclear. If the execution agent is interrupted again during rollback, upon recovery, the saved state summary and fixed rollback parameters must be used; temporary rewrite commands for the generated model cannot be invoked.

[0107] Boundary testing includes branches with complete evidence, branches with permissions or parameters just at the allowed boundary, and branches lacking only one current observation. Verification includes whether a node has been converted to read-only diagnostics, whether an unobservable exit point is active, whether a no-rollback action has been blocked, and whether evidence references still point to a locked snapshot.

[0108] Knowledge retrieval, sandboxing, and execution proxy each use the least privilege credentials. The work order inference node only stores the credential reference summary and permission scope. Insufficient permissions result in pruning reasons or manual approval nodes, which are not interpreted by the model as faulty object states; when exported externally, asset names are replaced with stable anonymous identifiers.

[0109] Closed, continuous tree versions that have exceeded the audit period can be compressed into checkpoints, but the parent-child summary chain, knowledge snapshot, model artifacts, observation references, and fixed rollback locations must be preserved. Nodes awaiting verification, unobservable, with unclear commits, or still referenced by published tickets must not be compressed.

[0110] When reproducing a real-world example, first lock the current state of the faulty object and the knowledge snapshot K1, then load the immutable model list M1 and its field syntax. After generating candidate nodes through constrained decoding, expand the mind tree using actual observations as the exit point, sequentially performing hard pruning, Q-value comparison, dependency graph orchestration, and sandbox checks. Work orders that pass the checks are frozen in K1, M1, and the graph summary. Subsequent observations or manual modifications only add successor nodes; when knowledge is updated to K2, only unpublished nodes that depend on the changed entries are regenerated, while published work orders corresponding to K1 remain traceable.

[0111] Knowledge retrieval, constrained decoding, graph orchestration, and sandboxing can be deployed on the same control node or distributed through a structured interface. Node storage can use a graph database or other media that supports append-only versions. Alternative implementations still require locking knowledge snapshots and model artifacts, restricting fields and reference ranges with finite state syntax, and using pre-execution state summary connections to fix rollback edges. If the underlying components cannot save these versions and edge relationships, an immutable list and parent-child summary chains should be added at the orchestration layer.

[0112] Example 3 illustrates the input, status changes, and exception handling by taking the same alarm as different handling knowledge in two software versions, where a read-only diagnostic evidence is currently missing and the repair action requires hierarchical authorization, and a diagnostic node needs to be generated first before deciding on the repair branch that can be rolled back.

[0113] Taking the image pull failure alarm on the container node as an example, the knowledge base contains three processing items: agent configuration, certificate expiration, and repository rate limiting.

[0114] Step 1: Solidify the node operating system, container runtime version, repository address, and recent changes, and lock the knowledge snapshot K7.

[0115] Step 2: The model generates candidate nodes based on three evidence items. Each node contains applicable conditions, observation commands, and rollback actions.

[0116] Step 3: Expand the mind tree with DNS resolution, certificate chains, and response codes as observation branches.

[0117] Step 4: If the current version does not support a certain proxy parameter, the proxy modification branch will be removed; if the certificate status is unknown, the diagnostic steps will be converted to read-only certificates.

[0118] Step 5: After the diagnostic returns a valid certificate and a response code indicating rate limiting, only the branches with backoff and mirror source switching are retained.

[0119] Step 6: Generate the work order dependency graph and write the actual response code and image digest back to the tree version after execution.

[0120] When a candidate node lacks knowledge, current observations, permissions, or rollback evidence, it is not supplemented with language model confidence; the device is classified as a knowledge gap, read-only diagnosis, manual approval, or unknown node according to the following boundaries.

[0121] (1) When there is no valid version of a knowledge entry or the summary verification fails, the execution action is prohibited and only the knowledge gap is output.

[0122] (2) If the model output field does not conform to the pattern, the candidate is discarded and the input-output summary is recorded. The command is not inferred from the free text.

[0123] (3) When multiple branches have similar scores and involve mutually exclusive high-risk actions, the parallel branches are retained and manual selection is required.

[0124] (4) When the observed value exceeds the predetermined range, enter the unknown node and stop automatic repair.

[0125] (1) Candidate nodes can be generated by rule templates, generation models or a combination of both, and the subsequent deterministic verification process remains unchanged.

[0126] (2) Branch selection can be achieved using bundle search, shortest cost path or constraint satisfaction algorithm.

[0127] (3) The sandbox can be a container, command parser or device simulation interface, as long as it does not produce real side effects and can return parameter parsing results.

[0128] Figure 2 The model employs six submission boundary partitioning mechanisms: evidence freezing, candidate generation, tree expansion, hard constraint pruning, work order orchestration, and execution feedback. The model only participates in candidate formation in module 12; modules 14 through 16 process data based on structured fields and deterministic rules.

[0129] The Context and Knowledge Snapshot module 11 solidifies the original alarm value, object stability identifier, software version, current status observation, and permission boundaries into a context summary, while locking the set of knowledge entries and their effective range.

[0130] The constrained candidate generation module 12 adds node field syntax, allowed knowledge reference set and tool whitelist to the decoding constraints, and outputs candidate nodes containing pre-predicate, action parameter source, expected observation and fixed rollback reference.

[0131] The Mind Tree Extension Module 13 selects the exit condition as true, false, or unobservable based on the evaluation result of the expected predicate by actual observation; adding a new observation only expands the subtree that depends on the observation, without rewriting the already frozen sibling branches.

[0132] The deterministic pruning module 14 sequentially checks the knowledge version, current evidence, parameter resolvability, permissions, and fixed rollback edge; actions that can be safely supplemented are converted into read-only diagnostic nodes, and the remaining branches that do not meet the hard constraints are marked with the reason and then stop expanding.

[0133] The work order diagram arrangement module 15 selects branches from the reserved branches that cover the fault phenomena and whose total cost meets the boundary, merges shared diagnostic nodes, and maintains the order of mutual exclusion repair and rollback edges.

[0134] The verification and feedback module 16 first performs field, permission, and rollback integrity checks, and then parses the parameters in a sandbox without production side effects; the response code, object digest, and rollback confirmation obtained after release are added as evidence for the new tree version.

[0135] Figure 2 The write-back arrow in the code only transmits the actual observation and its source summary, and does not allow module 16 to directly write the execution results back to the old knowledge entries; knowledge updates form a new snapshot version, and historical work orders still reference the knowledge and model artifacts frozen at the time of generation.

[0136] The device can consist of a knowledge retrieval service, a parameter-frozen generative model, a work order orchestrator, a sandbox, and an execution agent; the services pass work order inference nodes with schema versions to each other, but do not pass free text commands to be executed.

[0137] Knowledge entries and ticket versions use content summary addressing, and ticket records referencing relationships without copying variable links.

[0138] The resource identifier and credential reference in the command template are parsed at the work order execution end. The generation end only saves the parameter source and permission requirements, and does not save the plaintext credentials.

[0139] Fault samples with known root causes, version differences, and knowledge conflicts are selected, and keyword concatenation, unconstrained generation, and the method of this invention are performed respectively, and then replayed in an isolated environment.

[0140] Traceability is verified by checking whether each work order action can be located to the locked knowledge item, read-only diagnostic observation, and node parent relationship;

[0141] For nodes that were blocked before release, the percentages of reasons why parameters, permissions, versions, and rollback conditions were not met were statistically analyzed.

[0142] For all actions with side effects, check for fixed rollback edges where parameters are frozen and reachable;

[0143] After the knowledge base is updated, historical work orders are replayed to compare whether their reference snapshots, node meanings, and action parameters are preserved.

[0144] In samples where evidence is insufficient or observation is unavailable, check whether the verification system switches to read-only diagnostics, manual approval, or unknown nodes without automatically performing repairs.

[0145] The knowledge retrieval service stores the valid range of entries and content summaries, generates an immutable model list and field syntax for service loading, the orchestrator stores mind trees and work order diagrams, and the execution agent only parses structured parameters that have passed sandbox checks. Each node is associated with a fault context summary, knowledge snapshot, model artifact summary, and mind tree node identifier, and credentials only store controlled references.

[0146] Figure 2 The modules shown can be deployed centrally, or module 16 and the execution agent can be deployed in a controlled operation and maintenance domain; regardless of how the process is split, module 12 cannot bypass module 14 and module 16 to directly output production write actions.

[0147] The Context and Knowledge Snapshot module 11 is used to normalize alarms, configuration items, software versions and permission boundaries, and lock knowledge base version snapshots that match the fault context.

[0148] The constrained candidate generation module 12 is used to input the fault context, knowledge snapshot and work order node structure constraints into the generation model to obtain candidate work order inference nodes that conform to the predetermined field pattern.

[0149] The mind tree extension module 13 is used to extend the mind tree with the expected observations of candidate nodes as branch conditions, and to calculate the coverage of unexplained fault phenomena and the need for new evidence for each branch.

[0150] The deterministic pruning module 14 is used to prune the mind tree based on version applicability, current evidence, parameter resolvability, permissions, and rollback reachability.

[0151] The work order diagram arrangement module 15 is used to extract the branch with the highest branch score that covers the fault phenomenon, satisfies all the hard constraints of version, current status, parameters, permissions and fixed rollback edge from the pruned mind tree, and convert the branch into a work order dependency diagram that includes preconditions, execution actions, observation points and rollback edges.

[0152] The verification and feedback module 16 is used to perform static verification and sandbox parameter checks on the work order dependency graph, output the work order, and write the execution observations back as evidence for the mind tree nodes.

[0153] Electronic devices that carry out generation, orchestration, or verification services include processors, memory, and communication interfaces. The memory stores knowledge snapshots, immutable model inventories, work order inference nodes, fixed rollback edges, and execution observations; the processor appends nodes based on fault context summaries and tree versions; and the communication interface associates existing execution records with node identifiers and invocation idempotent keys when it receives duplicate tool receipts.

[0154] The above implementation methods are used to illustrate the implementation relationship between knowledge snapshots, constrained candidate nodes, observation branches, deterministic pruning, and fixed rollback; when replacing the model, retrieval engine, or sandbox, the evidence citation, current state activation, and production write interface isolation rules still need to be maintained.

Claims

1. A method for generating maintenance work orders for a knowledge base based on mind trees, characterized in that, include: Collect the status and permission boundaries of faulty objects, filter knowledge entries according to applicable objects, versions, time and permission scope, and form a knowledge base version snapshot that includes preconditions, operations, expected observations, evidence sources and fixed rollback operations; The fault object data, the snapshot, the work order inference node field pattern, the tool interface pattern, and the prohibited action set are used as read-only inputs to the parameter-frozen generative model. After constrained decoding, candidate work order inference nodes that conform to the field pattern and contain knowledge evidence references, execution interfaces, expected observations, observation exits, permission levels, and rollback nodes are generated. Using the faulty object data as the root node, establish success, failure, and unobservable branches according to the expected observation predicates, and only activate the matching exit based on the actual observation returned by the execution agent; Based on five constraints—knowledge version, current evidence, parameters, permissions, and rollback reachability—infeasible branches are pruned, candidate nodes whose current evidence can be supplemented by probes without side effects are converted into read-only diagnostic nodes, and the target branch is selected. The target branch is converted into a work order dependency graph, shared read-only diagnostic nodes are merged, mutually exclusive repair branches are retained, and state summaries, execution observations, and fixed rollback nodes are connected for actions with side effects. The work order dependency graph is statically validated and sandboxed without connecting to the production interface. After passing the validation, a structured operation and maintenance work order is output. Actual observations are received, and when they do not meet the original expected observation predicates, failure exits or unobservable exits are activated, generating a new version that references the original mind tree version without rewriting the published work order.

2. The method as described in claim 1, characterized in that, The generative model is a decoder-based Transformer language model with parameters frozen during the operation of the method. It includes a lexical embedding layer, L sequentially connected causal mask multi-head self-attention and feedforward network modules, residual connections and normalization layers, and an output projection layer. Each self-attention module has H attention heads and a hidden dimension of D. The immutable model inventory records L, H, D, vocabulary and segmenter summary, weight artifact summary, quantization method, maximum context length, maximum output length, and decoded syntax summary.

3. The method as described in claim 1, characterized in that, The field pattern is converted into a deterministic finite state grammar, and knowledge evidence references and resource identifiers are constructed into a prefix trie. For each word output by the generative model, the set of allowed words is obtained based on the current grammar state, allowed enumeration values ​​and the prefix trie, and the remaining words are masked. If the lexical set is empty, the maximum output length is reached but the syntax is not in an accepting state, or the output contains evidence of natural language other than the field pattern or that the reference does not exist, the corresponding candidate work order inference node is rejected.

4. The method as described in claim 1, characterized in that, For a branch p that satisfies the five constraints, calculate Q(p) = Cover(p) - λ1Risk(p) - λ2Cost(p) - λ3Unknown(p), where Cover(p) is the proportion of the weight of the fault phenomenon supported by actual observation or valid knowledge evidence to the total weight of all fault phenomena, Risk(p) is the normalized risk formed by the permission level, the number of actions with side effects, and the rollback distance, Cost(p) is the normalized cost formed by the expected downtime, the number of changed objects, and the number of new probes, and Unknown(p) is the proportion of the number of nodes lacking actual observation or valid knowledge evidence to the total number of branch nodes.

5. The method as described in claim 1, characterized in that, The side-effect-free probe only calls a predefined read-only interface or a recoverable probe and has a predetermined output field and value range. When the output is not within the predetermined value range, it enters an unobservable exit. The sandbox includes at least one of a command parser, an isolation container, or a device emulation interface. It does not carry production credentials or a production management network. Interfaces that cannot be confirmed to be side-effect-free only perform syntax and parameter checks in the sandbox without execution.

6. The method as described in claim 1, characterized in that, When a work order is published, the model version summary, knowledge base version snapshot summary, and work order dependency graph summary are frozen. Actual observations include at least the work order node identifier, actual output, observation interface, observation time interval, and input summary. Only when the input summary and object stability identifier are consistent with the published node are they written into the new mind tree version. Manual modifications are also appended to the new node.

7. A knowledge base maintenance work order generation device based on mind tree, characterized in that, The system includes a context and knowledge snapshot module, a constrained candidate generation module, a mind tree expansion module, a deterministic pruning module, a work order diagram orchestration module, and a verification and feedback module. The context and knowledge snapshot module collects the status of faulty objects and locks the knowledge base version snapshot. The constrained candidate generation module generates structured candidate work order inference nodes based on field patterns and evidence citation ranges. The mind tree expansion module establishes exit points using expected observation predicates and activates corresponding child nodes based on actual observations. The deterministic pruning module performs constraints on knowledge version, current evidence, parameters, permissions, and fixed rollback edges, and converts nodes that can supplement evidence into read-only diagnostic nodes. The work order diagram orchestration module selects branches, merges shared diagnostic nodes, and maintains mutually exclusive repair and fixed rollback relationships. The verification and feedback module performs static verification and sandbox verification without production side effects, outputs structured operation and maintenance work orders, and writes the execution observations into the new mind tree version.

8. An electronic device, characterized in that, The device includes a processor, a memory, a communication interface, and a computer program stored in the memory and capable of running on the processor. The communication interface is used to connect to an alarm platform, a configuration management library, a knowledge base, a sandbox, or an execution agent. When the computer program is executed by the processor, it implements the method described in any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 6.

Images