A mountain torrent prevention scheme intelligent generation method and system based on marginal condition constraint

Abstract

The application discloses a mountain torrent defense scheme intelligent generation method and system based on marginal condition constraints, and relates to the technical field of artificial intelligence and natural language processing. Through receiving real-time rainfall, forecast rainfall or manual triggering, a scene snapshot is constructed; marginal condition data is recalled, modeled as a structured record and injected into a large model prompt word; a defense scheme is generated according to fields under ontology constraints; after being verified by four lines of defense, if it fails, it is modified back; for the scheme that passes the verification, an evidence URI is added, a JSONSchema structured scheme is generated, and after being confirmed by a human, it is pushed to the platform for execution and forms a business closed loop. Through the technical link of "scene snapshot construction -> marginal condition assembly -> ontology constraint generation -> four lines of defense verification -> closed loop feedback optimization", the application realizes the intelligent, standardized and traceable generation of the mountain torrent defense scheme, and significantly improves the response efficiency and scheme quality.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence and natural language processing, and in particular to an intelligent generation method and system for mountain flood defense schemes based on marginal condition constraints. Background Technology

[0002] Flash floods are among the most devastating natural disasters in my country, characterized by their suddenness, rapid onset, and immense destructive power. They often occur in small mountainous watersheds, with rainfall often escalating to a point where disaster can strike within hours or even tens of minutes, demanding extremely high timeliness in response and reliability in decision-making. Delays in response plans or omissions of critical measures can directly lead to casualties and significant property damage.

[0003] Currently, the preparation of mountain flood prevention plans mainly falls into two categories: traditional manual preparation and large-scale model-assisted generation. Traditional plans are prepared by staff based on past flood control experience, and are mostly in paper form or fixed electronic documents. They are generally revised once a year, making it impossible to update ledger information, routes, and personnel changes in a timely manner. In recent years, large-scale language models have begun to be used in emergency plan preparation. After inputting plan templates, historical cases, or regulations into the large-scale model, the model automatically generates the plan text.

[0004] Current technologies for developing flash flood defense plans still have many shortcomings and cannot meet the needs of highly accurate and reliable flood control decision-making. First, the facts are uncontrollable; large models suffer from inherent illusions, and the generated watershed data, evacuation routes, and responsible personnel information are prone to discrepancies with authoritative records, resulting in a large workload and high error rate for manual review. Second, the basis is not traceable; the generated content lacks standards, case studies, and data source labeling, failing to meet the requirements for record-keeping and auditing accountability in flood control decisions. Third, constraints are difficult to explicitly inject; it is difficult to set complex business rules such as administrative boundaries, resettlement site capacity limits, and evacuation route topology as hard constraints, easily generating non-compliant and contradictory defense plans. Fourth, the output format is not standardized; free text formats cannot be directly parsed and called by flood control business systems, requiring manual secondary processing, which easily introduces errors. Fifth, there is no automated verification mechanism; the compliance and completeness of the plan rely entirely on manual review, which is inefficient and prone to overlooking key issues, failing to meet the practical needs of rapid emergency response to flash flood disasters. Summary of the Invention

[0005] To address the aforementioned issues, this invention provides an intelligent method and system for generating flash flood defense plans based on marginal condition constraints. The method limits the field structure, mandatory rules, and dependencies between fields of the plan through an ontology constraint module, enabling the large model to be generated field-by-field within a constrained space. Each defense instruction and value in the generated result is attached with a Uniform Resource Identifier (URI), pointing to the original database record. The output is in JSON Schema object tree format, and after manual verification, it is pushed to the monitoring and early warning platform to drive business processes such as early warning issuance, SMS notification, evacuation tracking, and effect evaluation. During the generation process, four checks are performed sequentially: context injection verification, ontology structure verification, evidence URI verification, and business rule self-review. If a check fails, it is automatically returned for correction, reducing manual review from a complete reading to random sampling. This provides flood control departments at all levels with a reliable, usable, and traceable intelligent plan generation capability.

[0006] This invention is implemented as follows:

[0007] It includes two aspects, the first aspect:

[0008] A method for intelligently generating flash flood prevention schemes based on marginal condition constraints includes the following steps:

[0009] Step S1. Triggering and Condition Preparation: Receive real-time rainfall and water level data and forecast rainfall data from the flash flood monitoring and early warning platform, or manual triggering instructions from operational personnel, construct a snapshot of the current defense scenario, and clarify the affected watershed, warning level, administrative region, and key elements;

[0010] Step S2. Marginal Condition Assembly: Based on the scenario snapshot, retrieve six types of marginal condition data from the knowledge base, case library, risk map library and basic database, including basic watershed information, list of dangerous areas, relocation routes, responsible persons, historical similar cases, and relevant defense specifications. Model them uniformly as structured marginal condition records with permID and inject large model prompt words.

[0011] Step S3. Segmented generation under ontology constraints: Define field structure, field type, mandatory rules and field dependency constraints. Generate solution text for the large model field by field. Key fields reference the injected marginal condition records. Reject output and trigger correction when missing or conflicting.

[0012] Step S4. Four-line defense verification: The generated result passes through four lines of defense in sequence: context injection verification, ontology structure constraint verification, evidence URI verification, and business rule self-review; if the verification fails, the error information is returned to the large model for correction; after passing the verification, it enters the evidence binding module;

[0013] Step S5. Output and Execution: Attach evidence URIs to the key fields of the verified scheme, generate a JSONSchema structured scheme, and push it to the monitoring and early warning platform after manual confirmation and entry review to drive downstream tasks.

[0014] Furthermore, in step S1, the warning levels are divided into four levels: blue, yellow, orange, and red, and the classification criteria are as follows:

[0015] If the water level is less than or equal to the warning level minus 0.5m, it is classified as blue; if the water level is greater than the warning level minus 0.5m but less than or equal to the warning level, it is classified as yellow; if the water level is greater than the warning level but less than the guaranteed level, it is classified as orange; and if the water level is greater than or equal to the guaranteed level, it is classified as red.

[0016] If the 6-hour forecast rainfall is less than 25mm, it is classified as blue; if the 6-hour forecast rainfall is greater than or equal to 25mm and less than 50mm, it is classified as yellow; if the 6-hour forecast rainfall is greater than or equal to 50mm and less than 150mm, it is classified as orange; if the 6-hour forecast rainfall is greater than or equal to 150mm, it is classified as red.

[0017] The warning levels are determined by combining the water level dimension and the forecasted rainfall dimension, and the highest level among the two dimensions is taken as the final warning level; the order of warning levels from highest to lowest is: red > orange > yellow > blue.

[0018] Furthermore, in step S2, the marginal condition assembly employs a two-level retrieval mechanism combining exact matching and KNN topology expansion to perform deterministic data retrieval.

[0019] Exact matching layer; using watershed coding as the key to perform hash indexing O(1) to recall direct records; when the number of hit records is insufficient, key fields are missing, data times out, or confidence is too low, extend up / down the water system topology by K levels, and extend the record confidence by... attenuation;

[0020] The retrieval results for recalculation steps such as KNN topology expansion and historical case similarity matching are cached: The cache unit is "search key → expanded complete result set". After the first recalculation, the results are written to a non-relational in-memory database Redis with a cache TTL of 30 minutes, which serves as the rolling time window. "High-frequency hits" are defined as: the same search key accumulating ≥3 hits within the rolling time window. After reaching this threshold, subsequent hits of the same key within the TTL directly return the cached results, skipping repeated topology traversal and similarity calculations. Search requests that do not reach the high-frequency threshold execute the complete recalculation logic in real time. The high-frequency hit count is maintained by an atomic increment operation performed sequentially by a Redis counter, which is reset synchronously with the cache upon timeout.

[0021] Topology extension layer: Let the current watershed be... The tributary-mainstream relationship of a water system is abstracted into a directed graph. The direction of the edge is defined as from upstream to downstream. K-level neighborhood The calculation formula is as follows:

[0022]

[0023] in, For the node To the node The shortest topological distance; the search range is expanded to Confidence decay: Confidence of expanded records according to Attenuation, in which .

[0024] Furthermore, in step S2, the marginal condition assembly involves using a multi-dimensional weighted similarity algorithm to compare the current scenario with historical cases across six dimensions, and then summing the results to obtain a comprehensive similarity score, as detailed below:

[0025] Obtain the feature vector of the current early warning scenario. The feature vector includes at least the following six dimensions: rainfall level characteristics, spatiotemporal distribution characteristics of rainfall, watershed geomorphological characteristics, distribution characteristics of danger zones, time decay characteristics, and historical treatment effect characteristics.

[0026] Calculate the dimensional similarity between the current warning scenario and each historical case across each feature dimension. The weighted average of the similarities across the various dimensions is used to obtain the overall similarity, calculated using the following formula:

[0027] " in, The total number of dimensions involved in the comparison; For the first A dimensional similarity function; For the current scenario in the first dimensional eigenvalues For historical cases in eigenvalues ​​of dimension;

[0028] Retrieval threshold for the current warning level The retrieval threshold is determined based on a preset mapping relationship of warning levels, and decreases monotonically as the warning level increases.

[0029] The overall similarity is compared with the retrieval threshold. If the overall similarity is greater than or equal to the retrieval threshold, the historical case is marked as a strongly similar case and output.

[0030] Furthermore, in step S3, the large model generates solution text field by field, which is done according to the hierarchical structure defined by the ontology constraints, generating solution text field by field and node by node; the corresponding template is selected according to the trigger instruction type, and the permID of the marginal condition record is forcibly referenced for the key fields; after the fields are generated, it is verified whether the referenced permID belongs to the pre-injected record set, and whether the generated content matches the corresponding marginal condition record; the dependency relationship between fields is verified; when a key field cannot be generated due to missing marginal conditions, the generation of the current level is stopped, and the placeholder for the item to be supplemented and the reason for the missing item are output.

[0031] The second aspect:

[0032] A system for generating mountain flood defense schemes based on marginal condition constraints, the system comprising interconnected scenario access module, marginal condition retrieval and assembly module, ontology constraint module, large model generation module, four-line defense verification module, evidence binding module, and structured output and execution module;

[0033] The scenario access module is connected to the flash flood monitoring and early warning platform to receive real-time rainfall and water level data, forecast rainfall data or manual triggering commands, and to build a standardized defense scenario snapshot.

[0034] The marginal condition retrieval and assembly module is connected to the scenario access module and is used to recall six types of marginal condition data from the multi-source database based on the scenario snapshot, uniformly model them into structured marginal condition records with permanent identifiers and inject large model prompt words;

[0035] The ontology constraint module is used to predefine field structure, field type, mandatory field rules, and field dependency constraints.

[0036] The large model generation module is connected to the marginal condition retrieval and assembly module and the ontology constraint module, respectively. It is used to generate scheme text field by field under the constraints of the ontology constraint module. Key fields are forced to reference the injected marginal condition records. When there are missing or conflicting fields, the output is rejected and correction is triggered.

[0037] The four-line defense verification module is connected to the large model generation module and is used to perform context injection verification, ontology structure constraint verification, evidence URI verification and business rule self-examination on the generation result in sequence. If it fails, the error information is returned to the large model generation module for correction.

[0038] The evidence binding module is connected to the four-line defense verification module and is used to attach evidence URIs to the key fields of the scheme that pass the verification.

[0039] The structured output and execution module is connected to the evidence binding module and the flash flood monitoring and early warning platform, respectively, and is used to convert the scheme into JSONSchema structured data. After manual confirmation, the data is pushed to the flash flood monitoring and early warning platform to drive the execution of downstream tasks.

[0040] The beneficial effects of this invention are: by injecting structured data, controlling ontology constraints, tracing and labeling sources, outputting structured data, and implementing a multi-level automatic verification mechanism, a closed-loop compilation system for human-machine collaboration is constructed; the problems of inaccurate content, weak compliance, inability to connect with business systems, and heavy manual review burden in traditional intelligent compilation technologies are solved, thereby improving the accuracy, standardization, and timeliness of mountain flood defense plan compilation and meeting the actual business needs of flood control emergency response, decision-making auditing, and implementation.

[0041] 1. Controllable Fact Generation. By injecting basic records such as administrative divisions, danger zones, population, evacuation routes, and responsible persons into the system in a structured record format, and prohibiting the large model from generating key values ​​on its own, factual illusions are avoided from the source, reducing the workload of manual verification and the probability of errors.

[0042] 2. Comprehensive Constraint Coverage. The flash flood prevention plan is broken down into multiple interrelated field objects, each bound to a clearly defined source of marginal conditions. The generation process is constrained by the ontology structure; the system refuses to output if any critical fields are missing, ensuring the integrity of the plan and avoiding issues such as rule omissions, resource conflicts, and data mismatches. This guarantees the compliance and logical consistency of the plan's content.

[0043] 3. Traceable Sources. Each defense command, each numerical value, and each piece of experience is accompanied by a Uniform Resource Identifier (URI), pointing to the original record in the knowledge base, case library, or basic database. This fills the gap in the traditional technical evidence chain, enabling the entire decision-making process to be traceable, auditable, and compliant with government flood control decision-making standards.

[0044] 4. Structured and executable output. The generated results are in JSON Schema object tree format, which can be directly parsed by the monitoring and early warning platform to drive subsequent business processes such as SMS notification, evacuation tracking, and material dispatch, thereby automating the emergency response process and improving the efficiency of flash flood emergency response.

[0045] 5. Automatic Quality Verification. Multiple verification mechanisms are introduced during the generation process to automatically check field integrity, logical consistency, threshold compliance, and coverage of responsible parties, reducing human error and ensuring the solution complies with flood control business rules.

[0046] 6. Construct a closed-loop human-machine collaboration mechanism. Retain functions such as manual review, field rejection, batch approval, and operation logging, clearly defining human and machine responsibilities to resolve trust and accountability issues in purely automated solutions. Simultaneously, leverage real-world execution data to iterate through the knowledge base and template parameters, continuously optimizing solution generation accuracy and achieving continuous upgrades to intelligent programming capabilities.

[0047] The present invention will be explained in detail below with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0048] Figure 1 This is a flowchart of the intelligent generation method for flash flood defense schemes based on marginal condition constraints of the present invention;

[0049] Figure 2 In this embodiment of the invention, the scenario snapshot adopts a structured definition format;

[0050] Figure 3 The leaf node in this embodiment of the invention contains a field structure. Detailed Implementation

[0051] Example 1:

[0052] This embodiment presents an intelligent method for generating flash flood defense schemes based on marginal condition constraints. It does not treat the large model as the subject of factual judgment, but rather as a tool for language organization and logical arrangement. All factual content is provided by an external knowledge base, case library, risk map library, and basic database. All constraints are enforced in the form of an ontology structure. The generated results are automatically verified and bound to evidence before being output as a structured scheme.

[0053] like Figure 1 As shown, the workflow of the intelligent agent can be summarized into five stages: triggering and condition preparation → marginal condition assembly → segmented generation under ontology constraints → four-line defense verification → output and execution. Solid arrows indicate the data flow direction in each stage, and dashed arrows indicate the closed-loop control relationship of "generation-verification-correction" between stage four and stage three. This framework ensures: standardized input data, configurable retrieval scope, constrained generation process, verifiable output results, and traceable execution actions.

[0054] Specifically as follows:

[0055] Step S1. Triggering and Condition Preparation (Phase 1)

[0056] In this phase, the multi-source heterogeneous early warning inputs are unified into standardized defense scenario snapshots, providing a complete and consistent input benchmark for subsequent marginal condition retrieval.

[0057] (1) Design of scenario access module and construction of scenario snapshot

[0058] The scenario access module receives three types of inputs: real-time rainfall and water situation data (water level, rainfall, and flow time series) pushed by the flash flood monitoring and early warning platform, forecast rainfall data (rainfall level, coverage area, start and end time) issued by the meteorological department, and manual triggering commands initiated by business personnel through the system interface.

[0059] The module standardizes the input data and constructs a "current defense scenario snapshot". The scenario snapshot uses a structured definition format, such as... Figure 2 As shown;

[0060] Each scenario snapshot node includes a scenario identifier (scenarioId), trigger type (triggerType), trigger time (triggerTimestamp), a list of affected basins (affectedBasins), affected administrative districts (affectedDistricts), and scenario priority (scenarioPriority). The list of affected basins further includes basin code, basin name, forecast rainfall parameters (start and end times, cumulative rainfall, maximum rainfall intensity), current water level, and warning level.

[0061] The core algorithm logic for constructing scene snapshots is as follows:

[0062] ① Input normalization: Rainfall and water level data from different sources are uniformly converted into a standard time series format (30-minute intervals). Missing values ​​are filled in using linear interpolation, and outliers (beyond the physical possibility range) are marked and removed. Missing values ​​are filled in using linear interpolation.

[0063] ② Watershed Spatial Matching: Based on the watershed boundary vector data in the CGCS2000 coordinate system, the spatial intersection of the rainfall coverage area and the watershed surface is calculated, and the list of affected watersheds is determined according to the following criteria:

[0064] (1) Spatial overlap criteria: The area of ​​overlap between the rainfall coverage and the watershed surface reaches a set threshold (e.g., ≥20%), and the forecast surface rainfall in the watershed reaches its warning (or disaster-causing) rainfall threshold. Both conditions must be met for inclusion in the list.

[0065] (2) Topological association criteria: For watersheds where rainfall and water level monitoring stations are interconnected upstream and downstream in the water system topology, the expansion level K is determined according to the warning level linkage: blue K=0 (no expansion), yellow K=1, orange K=2, and red K=3. Only watersheds within level K are included to avoid unlimited expansion along the water system. The association between the station and the watershed is based on "the station is located within the watershed or within a certain distance (e.g., 5km) from the watershed outlet / channel".

[0066] (3) Output specifications: The list of affected watersheds is output as "watershed code + impact degree (area proportion, areal rainfall, warning level)" rather than a simple code list, which serves as the input basis for subsequent marginal condition retrieval.

[0067] ③ Comprehensive Determination of Warning Level: The warning level is determined using a rule matrix that considers both the forecast rainfall magnitude and the current water level. Warning levels are categorized into four levels: blue, yellow, orange, and red. For example:

[0068] Water level dimensions: more than 0.5m below the warning level → blue; less than 0.5m below the warning level → yellow; above the warning level → orange; above the guaranteed level → red.

[0069] Rainfall forecast: 6h < 25mm → Blue; 25mm ≤ 6h < 50mm → Yellow; 6h ≥ 100mm → Orange; 6h ≥ 150mm → Red.

[0070] The higher of the two dimensions above will be the warning level.

[0071] ④ Administrative division association: Using the spatial range of the affected watershed as the query condition, associate the data of the danger zone ledger and extract the code list of all townships / administrative villages involved.

[0072] ⑤ Shared resource identification: When the number of affected watersheds is ≥2, the system automatically checks whether there are duplicate references to relocation routes, resettlement sites, and emergency rescue teams between watersheds. If so, they are marked as shared resources for cross-watershed coordination verification in subsequent stages.

[0073] ⑥ Priority ranking: Determine the priority of scenario handling based on a comprehensive score of the warning level and the scope of impact (number of danger zones × population).

[0074] (2) Standardized definition of manual triggering instructions

[0075] Manual triggering is the entry point for system solution generation initiated by business personnel when the system is not under automatic warning conditions. To eliminate the ambiguity and non-standardization of manual input, the system standardizes manual triggering commands and defines the following command template:

[0076]

[0077] After receiving a manual instruction, the system uses an instruction parser to extract keywords (instruction type, target watershed / administrative region code, rainfall parameters, etc.), verifies the validity of the parameters (whether the code exists and whether the rainfall is within a reasonable range), and triggers the scenario access module to build the corresponding scenario snapshot after the verification is completed.

[0078] Step S2. Marginal Condition Assembly (Phase Two)

[0079] Based on the scenario snapshot, six types of marginal conditions are recalled from multi-source data, uniformly modeled as structured records, and injected with large model prompt words to ensure the complete factual basis of the generation process.

[0080] Parameters such as watershed coding, administrative divisions, and warning levels in the scenario snapshot are mapped to the corresponding data retrieval scope. Through parallel retrieval using precise matching and similarity calculation, the discrete raw data is uniformly encapsulated into structured marginal condition records with permID. This avoids large models fabricating data out of thin air due to a lack of factual constraints during the generation stage, ensuring that every defense command has a clear and traceable data source.

[0081] (1) Triggering and driving logic conditions for marginal condition retrieval

[0082] The initiation of marginal condition retrieval is not unconditional; rather, it is driven by key parameters in the scenario snapshot. The triggering chain consists of three levels of determination from top to bottom:

[0083] Level 1 Scenario Snapshot Readiness Check: After the scenario snapshot is built, the system performs an integrity check.

[0084] Are all required fields complete (scenarioId, triggerType, list of affected watersheds, warning level)?

[0085] Does the watershed code have a matching record in the database?

[0086] Whether the warning level is valid: Blue, Yellow, Orange, Red (not empty).

[0087] If any condition is not met, the system will refuse to enter the retrieval stage and return an error message to the front end: "Scenario snapshot is incomplete, please confirm the input parameters".

[0088] Second-level search scope activation determination: After the scenario snapshot is ready, the search depth is determined based on the warning level and scenario priority. The similarity threshold θ is dynamically graded according to the warning level (blue = 0.85, yellow = 0.65, orange = 0.55, red has no limit):

[0089]

[0090] The retrieval depth, similarity threshold θ, and topology expansion level K all increase with the warning level: the higher the warning level, the wider the retrieval range, the lower the threshold, and the deeper the topology expansion. During a red warning, the system imposes no restrictions and recalls all potentially relevant cases and data records.

[0091] The third-level marginal condition is checked for readiness by category: After the retrieval is completed, the system checks the recall results of the six categories of marginal conditions one by one:

[0092] Basic watershed information, list of hazardous areas, and information of responsible persons are mandatory. If any of these data is empty, the system will suspend the generation process and issue a "data missing prompt" (indicating the missing category and watershed code) to the business personnel, and will not proceed to stage three.

[0093] The transfer route is a quasi-mandatory type. If it is empty, a warning will be issued, but it can still enter stage three (the large model will generate a placeholder scheme for "transfer route to be supplemented").

[0094] Historical similar cases and related defense specifications are considered enhancements; when data is missing, the process is not blocked, only the richness of the solutions is reduced.

[0095] (2) Marginal condition retrieval module parameters and retrieval scope constraints

[0096] Module Structure: The retrieval module consists of two main sub-engines: a deterministic data retrieval engine and a historical case matching engine. The deterministic engine uses watershed codes as keys to perform precise matching in the basic database / risk map library / RAG index and expands the recall along the river system topology; the matching engine performs multi-dimensional weighted similarity calculations on historical cases and recalls them in tiers according to thresholds. The two engines execute in parallel, and the results are aggregated and uniformly packaged into structured marginal condition records (records contain a unique identifier permID and a source identifier sourceURI), injecting three prompt words at the stage.

[0097] Workflow: Once the scenario snapshot is ready, both engines start simultaneously.

[0098] ① The deterministic engine takes watershed coding as input, classifies and retrieves six categories of marginal condition data, executes each category independently, and merges the results by watershed dimension; ② The matching engine takes the feature vector of the scenario snapshot as input, traverses the knowledge base and case base to calculate similarity, and selects the Top-K cases; ③ The two results are merged and deduplicated by the marginal condition assembler, and then output after assigning `permID` and `sourceURI` to each case.

[0099] The retrieval module retrieves six types of marginal condition data from four major databases:

[0100]

[0101] Deterministic data retrieval (first five categories): exact matching + KNN topology expansion is used; the watershed code is used as the key to perform hash index (O(1)) to recall direct records; when the number of hit records is insufficient (basic information / danger zone / responsible person <1, transfer route <2), key fields are missing, data timeout or confidence is too low, the K level is expanded upstream / downstream along the water system topology (K value increases with the warning level), and the confidence of the expanded record is reduced by c'(v)=c(v)·(1-0.2d).

[0102] The retrieval results for recalculation steps such as KNN topology expansion and historical case similarity matching are cached: The cache unit is "search key → expanded complete result set". After the initial recalculation, the results are written to Redis with a cache TTL of 30 minutes, which serves as the rolling time window. "High-frequency hits" are defined as: the same search key accumulating ≥3 hits within the rolling time window. Once this threshold is reached, subsequent hits of the same key within the TTL directly return the cached results, skipping repeated topology traversal and similarity calculations. Search requests that do not reach the high-frequency threshold execute the complete recalculation logic in real time. The high-frequency hit count is maintained sequentially by a Redis counter (INCR), and the counter and cache are reset synchronously upon timeout.

[0103] The formal description of the KNN topology extension is as follows: Let the current watershed be... The tributary-mainstream relationship of a river system is abstracted as a directed graph G=(V,E), with edge directions defined as pointing from upstream to downstream. Definition K-level neighborhood For: From The set of nodes that can be reached in no more than K steps downstream or in no more than K steps upstream (i.e., by traversing edge E in the reverse direction), and which do not contain [the following]. The formula for calculating itself is as follows:

[0104]

[0105] Where d(a,b) is the shortest topological distance (number of edges) from a to b. When the number of records is insufficient, the search scope is expanded to The confidence level c of the extended record is calculated by Attenuation, in which .

[0106]

[0107] Historical case similarity retrieval: A multi-dimensional weighted similarity algorithm is employed. The current scenario is compared with historical cases across six dimensions, and the weighted sum is used to obtain a comprehensive similarity score.

[0108]

[0109] in, The total number of dimensions involved in the comparison; For the first A dimensional similarity function; For the current scenario in the first dimensional eigenvalues For historical cases in The eigenvalues ​​of the dimension.

[0110] The weights for each dimension and the similarity function are as follows:

[0111]

[0112] The similarity threshold θ is dynamically determined by the warning level (blue = 0.85, yellow = 0.65, orange = 0.55, red has no limit). Taking the typical yellow value θ = 0.65 as an example: cases with similarity ≥ θ are forcibly cited as strongly similar cases; cases with similarity θ - 0.25 to θ are only used as reference cases; and cases with similarity < θ - 0.25 are not recalled. The complete threshold ranges for each level are shown in the search range activation determination table above.

[0113] Calculation example: The similarity of a historical case across all dimensions is [0.80, 0.60, 0.70, 0.75, 0.90, 0.85]. The weighted sum is 0.755, which is ≥0.65. Therefore, it is considered a strongly similar case for recall.

[0114] In this step, the calculated comprehensive similarity is compared with the retrieval threshold θ corresponding to the current warning level. If the comprehensive similarity is greater than or equal to θ, the historical case is determined to be strongly similar to the current scenario. The case is then marked as a strongly similar case and included in the subsequent scheme generation process for mandatory reference.

[0115] Step S3. Segmentation Generation under Ontology Constraints (Stage Three)

[0116] Under the constraints of preset field structure, type rules and dependency relationships, the large model generates defense scheme text field by field. Key fields are forced to reference the injected marginal condition record (permID). When there is a missing or conflicting record, the output is rejected and the correction is automatically triggered.

[0117] This approach uses structured marginal condition records injected in the preceding stages as a hard fact foundation. It defines the hierarchical structure, field types, and inter-field dependencies of the solution through ontology constraint templates, enabling the large model to be organized linguistically and logically within a constrained space. This avoids factual errors, structural variations, and omissions of key fields caused by the large model's unrestrained development, ensuring that the generated defense solution is directly parsable in format and allows for item-by-item accountability in content.

[0118] (1) Definition of ontology constraints

[0119] The ontology constraint module defines three types of constraints, expressed in a structured JSON Schema format.

[0120] Field structure constraints: Define the field hierarchy of the plan (city-level plan → county-level sub-plan → watershed plan → danger zone relocation plan), each level contains standard field definitions (such as "relocation list", "resettlement site allocation", "rescue team dispatch", "material allocation", "precautions", etc.).

[0121] Field types and required field rules: Specify the data type (String / Integer / Float / Array / ) for each field. <reference>The fields for "Number of Transferred Population" and "Whether they are required" are specified. For example, the "Number of Transferred Population" field is of type Integer, is required, and its value range references the "Permanent Resident Population" field in the danger zone ledger and must not exceed this value.

[0122] Field dependencies: Define the logical relationships between fields, such as "total capacity of resettlement sites" in the city-level overall plan = ∑ "capacity of resettlement sites" in each county plan (summing constraint), and "transfer routes" in the county plan = "set of available transfer routes in the city" in the city-level plan (inclusion constraint).

[0123] (2) Segmented generation control mechanism

[0124] In Phase 3, the large model is not generated as a single, all-in-one solution text. Instead, it is generated field-by-field and node-by-node according to the hierarchical structure defined by the ontology constraints. The generation control flow is as follows:

[0125] ① Load the template: Select the corresponding template based on the trigger command type: "Basin Plan", "Administrative Region Plan", "Joint Dispatch" or "Historical Review".

[0126] ② Inject Marginal Condition Records: Organize the six types of structured marginal condition records output from Phase 2 into a JSON array by category, embedding prompt words. Each record must contain the `permID` and `sourceURI` fields.

[0127] ③ Field-by-field generation: The large model generates the content of each field sequentially according to the template field order. For key fields (such as the number of transferred population, transfer route code, name of the person in charge, and name of the resettlement site), the system adopts a forced reference mode. The large model must directly reference the `permID` of a certain marginal condition record and cannot arbitrarily fabricate it.

[0128] ④ Reference consistency check: After each field is generated, the system immediately checks whether the referenced `permID` exists in the record set injected in phase two; if the referenced `permID` does not exist or the generated content is inconsistent with the referenced record, the field is rejected and a regeneration is requested.

[0129] ⑤ Dependency rule check: Dependencies between fields (such as summation constraints and inclusion constraints) are checked in real time during the generation process. For example, if the sum of the "number of people transferred" in the county-level sub-plans exceeds the "total number of people to be transferred" in the city-level overall plan, the system will prompt a conflict and require adjustment.

[0130] ⑥ Missing fields handling: When a key field cannot be generated due to missing marginal conditions, the system stops generating at the current level, generates a "to be supplemented" placeholder, and returns the specific reason for the missing field to the front end, without proceeding to stage four.

[0131] (3) Design of the boundary of the large model character

[0132] ① In this invention, the large model is strictly limited to the following three types of tasks:

[0133] Language organization task: Transform the structured marginal condition records into a written plan that conforms to flood control operational practices;

[0134] Logical arrangement task: Arrange the paragraph structure of the plan reasonably according to the spatial relationship of the watershed, the administrative division level, and the time sequence;

[0135] Experience sharing task: Based on the experience of handling similar historical cases, generate non-numerical texts such as risk assessment, precautions, and recommended measures.

[0136] ②Large models are prohibited from performing the following three types of tasks:

[0137] Factual data generation: Key figures such as the population of danger zones, the length of evacuation routes, and the capacity of resettlement sites must not be calculated or fabricated on one's own;

[0138] Constraint rule judgment: Business rules such as early warning thresholds and administrative boundaries must not be interpreted independently; all rules must be executed by an external rule engine.

[0139] Source statement: Data sources must not be fabricated, and all source identifiers are generated by the evidence binding module.

[0140] Through the aforementioned role boundary design, the large model is downgraded from an "omnipotent generator" to a "restricted language assistant," fundamentally reducing the risk of hallucinations.

[0141] Step S4. Verification of the Four Lines of Defense (Phase Four)

[0142] Four lines of defense compress the error space layer by layer. If the error fails, the solution is automatically corrected by backflow. If the error passes, the solution is bound to a chain of evidence to ensure the credibility and traceability of the output.

[0143] This system is used to perform automated, layer-by-layer review of solution text generated from large models: The first line of defense checks whether the context is fully injected (to prevent the large model from ignoring provided marginal conditions); the second line of defense checks whether the output conforms to the preset ontology field structure (to prevent structural variations or missing fields); the third line of defense compares key values ​​in the solution with the original database line by line (to prevent numerical tampering or error drift); and the fourth line of defense reviews whether the solution complies with business rules (ensuring that each danger zone has relocation measures, resettlement sites have sufficient capacity, and responsible personnel cover villages and groups). By compressing the error space through multiple lines of defense, manual review is downgraded from "reading through the entire document" to "spot checks and confirmations."

[0144] (1) First line of defense: Context injection verification

[0145] The core objective of context injection validation is to ensure that the large model actually uses all injected marginal condition records during the generation process, rather than ignoring or omitting key inputs. Validation rules include:

[0146] Each danger zone in the danger zone list must be referenced at least once in the generated solution;

[0147] Key records such as evacuation routes, responsible persons, and resettlement sites must be cited according to the dimension of danger zones;

[0148] If similar historical cases and relevant defense specifications are injected, corresponding references should appear in the "Risk Assessment" or "Precautions" section of the solution.

[0149] Validation method: Double check using regular expressions and `permID` citation tracing. The system calculates the difference between the actual set of `permID` occurrences in the generated text and the `permID` set injected in phase two. If the `permID` of the mandatory class record does not appear, the validation fails, and a "context injection incomplete" message is returned, requiring phase three to regenerate.

[0150] (2) Second line of defense: verification of the body structure constraints

[0151] Ontology structure constraint validation ensures that the generated results strictly conform to the preset JSON Schema template. Validation rules include:

[0152] Field missing check: All required fields must exist and cannot be empty;

[0153] Field type check: The JSON data type of each field must conform to the schema definition (e.g., the number of transferred populations must be Integer, not string).

[0154] Field hierarchy check: The nesting relationship between city-level, county-level, watershed-level, and hazardous area-level schemes must conform to the template hierarchy;

[0155] Enumeration value check: The values ​​of enumeration fields such as warning level, transfer method, and priority must be within the allowed set.

[0156] Validation method: The large model output is parsed into a JSON object, and a JSONSchemaValidator (such as Ajv) is used to validate each field. Any field that violates the constraints will be recorded as a "structural error," the specific path will be located, and the process will be redirected back to stage three for targeted correction.

[0157] (3) The third line of defense: URI verification of evidence

[0158] Evidence URI verification is used to compare key values ​​in the plan with the original database line by line, preventing numerical tampering, unit conversion errors, or data drift during the application of the large model. Key numerical fields include: permanent residents in the danger zone, warning threshold, evacuation route length, resettlement site capacity, and contact information of the responsible person.

[0159] The verification rules include:

[0160] Strict equality verification: For identification fields (such as watershed codes, danger zone codes, and responsible person's mobile phone numbers), the generated values ​​must be completely consistent with the original records;

[0161] Range constraint validation: For numeric fields (such as the number of relocated people and the capacity of resettlement sites), the generated value must be within the range allowed by the original record (such as the number of relocated people ≤ the number of permanent residents).

[0162] Unit consistency verification: For fields with units (such as rainfall in mm, water level in m), the units in the generated values ​​must be consistent with the original records.

[0163] Verification method: Extract all fields containing `permID` from the generated results, perform a reverse query on the original database using `sourceURI`, and compare the generated values ​​with the original values. If the deviation exceeds a threshold, it is considered a "broken chain of evidence," and the specific fields and expected / actual values ​​are returned, triggering Phase 3 correction.

[0164] (4) Fourth line of defense: self-review of business rules

[0165] The business rule self-review is used to examine the feasibility and rationality of a plan from a business logic perspective. The review rules are based on the accumulated experience of flood control business experts, forming a configurable rule base.

[0166]

[0167] Verification method: The rule base is compiled into an executable script for the Drools rule engine, and the scenario object is used as the fact input to trigger rule matching. When a violation rule is hit, the system returns the violation type, the entities involved, and correction suggestions, which are then fed back to Phase 3 for correction. All rules allow business users to dynamically adjust parameters through a visual interface.

[0168] (5) Reflux correction strategy

[0169] When any line of defense fails in Phase 4, the system does not simply retry, but instead adopts a precise backflow strategy:

[0170] Encapsulate the error type, error location, expected / actual value, and related marginal conditions into a "correction context";

[0171] The correction context is added to the prompts in Stage 3, requiring the large model to make local corrections for the failures;

[0172] To avoid cyclical oscillations, the maximum number of backflow attempts is set to N=3. If the process fails after more than 3 attempts, the system will mark the current solution as "requiring manual intervention" and display all failures and evidence chains to the front end for manual correction by business personnel.

[0173] Step S5. Output and Execution (Phase Five)

[0174] By attaching evidence URIs to the key fields of the verified scheme, a JSONSchema structured scheme is generated. After manual confirmation, it is pushed to the monitoring and early warning platform to drive downstream tasks such as early warning issuance, SMS notification, transfer tracking, and effect evaluation, forming a complete business closed loop.

[0175] This system outputs the defense plan, after passing Phase 4 verification, in the form of a standard JSON Schema object tree. Each node includes a source identifier, confidence level, and review suggestions. After approval through manual confirmation (a web-based review panel that supports reviewing each piece of evidence and rejecting single fields), the plan is pushed to the flash flood monitoring and early warning platform via API, automatically populating business modules such as early warning issuance, SMS notification, evacuation tracking, and effect evaluation. This achieves a closed-loop process of "intelligent generation → manual review → platform execution → case archiving."

[0176] (1) Evidence binding and structured output

[0177] One of the core tasks of Phase Five is to attach chains of evidence to key fields in the scheme. The output structure uses a JSON Schema object tree, where each leaf node contains fields such as... Figure 3 As shown:

[0178] sourceType=DATABASE: Field values ​​are directly derived from the underlying database or risk graph library;

[0179] sourceType=CASE_LIB: The field value is derived from similar historical cases;

[0180] sourceType=KNOWLEDGE: The field value is derived from the defense specification or expert knowledge base;

[0181] sourceType=LLM_DERIVED: Field values ​​are generated by the large model based on the aforementioned facts and language organization (only allowed for non-numerical, unconstrained text).

[0182] By binding evidence, business personnel can click on each item in the plan on the review interface to view its data source, original records, and confidence level, achieving "traceability with a single click".

[0183] (2) Manual confirmation of entrance design

[0184] Although the four lines of defense have intercepted most errors, flood prevention involves the safety of people's lives and property, and the final plan still requires manual confirmation. The manual confirmation portal provides the following functions:

[0185] Evidence Chain View: Displays the source, confidence level, and verification results of each key field at the field level;

[0186] Single-field rejection: Reviewers can reject any field, and the system will return that field to stage three for regeneration.

[0187] Batch approval: Supports one-click batch approval for fields that pass all validations and have a confidence level ≥ 0.95;

[0188] Modification tracking: All manual modifications are recorded, including the operator, modification time, values ​​before and after modification, and reason for modification, to meet auditing requirements.

[0189] (3) Push execution and closed-loop feedback

[0190] The manually confirmed plan is pushed to the flash flood monitoring and early warning platform via a standardized API. The platform then automatically distributes the plan to the relevant business modules based on the specified fields.

[0191] Early warning release module: Generates early warning broadcast text based on the early warning level and scope of impact in the plan;

[0192] SMS notification module: Generates targeted notification SMS messages based on the responsible person's information, and supports automatic filling of SMS template variables;

[0193] Transfer tracking module: Distributes the transfer task list to the mobile APP of the grassroots responsible persons and transmits the transfer progress in real time;

[0194] Effectiveness evaluation module: Records data such as the actual number of people transferred, transfer time, and early warning response rate.

[0195] After execution, the platform sends the actual execution data back to the agent. The agent encapsulates this "scenario snapshot + generated solution + execution result" into a new historical case, which is then archived into the case library after confirmation by business personnel, forming a complete closed loop of "case-driven → solution generation → execution feedback → knowledge feedback".

[0196] Appendix 1: Design for Interface with Flash Flood Monitoring and Early Warning Platform

[0197] The intelligent agent is connected to the flash flood disaster monitoring and early warning platform using a loosely coupled architecture. Data interaction is achieved through a dual-channel approach using standardized RESTful API and WebSocket, ensuring that the intelligent agent can be connected as an independent module without affecting the operation of the existing platform.

[0198] (1) Data inflow direction (monitoring and early warning platform → intelligent agent)

[0199] The data inflow channel assumes the responsibility of "context awareness," providing real-time and historical data support for Phase 1 (context snapshot construction) and Phase 2 (marginal condition retrieval).

[0200] ① Interface method and security policy

[0201] Data inflow employs a dual-channel architecture. The RESTful API channel is used to retrieve historical data, basic ledgers, and knowledge base records on demand, with data format uniformly in JSON and transmission encrypted using HTTPS+TLS1.3. The WebSocket long-connection channel is used for proactively pushing real-time rainfall and flood information, forecast rainfall, and warning status changes. It adopts full-duplex mode, with a heartbeat interval of 30 seconds, and automatically reconnects exponentially after a disconnection, with a maximum reconnection interval of 60 seconds.

[0202] Interface authentication employs a dual mechanism combining short-term tokens and an IP whitelist. Tokens are valid for 2 hours, issued by the monitoring and early warning platform, and obtained by the agent upon startup via ClientCredentials mode, automatically renewing 5 minutes before expiration. All transmitted data is encrypted using TLS 1.3, and all communication logs are recorded.

[0203] ② Data Categories and Fields

[0204] The monitoring and early warning platform provides the intelligent agent with the following data: Real-time rainfall and water level data is pushed every 5 minutes via WebSocket, including station code, timestamp, 6-hour cumulative rainfall (mm), water level (m), flow rate (m³ / s), and warning level markers. Forecast rainfall data is pushed via WebSocket when the forecast product is updated, including grid ID, forecast lead time (1 hour / 3 hours / 6 hours / 24 hours), forecast rainfall (mm), and confidence interval. Danger zone warning status is pushed in real time via WebSocket when the status changes, including danger zone code, current warning level, warning issuance time, and expected start time of impact.

[0205] The hazard zone register is retrieved once via a RESTful API during scenario snapshot construction, including hazard zone code, name, CGCS2000 coordinate system location, resident population, number of vulnerable populations, associated watershed code, and risk level. Evacuation routes are also retrieved during scenario snapshot construction, including route code, origin and destination GPS coordinate sequence, length (km), traffic capacity (persons / hour), road surface type, and associated hazard zone code. Responsible personnel information is retrieved during scenario snapshot construction, including name, position, mobile phone number, scope of responsibility code, and on-duty status (on-duty / off-duty / standby). Historical similar cases and relevant defense specifications are provided by the agent's internal knowledge base and case library; see Phase Two for details.

[0206] ③ Data readiness verification

[0207] Before each scenario snapshot is built, the agent performs three readiness checks on the incoming data. The first is a real-time data timeliness check: the difference between the latest data timestamp and the current time must not exceed 10 minutes; otherwise, it is marked as "data delayed" and downgraded. The second is a forecast data integrity check: the 24-hour forecast rainfall grid coverage rate must be no less than 90% (i.e., the percentage of effective grid points in the forecast rainfall coverage area); if insufficient, it is supplemented by interpolation using neighboring grid points according to the worst-case scenario principle. The third is a basic data consistency check: the codes in the retrieved hazard zone ledger, evacuation routes, and responsible person information must be consistent across tables; inconsistent records are marked as "data conflict" and excluded from the search scope. The check results are recorded in the "Data Readiness Status" field of the scenario snapshot, serving as a prerequisite for the Phase Two marginal condition search.

[0208] (2) Direction of solution outflow (intelligent agent → monitoring and early warning platform)

[0209] The solution outflow channel assumes the responsibility of "solution execution driving", pushing the JSON Schema structured solution that has been manually confirmed in Phase 5 to the platform, driving the automatic execution of each business module.

[0210] ①Push Protocol

[0211] The solution is pushed via an API, and the content is a JSON Schema object tree. Each leaf node includes a field value, permID, confidence level, and source identifier. Upon receiving the solution, the platform returns a response with the structure `{planId,status,moduleStatus[]}`, reporting the reception and parsing status for each module. The planId is generated by the agent and is in the format "DP-{administrative region code}-{trigger timestamp}-{version number}". The platform uses the planId for idempotent deduplication, ensuring that repeated pushes of the same planId will not result in duplicate execution.

[0212] ② Module-level distribution logic

[0213] After the platform parses the solution object tree, it automatically routes to the four business modules according to the fields.

[0214] The early warning release module extracts the fields of early warning level, impact range description and suggested measures, automatically concatenates the early warning broadcast text (format: "[XX Early Warning] Affected by heavy rainfall in XX basin, it is expected that from XX hour XX minute..."), and pushes it to the early warning broadcast terminal to complete the broadcast.

[0215] The SMS notification module extracts the responsible person's name, mobile phone number, and notification content template variables, and generates targeted SMS messages in batches according to the list of responsible persons. It supports automatic filling of template variables, replacing {Name} with the responsible person's name, {Danger Zone Name} with the corresponding danger zone, {Transfer Start Time} with the estimated transfer start time, and {Resettlement Site Name} with the destination resettlement site. A single batch can send a maximum of 500 messages, with an interval of at least 10 seconds between multiple batches to prevent instantaneous overload of the SMS gateway.

[0216] The relocation tracking module extracts the relocation task list, including danger zone codes, number of people to be relocated, relocation route codes, resettlement point codes, and estimated start time. The list is then broken down into relocation tasks for individual danger zones and pushed to grassroots personnel via a mobile app. Each task is tracked in three states within the app: "Pending Receive → In Progress → Completed." Grassroots personnel can check in and confirm at each status node, and the platform summarizes the relocation progress in real time.

[0217] The effectiveness evaluation module extracts the expected number of people to be transferred, the expected transfer time, and the early warning response level to create an evaluation baseline record for this plan. Subsequently, it compares and analyzes the deviations with the actual implementation data returned by the closed-loop feedback, which is used for evaluating the effectiveness of the plan and rating the quality of historical cases.

[0218] ③ Push failure and retry

[0219] The handling strategy for push failures is divided into three layers. The first layer automatically retryes three times upon encountering HTTP 4xx or 5xx errors or a 30-second timeout, with retry intervals of 10 seconds, 30 seconds, and 60 seconds respectively (increasing backoff intervals). The second layer saves the solution as an offline JSON file to a specified directory, sends a "push failed" alert to the front end, and allows manual re-initiation of the push at an opportune time. The third layer handles successful pushes but with partial failures at the module level (i.e., some modules parsed successfully while others failed). Successful modules execute their business operations normally, while error messages from failed modules are displayed on a manual confirmation panel, where reviewers determine whether to "ignore and continue" or "correct and re-push."

[0220] (3) Closed-loop feedback (monitoring and early warning platform → intelligent agent)

[0221] The closed-loop feedback channel assumes the responsibility of "knowledge feedback," transmitting the actual implementation results of the solution back to the intelligent agent to complete the accumulation of historical cases and continuous optimization of the model.

[0222] ①Feedback data content

[0223] After the plan is completed—that is, all transfer tasks enter the "completed" state and the warning validity period has expired—the platform sends back feedback data through the `POST / api / v1 / defense-plan / feedback` interface. The feedback data contains 8 fields: planId (generated by the agent and used to associate with the original plan), actualTransferCount (from the transfer tracking module, recording the actual number of people transferred), actualTransferDuration (from the transfer tracking module, recording the actual time from the notification to the last person arriving at the resettlement point, in minutes), warningResponseRate (from the effect evaluation module, recording the proportion of people actually responding to the transfer among the number of people covered by the warning broadcast), casualties (from the effect evaluation module, recording the casualty situation and a brief description of the cause), routeStatus (from the transfer tracking module, recording the actual traffic status of each transfer route as smooth / congested / interrupted and the reason for the interruption), shelterUtilization (from the effect evaluation module, recording the utilization rate of the actual number of people arriving at each resettlement point and the designed capacity), and manualOverrideCount (from the manual confirmation panel, recording the cumulative number of manual interventions during the plan execution process, including fine-tuning and rejection).

[0224] ② Case archiving process

[0225] After receiving the feedback data, the agent completes the case archiving process as follows:

[0226] a. Related Encapsulation: The five elements of this case—"scenario snapshot + generated solution + four-line defense verification report + manual modification record + execution feedback data"—are related and encapsulated into a complete case record;

[0227] b. Quality rating: The system automatically calculates the effectiveness score of the plan based on feedback data (transfer completion rate, early warning response rate, deviation from expectations, etc.), and rates it as "excellent / good / average / failure".

[0228] c. Business personnel confirmation: Before the case is archived, it is submitted to the manual confirmation panel. Business personnel can modify the quality rating, add notes and lessons learned, and after confirmation, it is officially written into the case library.

[0229] d. Similarity Index Update: The feature vectors of new cases are synchronously written into the vector database index for use in subsequent phase two similar case retrieval.

[0230] ③ Feedback-driven optimization

[0231] The accumulated feedback data provides a basis for continuous system optimization:

[0232] Threshold parameter optimization: Regularly analyze the deviation of the plan execution (such as the expected number of people transferred vs. the actual number of people transferred), and adjust the default values ​​of the similarity threshold θ and the KNN expansion level;

[0233] Ontology template iteration: Identify fields that require frequent manual intervention, optimize template field definitions and constraint rules, and reduce the need for manual modifications;

[0234] Knowledge base supplementation: Identify data items or business rules that are "missing in the solution but found to be critical during execution" and incorporate them into the knowledge base or defense specifications.

[0235] Appendix 2: Technical Points

[0236] The core idea of ​​this invention is to redefine the role of large-scale models in the generation of flash flood prevention plans. Large-scale models are not responsible for factual judgments, estimating the number of people to be relocated, determining warning levels, or assessing route safety; these tasks are handled by deterministic data and business rules. Large-scale models are responsible for language organization (converting structured records into textual descriptions of the plan), logical arrangement (arranging paragraph structures according to spatial relationships and administrative levels), and experience sharing (generating non-numerical descriptions based on historical cases).

[0237] This approach reduces the risk of factual errors in high-risk decision-making scenarios. Traditionally, large models simultaneously handle both fact generation and language representation, making factual errors difficult to detect as they are hidden within fluent text. This invention separates these two tasks: facts are provided by a database, and language is organized by a large model, ensuring that every value in the generated result can be traced back to its original record. Even if the large model deviates in the language organization stage, the verification module can detect and correct it through numerical comparison.

[0238] 2. Six types of basic data are uniformly modeled as structured records and forcibly injected.

[0239] The system unifies six types of data—basic watershed information, hazard zone list, evacuation routes, responsible personnel information, historical similar cases, and relevant defense standards—into structured records. Each record includes a unique identifier, record type, content fields, source information, and confidence level. Before generation, the six types of data are embedded as JSON arrays with prompts in the large model. The large model can only reference the injected records and cannot fabricate values.

[0240] This mechanism ensures the factual accuracy of the generated content. Taking the number of transferred populations as an example: the large model must reference the "permanent resident population" field from the injected danger zone list, and cannot estimate it itself. If a record is missing, the large model stops generating that field and returns the reason for the missing information, rather than filling it in with a seemingly reasonable number. In the traditional approach, the large model might write population data from County A to County B; after unified modeling and forced injection, each value has a corresponding data identifier that can be checked, and the verification module intercepts any generated content that is inconsistent with the original record.

[0241] 3. Segmentation generation mechanism based on preset constraints

[0242] The system pre-sets three types of constraints: field structure constraints, field type and mandatory field rules, and field dependencies. The large model generates plans field by field within these constraints. Key fields (number of relocated people, relocation route code, name of responsible person, etc.) must reference injected data identifiers; if the reference is missing or the value is incorrect, output is rejected and correction is triggered. Field dependencies are checked in real time during the generation process; for example, the total capacity of resettlement sites in the city-level overall plan must equal the sum of the capacities of the plans for each county.

[0243] This mechanism avoids the problems of missing fields, structural confusion, and logical contradictions that easily occur when a large model outputs an entire text segment at once in traditional methods. Segmented generation breaks down a large task into multiple smaller tasks, and the generation of each field is constrained and controlled. When an error occurs, only the current field is corrected without affecting other generated content.

[0244] 4. Four lines of defense, layer-by-layer verification and automatic backflow correction

[0245] After generation, the system sequentially performs four checks: context injection verification, ontology structure verification, evidence URI verification, and business rule self-review, targeting four types of errors: "unused data," "structural misalignment," "numerical deviation," and "business violation." If any line of defense fails, the system encapsulates the error information into a correction context and returns it to the generation module for local correction. The maximum number of return cycles is N=3; exceeding this limit will result in a "manual intervention required" flag.

[0246] The four lines of defense each have their own focus and are not interchangeable. The first line prevents the large model from ignoring injected data and fabricating its own; the second line prevents the output structure from not conforming to the preset template; the third line prevents numerical tampering or error drift during the referencing process; and the fourth line prevents the solution from violating business rules. In the traditional approach, the quality of the solution relies entirely on manual review, line by line. Reviewers need to verify every value, every route, and every responsible person against the ledger, a time-consuming process prone to oversights due to fatigue. This invention intercepts most errors in the automatic verification stage, reducing manual review from "reading through the entire document" to "spot checks and confirmations."

[0247] 5. Evidence binding and structured output form a complete closed loop.

[0248] After verification, the system adds a source identifier to each key field in the solution and outputs a JSON Schema object tree. Once manually confirmed, the solution is pushed to the monitoring and early warning platform via API, driving four business modules: early warning issuance, SMS notification, migration tracking, and effect evaluation. After execution, the actual execution data is returned to the agent, encapsulated into a new historical case archive, and used to drive similarity threshold optimization and ontology template iteration.

[0249] This mechanism allows the generated results to be both manually reviewed and directly executed by business systems. Traditionally, large models output free text, requiring business personnel to manually input and format it before it can be integrated with business systems, increasing workload and potentially introducing transcription errors. With structured output, the platform directly parses the JSON object tree and automatically routes it to the appropriate business modules by field, eliminating the need for manual intervention. Furthermore, the source identifier attached to each defense instruction meets government decision-making and auditing requirements, allowing for tracing the basis for solution formulation afterward. Execution feedback is archived as new historical cases, enabling continuous system optimization—when similar scenarios occur later, the system can not only match historical cases to learn from experience but also adjust the ontology template and similarity threshold based on execution feedback data.

[0250] Example 2:

[0251] This embodiment presents a flash flood defense scheme generation system based on marginal condition constraints. It is a system based on the generation method of Embodiment 1. The system consists of seven functional modules, with data flowing sequentially along the path of "trigger → retrieval → generation → verification → output," including the following modules:

[0252] 1. Scenario Access Module

[0253] The system's input points receive three types of inputs: real-time rainfall and water level data (water level, rainfall, flow rate) pushed by the flash flood monitoring and early warning platform, rainfall forecasts (magnitude, coverage, start and end times) issued by the meteorological department, and manual trigger commands initiated by operational personnel through the interface (five categories: watershed plan, administrative region plan, rainfall simulation, joint dispatch, and historical review).

[0254] The module normalizes the input: rainfall and water level data from different sources are unified into 30-minute time series, missing values ​​are linearly interpolated, and outliers are marked and removed. Based on the CGCS2000 coordinate system watershed boundary vector, the spatial intersection of the rainfall coverage area and the watershed surface is calculated to determine the list of affected watersheds. The warning level (blue / yellow / orange / red) is determined by combining the rainfall forecast magnitude and the current water level, and the relevant township and administrative village codes are extracted from the danger zone ledger. When the number of affected watersheds is ≥2, shared resources are automatically identified. The final output is a "current defense scenario snapshot", which includes scenario identifier, trigger type, affected watersheds, warning level, involved administrative divisions, shared resource markers, and priority score.

[0255] 2. Marginal Condition Retrieval and Assembly Module

[0256] Based on the scenario snapshot, six types of data are retrieved from the basic database, risk map library, knowledge base, and case library: basic watershed information, list of dangerous areas, evacuation routes, information of responsible persons, historical similar cases, and relevant defense specifications.

[0257] The module has two sub-engines running in parallel. The deterministic retrieval engine uses watershed codes as keys for precise matching. When results are insufficient, it expands upstream / downstream along the river system topology. The expansion level K increases with the warning level (K=0 for blue, K=1 for yellow, K=2 for orange, and K=3 for red), and the confidence of the expanded records decreases with distance. The historical case matching engine takes the scene snapshot feature vector as input and calculates weighted similarity based on six dimensions: rainfall level, spatiotemporal distribution of rainfall, watershed characteristics, hazard area type, time factor, and treatment effect. It then dynamically categorizes and recalls cases according to warning level thresholds (forced citation / reference / no recall).

[0258] The two results are merged and deduplicated, each record is assigned a unique identifier and source identifier, and encapsulated as a structured record with large model prompts. After retrieval, the data readiness status is checked by category: watershed basic information, list of dangerous areas, and responsible persons are mandatory (if missing, the process is suspended); transfer routes are quasi-mandatory (if missing, a warning is issued but the process continues); historical cases and defense specifications are enhanced (if missing, the process is not blocked).

[0259] 3. Ontology Constraint Module

[0260] Define a structured template for the scheme, providing constrained space for generating large models. Define three types of constraints in JSON Schema format:

[0261] The field structure constraints specify the scheme hierarchy (city-level scheme → county-level sub-schemes → watershed scheme → danger zone relocation scheme), with each level containing standard fields (relocation list, resettlement site allocation, emergency rescue team dispatch, material allocation, precautions, etc.).

[0262] The field types and mandatory rules specify the data type (String / Integer / Float / Array / Reference) and whether each field is mandatory. For example, the "Number of Transferred Population" field is of type Integer, is mandatory, and its value cannot exceed the "Permanent Resident Population" value in the danger zone ledger.

[0263] Dependencies between fields define the logical relationships between fields. For example, the "total capacity of resettlement sites" in the city-level master plan is equal to the sum of the "resettlement site capacities" in each county plan (summation constraint), and the "transfer routes" in the county-level plans must belong to the "set of available transfer routes in the city" in the city-level plan (inclusion constraint).

[0264] The module loads the corresponding template (basin plan / administrative region plan / joint scheduling / historical review) according to the trigger command type, and the constraint rules are verified in real time during the generation process.

[0265] 4. Large Model Generation Module

[0266] After loading the ontology template, the six types of structured marginal condition records are organized into JSON arrays with embedded prompts. The large model is generated field by field in the order of the template fields. Key fields (number of transferred population, transfer route code, name of responsible person, name of resettlement site, etc.) adopt a mandatory reference mode—they must reference the unique identifier of a certain marginal condition record and cannot be fabricated.

[0267] After each field is completed, the existence of the reference is immediately verified, and the generated content is checked to ensure consistency with the referenced record. Dependencies between fields (sum constraints, containment constraints) are checked in real time during the generation process.

[0268] The role of the large model is limited to three types of tasks: language organization (converting structured records into scheme text descriptions), logical arrangement (arranging paragraph structure according to spatial relationships and administrative levels), and experience reference (generating non-numerical text based on historical cases). Factual numerical generation, constraint rule judgment, and source declaration are prohibited. When a key field cannot be generated due to missing data, the current level is stopped, and a "to be supplemented" placeholder and the reason for the missing data are returned.

[0269] 5. Four-line defense verification module

[0270] The first step (context injection validation): Using regular expressions and citation tracking, check whether each danger zone in the danger zone list is referenced at least once in the plan, and whether key records such as transfer routes, responsible persons, and resettlement points are referenced according to the danger zone dimension. Calculate the difference between the actual set of identifiers appearing in the generated text and the injected set; if any mandatory record does not appear, the plan is considered unsuccessful.

[0271] The second step (ontology structure validation): The generated result is parsed into a JSON object, and SchemaValidator is used to validate each field for missing fields, types, levels, and enumeration values. Fields that violate constraints are recorded as "structure error" and their specific paths are located.

[0272] The third step (evidence URI verification): Extract all fields with identifiers and perform a reverse query on the original database using the source URI. Perform strict equality verification on identifier fields (basin code, danger zone code, mobile phone number, etc.), range constraint verification on numerical fields (number of transferred population ≤ permanent population, etc.), and unit consistency verification on fields with units.

[0273] The fourth step (self-review of business rules): compile the rule base into an executable script and review seven categories of rules, including transfer coverage, resettlement site capacity, accessibility of responsible persons, route accessibility, early warning level matching, cross-basin coordination, and time consistency.

[0274] When any line of defense fails, the error type, location, expected / actual value, and related records are encapsulated into a correction context and fed back to the generation module for local correction. The maximum number of reflows is N=3; exceeding this limit will trigger a "manual intervention required" flag.

[0275] 6. Evidence Binding Module

[0276] Add a source identifier to each key field in the validated solution. Each leaf node is labeled with the source type: DATABASE (base database or risk graph), CASE_LIB (historical similar cases), KNOWLEDGE (defense specifications or expert knowledge base), LLM_DERIVED (non-numerical text generated by the large model based on the aforementioned facts, descriptive content only).

[0277] Business personnel can click on each solution item on the review interface to view the data source, original records, and confidence level. The module also records the validation results and confidence scores for each field, providing assistance for manual confirmation.

[0278] 7. Structured Output and Execution Module

[0279] The validated solutions are output as a JSONSchema object tree, with each node containing field values, source identifiers, confidence levels, and review recommendations.

[0280] The manual confirmation entry supports: evidence chain view (displaying the source and verification results at the field level), single field rejection (rejecting any field and returning it to the generation module for regeneration), batch approval (approving fields that have passed verification and have a confidence level ≥ 0.95 with one click), and modification log (recording the operator, time, values ​​before and after modification, and reason).

[0281] Once confirmed, the plan is pushed to the flash flood monitoring and early warning platform via a standardized API. The platform uses the planId for idempotent deduplication and automatically routes the data to four business modules based on the field: early warning release (generating broadcast text and pushing it to the broadcast terminal), SMS notification (sending messages in batches according to the list of responsible persons, with a maximum of 500 messages per batch and a batch interval of no less than 10 seconds), evacuation tracking (breaking down evacuation tasks into tasks based on individual danger zones and pushing them to the grassroots responsible persons' APP, with real-time feedback on execution progress), and effect evaluation (creating evaluation baseline records for subsequent deviation comparison).

[0282] When a push fails, it is handled according to a three-tier strategy: automatically retry 3 times (with an increasing backoff interval of 10 seconds / 30 seconds / 60 seconds); if the retry fails, save the JSON file offline and issue an alarm; if some modules fail, the successful modules will continue to execute normally, and the failed modules will be displayed for manual judgment.

[0283] After the plan is executed, the platform will send the actual execution data (actual number of people transferred, transfer time, early warning response rate, casualties, route accessibility, resettlement site utilization rate, and number of manual interventions) back to the intelligent agent. The system will associate and encapsulate the scenario snapshot, generated plan, verification report, manual modification records, and execution feedback data into a new historical case. After confirmation by business personnel, the case will be archived into the case library to drive similarity threshold optimization and ontology template iteration.

[0284] System Flow:

[0285] 1. Conditional Structured Injection

[0286] The system unifies the six types of basic data required for flash flood prevention—basin basic information, hazard zone list, evacuation routes, responsible person information, historical similar cases, and relevant prevention standards—into structured records. Each record includes a unique identifier (permID), record type, content fields, source information (sourceURI), confidence level, and validity period.

[0287] During the generation process, the large model can only reference the injected data records and cannot fabricate values. Taking the "Number of Transferred Population" field as an example, the large model must reference the "Permanent Resident Population" field value of the corresponding danger zone from the injected danger zone list record; it cannot estimate or generate it itself. If the ledger record for that danger zone is missing, the large model will stop generating that field and return the reason for the missing value, rather than filling it with a seemingly reasonable number.

[0288] This mechanism downgrades the large model from a "fact generator" to a "fact referencer," preventing factual illusions from the outset. In the traditional approach, the large model might write population data from County A to County B, or write revoked relocation routes into the current scheme; after structured injection, each value has a corresponding permID that can be looked up, and the verification module will intercept if the generated content is inconsistent with the original record.

[0289] 2. Segmentation generation under constraints

[0290] The system presets three types of constraints to define the generation space of large models:

[0291] The field structure constraint defines the standard field hierarchy of the scheme (city-level scheme → county-level sub-scheme → watershed scheme → danger zone relocation scheme). Each level contains specified fields (relocation list, resettlement site allocation, emergency rescue team dispatch, material allocation, precautions, etc.). The large model cannot add or delete field levels on its own.

[0292] Field Types and Required Field Rules – Specify the data type (String / Integer / Float / Array / Reference) and whether each field is required. For example, "Number of Transferred Population" is of type Integer, is required, and its value cannot exceed the "Permanent Residents" field in the danger zone ledger; "Responsible Person's Mobile Phone Number" is of type String, is required, and must be in 11-digit format.

[0293] Field dependencies – specifying the logical relationships between fields. For example, the "total capacity of resettlement sites" in the city-level master plan is equal to the sum of the "resettlement site capacities" in each county plan (summation constraint), the "transfer routes" in the county-level plans must belong to the "set of available transfer routes in the city" in the city-level plan (inclusion constraint), and the number of people allocated to the same route at the same time cannot exceed the route's maximum capacity (capacity constraint).

[0294] The large model is generated field by field, with reference consistency and dependencies checked immediately after each field is completed. Key fields (number of relocated people, relocation route code, name of responsible person, name of resettlement site, etc.) must reference injected data identifiers; if missing, output is rejected and correction is triggered. The large model's tasks are limited to language organization (converting structured records into a textual description of the plan), logical arrangement (arranging paragraph structure according to spatial relationships and administrative levels), and experience reference (generating non-numerical descriptions based on historical cases). Factual numerical generation, constraint rule judgment, and source declaration are prohibited.

[0295] 3. Defense line verification mechanism

[0296] After generation, the system performs four checks in sequence, each line of defense targeting different error types:

[0297] The first line of defense (context injection verification) checks whether the large model actually uses all injected marginal condition records. This is done by using regular expressions and citation tracking to calculate the difference between the actual set of data identifiers appearing in the generated text and the injected set. If mandatory records (danger zone lists, responsible persons, etc.) do not appear in the solution, the test fails. This line of defense prevents the large model from "ignoring" injected data and fabricating content on its own.

[0298] The second step (ontology structure validation) checks whether the output conforms to the preset JSON Schema structure. The generated result is parsed into a JSON object, and each field is checked for missing fields, type mismatches, hierarchical errors, and invalid enumeration values. For example, if a scheme lacks a "transfer list" field, or if the "transfer population" field is of type String instead of Integer, it is considered a structural error.

[0299] The third layer (evidence URI verification) involves comparing key values ​​in the solution against the original database line by line. Identifier fields (watershed codes, danger zone codes, mobile phone numbers, etc.) undergo strict equality verification; numerical fields undergo range constraint verification (number of relocated people ≤ permanent residents, number of allocated personnel ≤ resettlement site capacity, etc.); and fields with units undergo unit consistency verification. This layer of defense prevents numerical tampering or error drift during the application of the large model.

[0300] The fourth step (self-review of business rules) is to review whether the plan meets the business rules for mountain flood prevention, including seven categories of rules: relocation coverage (at least one relocation route and one responsible person for each danger zone), resettlement site capacity (the allocated population does not exceed the total capacity), accessibility of responsible persons (contact information is valid and they are on duty), route passability (no over-allocation at the same time), early warning level matching (the plan response level is consistent with the scenario early warning level), cross-basin coordination (shared resources do not conflict), and time consistency (the relocation start time is earlier than the flood arrival time).

[0301] When any line of defense fails, the system encapsulates the error type, location, expected value, actual value, and related data records into a correction context, and sends it back to the generation module for local correction. The maximum number of backflows is N=3; exceeding this limit will result in a "manual intervention required" flag, which will be handled manually by business personnel. The four lines of defense target four types of errors: "unused data," "structural misalignment," "numerical deviation," and "business violation," each with its own specific function and not interchangeable with the others.

[0302] 4. Evidence chain binding and structured output

[0303] After passing through four lines of defense, the system adds a source identifier to each key field in the solution and generates a JSON Schema object tree. Each node contains the field value, source type, source identifier, confidence level, and review recommendations.

[0304] The data sources are categorized into four types: DATABASE (field values ​​are directly derived from the base database or risk graph library), CASE_LIB (field values ​​are derived from historical similar cases), KNOWLEDGE (field values ​​are derived from defense specifications or expert knowledge bases), and LLM_DERIVED (field values ​​are generated by the large model based on the aforementioned facts and are limited to non-numerical descriptive text). All numerical values ​​must come from the injected data records, and the descriptive text must not contain specific numerical values.

[0305] Business personnel can click on each plan item in the review interface to view the data source, original records, and confidence level, achieving "traceability with a single click." After manual confirmation, the plan is pushed to the flash flood monitoring and early warning platform via a standardized API. The platform uses the planId for idempotent deduplication and automatically routes the data to four business modules: early warning issuance, SMS notification, evacuation tracking, and effect evaluation, driving subsequent execution. After execution, the actual execution data is sent back to the agent. The system associates and encapsulates the current scenario snapshot, generated plan, verification report, manual modification records, and execution feedback data into a new historical case. After confirmation by business personnel, this case is archived in the case library, driving similarity threshold optimization and ontology template iteration.

[0306] Example 3:

[0307] This example demonstrates an automatically generated county-level flash flood prevention plan, as detailed below:

[0308] I. Structural Composition

[0309] This embodiment is deployed at a county flood control and drought relief headquarters, and the system consists of the following parts:

[0310] 1. Monitoring data access terminal: Connects to the provincial hydrological bureau's rainfall and water level monitoring platform to receive real-time water level, rainfall, and flow data;

[0311] 2. Marginal Condition Database: Stores basic information on several small watersheds in the county, a register of more than 100 dangerous areas, dozens of evacuation routes, information on hundreds of responsible persons at all levels, as well as historical disaster cases and provincial defense standards for the past ten years;

[0312] 3. Large Model Service Node: Deploys domestically developed large models, used solely for language organization and logic orchestration;

[0313] 4. Validation Engine: Built-in validation rules for field integrity, numerical consistency, threshold compliance, and responsibility coverage;

[0314] 5. Monitoring and Early Warning Platform: After receiving structured solutions, it drives services such as SMS notifications and transfer tracking.

[0315] II. Working Principle and Function

[0316] When the provincial hydrological bureau issues a heavy rainfall warning for a certain river basin in the next few hours, the system operates according to the following steps:

[0317] The first step is for the scenario access module to read the early warning information, automatically construct a scenario snapshot, and identify the affected watershed code, the start and end time of rainfall, the warning level, and the list of townships and administrative villages involved.

[0318] The second step involves the marginal condition retrieval module retrieving six types of basic data from the database based on the watershed code and administrative divisions: the watershed's area, river system characteristics, and historical flooding data; the location, population, and warning thresholds of affected danger zones; available evacuation routes and resettlement site capacity; the names and contact information of responsible personnel at all levels; historical experience in handling similar rainfall events; and applicable provincial defense regulations. This data is uniformly modeled as structured records, each with a unique identifier and source information, and then infused with prompts from the large model.

[0319] The third step involves the large model generating a solution field by field under predefined field structure constraints. For example, when generating the "Transfer List" field, the danger zone code and population count must be referenced from the injected data; fabricated data is not allowed. If a danger zone does not have a designated transfer route, the system will refuse to complete that field and trigger a correction.

[0320] The fourth step involves four validation steps: checking if the context is fully injected; checking if the output conforms to the field structure; comparing key values ​​with the original database; and reviewing whether each danger zone has relocation measures, whether the resettlement site capacity is sufficient, and whether the responsible personnel cover the villages. If the relocated population in a danger zone exceeds the resettlement site capacity, the validation fails, and the error message is returned to the generation stage. The large model corrects the field while retaining the content that has passed the validation.

[0321] The fifth step involves attaching a source identifier to each key field in the validated scheme, generating a structured object tree. County flood control headquarters staff can view the scheme in the system and trace it back to the original database record by clicking on any value. Once confirmed, the scheme is pushed to the monitoring and early warning platform with a single click, automatically sending SMS messages to the responsible personnel and initiating evacuation tracking.

[0322] III. Effects

[0323] Before adopting this implementation method, it took several staff members several hours to develop a defense plan for the county, and it was prone to problems such as population data mismatch and omissions in evacuation routes. After adoption, the plan generation time was shortened to less than ten minutes, all key data came from authoritative databases, and four levels of verification automatically intercepted common errors. Only manual review and confirmation were required before release. During the trial period, the system generated over a hundred plans and intercepted dozens of problems. No evacuation delays due to plan errors occurred during actual implementation.

[0324] Example 4:

[0325] This example demonstrates a city-level multi-basin joint scheduling scheme generation case, as detailed below:

[0326] I. Structural Composition

[0327] This embodiment is deployed in a municipal water resources bureau, and adds the following to the county-level embodiment:

[0328] 1. Cross-basin coordination module: handles resource coordination when multiple river basins issue simultaneous early warnings;

[0329] 2. Interface with the superior platform: Submit the plan to the provincial platform and receive approval;

[0330] 3. Solution version management: Saves each generated solution and modification record, supporting post-event auditing.

[0331] II. Working Principle and Function

[0332] When the meteorological department forecasts that the city will experience regional rainstorms, affecting multiple counties and districts and more than ten river basins, the system workflow is as follows:

[0333] The scenario access module identifies complex scenarios where multiple watersheds issue warnings simultaneously and automatically marks shared resources that need to be coordinated, such as inter-county evacuation routes, municipal resettlement sites, and emergency rescue teams.

[0334] The marginal condition retrieval module retrieves basic data for each watershed and identifies the relationships between them. For example, adjacent watersheds may share the same relocation route if their danger zones are located in the same area. The system injects these relationships as additional constraints into prompts to avoid generating conflicting scheduling instructions.

[0335] The large model is generated field by field according to a hierarchical structure of "city-level overall plan + county-level sub-plans". The city-level plan focuses on resource coordination and cross-county coordination, while the county-level plan focuses on specific transfer and implementation. During the generation process, the ontology constraint module mandates that the city-level plan must include summary information of each county-level sub-plan, and the county-level plan must reference the resource allocation conclusions in the city-level plan to ensure hierarchical consistency.

[0336] The verification process includes an added cross-county conflict check: whether the same evacuation route is assigned to different danger zones at the same time, whether the total capacity of the municipal resettlement sites meets the combined needs of all counties, and whether there are time conflicts in the dispatch of rescue teams. When problems are found, the data is fed back for correction, and the large model readjusts the resource allocation scheme.

[0337] The output is a structured object tree containing the overall municipal plan and multiple county-level sub-plans, with source identifiers attached to key fields of each plan. The municipal plan is submitted to the provincial platform after being confirmed by the municipal flood control headquarters, while the county-level plans are simultaneously distributed to each county for implementation.

[0338] III. Effects

[0339] In the context of regional rainstorms, traditional methods require each county to develop its own plan followed by manual coordination, taking several hours and prone to resource allocation conflicts. With this implementation, the city-level overall plan and county-level sub-plans are generated simultaneously. Cross-county conflicts are automatically identified and corrected during the verification process, with the overall time controlled within tens of minutes. The plan version management function supports post-event traceability of the reasons for each modification and the responsible party, meeting government decision-making audit requirements. During the trial period in the flood season, the system generated joint dispatch plans during two regional rainstorms, involving more than ten river basins, nearly a hundred danger zones, and tens of thousands of relocated people, without any resource dispatch conflicts occurring during execution.

[0340] Example 5:

[0341] This embodiment is a solution optimization driven by historical cases.

[0342] I. Structural Composition

[0343] This embodiment adds a case study module to the county-level embodiment:

[0344] 1. Historical Case Database: Includes cases of flash flood disaster response in the province over the past ten years, with each case recording rainfall characteristics, disaster process, prevention measures, evacuation effects, and existing problems;

[0345] 2. Similarity matching engine: Calculates the similarity between the current scenario and historical cases based on dimensions such as rainfall level, watershed characteristics, and hazard zone type;

[0346] 3. Experience Injection Interface: Injects the experience of handling similar cases as a marginal condition into the generation process.

[0347] II. Working Principle and Function

[0348] When the system identifies a current scenario as highly similar to a historical case, the workflow is as follows:

[0349] When building a snapshot, the scenario access module simultaneously triggers the similarity matching engine. For example, if the current scenario is "short-term heavy rainfall in a certain river basin, involving multiple high-risk areas and nearly a thousand permanent residents", the system will match a case of similar rainfall in the same river basin several years ago, which has a high similarity score.

[0350] In addition to recalling the six regular data categories, the marginal condition retrieval module additionally recalls the handling experience of the historical case: the timing of the relocation, the actual relocation time, the selection of the resettlement site, and the problems encountered (such as a route being interrupted due to a landslide). This experience is used as a marginal condition for the "historical similarity" category and is injected into prompt words along with other data.

[0351] When generating a solution for the large model, the "Notes" field references this case experience, suggesting, "In a similar scenario in a certain year, a certain relocation route was interrupted due to a landslide; it is recommended to prepare an alternative route for this instance." This suggestion includes the source identifier of the historical case, which reviewers can click to view details.

[0352] The verification process includes an added review of the reasonableness of historical experience: checking whether the large model correctly draws on historical experience, rather than incorrectly referencing irrelevant cases. For example, if the large model incorporates experience from low-similarity cases into the current solution, the third line of defense (evidence URI verification) will find that the referenced case identifier does not match the current scenario well enough, triggering a backflow correction.

[0353] III. Effects

[0354] The incorporation of historical case experience makes the solutions more targeted and actionable. During the trial period in the flood season, the system automatically matched dozens of historical cases when generating solutions, some of which provided effective suggestions for route adjustments and optimization of relocation timing. Post-event evaluation showed that solutions referencing historical cases improved relocation efficiency in actual implementation, and delays caused by route issues were significantly reduced. The case source identification function enables reviewers to quickly determine the reliability of experience-based suggestions, avoiding blind adoption.

[0355] The above description is only used to illustrate the technical solutions of the present invention and is not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention (such as the application of various formulas, the order of steps, etc.) without departing from the spirit and scope of the technical solutions of the present invention.< / reference>

Claims

1. A method for intelligently generating flash flood prevention schemes based on marginal condition constraints, characterized in that, Includes the following steps: Step S1. Triggering and Condition Preparation: Receive real-time rainfall and water level data and forecast rainfall data from the flash flood monitoring and early warning platform, or manual triggering instructions from operational personnel, construct a snapshot of the current defense scenario, and clarify the affected watershed, warning level, administrative region, and key elements; Step S2. Marginal Condition Assembly: Based on the scenario snapshot, retrieve six types of marginal condition data from the knowledge base, case library, risk map library and basic database, including basic watershed information, list of dangerous areas, relocation routes, responsible persons, historical similar cases, and relevant defense specifications. Model them uniformly as structured marginal condition records with permID and inject large model prompt words. Step S3. Segmented generation under ontology constraints: Define field structure, field type, mandatory rules and field dependency constraints. Generate solution text for the large model field by field. Key fields reference the injected marginal condition records. Reject output and trigger correction when missing or conflicting. Step S4. Four-line defense verification: The generated result passes through four lines of defense in sequence: context injection verification, ontology structure constraint verification, evidence URI verification, and business rule self-examination. If the validation fails, the error message will be sent back to the larger model for correction. After successful verification, the evidence binding module is accessed. Step S5. Output and Execution: Attach evidence URIs to the key fields of the verified scheme, generate a JSONSchema structured scheme, and push it to the monitoring and early warning platform after manual confirmation and entry review to drive downstream tasks.

2. The intelligent generation method for flash flood prevention schemes based on marginal condition constraints according to claim 1, characterized in that, In step S1, the method for determining the warning level is as follows: a first warning level is obtained based on the water level; a second warning level is obtained based on the 6-hour forecast rainfall; and the highest level between the first and second warning levels is selected as the final warning level. The warning levels are red > orange > yellow > blue.

3. The intelligent generation method for flash flood prevention schemes based on marginal condition constraints according to claim 1, characterized in that, In step S2, the marginal condition assembly involves a two-level retrieval mechanism combining exact matching and KNN topology expansion to perform deterministic data retrieval. Exact Matching Layer: Using the watershed code as the key, a hash index is used to retrieve direct records in O(1) mode; when the number of hit records is insufficient, key fields are missing, data times out, or confidence is too low, the system expands upstream / downstream by K levels along the water system topology, with the expanded record confidence level adjusted accordingly. attenuation; The retrieval results of the KNN topology expansion and historical case similarity matching recalculation are cached: the cache unit is "search key → expanded complete result set". After the first recalculation, the result is written to the non-relational in-memory database Redis. The cache TTL is 30 minutes and this expiration time is used as the rolling time window. "High frequency hit" is defined as: the same search key has a cumulative hit count of ≥3 times within the rolling time window. After reaching this threshold, subsequent hits of the same key within the TTL are directly returned to the cached result, skipping repeated topology traversal and similarity calculation. For retrieval requests that do not reach the high-frequency threshold, a complete recalculation logic is executed in real time; the high-frequency hit count is maintained by a Redis counter through atomic increment operations, and the counter is reset synchronously with the cache after a timeout. Topology extension layer: Let the current watershed be... The tributary-mainstream relationship of a water system is abstracted into a directed graph. The direction of the edge is defined as from upstream to downstream. K-level neighborhood The calculation formula is as follows: in, For the node To the node The shortest topological distance; the search range is expanded to Confidence decay: Confidence of expanded records according to Attenuation, in which .

4. The intelligent generation method for flash flood prevention schemes based on marginal condition constraints according to claim 1, characterized in that, In step S2, the marginal condition assembly involves using a multi-dimensional weighted similarity algorithm to compare the current scenario with historical cases across six dimensions, and then summing the results to obtain a comprehensive similarity score, as detailed below: Obtain the feature vector of the current early warning scenario. The feature vector includes at least the following six dimensions: rainfall level characteristics, spatiotemporal distribution characteristics of rainfall, watershed geomorphological characteristics, distribution characteristics of danger zones, time decay characteristics, and historical treatment effect characteristics. Calculate the dimensional similarity between the current warning scenario and each historical case across each feature dimension. The weighted average of the similarities across the various dimensions is used to obtain the overall similarity, calculated using the following formula: " in, The total number of dimensions involved in the comparison; For the first A dimensional similarity function; For the current scenario in the first dimensional eigenvalues For historical cases in eigenvalues ​​of dimension; Retrieval threshold for the current warning level The retrieval threshold is determined based on a preset mapping relationship of warning levels, and decreases monotonically as the warning level increases. The overall similarity is compared with the retrieval threshold. If the overall similarity is greater than or equal to the retrieval threshold, the historical case is marked as a strongly similar case and output.

5. The intelligent generation method for flash flood prevention schemes based on marginal condition constraints according to claim 1, characterized in that, In step S3, the large model generates solution text field by field, which is done according to the hierarchical structure defined by the ontology constraints, generating solution text field by field and node by node; the corresponding template is selected according to the trigger instruction type, and the permID of the marginal condition record is forcibly referenced for the key fields; after the fields are generated, it is verified whether the referenced permID belongs to the pre-injected record set, and whether the generated content matches the corresponding marginal condition record; the dependency relationship between fields is verified; when a key field cannot be generated due to missing marginal conditions, the generation of the current level is stopped, and the placeholder for the item to be supplemented and the reason for the missing item are output.

6. A system for generating flash flood defense schemes based on marginal condition constraints, the system being used to implement the generation method according to any one of claims 1-5, characterized in that, The system includes interconnected modules for scenario access, marginal condition retrieval and assembly, ontology constraint, large model generation, four lines of defense verification, evidence binding, and structured output and execution. The scenario access module is connected to the flash flood monitoring and early warning platform to receive real-time rainfall and water level data, forecast rainfall data or manual triggering commands, and to build a standardized defense scenario snapshot. The marginal condition retrieval and assembly module is connected to the scenario access module and is used to recall six types of marginal condition data from the multi-source database based on the scenario snapshot, uniformly model them into structured marginal condition records with permanent identifiers and inject large model prompt words; The ontology constraint module is used to predefine field structure, field type, mandatory field rules, and field dependency constraints. The large model generation module is connected to the marginal condition retrieval and assembly module and the ontology constraint module, respectively. It is used to generate scheme text field by field under the constraints of the ontology constraint module. Key fields are forced to reference the injected marginal condition records. When there are missing or conflicting fields, the output is rejected and correction is triggered. The four-line defense verification module is connected to the large model generation module and is used to perform context injection verification, ontology structure constraint verification, evidence URI verification and business rule self-examination on the generation result in sequence. If it fails, the error information is returned to the large model generation module for correction. The evidence binding module is connected to the four-line defense verification module and is used to attach evidence URIs to the key fields of the scheme that pass the verification. The structured output and execution module is connected to the evidence binding module and the flash flood monitoring and early warning platform, respectively, and is used to convert the scheme into JSONSchema structured data. After manual confirmation, the data is pushed to the flash flood monitoring and early warning platform to drive the execution of downstream tasks.

Images