A disaster emergency plan dynamic matching method based on multi-dimensional features

Abstract

The application discloses a kind of disaster emergency plan dynamic matching methods based on multidimensional features, specifically relates to emergency management information processing field, for solving the problem that the reply continues to change in the process of disaster disposal causes plan matching result and field state disjunction;By merging disposal action reply and key resource reply based on event identification, form the action set to be confirmed, initial scene snapshot and constrainted scene snapshot, filter candidate plan set, generate starting execution condition check result, starting condition evidence string and reply landing point fragment around starting execution condition and form switching check result, combined with matching basis record, new arrival reply execution verification range positioning, local recalculation and re-matching, realize that plan matching result is revised continuously with disposal progress and keeps judgment basis traceability.

Description

Technical Field

[0001] This invention relates to the field of emergency management information processing, and more specifically, to a method for dynamic matching of disaster emergency plans based on multi-dimensional features. Background Technology

[0002] In disaster emergency response, existing technologies are capable of retrieving, reconstructing, recommending, and generating emergency plans based on real-time information, situation assessment, risk analysis, resource status, and historical plans at the accident site. These plans are continuously dynamically matched and updated as the situation on-site changes. Some solutions focus on organizing multiple types of information into structured features for matching, while others emphasize using knowledge graphs or semantic analysis to improve recommendation accuracy. Still others link current emergency information with plan results to continuously update models and knowledge bases. Overall, existing solutions possess the basic capabilities of "multi-dimensional feature participation in plan matching" and "dynamic adjustment based on on-site changes," supporting the transformation of disaster emergency plans from static invocation to dynamic matching. This aligns well with the business scenario of constantly changing information and the need for continuous plan adjustments during disaster emergency response.

[0003] However, in the practical application of dynamic matching of disaster emergency plans based on multi-dimensional features, after the previous round of matching results has entered the execution phase, the scenario features used in the next round of matching often remain in the pre-response state or only reflect part of the post-response state. This leads to inconsistencies between the results of the new round of dynamic matching and the actual on-site response progress. This causes the system to continue providing already executed response steps or to use plan logic that is no longer suitable for the current stage. While the system appears to be continuously outputting matching results, the recommended content is actually lagging and mismatched. Furthermore, these mismatched results will enter subsequent plan updates, knowledge graph updates, or model learning processes, making it even more difficult for the dynamic matching results to remain consistent with the on-site response status during continuous use, thus affecting the system's actual usability and credibility in disaster emergency plan dynamic matching scenarios.

[0004] To address the aforementioned problems, a technical solution is provided. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a dynamic matching method for disaster emergency plans based on multi-dimensional features. This method merges action receipts and key resource receipts based on event identifiers to form a set of actions to be confirmed, an initial scene snapshot, and a constrained scene snapshot. It then filters a set of candidate plans, generates a verification result of the initial execution conditions, an evidence string of the initial conditions, and a receipt landing point fragment around the initial execution conditions, and forms a switching verification result. Combined with matching basis records, it locates the execution verification scope of newly arriving receipts, performs partial recalculation and rematching, enabling the plan matching result to be continuously revised as the handling progresses and maintaining the traceability of the judgment basis, thereby solving the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] S1. Collect and organize the action receipts and key resource receipts based on the event identifiers, generate merged action receipts and key resource receipts, form a set of actions to be confirmed, and generate an initial scene snapshot.

[0008] S2. Determine the set of affected scene fields based on the set of actions to be confirmed and the action-to-scene field mapping table, perform scene snapshot constraint processing on the initial scene snapshot to generate a constrained scene snapshot, and retrieve the contingency plan library to form a candidate contingency plan set;

[0009] S3. Read the starting execution conditions of the candidate plan set and generate the starting execution condition verification result. Combine the set of actions to be confirmed to construct the starting condition evidence string and the receipt landing point fragment. Generate the switching verification result based on the connection state of the execution starting point and the stable state supported by the receipt.

[0010] S4. Register the matching basis record and pending confirmation item corresponding to the switching verification result with the event identifier. After receiving the new arrival receipt, generate the verification range record and perform partial recalculation. Revise the rematch trigger condition and the contingency plan removal condition and update the switching verification result.

[0011] Furthermore, based on the event identifier, the system extracts the action receipts and key resource receipts from the event reporting system, command and dispatch system, and resource management system. The action receipts are indexed by the action identifier and combined with the state change sequence information to perform state evolution determination to form merged action receipts. The key resource receipts are indexed by the resource identifier and combined with the state change sequence information to perform state evolution determination to form merged key resource receipts.

[0012] Furthermore, based on the merged action receipts, identify action identifiers that are not closed and have conflicting states. Combine the merged key resource receipts with the associated resource identifiers to form a set of actions to be confirmed. Use the event basic scene information associated with the event identifier and the merged key resource receipts to generate an initial scene snapshot. Write the action identifier, the confirmation tag, and the associated resource identifier in the action status reference area.

[0013] Furthermore, based on the action identifier in the action set to be confirmed, the action to scene field mapping table is queried to form an affected scene field set and write the field index marker of the initial scene snapshot. Based on the merged disposal action receipt and the merged key resource receipt, the confirmation write judgment is performed. For scene fields that meet the write requirements, the scene state after the action is affected is written. For scene fields that do not meet the write requirements, the original value is retained and the pending confirmation state is registered to form a constrained scene snapshot.

[0014] Furthermore, based on the event category and event handling stage marker in the constrained scene snapshot, a pre-screened set of contingency plans is formed by searching the contingency plan library. Then, a preliminary set of contingency plans is formed by comparing the resource occupancy premise with the resource status area. The initial execution conditions of the preliminary set of contingency plans are read and the action-level conflict determination and resource-level conflict determination are performed with the action set to be confirmed and the merged key resource receipt. Contingency plans without registered conflict markers are retained to form a candidate set of contingency plans.

[0015] Furthermore, the starting execution conditions in the candidate plan set are read, and the starting execution conditions are checked against the merged disposal action receipts, merged key resource receipts, and constrained scene snapshots according to the condition sequence number. A check status sequence containing satisfied, unsatisfied, and pending confirmation statuses is generated, and the starting execution condition check result is generated according to the sequential condition judgment rules.

[0016] Furthermore, the evidence source is extracted according to the condition sequence number of the initial execution condition and combined with the set of actions to be confirmed to generate the initial condition evidence string. Based on the initial condition evidence string, the front-end connection form is identified and the initial connection domain mapping table is used to generate the initial condition connection settlement value. At the same time, the receipt landing point fragment is generated around the action requirements and resource requirements in the initial execution condition and the double receipt settlement consistency value is generated through the receipt consistency domain mapping table.

[0017] Furthermore, the initial condition settlement value and the double-receipt settlement consistency value are input into the monotone complementary tree analysis to generate the switching confidence coefficient. The switching confidence coefficient and the initial execution condition verification result are then combined to form the plan-level switching verification result. Based on the plan-level switching verification result and the switching confidence coefficient, the target plan or current plan and the items to be confirmed are sorted and output.

[0018] Furthermore, matching basis records are established based on event identifiers and items to be confirmed are sealed. The matching basis records are written with the switching verification results, the initial execution condition verification results, the initial condition evidence string, the receipt landing point fragment, the action receipt status summary and the key resource receipt status summary. After the new receipts arrive, the merged action receipts and the merged key resource receipts are updated and a verification scope record is generated.

[0019] Furthermore, based on the verification scope record, the initial execution condition verification result, the initial condition evidence string and the receipt landing point fragment are partially recalculated to form the previous judgment verification result. The previous judgment verification result drives the revision of the rematch trigger condition and the contingency plan elimination condition. After the revision is completed, the switching verification result is regenerated and the matching basis record and the item to be confirmed are updated.

[0020] The technical effects and advantages of the present invention, a dynamic matching method for disaster emergency plans based on multi-dimensional features, are as follows:

[0021] This invention addresses the real-world scenario of continuously changing information, unstable response status, and distorted contingency plan switching during disaster response. It establishes a continuous processing chain from event merging, scenario constraints, candidate plan screening, switch verification, to verification, revision, and re-matching. This ensures that contingency plan matching is not limited to a one-time search result but is continuously updated to reflect the progress of the response. By first separating unstable response actions from the actual scenario, then retaining clues for confirmation in the scenario snapshot, and verifying the candidate plans in conjunction with the initial execution conditions, it reduces the possibility of misjudging incomplete states as met, making the contingency plan matching results more consistent with the actual on-site situation, and ensuring that the output results better align with the usage habits and judgment rhythm in emergency command.

[0022] Meanwhile, this invention saves matching basis records and combines them with new arrival receipts to locate the verification range and perform partial recalculation. This ensures that subsequent revisions are based on previous judgments, eliminating the need for repeated re-judgments from the entire dataset. This maintains the continuity of the judgment process and improves the stability and traceability of the dynamic matching process. This approach not only ensures that the plan switching results are neither too early nor too late when there are frequent changes in the response phase, but also allows for natural matching corrections as the pending confirmation status gradually dissipates. It is more suitable for the dynamic matching of disaster emergency plans, a business scenario requiring continuous judgment and verification. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating a dynamic matching method for disaster emergency response plans based on multi-dimensional features, as described in this invention. Detailed Implementation

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

[0025] Please see Figure 1 This invention provides a dynamic matching method for disaster emergency response plans based on multi-dimensional features, including:

[0026] S1. Collect and organize the action receipts and key resource receipts based on the event identifiers, generate merged action receipts and key resource receipts, form a set of actions to be confirmed, and generate an initial scene snapshot.

[0027] S2. Determine the set of affected scene fields based on the set of actions to be confirmed and the action-to-scene field mapping table, perform scene snapshot constraint processing on the initial scene snapshot to generate a constrained scene snapshot, and retrieve the contingency plan library to form a candidate contingency plan set.

[0028] S3. Read the starting execution conditions of the candidate plan set and generate the starting execution condition verification result. Combine the set of actions to be confirmed to construct the starting condition evidence string and the receipt landing point fragment. Generate the switching verification result based on the connection state of the execution starting point and the stable state supported by the receipt.

[0029] S4. Register the matching basis record and pending confirmation item corresponding to the switching verification result with the event identifier. After receiving the new arrival receipt, generate the verification range record and perform partial recalculation. Revise the rematch trigger condition and the contingency plan removal condition and update the switching verification result.

[0030] This invention does not treat disaster emergency plan matching as a one-time retrieval problem. Instead, it incorporates the continuously changing business fact of response action receipts and key resource receipts into the main matching process. First, it merges multi-source receipts using event identifiers to form merged response action receipts and merged key resource receipts. Unstable response actions are extracted as a set of actions to be confirmed. Then, an initial scene snapshot is constructed based on this, and a constrained scene snapshot is formed through scene snapshot constraint processing. Based on the separate expression of scene facts and clues to be confirmed, a set of candidate plans is screened out. Subsequently, based on the initial execution conditions of the candidate plans, the initial execution condition verification result, the initial condition evidence string, and the receipt landing point fragment are generated to form a switch verification result, thereby determining whether the current point in time is suitable for switching plans. Finally, the judgment basis of this round is saved through matching basis records. When a new receipt arrives, a partial recalculation and rematch are performed according to the verification scope, so that the plan matching result can be continuously revised as the response progresses. The overall solution is to first unify the event context, then constrain the scene expression, then verify the switching conditions, and finally achieve dynamic matching through basis recording and incremental verification.

[0031] In the dynamic matching scenario of disaster emergency response plan, event reporting information, response action receipts and key resource receipts belong to different business links, and the recording rhythm and status expression are not consistent. Using information from any link alone can easily lead to the understanding of the response progress as a static scenario. The role of step S1 is to first establish a unified event scope around the event identifier, organize the response execution status and resource status into the same event context, and separate the unstable response actions from the scenario facts, so that the scenario expression includes both the current status information and the clues to be confirmed.

[0032] S1.1: Event identifier merging scope establishment.

[0033] First, the event identifier is read from the event reporting system and used as the merging key for this processing flow. This merging key is used to group multi-source data belonging to the same event into the same processing scope and serves as a unique association field. Then, the command and dispatch system retrieves action receipts consistent with the event identifier, and the resource management system retrieves key resource receipts consistent with the event identifier. The retrieval results form an event identifier-related data set, which is a collection of action receipts and key resource receipts aggregated based on the same event identifier. The event identifier-related data set retains the action receipts and key resource receipts corresponding to the event identifier. If there are different association field names in the command and dispatch system or the resource management system, field mapping is performed first to map the external fields to a unified event identifier field before including them in the event identifier-related data set. After the event identifier merging scope is established, subsequent sub-steps are processed within the event identifier-related data set, without re-retrieving all receipt records.

[0034] S1.2: Merge and organize action receipts and key resource receipts.

[0035] Based on the event scope already defined in the event identifier associated data set, step S1 performs merging and sorting on the action receipts and key resource receipts respectively. The merging and sorting involves aggregating and sorting multiple receipts according to the same identifier and determining the current acceptance status. Action receipts are merged according to action identifiers, and key resource receipts are merged according to resource identifiers. The merging and sorting includes three processing steps: index establishment, order determination, and status evolution determination. The status evolution determination is a determination process that determines the current acceptance status based on the order of status changes and preset evolution rules.

[0036] In the index creation stage, step S1 establishes an action receipt index table based on action identifiers and a key resource receipt index table based on resource identifiers, allowing multiple receipts with the same action identifier or resource identifier to enter the same index item. In the sequence determination stage, step S1 extracts the status change sequence information from the original receipt record. The status change sequence information preferentially uses the sequence identifier inherent in the receipt; if the sequence identifier is missing, the receipt time identifier is used; if the receipt time identifiers cannot be compared, the receiving sequence identifier is used. When the status change sequence information of two receipts still cannot be distinguished, the two receipts are retained side by side and a sequence conflict flag is registered. In the status evolution determination stage... For receipts within the same index entry whose order can be determined, sort them according to the order of status change information, and determine the latest valid status based on the status evolution determination rules. The status evolution determination rules are executed separately for action status and resource status. The determination of action status is based on the evolution relationship between action completion status, action execution status, action issuance status, and action cancellation status. The determination of resource status is based on the evolution relationship between resource availability status, resource occupation status, resource release status, and resource unavailable status. If there are contradictory receipt records in the same index entry that cannot be resolved according to the status evolution determination rules, a conflict mark is retained on that index entry.

[0037] After the action receipts are merged and organized, a merged action receipt is formed. Each item in the merged action receipt includes an action identifier, the latest valid status, status change sequence information, associated resource identifier, and conflict marker. The latest valid status is the current status used as the basis for judgment after resolving duplication, contradiction, and timing conflicts. After the key resource receipts are merged and organized, a merged key resource receipt is formed. Each item in the merged key resource receipt includes a resource identifier, the latest valid status, status change sequence information, and conflict marker. The merged action receipts and the merged key resource receipts serve as the sole receipt input objects for subsequent judgments in step S1, and their names remain consistent in subsequent paragraphs.

[0038] S1.3: The set of actions to be confirmed is formed.

[0039] Based on the merged action receipts and key resource receipts having formed valid action-level and resource-level state representations, step S1 continues to form a set of actions to be confirmed. This set consists of action entries that cannot be written into the scene facts due to unstable states. The set of actions to be confirmed is used to identify actions that cannot be written into the scene facts temporarily. The formation process is divided into two parts: action state determination and resource association verification. The processing objects remain consistently the merged action receipts and key resource receipts.

[0040] In the action status determination, the processed action receipts are traversed and merged item by item. First, it is determined whether the action identifier has reached a terminated state. The terminated state is the final state where the action has been completed or canceled and will no longer continue. The terminated state includes the action completion state and the action cancellation state. Action identifiers that have not reached a terminated state and whose latest valid state is the action issuance state or the action execution state are marked as receipt not closed. The receipt not closed is the state where the action has been issued or is being executed but has not yet formed a closed loop receipt for completion or cancellation. Action identifiers with conflict markers are marked as state conflict. When the same action identifier simultaneously satisfies the conditions of receipt not closed and state conflict, the two types of tags are recorded side by side in the candidate action set to be confirmed. The candidate action set to be confirmed is the set of action items that have entered the confirmation screening but have not yet completed the resource association verification. The above action identifiers are added to the candidate action set to be confirmed.

[0041] During resource association verification, the associated resource identifiers corresponding to each action identifier in the candidate action set to be confirmed are read, and the latest valid status and conflict markers of the corresponding resource identifiers are searched in the merged key resource receipts. If a conflict marker exists for the corresponding resource identifier in the merged key resource receipts, a resource conflict tag is added to the corresponding action identifier. If no conflict marker exists for the corresponding resource identifier, the occupancy relationship is determined to be unclosed. An unclosed occupancy relationship means that the resource has entered an occupied state but has not yet formed a corresponding release or stable termination record. The determination of an unclosed occupancy relationship is based on the occupancy-release association chain between the action identifier and the associated resource identifier under the same event identifier. The occupancy-release association chain is a resource occupancy and release relationship chain formed by sequentially connecting the same action identifier and the associated resource identifier in the state sequence. The occupancy-release association chain is formed by organizing the associated resource identifiers and state change sequence information in the merged disposal action receipts. When a resource has entered an occupied state but no release state record corresponding to the associated resource identifier has appeared, or when the resource state changes back and forth between the occupied state and the unavailable state without forming a stable termination state, a resource conflict tag is added to the corresponding action identifier. At this point, the action set to be confirmed is formally formed.

[0042] The set of actions to be confirmed is stored in an itemized structure. Each item contains an action identifier, the current receipt status, the associated resource identifier, and a confirmation tag. In step S1, only three types of business tags are used for confirmation tags: receipt not closed, status conflict, and resource conflict. If the same action identifier meets multiple conditions simultaneously, the confirmation tags are recorded in the same item in a parallel manner. After the set of actions to be confirmed is formed in step S1, the confirmation tags are not resolved in this step. The set of actions to be confirmed serves as the direct input object for the scene snapshot constraint processing in step S2.

[0043] S1.4: Initial scene snapshot generation.

[0044] Assuming that unstable actions have been identified in the action set to be confirmed, step S1 generates an initial scene snapshot. This initial scene snapshot is an initial record of the scene based on the current event information and resource status. The initial scene snapshot adopts a partitioned structure, uniformly including an event status area, a resource status area, and an action status reference area. The event status area records the basic event scene fields, the resource status area records the current status of key resources, and the action status reference area is used to attach the confirmed actions and their relationships without directly writing the scene conclusion. The event status area is written with the event's basic scene information associated with the event identifier in the event reporting system. This basic scene information includes at least the event category and the event handling stage marker. If the event handling stage marker is not explicitly given in the event reporting system, step S1 leaves it empty and does not infer it in this step.

[0045] The resource status area writes the resource identifier and latest valid status from the merged key resource receipts. The writing process creates resource status records item by item based on resource identifiers, retaining a conflict flag field to indicate whether there are any unresolved conflicts for that resource status. The action status reference area writes the action identifier, confirmation tag, and associated resource identifier from the set of actions to be confirmed. This area does not write the scene conclusions after the actions' impact; it only saves the reference relationships and status tags. The purpose is to enable the initial scene snapshot to simultaneously express the basic scene status and key resource status of the event, and to explicitly attach confirmation action clues through the action status reference area, without prematurely converting unstable actions into scene facts.

[0046] After the initial scene snapshot is generated, step S1 outputs the event identifier, the merged action receipt, the merged key resource receipt, the set of actions to be confirmed, and the initial scene snapshot. When step S2 reads the set of actions to be confirmed and the initial scene snapshot, it can directly identify which scene fields are allowed to be written and which scene fields need to remain in a pending confirmation state, thereby forming a candidate plan retrieval basis consistent with the actual progress of the action in the scene snapshot constraint processing.

[0047] After step S1 is completed, the event identifier has defined the scope of data ownership, the merged action receipts and the merged key resource receipts have formed a unified status record, the action set to be confirmed has clearly marked the action items that cannot be directly written into the scene facts, the initial scene snapshot has integrated the basic scene information of the event and the status of key resources and retained the action status reference area, and a structured correspondence has been formed between the event scene and the action execution status.

[0048] The initial scene snapshot given in step S1 retains the basic scene information of the event and clues of actions to be confirmed. This way of expression is suitable for describing the actual handling progress, but it cannot be directly used as the basis for retrieving contingency plans because some scene fields have been affected by the set of actions to be confirmed and have not yet been confirmed. Step S2 establishes the boundaries of affected scene fields around the set of actions to be confirmed and the initial scene snapshot. The confirmed state and the state to be confirmed are expressed separately at the scene level through scene snapshot constraint processing. Then, contingency plans are filtered according to scene conditions and conflict conditions.

[0049] S2.1: The set of fields affected by the scenario is determined.

[0050] Step S2 first establishes the field mapping boundary between the set of actions to be confirmed and the initial scene snapshot. During processing, the action identifiers in the set of actions to be confirmed are read, and the corresponding records are retrieved from the action-to-scene-field mapping table. This table is a pre-configured table showing the correspondence between action identifiers and scene fields, along with writing rules, thus forming an action-impact mapping relationship. This relationship is the correspondence between an action identifier and the scene field it affects. The action-to-scene-field mapping table is pre-stored in the contingency plan configuration library. Each record in the table contains at least an action identifier, a scene field identifier, an impact direction, a writing method, an impact priority relationship, and a same-level conflict resolution rule. The scene field identifier is used to locate specific fields in the initial scene snapshot; the impact direction describes the direction of the action's influence on the scene field's state; the writing method specifies whether a direct write or a state transition write is performed on the scene field; the impact priority relationship handles situations where multiple action identifiers simultaneously affect the same scene field; and the same-level conflict resolution rule handles multiple action identifiers with the same impact priority relationship.

[0051] The affected scene field set is obtained by summarizing the action impact mapping relationship. This set consists of scene fields that require restricted writing due to potential state changes caused by actions to be confirmed. The affected scene field set is stored using a field entry structure. Each field entry contains at least a scene field identifier, a list of associated action identifiers, and a list of impact priority relationships. All action identifiers in the associated action identifier list come from the set of actions to be confirmed. After the field entries are formed, step S2 establishes field index markers in the initial scene snapshot. These field index markers are index records written into the scene snapshot and used to identify the correspondence between scene fields and associated actions. The field index markers are written to the action state reference area of ​​the initial scene snapshot, including the correspondence between scene field identifiers and the list of associated action identifiers. Through this process, the scope of affected scene fields in the initial scene snapshot is clearly defined. Step S2 subsequently only performs scene snapshot constraint processing on the fields corresponding to the affected scene field set, while irrelevant fields retain their original values ​​from the initial scene snapshot.

[0052] S2.2: Scene snapshot constraint processing execution.

[0053] After the set of affected scene fields is established, scene snapshot constraint processing is performed on the initial scene snapshot. This process restricts the writing of affected scene fields according to confirmation conditions, resulting in a constrained scene snapshot. The constrained scene snapshot is a scene record formed after restricting the writing of affected fields based on the initial scene snapshot. The core of scene snapshot constraint processing is to determine the write behavior of the corresponding fields in the affected scene field set and write the determination result back to the initial scene snapshot copy in a unified field status expression. The initial scene snapshot copy, after processing in this step, is named the constrained scene snapshot.

[0054] At the start of processing, each field entry in the affected scenario field set is read sequentially, and the corresponding entry in the action set to be confirmed is located according to the list of associated action identifiers in the field entries. Simultaneously, the relevant status records in the merged action receipts and the merged key resource receipts are read. Subsequently, a confirmation write judgment condition is formed, which is a combination of conditions used to determine whether the affected scenario field allows the write action to affect the result. The confirmation write judgment condition consists of an action status part and a resource status part. The action status part determines whether the action meets the action completion status requirements defined in the mapping table based on the latest valid status and conflict flag in the merged action receipts. The resource status part determines whether the resource meets the resource availability status requirements defined in the mapping table based on the latest valid status and conflict flag in the merged key resource receipts. When both the action status part and the resource status part meet the write requirements, the corresponding associated action identifier is considered to have confirmed the write operation. If either part does not meet the write requirements, the corresponding associated action identifier is considered to have failed to confirm the write operation. The specific definition of the write requirements is configured in the action-to-scenario field mapping table, and the configuration content includes at least the action completion status requirements, resource availability status requirements, and status transition rule identifiers.

[0055] When multiple associated action identifiers exist in a field entry, step S2 determines them sequentially according to their influence priority. First, the associated action identifier with the highest influence priority is retrieved. If the write operation is confirmed, the scene state after the action's influence is generated based on the write method and state transition rules in the action-to-scene-field mapping table, and written to the corresponding scene field. The state transition rules are used to convert the original value of the current scene field into the scene state after the action's influence, and these rules are also stored in the action-to-scene-field mapping table. If the write operation is confirmed to be invalid, the corresponding scene field retains its original scene field value from the initial scene snapshot, and a field status marker is registered next to the corresponding scene field as a pending confirmation state. This field status marker is a marker attached to the scene field to store its confirmed or pending confirmation attribute, and the associated action identifier and pending confirmation label are written to it. The field status marker adopts a scene field-level additional record structure, which is a record structure that is bound to and stores additional status information one by one with the scene field, and is bound to the scene field identifier, without replacing the original value of the scene field.

[0056] If multiple associated action identifiers in a field entry do not meet the confirmation write criteria, only the pending confirmation state is recorded, and the scene state after the action's impact is not generated. If a low-priority associated action identifier meets the confirmation write criteria while a high-priority associated action identifier does not, the original value of the corresponding scene field is maintained, and the pending confirmation state is recorded; the write result of the low-priority associated action identifier is not directly adopted. This is because the scene field state remains unresolved when the high-priority associated action identifier is not yet stable. After the scene snapshot constraint processing is completed, the constrained scene snapshot contains both fields corresponding to the confirmed write state and fields corresponding to the pending confirmation state, with their boundaries clearly distinguished by field state markers.

[0057] S2.3: Retrieval of scenario snapshot plans after constraints.

[0058] After the constrained scene snapshot is formed, step S2 uses the constrained scene snapshot as input to perform a contingency plan library search, forming a preliminary contingency plan set. The contingency plan library search employs a two-layer process: rule-based index retrieval and condition-based matching retrieval. The rule-based index retrieval is a search method that performs rapid filtering based on a pre-established scene adaptation index, while the condition-based matching retrieval is a search method that compares each contingency plan within the pre-selected contingency plan set according to resource occupancy. The rule-based index retrieval first reads the event category and event handling stage markers from the event status area of ​​the constrained scene snapshot, and then searches for matching records in the scene adaptation index of the contingency plan library. The scene adaptation index is a rapid matching index of contingency plans organized by event category and event handling stage, thus forming a pre-selected contingency plan set. This pre-selected contingency plan set is the set of contingency plans retained after initial scene adaptation filtering. The scene adaptation index at least contains a set of contingency plan identifiers corresponding to the event category field and the event handling stage field. When the event handling stage marker is empty, the rule-based index retrieval performs a search based on the event category field and records the empty event handling stage field in the scene matching record, without performing stage-based exclusion at this layer.

[0059] Conditional matching retrieval is performed within the pre-screened plan set. The resource occupancy prerequisites of each plan in the pre-screened plan set are read one by one and compared item by item with the resource status area of ​​the constrained scene snapshot. Resource occupancy prerequisites must include at least a resource identifier and resource status requirements. The comparison results are categorized into three types: resource matching status, resource conflict status, and resource pending confirmation status. When the resource status in the resource status area of ​​the constrained scene snapshot meets the resource status requirements, it is recorded as a resource matching status; when the resource status in the resource status area of ​​the constrained scene snapshot is directly opposite to the resource status requirements, it is recorded as a resource conflict status; when the field status marker associated with the corresponding resource identifier in the constrained scene snapshot is registered as pending confirmation, it is recorded as a resource pending confirmation status. Plans with resource conflict statuses are removed from the pre-screened plan set. Plans containing only resource matching status and resource pending confirmation status are retained in the initial plan set. The initial plan set is the set of plans retained after further comparison of resource conditions, and the resource matching status and resource pending confirmation status are written into the scene matching record. The resulting initial plan set is consistent with the constrained scene snapshot at the event status and resource status levels.

[0060] S2.4: Conflict elimination of action set to be confirmed and generation of candidate plan set.

[0061] After the initial set of contingency plans is formed, the conflict elimination process for the action set to be confirmed continues, forming a candidate set of contingency plans. This candidate set consists of contingency plans retained for subsequent verification after scenario screening and conflict elimination. Conflict elimination includes two types of judgments: action-level conflict judgment and resource-level conflict judgment. Action-level conflict judgment determines whether there is a contradiction between the action requirements in the initial execution conditions and the action set to be confirmed. Resource-level conflict judgment determines whether there is a contradiction between the resource requirements in the initial execution conditions and the resource status and associated resources to be confirmed. Both types of judgments are performed one by one within the initial set of contingency plans. First, the initial execution conditions of each contingency plan are read. In this step, the initial execution conditions are represented by a set of sequential condition entries stored in the contingency plan. This set of sequential condition entries is a set of initial execution condition entries for the contingency plan stored in order of condition number. Each initial execution condition entry includes at least a condition number, a condition type, and a condition object identifier.

[0062] In the action-level conflict determination, step S2 extracts the condition entries of the condition type being action requirement from the initial execution conditions and aligns them item by item with the action set to be confirmed. When the condition object identifier matches the action identifier in the action set to be confirmed, the corresponding confirmation tag is read. If the confirmation tag contains any of the following: unclosed receipt, state conflict, or resource conflict, an action-level conflict flag is registered on the plan, and the corresponding condition number, action identifier, and confirmation tag are written into the conflict determination result summary. If the condition object identifier does not match the action identifier in the action set to be confirmed, no action-level conflict flag is registered.

[0063] In resource-level conflict determination, condition entries of the type "resource requirement" are extracted from the initial execution conditions, and the condition object identifier is aligned with the resource identifier in the merged key resource receipt. Simultaneously, the associated resource identifiers in the action set to be confirmed are verified. When the latest valid state in the merged key resource receipt and the initial execution condition requirement fall into an opposing state pair defined in the resource state opposition table, a resource-level conflict marker is registered on the plan. The resource state opposition table is a pre-defined lookup table of direct exclusion relationships between resource states. Even if no direct conflict exists in the merged key resource receipt, but the corresponding resource identifier appears in the associated resource identifiers of the action set to be confirmed, and the associated action entry contains a resource conflict tag or an unclosed receipt tag, a resource-level conflict marker is also registered. The corresponding condition number, resource identifier, and associated action identifier are written into the conflict determination result summary. After action-level and resource-level conflict determinations are completed, plans without registered action-level and resource-level conflict markers are written into the candidate plan set, along with a scenario matching record and a conflict determination result summary. After the candidate plan set is formed, step S3 can directly read the candidate plan set to perform the initial execution condition check and switch judgment.

[0064] After step S2 is completed, the set of affected scenario fields has been mapped from the set of actions to be confirmed to the initial scenario snapshot. The constrained scenario snapshot has clearly distinguished between the confirmed write state and the pending confirmation state. The contingency plan library retrieval has formed a preliminary set of contingency plans. The action-level conflict determination and resource-level conflict determination have completed conflict elimination. The candidate contingency plan set has scenario boundaries and conflict boundaries that are consistent with the current handling progress.

[0065] The candidate plan set formed in step S2 has eliminated plans that do not match the scenario and have explicit conflicts. However, the candidate plan set is still at the level of scenario matching and has not yet answered whether the plan has the conditions for switching at the current time. Especially when the receipt continues to change and the pending confirmation status still exists, the scenario matching result alone is not enough to support the switching judgment. Step S3 verifies the execution start point and judges the state settlement of the candidate plan set based on the results of the initial execution condition verification, the initial condition evidence string, the receipt landing point fragment and the domain parameter calculation.

[0066] S3.1: Generation of initial execution condition verification results.

[0067] The candidate contingency plan set has already been screened in step S2. However, whether each contingency plan in the set meets the activation conditions at the current time still needs to be checked individually. Step S3 first generates an initial execution condition verification result for each candidate contingency plan. The initial execution condition verification result is formed after checking the initial execution conditions of the contingency plan item by item. During processing, the initial execution conditions of the contingency plans in the candidate contingency plan set are read one by one. The initial execution conditions maintain the sequential condition entry set structure unchanged. Each condition entry in the sequential condition entry set contains a condition number, a condition type, and a condition object identifier.

[0068] The initial execution condition verification process is performed sequentially according to the condition number. When the condition type is an action requirement, the action status and conflict flag corresponding to the condition object identifier are read from the merged disposal action receipt, and the same action identifier is checked simultaneously in the set of actions to be confirmed. When the condition type is a resource requirement, the resource status and conflict flag corresponding to the condition object identifier are read from the merged key resource receipt, and the related resource identifier overriding is checked simultaneously in the set of actions to be confirmed. When the condition type is a status requirement, the scene field value and field status flag corresponding to the condition object identifier are read from the constrained scene snapshot. The field status flag comes from the scene snapshot constraint processing result in step S2.

[0069] During item-by-item verification, a verification status sequence is generated. This sequence is a sequence of verification status results for each condition, arranged by condition number. The status labels in the verification status sequence are fixed as three categories: satisfied, not satisfied, and pending confirmation. "Satisfied" indicates that the condition item has been explicitly supported by the merged action receipt, the merged key resource receipt, or the constrained scene snapshot. "Pending confirmation" indicates that the object corresponding to the condition item falls within the coverage of the pending confirmation action set, or that the scene field corresponding to the constrained scene snapshot is registered as pending confirmation. Other situations that directly conflict with the condition requirements are registered as "not satisfied."

[0070] After the verification state sequence is formed, the sequential condition judgment rule is executed. This rule determines whether the overall initial execution condition is met based on the order of conditions, thereby generating an overall verification conclusion. The sequential condition judgment rule is based on the sequential constraints of the initial execution conditions. First, it identifies continuous condition segments starting from the condition number. Then, it checks whether any unmet conditions occur within these segments. If an unmet condition occurs, the overall verification conclusion is recorded as invalid; if no unmet condition occurs, the overall verification conclusion is recorded as valid. Simultaneously, the condition numbers corresponding to the states to be confirmed within and after the continuous condition segments are retained, forming a set of conditions to be confirmed. The final verification result of the initial execution conditions includes the verification state sequence, the overall verification conclusion, and the set of conditions to be confirmed. The names of these components remain consistent throughout subsequent sub-steps in step S3.

[0071] S3.2: Generation of initial condition evidence string and calculation of initial condition through-settlement value.

[0072] In dynamic matching scenarios, initial execution conditions often have sequential dependencies. Even if a subsequent condition is met, it cannot replace the supporting role of the preceding condition in activating the contingency plan. During on-site handling, the receipt status may cause some conditions to enter a pending confirmation state, resulting in a situation where there are many condition items but the initial segment has not yet been connected. If the judgment is based solely on the number of satisfied items or the existence of satisfied items, it is easy to misjudge the satisfaction of a subsequent item as the start point being able to be activated, causing the contingency plan to be switched prematurely and backtracking during subsequent receipt updates. Therefore, it is necessary to first organize the evidence according to the condition sequence number and identify the connection pattern starting from the start point, and then compress the connection pattern into a quantitative expression that can reflect the degree of activation and connection, thereby deriving the initial condition connection settlement value.

[0073] The initial execution condition verification results have already provided a condition-level state classification. However, the verification state sequence can only express whether the condition items are met, not whether the initial connection has truly been formed. Step S3 continues to generate an initial condition evidence string and calculate the initial condition connection settlement value. The initial condition evidence string is a sequence of condition-supporting evidence formed by concatenating condition numbers, and the initial condition connection settlement value is a dimensionless quantity characterizing the degree of continuous connection of the initial execution conditions from the starting point. The processing object still corresponds to a single candidate plan, and the data sources are fixed as the initial execution conditions, merged disposal action receipts, merged key resource receipts, constrained scene snapshots, and sets of actions to be confirmed.

[0074] Step S3 extracts evidence sources in the order of the condition sequence numbers of the initial execution conditions. When the condition type is an action requirement, the action status, conflict marker, and status change order information are read from the merged disposal action receipt. When the condition type is a resource requirement, the resource status, conflict marker, and status change order information are read from the merged key resource receipt. When the condition type is a status requirement, the scene field values ​​and field status markers are read from the constrained scene snapshot; then, a check of the pending action set coverage is performed; when the pending action set covers the condition object identifier or associated resource identifier, the evidence status is preferentially registered as pending confirmation of occupancy, and is no longer registered as implemented.

[0075] The evidence status labels are fixedly categorized into five types: Implemented, Pending Confirmation of Occupation, Resource Conflict, Action Issued but Not Yet Received, and Not Met. Among them, "Pending Confirmation of Occupation" indicates that the condition object is already occupied by the pending action or its associated resources, and cannot yet be considered implemented. "Implemented" means the condition item has clear support and is not covered by the pending action set. "Resource Conflict" means the resource requirement condition item directly conflicts with the merged key resource receipt status, or the resource associated with the action requirement condition item has a resource conflict label in the pending action set. "Action Issued but Not Yet Received" means the action identifier corresponding to the action requirement condition item has been issued but not yet recorded as complete. Other unsupported situations are registered as "Not Met." The sequence of evidence status labels arranged according to the condition number constitutes the initial condition evidence string.

[0076] The initial conditional connection settlement value calculation employs connection morphology recognition combined with an initial connection domain mapping table. The connection morphology recognition process scans from the first item of the initial conditional evidence string, recording the termination condition sequence number of the first consecutive implemented item, the evidence status label of the first non-implemented item, and whether implemented items appear after the first non-implemented item, along with their location distribution. These records collectively form the connection morphology code, which is an identifier formed by encoding the first consecutive implemented status and subsequent distribution characteristics in the initial conditional evidence string. The initial connection domain mapping table uses the connection morphology code as the mapping input and outputs the initial conditional connection settlement value. This initial connection domain mapping table is a pre-set lookup table that maps the connection morphology code to the initial conditional connection settlement value. The initial connection domain mapping table is pre-established based on historical valid switching records and historical rollback records. The mapping input is fixed as the connection morphology code, and the mapping output is the dimensionless initial conditional connection settlement value. The initial connection domain mapping table is saved by version, with each version containing the morphology code definition, mapping output range, and establishment date. The initial conditions for the boundary of the settlement value interval are determined by the historical record calibration process. The calibration process adopts a combination of morphological distribution statistics and sequential search, with the requirements for erroneous switching suppression and switching identification retention as constraints.

[0077] In one embodiment, the initial connectivity mapping table is constructed as follows: Starting condition evidence strings are extracted from matching records that have undergone review and have actual switching results. The sequence of the first consecutive implemented termination condition, the evidence status label of the first non-implemented item, and the presence and location of subsequent implemented items are extracted according to the order of the initial execution conditions of the plan. These are combined into connectivity morphology codes, and the distribution of effective and rollback switching is statistically analyzed by code group. For example, a connectivity morphology code record might be: the first consecutive implemented item terminates at condition number 3, the first non-implemented item is pending confirmation of occupancy, and the subsequent implemented item appears at condition number 5. Another set of connectivity morphology code records might be: the first consecutive implemented item terminates at condition number 2, the first non-implemented item is a resource conflict, and the subsequent implemented item does not appear. Subsequently, business personnel classify each code into intervals based on historical review conclusions, mapping codes that stably support switching to high intervals, codes that frequently rollback to low intervals, and codes with mixed distributions to middle intervals. The morphology code, output interval, sample batch, table version, and manual verification mark are then saved.

[0078] S3.3: Generation of receipt landing point segments and calculation of settlement consistency value between double receipts.

[0079] Another challenge in dynamic matching lies in determining whether the feedback support has been stably established. Action feedback and key resource feedback originate from different business chains, and their responses to the same action may be asynchronous or exhibit inconsistent directions within a short period. Judging solely based on a single feedback can easily lead to misjudging a state where the action side has progressed but the resource side has not yet formed support as switchable, or a state where the resource side has recovered but the action side's chain is not yet closed as initiable, causing the switchover verification results to repeatedly change during continuous operation. Therefore, it is necessary to organize action and resource feedback into feedback landing point segments according to their arrival process, identify consistent confirmation and conflict patterns, and further develop a quantitative expression representing the degree of consistency between the two feedback supports, thereby deriving the dual feedback settlement consistency value.

[0080] The initial condition's connection settlement value already reflects the degree of connection of the initial execution conditions. However, the connection of the initial stage does not directly indicate that the receipt status has stabilized. Step S3 continues to generate receipt landing point fragments around the action requirement conditions and resource requirement conditions in the initial execution conditions, and calculates the double receipt settlement consistency value. The receipt landing point fragment is a support fragment of action receipts and resource receipts gathered around a single condition item. The double receipt settlement consistency value is a dimensionless value characterizing the degree of consistent support formed by the action receipt and key resource receipt for the same condition. State requirement conditions are not included in the receipt landing point fragment construction; state requirement conditions have already been checked in the initial execution condition verification results through the constrained scene snapshot.

[0081] At the start of processing, condition entries of type action requirement and resource requirement are extracted from the initial execution conditions. A fragment index is built according to the condition sequence number. The fragment index is a receipt landing point fragment location index built according to the condition sequence number. Each item in the fragment index corresponds to a condition entry, and the fragment index item stores the condition sequence number and condition object identifier. Subsequently, based on the fragment index, associated status records are extracted from the merged disposal action receipts and merged key resource receipts, and organized into receipt landing point fragments according to the status change order information. The receipt landing point fragment contains at least the condition sequence number, condition object identifier, action status record, resource status record, and fragment status label.

[0082] Fragment status labels are fixed into four categories: same-direction confirmation, one-sided confirmation, reverse conflict, and pending confirmation coverage. When a pending confirmation action set covers a condition object identifier or associated resource identifier, the fragment status label is registered as pending confirmation coverage. Same-direction confirmation indicates that the action status record and resource status record jointly support the entry corresponding to the starting execution condition. One-sided confirmation indicates that only one side of the action status record and resource status record forms support, while the other side lacks support or remains in an unclosed state. Reverse conflict indicates that the action status record and resource status record form opposite support directions on the same condition entry; for example, the action status record indicates that execution is required, while the resource status record indicates that the resource is unavailable and has not been released. When a fragment status label is generated, a fragment status source field is also written. The fragment status source field is used to record whether the label was triggered by an action status record, a resource status record, or a pending confirmation action set.

[0083] The calculation of the settlement consistency value for dual receipts employs segment consistency pattern recognition combined with a receipt consistency domain mapping table. The segment consistency pattern recognition process scans the receipt landing segment sequentially according to the condition number, identifies continuous segments with same-direction confirmation, records the location of reverse conflict interruption, records the distribution of unilateral confirmation entries and the distribution of pending confirmation coverage entries, forming a segment consistency pattern code. This code is an identifier formed by encoding the distribution characteristics of same-direction confirmation, conflict, and pending confirmation in the receipt landing segment. The receipt consistency domain mapping table takes the segment consistency pattern code as input and the dual receipt settlement consistency value as output. This table is a pre-set reference table that maps the segment consistency pattern code to the dual receipt settlement consistency value. Historical switching judgment records are used as calibration samples when establishing the receipt consistency domain mapping table, and the erroneous switching suppression priority rule and the hysteresis switching control rule are used as the basis for selecting interval boundaries. The erroneous switching suppression priority rule is used to constrain segment consistency pattern codes containing reverse conflict patterns from falling into the low-confidence output interval, while the hysteresis switching control rule is used to constrain segment consistency pattern codes with continuously existing unilateral confirmation from directly entering the high-confidence output interval. After the consistent settlement value of the double receipt is generated, it will be included in step S3 for subsequent analysis along with the settlement value of the initial condition.

[0084] In one embodiment, the receipt consistency domain mapping table is constructed as follows: Receipt landing point segments are extracted from the same batch of matching basis records. The length of the continuous segment of same-direction confirmation, the first occurrence position of reverse conflict, the set of one-sided confirmation entries, and the set of pending confirmation coverage entries are extracted according to the condition sequence number. These are combined into a segment consistency morphological code, and the actual switching results are statistically analyzed by code grouping. For example, the segment consistency morphological code record is: continuous segment of same-direction confirmation covers condition sequence numbers 1 to 2, no reverse conflict occurs, one-sided confirmation appears at condition sequence number 4, and pending confirmation coverage does not occur. Another set of segment consistency morphological codes is... The code is recorded as follows: continuous segments with same-direction confirmation only cover condition number 1, reverse conflict occurs at condition number 2, and pending confirmation coverage occurs at condition number 3. Then, based on historical erroneous switching and rollback situations, the intervals are classified. Codes with no reverse conflict and stable continuous segments with same-direction confirmation are mapped to the high interval, codes with reverse conflict in the previous segment are mapped to the low interval, and codes with continuous single-sided confirmation but no reverse conflict are mapped to the middle interval. The morphological code, output interval, sample batch, table version, and manual verification mark are also saved, thus forming two independent domain mapping tables with clear objects and traceability.

[0085] S3.4: Output of monotone complementary tree analysis and switching verification results.

[0086] The initial execution condition verification results, the initial condition connection settlement value, and the double-receipt settlement consistency value have been formed. The aforementioned results correspond to the execution starting point condition status, the degree of connection of the previous section, and the degree of double-receipt settlement consistency, respectively. Step S3 performs monotonic complementary tree analysis on this basis and outputs the switching verification results. The monotonic complementary tree analysis is a tree model analysis that applies monotonic constraints to two input values ​​and maintains the distinguishability of complementary mismatch.

[0087] In the reasoning phase, step S3, for each plan in the candidate plan set, inputs the initial condition settlement value and the double-receipt settlement consistency value into a monotone complementary tree analysis, outputting a dimensionless switching confidence coefficient. This switching confidence coefficient is a dimensionless output value characterizing the switching confidence level of the current plan. Subsequently, based on the initial execution condition verification result and the switching confidence coefficient, a plan-level switching verification result is formed. This plan-level switching verification result is a switching feasibility judgment result for a single candidate plan. If the overall verification conclusion is invalid, the plan-level switching verification result is recorded as failing. If the overall verification conclusion is valid, the boundary configuration of the interval containing the switching confidence coefficient is read, and the interval category is determined. The interval categories are fixed and include switching intervals, pending confirmation intervals, and reserved intervals. When the switching confidence coefficient falls into a switching interval, the plan-level switching verification result is recorded as passing; when the switching confidence coefficient falls into a pending confirmation interval, the plan-level switching verification result is recorded as pending confirmation passing, and a pending confirmation item is generated simultaneously; when the switching confidence coefficient falls into a reserved interval, the plan-level switching verification result is recorded as failing.

[0088] Items to be confirmed are extracted from the initial condition evidence string and the receipt landing fragment. Entries in the initial condition evidence string with the status tags "Pending Confirmation Occupation," "Resource Conflict," or "Action Issued but Not Yet Received" are written into the pending confirmation items. Entries in the receipt landing fragment with the status tags "One-Sided Confirmation," "Reverse Conflict," or "Pending Confirmation Overriding" are written into the pending confirmation items. The structure of each pending confirmation item is standardized, including the condition sequence number, condition object identifier, source type, and status tag. The source type is used to distinguish the source of the initial condition evidence string from the source of the receipt landing fragment.

[0089] After each candidate plan set is processed, step S3 sorts and selects all plan-level switching verification results. The sorting rules are fixed as follows: first, sort by plan-level switching verification result category, with passed plans taking precedence over pending confirmation; failed plans are not included in the target plan selection; then sort by switching confidence coefficient; and finally, sort by the number of pending confirmation condition items in the initial execution condition verification result. If the plan-level switching verification result of the first plan in the sorted results is passed, the first plan is output as the target plan. If no passed plan is found, the current plan is retained, and the pending confirmation item corresponding to the first plan in the sorted results is output. Step S3 finally outputs the switching verification result, which includes the target plan or the current plan and the pending confirmation item, and retains the association identifier with the candidate plan set.

[0090] In one embodiment, monotonic complementary tree analysis uses event-level historical handling records to construct training samples. The sample source is the matching basis record that has been reviewed. Each sample is fixed to extract the initial condition through settlement value and the double receipt settlement consistency value, and is marked with the actual result as switch effective or switch reversal. The corresponding event identifier and contingency plan identifier are retained for traceability. Before the samples are put into the database, consistency cleaning is performed to delete records that lack initial condition evidence strings or receipt landing point fragments, and merge records of the same event and the same contingency plan that are repeatedly written in a short period of time. The samples are divided into groups according to event identifiers rather than randomly scattered according to records. For example, the first part of the samples is taken as the training set, the middle part of the samples is taken as the validation set, and the last part of the samples is taken as the test set in chronological order to prevent adjacent states of the same event from falling into different sets at the same time, which would cause the evaluation to be too optimistic.

[0091] The monotonic complementary tree analysis uses a tree group model, with a decision tree as the base tree. The input features are fixed as the initial condition settlement value and the double-return settlement consistency value, and the output is the switching confidence coefficient. During construction, a monotonically increasing constraint is set for both input features, meaning that the switching confidence coefficient is not allowed to decrease when either feature increases. In one embodiment, the tree structure parameters are set as follows: maximum depth 4, maximum number of leaf nodes per tree 16, minimum number of samples per leaf node 30, minimum gain for node splitting 0.01, number of trees 80, learning step size 0.05, sample extraction ratio 0.8, and column extraction ratio 1.0. The column extraction ratio is set to 1.0 because there are only two input features. During construction, class imbalance processing is enabled, and the switching back samples are repeatedly sampled to expand the training set so that the number of effective switching samples and the number of switching back samples are close. The monotonic constraint check is performed once after each round of training. If a local node is found to violate the monotonic relationship, the tree in this round is rolled back and the splitting candidate order is adjusted for retraining.

[0092] In monotonic complementary tree analysis, the complementary part is achieved through a splitting strategy and post-processing calibration. When evaluating candidate nodes, the splitting strategy not only considers the overall distinguishing ability but also checks for high-low sample areas, i.e., sample clusters with high initial condition settlement values ​​but low double-receipt settlement consistency values, or low initial condition settlement values ​​but high double-receipt settlement consistency values. If the number of samples in a high-low sample area reaches 25 and both the switch validity and switch rollback labels exist, a separate splitting path is retained and not merged with the high-high sample area, thus explicitly separating the complementary mismatch pattern from the model. After training, segmented calibration is performed on the validation set to map the original model output to the switch confidence coefficient interval. Combined with the false switch rate priority constraint and rollback rate constraint, the switch interval boundary and the unconfirmed interval boundary are determined. The boundary is not hardcoded into the algorithm logic but is written into the model configuration. The boundary selection process adopts a segmented scanning method on the validation set. For example, each time a fixed step size is moved to observe the changes in the effective switch coverage and false switch rate, and then the boundary combination that meets the business rules is selected.

[0093] In one embodiment, the optimization and parameter solidification of monotone complementary tree analysis are completed in a versioned process. First, the model versions that do not meet the monotone check or have insufficient complementary region identification ability are screened out using the validation set results. Then, the effective switching coverage, false switching rate, rollback rate, and monthly stability are reviewed using the test set. Monthly stability is achieved by observing whether the fluctuation of the results within the switching confidence coefficient interval exceeds the preset tolerance by grouping by month. The final release version saves the tree group model file, monotone constraint configuration, switching interval boundary configuration, pending confirmation interval boundary configuration, and training sample time range. During runtime, the monotone complementary tree analysis directly reads the release version, outputs the switching confidence coefficient for the input initial condition through settlement value and double retrieval settlement consistency value, and submits the switching confidence coefficient to the switching verification rules in step S3 to complete the pre-plan level switching verification result determination.

[0094] After step S3 is completed, the initial execution condition verification results have given the condition-level status and overall verification conclusion. The initial condition connection settlement value has characterized the degree of connection of the initial execution condition. The double receipt settlement consistency value has characterized the degree of consistency between the merged disposal action receipt and the merged key resource receipt on the initial execution condition. The monotonic complementary tree analysis has output the switching confidence coefficient. The switching verification results have formed the judgment results of the target plan or current plan and the items to be confirmed.

[0095] The switching verification result given in step S3 reflects the switching judgment at the current point in time. The merged disposal action receipts and merged key resource receipts in the disaster emergency response process will continue to be updated. The condition entries corresponding to the items to be confirmed will also undergo state migration as the receipts change. If the single judgment result lacks traceable basis records and verification and revision mechanisms, the dynamic matching result is easy to become out of touch with the actual disposal progress. Step S4 verifies and revises the previous judgment based on the matching basis record, items to be confirmed, verification scope record, rematch trigger conditions, and contingency plan removal conditions.

[0096] S4.1: Matching is based on the registration of records and the sealing of items to be confirmed.

[0097] Step S3 has generated the switchover verification results and items to be confirmed. Saving only the target plan or the current plan is insufficient to support subsequent verification and positioning. Step S4 first registers the matching basis record and seals the items to be confirmed. The matching basis record is a structured record that saves the basis and results of this round of switchover judgment, and the items to be confirmed are the condition entries that still require subsequent receipts for further verification.

[0098] During processing, the event identifier is used as the archiving key to establish a matching basis record entry; the target plan identifier or current plan identifier, the candidate plan set identifier list, the initial execution condition verification result, the initial condition evidence string, the receipt landing point fragment, the initial condition through settlement value, the double receipt settlement consistency value, the switching credibility coefficient, the switching verification result, the plan-level switching verification result sorting result formed in step S3, and the disposal action receipt status summary and key resource receipt status summary are written into the matching basis record entry.

[0099] The action response status summary records the action identifier, action status, conflict marker, and status change sequence information summary for the actions involved in step S3's verification and parameter calculation. This action response status summary is a compressed record of the action status and its timing information for the actions involved in the judgment. The key resource response status summary records the resource identifier, resource status, conflict marker, and status change sequence information for the resources involved in step S3's verification and parameter calculation. This key resource response status summary is a compressed record of the resource status and its timing information for the resources involved in the judgment. A mapping relationship is established between the summary entries and the condition numbers in the initial execution conditions, facilitating subsequent location of the original judgment basis by condition number.

[0100] Items pending confirmation are archived using an independent set of entries. Each item pending confirmation maintains consistency across four fields: condition sequence number, condition object identifier, source type, and status label. An event identifier and a matching basis record association identifier are written into each item pending confirmation. After the items pending confirmation are archived, the status labels are not removed in this sub-step; only archiving and index creation are completed.

[0101] Once the matching criteria record is registered, the previous switch judgment criteria already have a traceable, structured foundation. When new receipts are subsequently integrated, verification scope records can be directly established based on the condition sequence number and object identifier in the matching criteria record, without needing to re-parse the entire candidate plan set.

[0102] S4.2: New receipts are merged and updated, and verification scope records are generated.

[0103] The matching basis record has been fixed with the previous judgment basis. However, if a newly arrived receipt directly enters the local verification, the previous judgment basis and the current status source will be inconsistent in level. In step S4, the new receipt is first merged and updated in this sub-step, and then the verification scope record is generated. The verification scope record is a record that limits the scope of plans and conditions that only need to be reviewed in this round.

[0104] At the start of processing, newly arrived action receipts or key resource receipts are received, and the event identifier associated data set is located based on the event identifier. The event identifier associated data set is first read from the cache of this round of operation. If the cache does not exist, it is re-retrieved and reconstructed according to the event identifier merging rules in step S1. Subsequently, the event identifier associated data set is re-merged using the merging and sorting rules in step S1. After merging, the merged action receipts and merged key resource receipts continue to be used as a unified name.

[0105] After the merged action receipts and key resource receipts are updated, the action set to be confirmed is regenerated according to the rules for forming the action set to be confirmed in step S1, and the initial scene snapshot is updated according to the rules for generating the initial scene snapshot in step S1. Then, the constrained scene snapshot is updated according to the scene snapshot constraint processing rules in step S2. The updated object names still retain the action set to be confirmed, the initial scene snapshot, and the constrained scene snapshot, respectively.

[0106] The verification scope record generation is divided into two parts: hit identification and condition mapping. In hit identification, a hit verification list is first established using the action receipt status summary and key resource receipt status summary in the matching basis record. The hit verification list is a list of verification objects that summarizes the hit relationship between the new arrival receipt and the previous judgment basis. The action identifier hit entries in the hit verification list correspond to the case where the action identifier in the new arrival receipt is consistent with the action identifier in the status summary; the resource identifier hit entries correspond to the case where the resource identifier in the new arrival receipt is consistent with the resource identifier in the status summary. At the same time, the condition object identifier and source type in the item to be confirmed are included in the auxiliary hit judgment. When the new arrival receipt does not hit the status summary but hits the item to be confirmed, the hit entry is also registered.

[0107] In condition mapping, based on the initial condition evidence string and receipt landing fragment saved in the matching basis record, the action identifier or resource identifier in the hit verification list is back-mapped to the condition sequence number. The back-mapping rule is as follows: first, search for fragment entries in the receipt landing fragment where the condition object identifier matches the hit object identifier; then, search for evidence entries in the initial condition evidence string where the condition object identifier matches the hit object identifier. The results of the two types of searches are summarized to generate a verification scope record. The verification scope record must at least include the contingency plan identifier, condition sequence number, hit source, hit object identifier, and source entry identifier. Subsequent verification processing is limited to the scope covered by the verification scope record.

[0108] S4.3: Previous judgment verification and partial recalculation.

[0109] The verification scope record already provides the contingency plans and conditions that may change. Step S4 verifies the previous judgment and performs a partial recalculation in this sub-step. The goal is to obtain a clear conclusion as to whether the previous judgment still holds true. Specifically, the previous judgment verification is a consistency check of the conclusion from the previous round of switching judgments, and the partial recalculation is a process of recalculating only the items affected by the new receipt.

[0110] During processing, the original starting execution condition verification results, original starting condition evidence strings, original receipt landing point fragments, original starting condition through settlement values, original double receipt settlement consistency values, and original switching confidence coefficients are read one by one from the matching basis records according to the verification scope records. Then, the merged disposal action receipts, merged key resource receipts, action sets to be confirmed, and constrained scene snapshots are used to reprocess the hit condition entries.

[0111] The reprocessing process follows the rules and guidelines from step S3, regenerating the verification status, the corresponding starting condition evidence string entries, and the corresponding receipt landing point fragment entries for the condition numbers covered by the verification scope records. Condition numbers not covered by the verification scope records continue to use the original entries from the matching basis records. After replacing the original entries with the recalculated entries, the updated starting execution condition verification results, the updated starting condition evidence string, and the updated receipt landing point fragment are formed.

[0112] After the item replacement is completed, the rules for identifying the through-type pattern and the segment consistency pattern in step S3 are continued to be used to generate the updated starting condition through-type settlement value and the updated double receipt settlement consistency value. The updated switching confidence coefficient is generated using the monotone complementary tree analysis model version registered in step S3. Then, the updated plan-level switching verification result is formed according to the switching verification rules in step S3. At the same time, the updated pending confirmation item is regenerated based on the updated starting condition evidence string and the updated receipt landing point segment.

[0113] The previous judgment verification uses the switching verification results and the sorted results of the contingency plan-level switching verification results in the matching basis record as a reference, comparing the updated overall verification conclusion, the interval to which the switching confidence coefficient interval boundary belongs, and the changes in the status labels of the items to be confirmed after the update. The previous judgment verification result is fixedly recorded as one of four states: remaining valid, switched to switchable, switched to pending confirmation, and switched to failing. Among them, switching to switchable means that the original pending confirmation or original failing contingency plan has entered the switching interval after the update and meets the overall verification conclusion. Switching to failing means that the original passing or original pending confirmation contingency plan has an overall verification conclusion that is invalid or has entered the failing judgment state after the update. After the previous judgment verification result is formed, the re-matching trigger conditions and contingency plan removal conditions can be revised accordingly.

[0114] S4.4: Re-matching trigger conditions and contingency plan removal conditions revision and re-matching execution.

[0115] The previous verification result has already indicated the direction of the change. Simply updating the conclusion is insufficient to support continued operation. Step S4 in this sub-step writes the verification result into the re-matching trigger condition and the contingency plan removal condition, and performs re-matching. The re-matching trigger condition is a set of conditions that trigger the re-execution of contingency plan matching, and the contingency plan removal condition is a set of conditions that trigger contingency plan exclusion or postponement of exclusion.

[0116] The rematch trigger condition revision is based on the previous judgment and verification results and the status change of the pending items. When the verification result is "converted to switchable," the condition number, condition object identifier, and source type that triggered the change are written into the priority trigger entry in the rematch trigger condition. When the verification result is "converted to pending confirmation" or "remains true," the condition number, condition object identifier, and source type that are still in the pending confirmation state are written into the regular trigger entry in the rematch trigger condition. When the verification result is "converted to failure," the condition number, condition object identifier, and source type that caused the failure are written into the conflict trigger entry in the rematch trigger condition.

[0117] The effective interval boundaries of entries in the rematch triggering conditions are determined using an in-event replay calibration method. This method involves replaying historical records within the same event in the order of receipt arrival to calibrate the effective boundaries of the conditions. Specifically, historical matching records and previous judgment verification results are replayed according to the receipt arrival order under the same event identifier. The continuous occurrence characteristics of different entries causing changes in the switching verification result category during the replay process are statistically analyzed. Then, the contribution of the switching verification result category change and the false trigger suppression requirements are used as calibration criteria to form the effective interval boundaries of priority triggering entries, regular triggering entries, and conflict triggering entries.

[0118] The revision of the contingency plan's exclusion criteria revolves around the conflict cause entries. These entries are extracted from the updated initial execution condition verification results, the updated initial condition evidence string, and the updated receipt fragments. When a conflict cause entry corresponds to a resource conflict or reverse conflict status label, the condition number, condition object identifier, source type, and conflict source are written into the conflict exclusion entry in the contingency plan's exclusion criteria. When a conflict cause entry corresponds to a pending confirmation of occupation or a unilateral confirmation of continued existence status label, the condition number, condition object identifier, and source type are written into the deferred exclusion entry in the contingency plan's exclusion criteria. Both conflict exclusion and deferred exclusion entries are associated with the event identifier, contingency plan identifier, and matching basis record association identifier.

[0119] During rematch execution, steps S2 and S3 are initiated based on the revised rematch trigger conditions and contingency plan elimination conditions. Within the event identifier range, the candidate contingency plan set is regenerated by combining the merged action receipts, merged key resource receipts, action set to be confirmed, and initial scene snapshot. The candidate contingency plan set is then used to regenerate the initial execution condition verification result, initial condition evidence string, receipt landing point fragment, initial condition through settlement value, double receipt settlement consistency value, switching confidence coefficient, and switching verification result. After the rematch output result is formed, the matching basis record is re-registered and the item to be confirmed is sealed, thereby completing one round of verification revision and rematch corresponding to the current receipt change.

[0120] After step S4 is completed, the matching basis record has completely saved the switching verification results and its judgment basis. The items to be confirmed have established an index relationship with the matching basis record. The new arrival receipts have been merged, updated and mapped to the verification range record within the event identifier range. The previous judgment verification has formed a clear verification result. The rematch triggering condition and the contingency plan removal condition have been revised according to the verification result. The rematch result has been realigned with the current handling progress.

[0121] Specifically, the above are merely preferred embodiments of this application and are not intended to limit this application.

[0122] The preset parameters can be pre-calibrated through offline simulation testing or set to fixed values ​​according to on-site operating procedures.

[0123] In the description of this specification, references to terms such as "an embodiment," "example," and "specific example" indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0124] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention.

Claims

1. A dynamic matching method for disaster emergency response plans based on multi-dimensional features, characterized in that, Including the following steps: S1. Collect and organize the action receipts and key resource receipts based on the event identifiers, generate merged action receipts and key resource receipts, form a set of actions to be confirmed, and generate an initial scene snapshot. S2. Determine the set of affected scene fields based on the set of actions to be confirmed and the action-to-scene field mapping table, perform scene snapshot constraint processing on the initial scene snapshot to generate a constrained scene snapshot, and retrieve the contingency plan library to form a candidate contingency plan set; S3. Read the starting execution conditions of the candidate plan set and generate the starting execution condition verification result. Combine the set of actions to be confirmed to construct the starting condition evidence string and the receipt landing point fragment. Generate the switching verification result based on the connection state of the execution starting point and the stable state supported by the receipt. S4. Register the matching basis record and pending confirmation item corresponding to the switching verification result with the event identifier. After receiving the new arrival receipt, generate the verification range record and perform partial recalculation. Revise the rematch trigger condition and the contingency plan removal condition and update the switching verification result.

2. The method for dynamic matching of disaster emergency response plans based on multi-dimensional features according to claim 1, characterized in that, Step S1 includes: Based on the event identifier, the event reporting system, command and dispatch system, and resource management system extract the action receipts and key resource receipts. The action receipts are indexed by the action identifier and combined with the state change sequence information to perform state evolution determination to form a merged action receipt. The key resource receipts are indexed by the resource identifier and combined with the state change sequence information to perform state evolution determination to form a merged key resource receipt.

3. The method for dynamic matching of disaster emergency response plans based on multi-dimensional features according to claim 2, characterized in that, Step S1 also includes: Based on the merged action receipts, identify action identifiers that are not closed and have conflicting states. Combine the merged key resource receipts with the associated resource identifiers to form a set of actions to be confirmed. Use the event basic scene information associated with the event identifiers and the merged key resource receipts to generate an initial scene snapshot. Write the action identifiers, confirmation tags, and associated resource identifiers from the action status reference area into the action status reference area.

4. The method for dynamic matching of disaster emergency response plans based on multi-dimensional features according to claim 3, characterized in that, Step S2 includes: Based on the action identifier in the action set to be confirmed, query the action to scene field mapping table, form a set of affected scene fields and write the field index markers of the initial scene snapshot, perform confirmation write judgment based on the merged disposal action receipt and the merged key resource receipt, write the scene state after the action to the scene fields that meet the write requirements, retain the original value of the scene fields that do not meet the write requirements and register the pending confirmation state, and form a constrained scene snapshot.

5. The method for dynamic matching of disaster emergency response plans based on multi-dimensional features according to claim 4, characterized in that, Step S2 also includes: Based on the event category and event handling stage marker in the constrained scene snapshot, a preliminary set of pre-screened plans is formed by searching the plan library. Then, a preliminary set of plans is formed by comparing the resource occupancy premise with the resource status area. The initial execution conditions of the preliminary set of plans are read and the action-level conflict determination and resource-level conflict determination are performed with the action set to be confirmed and the merged key resource receipt. Plans without registered conflict markers are retained to form a candidate plan set.

6. The method for dynamic matching of disaster emergency response plans based on multi-dimensional features according to claim 5, characterized in that, Step S3 includes: Read the initial execution conditions from the candidate plan set, and check each initial execution condition against the merged disposal action receipt, the merged key resource receipt, and the constrained scene snapshot according to the condition number. Generate a check status sequence containing satisfied, unsatisfied, and pending confirmation states, and generate the initial execution condition check result according to the sequential condition judgment rule.

7. The method for dynamic matching of disaster emergency response plans based on multi-dimensional features according to claim 6, characterized in that, Step S3 also includes: The evidence source is extracted according to the condition number of the initial execution condition and combined with the set of actions to be confirmed to generate the initial condition evidence string. The front-end connection form is identified and passed through the initial connection domain mapping table to generate the initial condition connection settlement value. At the same time, the receipt landing point fragment is generated around the action requirements and resource requirements in the initial execution condition and the double receipt settlement consistency value is generated through the receipt consistency domain mapping table.

8. The method for dynamic matching of disaster emergency response plans based on multi-dimensional features according to claim 7, characterized in that, Step S3 also includes: The initial condition settlement value and the consistent settlement value of the double receipt are input into the monotone complementary tree analysis to generate the switching confidence coefficient. The switching confidence coefficient and the initial execution condition verification result are then used to form the plan-level switching verification result. Based on the plan-level switching verification result and the switching confidence coefficient, the target plan or the current plan and the items to be confirmed are sorted and output.

9. The method for dynamic matching of disaster emergency response plans based on multi-dimensional features according to claim 8, characterized in that, Step S4 includes: Establish matching basis records based on event identifiers and seal items to be confirmed. Write the switching verification results, the initial execution condition verification results, the initial condition evidence string, the receipt landing point fragment, the action receipt status summary, and the key resource receipt status summary into the matching basis records. After the new receipts arrive, update the merged action receipts and the merged key resource receipts and generate the verification scope record.

10. The method for dynamic matching of disaster emergency response plans based on multi-dimensional features according to claim 9, characterized in that, Step S4 also includes: Based on the verification scope record, the initial execution condition verification result, the initial condition evidence string and the receipt landing point fragment are partially recalculated to form the previous judgment verification result. The previous judgment verification result drives the revision of the rematch trigger condition and the contingency plan elimination condition. After the revision is completed, the switching verification result is regenerated and the matching basis record and the item to be confirmed are updated.

Images