A Temporal Planning Approach for Intelligent Flood Response

arXiv cs.AI Papers

Summary

The paper presents a temporal planning framework for intelligent flood response, enabling coordinated scheduling and dynamic replanning under resource constraints.

arXiv:2608.20510v1 Announce Type: new Abstract: Effective response to multiple, simultaneously flooded areas requires coordinating appropriate actions in the correct temporal order, under severe resource constraints. Automated planning provides a foundation for addressing this challenge by generating time-aware schedules, given a formal description of available resources, constraints, and goals. This work presents an intelligent flood-response framework that exploits temporal planning and models the complete operational life cycle of flood response. The framework incorporates priority-driven triage, route accessibility and travel costs, resource allocation, and supply management, while also supporting mid-execution re-planning in response to unexpected environmental changes. The framework is formulated both in the Action Notation Modeling Language (ANML) and the Planning Domain Definition Language (PDDL) 2.1, facilitating compatibility with a wider range of temporal planners. Experimental results establish the feasibility and scalability of the proposed framework, showing that flood response scenarios can be effectively modeled and solved using temporal planning, while providing guidance on planner selection.
Original Article
View Cached Full Text

Cached at: 08/24/26, 04:12 AM

# A Temporal Planning Approach for Intelligent Flood Response
Source: [https://arxiv.org/html/2608.20510](https://arxiv.org/html/2608.20510)
Md\. Monjurul Islam\\affilnum1,2and Sabah Binte Noor\\affilnum1Email:[sabah@duet\.ac\.bd](mailto:[email protected])

###### Abstract

Effective response to multiple, simultaneously flooded areas requires coordinating appropriate actions in the correct temporal order, under severe resource constraints\. Automated planning provides a foundation for addressing this challenge by generating time\-aware schedules, given a formal description of available resources, constraints, and goals\. This work presents an intelligent flood\-response framework that exploits temporal planning and models the complete operational life cycle of flood response\. The framework incorporates priority\-driven triage, route accessibility and travel costs, resource allocation, and supply management, while also supporting mid\-execution re\-planning in response to unexpected environmental changes\. The framework is formulated both in the Action Notation Modeling Language \(ANML\) and the Planning Domain Definition Language \(PDDL\) 2\.1, facilitating compatibility with a wider range of temporal planners\. Experimental results establish the feasibility and scalability of the proposed framework, showing that flood response scenarios can be effectively modeled and solved using temporal planning, while providing guidance on planner selection\.

###### keywords

Flood Response, Planning, Reasoning, AI and Society

††runninghead:Siddiqui, Islam, and Noor††affiliation:\\affilnum1Department of Computer Science and Engineering, Dhaka University of Engineering & Technology, Gazipur, 1707, Bangladesh
\\affilnum2Department of Computer Science and Engineering, Bangladesh Army University of Engineering & Technology, Natore, 6431, Bangladesh††corresponding:Sabah Binte Noor, Department of Computer Science and Engineering, Dhaka University of Engineering & Technology, Gazipur, 1707, Bangladesh\.## 1Introduction

An effective response to floods requires rapid decision\-making and coordinated actions\([8](https://arxiv.org/html/2608.20510#bib.bib12)\)\. Traditional flood management combines structural and non\-structural measures\. Structural measures include embankments and improved drainage, while non\-structural measures include early warning systems\([9](https://arxiv.org/html/2608.20510#bib.bib16)\)\. However, traditional approaches are increasingly considered inadequate to deal with complex flood events, especially when multiple locations are affected at the same time and response resources have to be allocated under severe time constraints\([10](https://arxiv.org/html/2608.20510#bib.bib17)\)\. Automated planning systems offer a viable solution to this problem\.

Automated planning systems use heuristic\-based search to reason over a formal description of available resources and operational constraints\([5](https://arxiv.org/html/2608.20510#bib.bib10)\)\. In this work, we formulate flood response as a temporal planning problem to provide structured coordination and scheduling of response actions under resource constraints, along with dynamic replanning to adapt to environmental changes during execution of the scheduled actions\.

Earlier works in disaster management focused primarily on preparedness and prevention, whereas recent studies emphasize response, recovery, and resilience\. However, absolute protection is neither achievable nor sustainable due to inherent uncertainties and high costs\([12](https://arxiv.org/html/2608.20510#bib.bib1)\)\. Therefore, strategic flood risk management principles recommend a portfolio of diverse responses rather than relying on a single measure\([11](https://arxiv.org/html/2608.20510#bib.bib2)\)\. A comparative study of the severe 1998 and 2020 Yangtze River floods by[7](https://arxiv.org/html/2608.20510#bib.bib3)showed that the results were significantly improved in 2020 due to the advanced emergency response and risk management capabilities\. This study indicates that effective response measures are critical for mitigating flood impacts and strengthening community resilience\.

Several studies formalize specific flood response operations as computational problems\.[2](https://arxiv.org/html/2608.20510#bib.bib5)use stochastic programming models to optimize rescue depot locations and supply allocation under uncertainty\. They employed a sample average approximation scheme to solve their models\.[13](https://arxiv.org/html/2608.20510#bib.bib4)developed a simulation model that captures human behavior during flood emergency evacuation\. Their model incorporates key variables such as the number of families at risk, evacuated populations, warning systems, and route inundation\. At a broader scale,[16](https://arxiv.org/html/2608.20510#bib.bib6)propose an interdisciplinary, AI\-driven framework for urban flood resilience that integrates urban planning, landscape architecture, and computer science, addressing the persistent gap between research and practice in achieving flood resilience\. Whereas[1](https://arxiv.org/html/2608.20510#bib.bib7)present a spatial planning framework centered on blue\-green infrastructure for prioritizing key infrastructure dimensions\.

Other researchers focus specifically on evacuation logistics during extreme events\.[17](https://arxiv.org/html/2608.20510#bib.bib8)examine storm flood evacuations in large coastal cities, with particular attention to elderly populations\. Their optimization of shelter placement and routing evacuees to nearby rather than distant facilities improved overall evacuation efficiency\. Meanwhile,[15](https://arxiv.org/html/2608.20510#bib.bib9)study pedestrian evacuation during dam\-break floods\. They utilize a fuzzy VIKOR method to evaluate potential shelters and a dual\-objective model to balance evacuation time, cost, and adaptability under evolving post\-disaster conditions\. While these works address important aspects of flood response, none employ automated planning and scheduling to generate time\-aware, coordinated response plans under resource constraints\.

The most relevant work in this domain is the RAPID framework by[6](https://arxiv.org/html/2608.20510#bib.bib15), which introduces a disaster response domain using the Planning Domain Definition Language \(PDDL\)\([4](https://arxiv.org/html/2608.20510#bib.bib14)\)with numeric planners to generate disaster response plans\. However, RAPID relies on classical PDDL with numeric fluents, and therefore, it cannot model action scheduling or the concurrent overlapping of operations\. This study addresses that limitation by introducing a temporal planning approach for temporally coherent flood response\.

In this work, we formalize flood response as a coordination problem to optimize critical operational decisions, including the allocation of teams, resources, and vehicles, as well as the timing and sequencing of concurrent actions\. We present a temporal planning framework, modeled in two formal languages, the Action Notation Modeling Language \(ANML\)\([14](https://arxiv.org/html/2608.20510#bib.bib13)\)and PDDL 2\.1\([3](https://arxiv.org/html/2608.20510#bib.bib11)\), covering the full operational cycle of flood response\. The proposed framework incorporates real\-world constraints like priority\-based triage ordering, route accessibility, vehicle capacity, and scheduling of concurrent operations\. Additionally, the framework includes a symbolic milestone system that captures the multi\-trip nature of evacuation and supply delivery without the computational overhead of continuous numeric reasoning\. Notably, the framework supports mid\-execution replanning to adapt to the dynamic changes in the environment\. As new data is revealed from the field, it allows us to update the instance to the current observable state and trigger replanning for an adapted schedule\. We also provide practical planner selection guidance based on scenario complexity and quality requirements\.

### Illustrative Example

A representative flood response scenario used to demonstrate the proposed domain is shown in Figure[1](https://arxiv.org/html/2608.20510#S1.F1)\. The scenario consists of two safe areas,safeAandsafeB, and two affected areas,zoneAandzoneB\. The locationsafeAis the main deployment base that has a transit vehicle \(bus\) with an evacuation capacity of 20 persons per trip, a freight vehicle \(truck\) used for resource transportation, a rescue team of 5 members, a medical support team of 5 members, and 100 units of relief goods \(food\)\.

![Refer to caption](https://arxiv.org/html/2608.20510v1/scenario.png)Figure 1:An example scenario with two safe areas \(safeAandsafeB\) and two affected zones \(zoneAandzoneB\)\.zoneArequires rescue operations, medical support, and 100 units of relief goods, whilezoneBrequires rescue operations and evacuation of 40 people\. Vehicle\-dependent travel times range from 11 to 38 time units\.Affected areazoneArequires rescue operations, medical support, and 100 units of food, whereaszoneBrequires rescue operations and evacuation of 40 people\. Travel time between locations depends on the vehicle\. For instance, a bus takes 18 time units to move fromsafeAtozoneA, while a truck takes 25, consistent with real\-world cases where vehicle type determines travel time\.

To illustrate how temporal planning operates on such a scenario, Figure[2](https://arxiv.org/html/2608.20510#S1.F2)shows a valid action schedule, produced by an automated temporal planner\. The plan consists of 25 actions with a makespan of 275 time units\. This plan demonstrates how temporal planning coordinates overlapping operations\. Specifically, at time 0, three actions execute concurrently: loading relief goods into the truck \(LoadResource\), while the medical support and rescue teams simultaneously board the bus \(BoardTeam\)\. After that, the bus departs at time 5 and arrives atzoneAat time 23, and both teams disembark from the bus and immediately begin rescue operations \(RescueAffectedPeople\) and medical support \(ProvideMedicalSupport\) in parallel at time 28\.

0255075100125150175200225250275TimeLoadResource\(food,safeA,truck,k100,k50\)50BoardTeam\(medics,safeA,bus\)5BoardTeam\(rescuers,safeA,bus\)5MoveVehicle\(bus,safeA,zoneA\)18DisembarkTeam\(medics,bus,zoneA\)5DisembarkTeam\(rescuers,bus,zoneA\)5RescueAffectedPeople\(zoneA,rescuers\)15ProvideMedicalSupport\(zoneA,medics\)15BoardTeam\(rescuers,zoneA,bus\)5MoveVehicle\(bus,zoneA,zoneB\)29MoveVehicle\(truck,safeA,zoneA\)25DeliverResource\(food,zoneA,truck,k100,k50\)50Evacuate\(zoneB,bus,p40,p20\)20DisembarkTeam\(rescuers,bus,zoneB\)5RescueAffectedPeople\(zoneB,rescuers\)15MoveVehicle\(bus,zoneB,safeA\)11DisembarkEvacuatedPeople\(bus,safeA\)10MoveVehicle\(bus,safeA,zoneB\)11MoveVehicle\(truck,zoneA,safeA\)25Evacuate\(zoneB,bus,p20,p0\)20MoveVehicle\(bus,zoneB,safeA\)11LoadResource\(food,safeA,truck,k50,k0\)50DisembarkEvacuatedPeople\(bus,safeA\)10MoveVehicle\(truck,safeA,zoneA\)25DeliverResource\(food,zoneA,truck,k50,k0\)50TransportResponseLogisticsFigure 2:A temporal plan for the example flood response scenario in Figure[1](https://arxiv.org/html/2608.20510#S1.F1)\. Each bar represents a durative action, where the horizontal placement indicates the start time and the width with the inscribed number indicates the execution duration in time units\. Actions aligned vertically execute concurrently\.In addition, the truck departs at time 50 and arrives atzoneAat time 75, and relief goods are then delivered\. Meanwhile, the rescue team is transported and is redeployed tozoneBvia bus, where evacuation and rescue operations are carried out across two evacuation sorties \(Evacuateat times 77 and 129\)\. Each evacuation sortie is followed by a return trip tosafeAto disembark evacuees before redeployment\. Applying the whole plan efficiently resolves all demands for evacuation, rescue, medical support, and resource delivery across the impacted zones, and several actions concurrently take place, similar to a real\-world scheduling scenario\.

## 2Background

In this section, we introduce basic notions of automated planning and modeling languages used in this work\. We first define the primary automated planning paradigms, including classical, numeric, and temporal planning, and then present an overview of the two modeling languages, PDDL and ANML, used to model the proposed domain\.

### 2\.1Automated Planning

Automated planning generates sequences of actions \(i\.e\., plans\) which transform an initial state into a desired goal state\([5](https://arxiv.org/html/2608.20510#bib.bib10)\)\. Depending on the complexity of the environment of the problem, planning models need to reason about logical conditions, quantitative resources, and temporal constraints\. These requirements give rise to three progressively expressive paradigms: classical planning, numeric planning, and temporal planning\.

Classical planning \(Definition[1](https://arxiv.org/html/2608.20510#Thmdefinition1)\) provides the fundamental structural syntax for automated planning\. It operates within a deterministic, fully observable, and static environment, meaning the agent has complete knowledge of the system state and the deterministic outcomes of its actions\.

###### Definition 1\.

Aclassical planning taskis represented as a tupleΠ=⟨F,A,γ,I,G⟩\\Pi=\\langle F,A,\\gamma,I,G\\rangle, where:

- •FFis a finite set of propositional facts,
- •AAis a finite set of actions,
- •γ:A↦ℚ0\+\\gamma:A\\mapsto\\mathbb\{Q\}\_\{0\}^\{\+\}is a function assigning a non\-negative rational cost to each action,
- •I⊆FI\\subseteq Frepresents the initial state, and
- •G⊆FG\\subseteq Fspecifies the goal conditions\.

Each actiona∈Aa\\in Ais a tuplea=⟨p​r​e​\(a\),a​d​d​\(a\),d​e​l​\(a\)⟩a=\\langle pre\(a\),add\(a\),del\(a\)\\rangle, wherep​r​e​\(a\),a​d​d​\(a\),d​e​l​\(a\)⊆Fpre\(a\),add\(a\),del\(a\)\\subseteq Fdenote the action’s precondition, add list, and delete list, respectively\. The add and delete lists collectively constitute the action effects\.

A solution to a classical planning task is a sequence of actions that transforms the initial state into a state satisfying the goal conditions\. An action is applicable only when its preconditions hold in the current state, after which its effects modify the state by adding and removing facts\. Definition[2](https://arxiv.org/html/2608.20510#Thmdefinition2)formally defines aplan\.

###### Definition 2\.

Aplanπ\\pifor a classical planning taskΠ\\Piis an ordered sequence of actions⟨a1,a2,…,an⟩\\langle a\_\{1\},a\_\{2\},\\dots,a\_\{n\}\\rangle\. The planπ\\piis valid if and only ifp​r​e​\(a1\)⊆Ipre\(\{a\_\{1\}\}\)\\subseteq Iand the sequential application of actionsa1,a2,…,ana\_\{1\},a\_\{2\},\\dots,a\_\{n\}successfully yields a state satisfying the goal conditionsGG\.

Classical planning cannot represent quantitative resources such as fuel, supply quantities, or vehicle capacities because states are purely propositional\. Many real\-world problems require reasoning about quantities that change during execution\. Numeric planning directly extends classical planning by introducing numeric state variables and arithmetic expressions into the planning model\([3](https://arxiv.org/html/2608.20510#bib.bib11)\)\.

###### Definition 3\.

Anumeric planning taskis defined as a tupleΠn=⟨F,X,A,γ,I,G⟩\\Pi\_\{n\}=\\langle F,X,A,\\gamma,I,G\\rangle, whereFF,AA, andγ\\gammaretain their definitions from the classical planning paradigm \(Definition[1](https://arxiv.org/html/2608.20510#Thmdefinition1)\), andXXis a finite set of numeric variables bounded over the rational numbersℚ\\mathbb\{Q\},I⊆F∪XI\\subseteq F\\cup Xis the initial state, andG⊆F∪XG\\subseteq F\\cup Xspecifies the goal conditions\.

Actions of a numeric planning task may modify both propositional facts and numeric variables through arithmetic updates\. Despite this added expressiveness, numeric planning still assumes that actions occur instantaneously\. Real\-world operations involve activities with duration, deadlines, and concurrency requirements that numeric planning tasks fail to encode\. Temporal planning addresses these limitations by explicitly incorporating time into the planning process\([3](https://arxiv.org/html/2608.20510#bib.bib11)\)\.

###### Definition 4\.

Atemporal planning taskis represented as a tupleΠt=⟨F,X,Ad,γ,I,G⟩\\Pi\_\{t\}=\\langle F,X,A^\{d\},\\gamma,I,G\\rangle, whereFF,XX,γ\\gamma,II, andGGare defined as in a numeric planning task \(Definition[3](https://arxiv.org/html/2608.20510#Thmdefinition3)\), andAdA^\{d\}is a finite set of*durative actions*\. Each actiona∈Ada\\in A^\{d\}is a tuple as given in \([1](https://arxiv.org/html/2608.20510#S2.E1)\)\.

a=⟨𝑝𝑟𝑒s​\(a\),𝑝𝑟𝑒o​\(a\),𝑝𝑟𝑒e​\(a\),𝑒𝑓𝑓s​\(a\),𝑒𝑓𝑓e​\(a\),𝑑𝑢𝑟⁡\(a\)⟩a=\\langle\\,\\mathit\{pre\}^\{s\}\(a\),\\;\\mathit\{pre\}^\{o\}\(a\),\\;\\mathit\{pre\}^\{e\}\(a\),\\;\\mathit\{eff\}^\{s\}\(a\),\\;\\mathit\{eff\}^\{e\}\(a\),\\;\\mathit\{dur\}\(a\)\\,\\rangle\(1\)where𝑝𝑟𝑒s​\(a\)\\mathit\{pre\}^\{s\}\(a\),𝑝𝑟𝑒o​\(a\)\\mathit\{pre\}^\{o\}\(a\),𝑝𝑟𝑒e​\(a\)\\mathit\{pre\}^\{e\}\(a\)⊆F∪X\\subseteq F\\cup Xare the*at\-start*,*over\-all*, and*at\-end*preconditions respectively,𝑒𝑓𝑓s​\(a\)\\mathit\{eff\}^\{s\}\(a\),𝑒𝑓𝑓e​\(a\)\\mathit\{eff\}^\{e\}\(a\)⊆F∪X\\subseteq F\\cup Xare the*at\-start*and*at\-end*effects, and𝑑𝑢𝑟⁡\(a\)∈ℝ\+\\mathit\{dur\}\(a\)\\in\\mathbb\{R\}^\{\+\}is the action duration\.

Temporal planning extends numeric planning by modeling actions as durative activities whose conditions and effects may occur at different points during execution\. At\-start preconditions must hold at the moment execution begins, over\-all preconditions must remain true throughout the open interval of the action’s duration, and at\-end preconditions must hold upon completion\. Effects are applied at their respective time points, modifying the state by adding and removing facts\. This enables planners to reason about overlapping actions, synchronization constraints, and time\-dependent resource usage\. Additionally, Timed Initial Literals \(TILs\) allow facts to change independently at predefined time points\.

The solution to a temporal planning task is a timed schedule of actions, i\.e\., a temporal plan \(Definition[5](https://arxiv.org/html/2608.20510#Thmdefinition5)\)\.

###### Definition 5\.

Atemporal planπt\\pi\_\{t\}for a temporal planning taskΠt\\Pi\_\{t\}is a timed schedule of durative actions represented as a tuple⟨\(t1:a1\),\(t2:a2\),…,\(tn:an\)⟩\\langle\(t\_\{1\}:a\_\{1\}\),\(t\_\{2\}:a\_\{2\}\),\.\.\.,\(t\_\{n\}:a\_\{n\}\)\\rangle, where eachti∈ℝ0\+t\_\{i\}\\in\\mathbb\{R\}^\{\+\}\_\{0\}is a time point of the start of some durative actionai∈Ada\_\{i\}\\in A\_\{d\}\. The scheduleπt\\pi\_\{t\}is valid iff all action preconditions are satisfied at their required time points, and the goal conditions are achieved upon completion of the schedule\.

Plan quality in temporal planning is most commonly measured by*makespan*\(Definition[6](https://arxiv.org/html/2608.20510#Thmdefinition6)\), the total time required to execute a schedule\.

###### Definition 6\.

Themakespanof a temporal planπt=⟨\(t1:a1\),\(t2:a2\),…,\(tn:an\)⟩\\pi\_\{t\}=\\langle\(t\_\{1\}\{:\}a\_\{1\}\),\(t\_\{2\}\{:\}a\_\{2\}\),\\dots,\(t\_\{n\}\{:\}a\_\{n\}\)\\rangleis the elapsed time between the start of its earliest action and the completion of its latest action, as specified in \([2](https://arxiv.org/html/2608.20510#S2.E2)\)\. A smaller makespan reflects a more temporally compact schedule with greater concurrency among actions\.

makespan⁡\(πt\)=max1≤i≤n⁡\(ti\+dur⁡\(ai\)\)−min1≤i≤n⁡\(ti\)\\mathrm\{makespan\}\(\\pi\_\{t\}\)\\;=\\;\\max\_\{1\\leq i\\leq n\}\\bigl\(t\_\{i\}\+\\mathrm\{dur\}\(a\_\{i\}\)\\bigr\)\\;\-\\;\\min\_\{1\\leq i\\leq n\}\(t\_\{i\}\)\(2\)

Flood response operations require synchronized activities with durations involving constrained time and resources, so temporal planning is the natural fit for this work\.

### 2\.2Planning Modeling Languages

Planning modeling languages specify planning domains and problem instances in terms that automated planners can process: defining actions, state variables, constraints, temporal properties, initial states, and goal conditions\. Early languages worked with propositional representations and instantaneous actions; modern ones also handle quantitative reasoning, temporal constraints, durative actions, and concurrency\. This work uses two temporal planning languages, PDDL and ANML, and the concepts from each that are relevant here are the following\.

#### 2\.2\.1The Planning Domain Definition Language

The Planning Domain Definition Language \(PDDL\) is a standardized formalism for modeling automated planning domains and problems\([4](https://arxiv.org/html/2608.20510#bib.bib14)\)\. It separates reusable domains containing typed predicates, functions, and parameterised action schemas from instance\-specific information such as the objects, the initial state, and the goal\. PDDL 2\.1 extends the classical propositional language with*numeric fluents*and*durative actions*\([3](https://arxiv.org/html/2608.20510#bib.bib11)\), enabling quantitative and temporal reasoning\.

A durative action in PDDL 2\.1 specifies a duration together with temporally annotated conditions and effects\. Three qualifiers locate these in time:at startconditions and effects apply at the instant execution begins,over allconditions must hold throughout the open interval of the action, andat endconditions and effects apply on completion\. The Temporal Fast Downward \(TFD\) planner used in our evaluation consumes PDDL 2\.1\.

#### 2\.2\.2The Action Notation Modeling Language

The Action Notation Modeling Language \(ANML\) is a high\-level formalism for modeling planning domains and problems\([14](https://arxiv.org/html/2608.20510#bib.bib13)\)\. Where PDDL is primarily propositional, ANML adopts a variable/value representation in which every variable is an implicit function of time, so that state transitions over an action’s execution are expressed directly on a timeline\. Types follow a single\-inheritance hierarchy and may carry member variables and constants\.

Conditions and effects are not separated by keywords but distinguished by their operators: relational operators \(e\.g\.==\) express conditions, while assignment and transition operators \(e\.g\.:=and:\-\>\) express effects\. Each condition and effect is scoped by a temporal qualifier relative to the action’sstartandendlandmarks, andalldenotes the whole execution window\. The Flexible Action and Planning Environment \(FAPE\) used in our evaluation consumes ANML\.

## 3Proposed Temporal Planning Framework

The proposed framework for flood\-response operations models disaster\-response activities as a temporal planning task involving heterogeneous response teams, transportation assets, operational priorities, and resource\-constrained logistics under time\-dependent execution\. Its objective is to generate temporally consistent schedules that coordinate rescue operations, medical assistance, civilian evacuation, and humanitarian supply distribution across geographically dispersed flood\-affected areas\. The framework comprises three main components: a*domain definition*that specifies the state representation, constraints, and durative actions of the flood\-response environment; an*instance formulation*that defines a specific disaster scenario through its initial and goal states; and*plan generation*, in which an automated temporal planner generates a valid execution schedule\. The remainder of this section describes each component\.

We use a compact illustrative scenario, presented in Figure[3](https://arxiv.org/html/2608.20510#S3.F3), as a running example throughout this section\. A single safe locationSSserves as a staging hub containing a transit vehicleTT, a freight vehicleFF, a rescue teamRR, a medical teamMM, and a stock of relief goods \(e\.g\.,food=k300\)\. From this safe hub, operations are carried out over two affected zones: ZoneAA\(priority 1\) and ZoneBB\(priority 2\)\. Each zone has associated evacuation and relief requirements\. A strict triage constraint is imposed through thepriorrelation: each response operation in ZoneAAmust be completed before the same operation in ZoneBBcan begin\. Vehicle\-specific travel times between the safe hub and affected zones are encoded as edge labels\. This compact instance captures all core structural elements of the domain: shared vehicles, competing zones, temporal routing constraints, and resource\-dependent service execution\.

SafeSSTransitVehicleTTFreightVehicleFFRescueTeamRRMedicalSupportTeamMMresource\_available\(food\)=k300ZoneAA– priority 1evac\_level=p60needs\_rescueneeds\_medical\_supportresource\_needed\(food\)=k200ZoneBB– priority 2evac\_level=p20T:2020,F:2525T:3030,F:4040prior\(serve first\)Figure 3:A compact flood\-response instance used as a running example\. A single safe locationSSstages a transit vehicleTT, a freight vehicleFF, a rescue teamRR, and a medical support teamMM, together with a stock of relief goods \(food=k300\)\. ZoneAAoutranks ZoneBBviaprior\. Edge labels give vehicle\-specific travel times\.### 3\.1Task Formulation

We present the proposed model using a propositional temporal\-planning formulation \(Definition[7](https://arxiv.org/html/2608.20510#Thmdefinition7)\), following the general formulation introduced in Definition[4](https://arxiv.org/html/2608.20510#Thmdefinition4)\. We first characterize the state space, then the action model, and finally the validity conditions a solution plan must satisfy\. The flood\-response planning task is stated as follows\.

###### Definition 7\.

Aflood\-response planning taskis a temporal planning problemΠf=⟨Ff,Xf,Afd,γf,If,Gf⟩\\Pi\_\{f\}=\\langle F\_\{f\},\\,X\_\{f\},\\,A\_\{f\}^\{d\},\\,\\gamma\_\{f\},\\,I\_\{f\},\\,G\_\{f\}\\rangledefined over a flood\-response domain, where:

- •FfF\_\{f\}is the finite set of grounded propositional facts over the predicate set𝒫\\mathcal\{P\}, specified in \([3](https://arxiv.org/html/2608.20510#S3.E3)\)\. 𝒫=\{prior,vehicle\_at,team\_at,team\_in\_vehicle,evac\_level,needs\_rescue,resource\_needed,needs\_medical\_support,evacuating,resource\_available,cargo\_loaded,cargo\_full,route\_accessible,valid\_evac\_step,valid\_supply\_step\}\\mathcal\{P\}=\\left\\\{\\begin\{aligned\} &\\texttt\{prior\},\\texttt\{vehicle\\\_at\},\\texttt\{team\\\_at\},\\\\ &\\texttt\{team\\\_in\\\_vehicle\},\\texttt\{evac\\\_level\},\\\\ &\\texttt\{needs\\\_rescue\},\\texttt\{resource\\\_needed\},\\\\ &\\texttt\{needs\\\_medical\\\_support\},\\texttt\{evacuating\},\\\\ &\\texttt\{resource\\\_available\},\\texttt\{cargo\\\_loaded\},\\\\ &\\texttt\{cargo\\\_full\},\\texttt\{route\\\_accessible\},\\\\ &\\texttt\{valid\\\_evac\\\_step\},\\texttt\{valid\\\_supply\\\_step\}\\end\{aligned\}\\right\\\}\(3\)
- •XfX\_\{f\}is the finite set of ground numeric fluents \(all*rigid*, i\.e\. never modified by an action effect\) over the set𝒳\\mathcal\{X\}=\{travel\_time,team\_size,person\_count\_diff,package\_count\_diff\}\.
- •AfdA\_\{f\}^\{d\}is the finite set of ground durative actions over the set of nine action schemas𝒜\\mathcal\{A\}, specified in \([4](https://arxiv.org/html/2608.20510#S3.E4)\), instantiated over the typed objects of a given problem instance\. 𝒜=\{BoardTeam,DisembarkTeam,MoveVehicle,Evacuate,DisembarkEvacuatedPeople,RescueAffectedPeople,LoadResource,DeliverResource,ProvideMedicalSupport\}\\mathcal\{A\}=\\left\\\{\\begin\{aligned\} &\\textsc\{BoardTeam\},\\textsc\{DisembarkTeam\},\\\\ &\\textsc\{MoveVehicle\},\\textsc\{Evacuate\},\\\\ &\\textsc\{DisembarkEvacuatedPeople\},\\\\ &\\textsc\{RescueAffectedPeople\},\\\\ &\\textsc\{LoadResource\},\\textsc\{DeliverResource\},\\\\ &\\textsc\{ProvideMedicalSupport\}\\end\{aligned\}\\right\\\}\(4\)
- •γf\\gamma\_\{f\}is the action cost function, whereγf=1\\gamma\_\{f\}=1for alla∈Afda\\in A\_\{f\}^\{d\}\.
- •If⊆Ff∪XfI\_\{f\}\\subseteq F\_\{f\}\\cup X\_\{f\}is the initial state, grounded over𝒫∪𝒳\\mathcal\{P\}\\cup\\mathcal\{X\}to describe the initial configuration of vehicles, teams, routes, operational requirements, and milestone levels for a given flood scenario\.
- •Gf⊆FfG\_\{f\}\\subseteq F\_\{f\}is the goal condition grounded over𝒫\\mathcal\{P\}, as formalized in \([5](https://arxiv.org/html/2608.20510#S3.E5)\)\. Gf=\{¬needs\_rescue​\(l\),¬evacuating​\(v\),¬needs\_medical\_support​\(l\),evac\_level​\(l,p0\),resource\_needed​\(l,r,k0\)\}G\_\{f\}=\\left\\\{\\begin\{aligned\} &\\neg\\texttt\{needs\\\_rescue\}\(l\),\\neg\\texttt\{evacuating\}\(v\),\\\\ &\\neg\\texttt\{needs\\\_medical\\\_support\}\(l\),\\\\ &\\texttt\{evac\\\_level\}\(l,\\texttt\{p0\}\),\\\\ &\\texttt\{resource\\\_needed\}\(l,r,\\texttt\{k0\}\)\\end\{aligned\}\\right\\\}\(5\)for alll∈ℒAl\\in\\mathcal\{L\}\_\{A\},r∈ℛr\\in\\mathcal\{R\}, andv∈𝒱Tv\\in\\mathcal\{V\}\_\{T\}, whereℒA\\mathcal\{L\}\_\{A\}denotes the set of affected locations,ℛ\\mathcal\{R\}is the set of resource types,𝒱T\\mathcal\{V\}\_\{T\}is the set of transit vehicles, andp0andk0are the base milestone values denoting full evacuation and full resource satisfaction\.

### 3\.2Modeling Decisions

The following modeling decisions are intended to balance representational expressiveness with planning tractability and motivate the predicates and action schemas introduced in the following subsections\.

##### Symbolic milestones instead of numeric fluents\.

Evacuation and supply progress are represented using ordered symbolic milestones rather than continuous numeric fluents\. This design avoids large numeric search spaces while preserving multi\-trip operational behavior and capacity\-aware progress tracking\.

##### Priority\-constrained execution\.

Area\-specific priorities are encoded directly within the preconditions of rescue, medical support, evacuation, and resource\-delivery actions\. Consequently, every generated plan automatically respects operational priorities without requiring additional validation or post\-processing\.

##### Temporal resource locking\.

Vehicles and teams are treated as temporally exclusive resources\. During transportation, they are temporarily unavailable for other actions, thereby preventing conflicting concurrent assignments\.

##### Native concurrency\.

The temporal\-planning formalism naturally permits concurrent execution of independent rescue, medical, transportation, and logistics operations when resource and ordering constraints are satisfied\.

### 3\.3World Representation

This subsection defines the representational structure of the planning domain, including the type hierarchy, the state predicates, and the symbolic milestone system used to model operational progress\.

#### 3\.3\.1Type System

The proposed domain uses a typed object hierarchy to organize operational entities involved in planning\. The domain is defined over four root types:Location,Vehicle,Team, andResource\. These root types are further specialized, as presented in \([6](https://arxiv.org/html/2608.20510#S3.E6)\), to capture the operational structure of flood\-response activities as follows:

Location\\displaystyle\\texttt\{Location\}⊇\{AffectedLocation,SafeLocation\}\\displaystyle\\supseteq\\\{\\texttt\{AffectedLocation\},\\texttt\{SafeLocation\}\\\}\(6\)Vehicle\\displaystyle\\texttt\{Vehicle\}⊇\{TransitVehicle,FreightVehicle\}\\displaystyle\\supseteq\\\{\\texttt\{TransitVehicle\},\\texttt\{FreightVehicle\}\\\}Team\\displaystyle\\texttt\{Team\}⊇\{RescueTeam,MedicalSupportTeam\}\\displaystyle\\supseteq\\\{\\texttt\{RescueTeam\},\\texttt\{MedicalSupportTeam\}\\\}- •Safe areas and affected zones:TheLocationtype represents all areas within the scenario and is specialized into two distinct subtypes:AffectedLocationandSafeLocation\.
- •Transportation Assets:TheVehicletype models transportation assets and is specialized into two subtypes:TransitVehiclefor personnel and evacuee transport andFreightVehiclefor relief cargo delivery\.
- •Response Teams:TheTeamtype represents deployable response units and is partitioned into two subtypes:RescueTeamandMedicalSupportTeam\.
- •Consumable Resources:Resourcedenotes consumable humanitarian supplies such as food, water, and medical kits\. Its dynamic quantities are represented through symbolic milestones and state predicates across locations\.

A distinguished constantNULLrepresents temporary unassignment of entities during transitional operations such as movement, boarding, loading, and unloading\.

#### 3\.3\.2State Representation

The predicates collectively define the operational world state of the flood\-response environment\. They are organized into spatial configuration, vehicle status, location requirements, operational progress, and rigid constants\.

- •Spatial configuration:The spatial information of vehicles and teams is captured byvehicle\_at\(v,l\),team\_at\(t,l\), andteam\_in\_vehicle\(t,v\), denoting vehicle locations, team deployment, and team boarding status, respectively\.
- •Vehicle status:Vehicle operations are captured byevacuating\(v\),route\_accessible\(v,l1,l2\),cargo\_full\(v\), andcargo\_loaded\(v,r\), indicating evacuation activity, cargo status, and route feasibility\.
- •Location requirements and priority:Operational requirements are expressed usingneeds\_rescue\(l\)andneeds\_medical\_support\(l\)\. A priority relationprior\(l,pl\)enforces that locationplmust be served beforel, restricting concurrent servicing of lower\-priority areas\.
- •Operational progress and milestones:Evacuation and supply delivery progress are modeled using ordered symbolic milestones rather than numeric fluents\. For instance, two ordered domains can be defined:PersonCountwithp60≻p40≻p20≻p0\\texttt\{p60\}\\succ\\texttt\{p40\}\\succ\\texttt\{p20\}\\succ\\texttt\{p0\}, andPackageCountwithk200≻k100≻k0\\texttt\{k200\}\\succ\\texttt\{k100\}\\succ\\texttt\{k0\}, wherep0andk0denote goal satisfaction\. Three predicates operate overevac\_level\(l,p\)\(remaining evacuees\),resource\_needed\(l,r,k\)\(remaining demand\), andresource\_available\(l,r,k\)\(available stock at safe locations\)\. Each relevant action advances the corresponding milestone toward its terminal\.
- •Constants:A set of numeric fluents governs action durations and remains fixed for each instance\. Numeric fluentteam\_size\(t\)defines team’s boarding and disembarkation durations,travel\_time\(v,l1,l2\)defines vehicle movement durations, whileperson\_count\_diff\(p\_1,p\_2\)andpackage\_count\_diff\(k\_1,k\_2\)scale evacuation and delivery durations according to corresponding workload\. Vehicle’s capacity constraints are enforced viavalid\_evac\_step\(v,p\_1,p\_2\)andvalid\_supply\_step\(v,k\_1,k\_2\), which restrict allowed milestone transitions\.

### 3\.4Action Schemas

The proposed domain is defined over nine durative actions\. A set of preconditions and effects specifies each action, annotated using temporal qualifiers that indicate when they apply:*at start*\(execution onset\),*over all*\(maintained throughout execution\), and*at end*\(completion\)\. The complete action schemas are presented in Tables[1](https://arxiv.org/html/2608.20510#S3.T1)–[3](https://arxiv.org/html/2608.20510#S3.T3)\.

#### 3\.4\.1Transport Actions

The transport actions,BoardTeam,DisembarkTeam, andMoveVehicle\(Table[1](https://arxiv.org/html/2608.20510#S3.T1)\), govern the movement of teams and vehicles across the locations\.BoardTeamandDisembarkTeamare symmetric operations that transfer a team into and out of a vehicle while maintaining the vehicle’s location as an invariant throughout execution\. Both actions scale in duration withteam\_size\.

MoveVehiclemodels physical relocation between locations and requires route accessibility between origin and destination\. The vehicle remains in transit for the entire duration, and travel time is parameterized by the specific vehicle and route\. Multi\-hop travel is achieved by consecutive move actions through intermediate locations\.

Table 1:Transport action schemas\. Parameter shorthands:ttdenotes a team;ll,f​r​o​mfrom, andt​otodenote locations;vTv\_\{T\}denotes a transit vehicle; andTTdenotes a vehicle\.
#### 3\.4\.2Response Actions

Response actions areRescueAffectedPeopleandProvideMedicalSupport\(Table[2](https://arxiv.org/html/2608.20510#S3.T2)\)\. These actions are executed on\-site by dedicated teams and require that the corresponding team remains present throughout execution as an*over all*invariant\. Both actions are governed by a shared triage constraint expressed through thepriorpredicate, which prevents service at a location unless all higher\-priority locations have already been fully serviced for the same task type\. For instance, ZoneAAmust be cleared before ZoneBBin Figure[3](https://arxiv.org/html/2608.20510#S3.F3)\. Each action has a fixed duration of constant time units and, upon completion, removes the corresponding demand predicate at the location\. Because rescue and medical teams are distinct resources, these actions may be executed concurrently at the same location when available\.

Table 2:Response action schemas\. Parameter shorthands:lAl\_\{A\}denotes an affected location;p​lpldenotes a higher\-priority affected location; andCCdenotes a constant value\.Table 3:Logistics action schemas\. Parameter shorthands:lAl\_\{A\}denotes an affected location;vTv\_\{T\}denotes a transit vehicle;p​fpfdenotes the initial evacuation milestone;p​tptdenotes the final evacuation milestone;p​lpldenotes a higher\-priority affected location thanlAl\_\{A\};lSl\_\{S\}denotes a safe location;rrdenotes a resource;vFv\_\{F\}denotes a freight vehicle;k​fkfdenotes the initial resource milestone;k​tktdenotes the final resource milestone; andCCdenotes a constant value\.ActionPreconditionsEffects\[Duration\]ann\.predicate\(s\)ann\.predicate\(s\)Evacuate\(lA,vT,p​f,p​t,p​l\)\(l\_\{A\},v\_\{T\},pf,pt,pl\)Startprior\(lA,p​l\)\(l\_\{A\},pl\),
evac\_level\(p​l,p0\)\(pl,\\texttt\{p0\}\),
evac\_level\(lA,p​f\)\(l\_\{A\},pf\),
¬\\negevacuating\(vT\)\(v\_\{T\}\)Start†\\textit\{Start\}^\{\\dagger\}¬\\negevac\_level\(lA,p​f\)\(l\_\{A\},pf\),
evac\_level\(lA,p​t\)\(l\_\{A\},pt\),
evacuating\(vT\)\(v\_\{T\}\)\[person\_count\_diff\(p​f,p​t\)\(pf,pt\)\]Over\-allvehicle\_at\(vT,lA\)\(v\_\{T\},l\_\{A\}\),
valid\_evac\_step\(vT,p​f,p​t\)\(v\_\{T\},pf,pt\)––DisembarkEvacuated\-People\(vT,lS\)\(v\_\{T\},l\_\{S\}\)Startevacuating\(vT\)\(v\_\{T\}\)––\[C\]Over\-allvehicle\_at\(vT,lS\)\(v\_\{T\},l\_\{S\}\)End¬\\negevacuating\(vT\)\(v\_\{T\}\)LoadResource\(r,l,vF,k​f,k​t\)\(r,l,v\_\{F\},kf,kt\)Startresource\_available\(l,r,k​f\)\(l,r,kf\),
¬\\negcargo\_loaded\(vF,r\)\(v\_\{F\},r\),
¬\\negcargo\_full\(vF\)\(v\_\{F\}\)Start¬\\negresource\_available\(l,r,k​f\)\(l,r,kf\),
resource\_available\(l,r,k​t\)\(l,r,kt\)\[package\_count\_diff\(k​f,k​t\)\(kf,kt\)\]Over\-allvehicle\_at\(vF,l\)\(v\_\{F\},l\),
valid\_supply\_step\(vF,k​f,k​t\)\(v\_\{F\},kf,kt\)Endcargo\_loaded\(vF,r\)\(v\_\{F\},r\),
cargo\_full\(vF\)\(v\_\{F\}\)DeliverResource\(r,lA,vF,k​f,k​t,p​l\)\(r,l\_\{A\},v\_\{F\},kf,kt,pl\)Startprior\(lA,p​l\)\(l\_\{A\},pl\),
evac\_level\(p​l,p0\)\(pl,\\texttt\{p0\}\),
resource\_needed\(p​l,r,k0\)\(pl,r,\\texttt\{k0\}\),
resource\_needed\(lA,r,k​f\)\(l\_\{A\},r,kf\),
cargo\_loaded\(vF,r\)\(v\_\{F\},r\)Start¬\\negresource\_needed\(lA,r,k​f\)\(l\_\{A\},r,kf\)\[package\_count\_diff\(k​f,k​t\)\(kf,kt\)\]Over\-allvehicle\_at\(vF,lA\)\(v\_\{F\},l\_\{A\}\),
valid\_supply\_step\(vF,k​f,k​t\)\(v\_\{F\},kf,kt\)Endresource\_needed\(lA,r,k​t\)\(l\_\{A\},r,kt\),
¬\\negcargo\_loaded\(vF,r\)\(v\_\{F\},r\),
¬\\negcargo\_full\(vF\)\(v\_\{F\}\)†Effect applied at action start, enabling concurrent scheduling\.
#### 3\.4\.3Logistics Actions

Logistics actions \(Table[3](https://arxiv.org/html/2608.20510#S3.T3)\) implement evacuation and supply operations across the same spatial network under shared priority constraints\.Evacuatemoves civilians in discrete capacity\-bounded steps governed byvalid\_evac\_step, updating evacuation milestones and marking vehicles as actively evacuating\. To enable concurrency, key milestone updates occur at action start\.DisembarkEvacuatedPeopledrops off evacuees at safe locations and releases vehicles for reuse\.

Supply operations are handled byLoadResourceandDeliverResource, which shuttle goods between depots and affected zones while updating resource demand milestones\. Both evacuation and supply actions use discretized progress variables rather than arithmetic quantities, ensuring compatibility with symbolic planning representations and enabling repeated execution until completion\.

### 3\.5Dependency Among Action Schemas

The actions form a structured causal network in which the effects of one action establish the preconditions of others\. This dependency structure is summarized in Figure[4](https://arxiv.org/html/2608.20510#S3.F4)\. Solid arrows denote causal dependencies, where the source action produces a fact required by the target action\. Nonetheless, the target action need not depend on the source action in every execution, since the required fact may already hold in the initial configuration\. Dashed arrows represent priority constraints that prevent execution in lower\-priority zones until higher\-priority zones are served by the same action\.

BoardTeamMoveVehicleDisembarkTeamEvacuateDisembarkEvacuatedPeopleRescueAffectedPeopleProvideMedicalSupportLoadResourceDeliverResourcevehicle at sourcevehicle at dest\.rescue teamat zonemedical teamat zoneteam in vehicleteam on groundhigher priority firsthigher priority firsthigher priority firsthigher priority firstvehicle emptyvehicle evacuatingvehicle at zonevehicle at safe areavehicle at depotcargo unloadedcargo loadedvehicle at zoneTransportResponseLogisticsCausal dependencyPriority constraintFigure 4:Dependency among the actions\. Transport actions are shown in plain white, response actions in light gray, and logistics actions with a diagonal hatch pattern\. Solid arrows indicate causal dependencies; however, the required fact may also be available in the initial configuration\. Dashed arrows indicate priority constraints\.Three interacting operational cycles emerge from this structure\.

- •Deployment Cycle: moves teams from the safe hub into affected zones via vehicle boarding, movement, and disembarkation, enabling on\-site response\.
- •Evacuation Cycle: alternates between loading civilians, transporting them to safety, and disembarking them at secure locations\.
- •Supply Cycle: manages the flow of relief goods from depots to affected zones through repeated loading and delivery operations\.

TheMoveVehicleaction participates in all three cycles and therefore constitutes the primary shared scheduling resource in the domain\. Priority constraints are enforced across response and logistics actions, ensuring strict triage ordering across zones\.

### 3\.6Instance Formulation

The domain specification defines the available object types, predicates, and action schemas, but it does not determine which concrete entities participate in a particular disaster\-response scenario\. This information is provided by a problem instance, which specifies the initial state \(IfI\_\{f\}\) and goal condition \(GfG\_\{f\}\) of the planning task \(Πf\\Pi\_\{f\}\) in Definition[7](https://arxiv.org/html/2608.20510#Thmdefinition7)\.

A problem instance instantiates the domain by declaring a finite set of objects, assigning values to all static predicates and lookup relations \(e\.g\., route accessibility and travel times\), and defining the initial distribution of resources, vehicles, response teams, and disaster\-response demands\. It also specifies the desired goal condition, thereby determining the objectives that must be achieved by a valid plan\.

Table[4](https://arxiv.org/html/2608.20510#S3.T4)specifies the planning problem corresponding to the representative flood\-response scenario in Figure[3](https://arxiv.org/html/2608.20510#S3.F3), instantiating the objects, initial state \(IfI\_\{f\}\), and goal condition \(GfG\_\{f\}\) of Definition[7](https://arxiv.org/html/2608.20510#Thmdefinition7)\.

Table 4:Planning task for the instance of Figure[3](https://arxiv.org/html/2608.20510#S3.F3), instantiating the objects, initial state \(IfI\_\{f\}\), and goal \(GfG\_\{f\}\) of Definition[7](https://arxiv.org/html/2608.20510#Thmdefinition7)\.The goal condition \(GfG\_\{f\}\) is achieved only when both zones have been fully evacuated \(p0\), all rescue, medical, and resource requirements in Zone \(A\) have been fulfilled, and no transit vehicle remains engaged in an ongoing evacuation operation\. Together, the domain specification and a problem instance define a temporal planning task \(Πf\\Pi\_\{f\}\) that can be solved directly by an automated planner\.

### 3\.7Plan Validity

A solution toΠf\\Pi\_\{f\}is a valid temporal planπf=⟨\(ti:ai\)⟩i=1n\\pi\_\{f\}=\\langle\(t\_\{i\}:a\_\{i\}\)\\rangle\_\{i=1\}^\{n\}in the sense of Definition[5](https://arxiv.org/html/2608.20510#Thmdefinition5): it must be temporally consistent, satisfy each action’s*at\-start*,*over\-all*, and*at\-end*conditions at the corresponding instants, and the state reached after executing all actions must satisfy the goalGfG\_\{f\}of Definition[7](https://arxiv.org/html/2608.20510#Thmdefinition7)\. Beyond these requirements, the flood\-response task imposes one domain\-specific condition,*priority ordering*\. For every pair of affected locationsℓ,ℓ′\\ell,\\ell^\{\\prime\}withprior​\(ℓ,ℓ′\)∈If\\texttt\{prior\}\(\\ell,\\ell^\{\\prime\}\)\\in I\_\{f\}, no response action may start atℓ\\ellwhile the corresponding requirement at the higher\-priority locationℓ′\\ell^\{\\prime\}remains outstanding\. Because this is enforced as a hard*at start*precondition in every affected action schema \(Tables[2](https://arxiv.org/html/2608.20510#S3.T2)and[3](https://arxiv.org/html/2608.20510#S3.T3)\) rather than as an optimisation objective, every admissible plan satisfies it by construction: no planner, regardless of its search strategy, can return a valid plan that violates it, and no post\-processing is required\.

## 4Dynamic Replanning

Our flood response formulation in Definition[7](https://arxiv.org/html/2608.20510#Thmdefinition7)assumes that the instance has complete and correct information about the world\. In practical flood\-response scenarios, critical information such as route accessibility, infrastructure status, and the number of stranded individuals may not be known a priori\. Thus, plans generated prior to deployment may become partially invalid as new information emerges during execution\. To address this operational reality, the proposed framework supports dynamic replanning\. Whenever a discrepancy between the planner’s model and the actual environment is revealed, the current planning problem is updated, and a new schedule is generated from the latest observable state\. This enables the framework to adapt ongoing operations while preserving actions that have already been executed\.

Algorithm 1Dynamic Replanning Procedure1:Original Instance

ℐ\\mathcal\{I\}, Original Plan

π0\\pi\_\{0\}, Surprise Time

TT, Fact Changes

𝒞\\mathcal\{C\}, Goal Changes

𝒢\\mathcal\{G\}, Planner

𝒫\\mathcal\{P\}
2:Replanned Schedule

πr\\pi\_\{r\}
3:

S←ParseInitialState​\(ℐ\)S\\leftarrow\\textsc\{ParseInitialState\}\(\\mathcal\{I\}\)
4:

π0<←SortByTime\(a∈π0∣a\.time<T\)\\pi\_\{0\}^\{<\}\\leftarrow\\textsc\{SortByTime\}\(\{a\\in\\pi\_\{0\}\\mid a\.\\text\{time\}<T\}\)
5:⊳\\trianglerightPhase 1: Reconstruct execution state

6:foreachaction

a∈π0<a\\in\\pi\_\{0\}^\{<\}do

7:

S←ApplyActionEffects​\(S,a\)S\\leftarrow\\textsc\{ApplyActionEffects\}\(S,a\)
8:endfor

9:⊳\\trianglerightPhase 2: Incorporate newly observed information

10:

S←UpdateState​\(S,𝒞\)S\\leftarrow\\textsc\{UpdateState\}\(S,\\mathcal\{C\}\)
11:

G←UpdateGoals\(ℐ\.goal,𝒢\)G\\leftarrow\\textsc\{UpdateGoals\}\(\\mathcal\{I\}\.\\text\{goal\},\\mathcal\{G\}\)
12:⊳\\trianglerightPhase 3: Construct replanning problem

13:

ℐ′\.header←ℐ\.header\\mathcal\{I\}^\{\\prime\}\.\\text\{header\}\\leftarrow\\mathcal\{I\}\.\\text\{header\}
14:

ℐ′\.objects←ℐ\.objects\\mathcal\{I\}^\{\\prime\}\.\\text\{objects\}\\leftarrow\\mathcal\{I\}\.\\text\{objects\}
15:

ℐ′\.init←ConstructInitFacts​\(S\)\\mathcal\{I\}^\{\\prime\}\.\\text\{init\}\\leftarrow\\textsc\{ConstructInitFacts\}\(S\)
16:

ℐ′\.goal←G\\mathcal\{I\}^\{\\prime\}\.\\text\{goal\}\\leftarrow G
17:⊳\\trianglerightPhase 4: Generate adapted schedule

18:

πr←Plan​\(𝒫,ℐ′\)\\pi\_\{r\}\\leftarrow\\textsc\{Plan\}\(\\mathcal\{P\},\\mathcal\{I\}^\{\\prime\}\)
19:return

πr\\pi\_\{r\}

Algorithm[1](https://arxiv.org/html/2608.20510#alg1)represents the replanning process\. Given an original planning instanceℐ\\mathcal\{I\}and its corresponding planπ0\\pi\_\{0\}, a surprise occurring at timeTTtriggers state reconstruction by simulating all actions whose start times precedeTT\. Newly observed facts and revised goals are then incorporated into the reconstructed state to produce an updated planning instance\. Finally, the temporal planner is invoked on the updated instance to generate a revised scheduleπr\\pi\_\{r\}that reflects the newly observed conditions\.

To evaluate the scalability of the proposed domain, we generated benchmarks of increasing complexity\. The benchmark\-generation method and complexity characteristics are described in the following section\.

## 5Benchmark Generation and Replanning Setup

This section describes the construction of both the primary benchmark used for evaluating planning performance and the replanning benchmark used to assess adaptability under dynamic environmental changes\.

### 5\.1Primary Benchmark Generation

We design a problem benchmark consisting of 50 problem instances to evaluate the scalability, runtime performance, and plan quality of the proposed domain\. Each instance is encoded in PDDL 2\.1 and ANML to evaluate across fundamentally different temporal planning paradigms: PDDL\-based heuristic search planners and ANML\-based timeline\-centric planners\.

The instances are organized into five tiers of increasing complexity, as summarized in Table[5](https://arxiv.org/html/2608.20510#S5.T5)\. Each tier consists of 10 problems\. All the instances from 1 to 50 correspond to an increase in the complexity of the flood instance scenario\. The number of grounded action spaces reaches as large as 84,579 actions\. This reflects the combinatorial nature of the binding problem\. As the number of agents and locations increases, the number of possible action groundings grows multiplicatively rather than additively\.

Table 5:Characteristics of instances grouped by complexity tier; each tier includes 10 problem instances, for a total of 50\.
### 5\.2Replanning Benchmark Generation

To evaluate the effectiveness of the proposed replanning approach, we generated systematically perturbed instances from the PDDL instances of the primary benchmark\. We model a single re\-planning step as the regeneration of a plan from the world state observed at the moment a discrepancy is revealed\.

#### 5\.2\.1Surprise Time Selection and Perturbation Types

Letπ0\\pi\_\{0\}denote the original plan, and the*surprise time*TTis fixed at the start time of a random action near the midpoint of the plan\. Placing the surprise at the midpoint ensures that a substantial portion of the plan has already been committed before the disruption occurs, while enough remains for the perturbation to demand meaningful recovery\. One of two perturbation types is injected into each instance to trigger the need for re\-planning:

- •Route Blockage:A route\-accessibility fact is removed for all vehicles\. Before committing the removal, a reachability check verifies that everyAffectedLocationremains reachable from at least oneSafeLocationin the residual undirected graph\. Instances where blocking would disconnect the graph fall back to the evacuee increase perturbation\.
- •Evacuee Increase:Theevac\_levelof a randomly affected zone is raised to a randomly selected, strictly higher level drawn from the set of evacuation milestones\. The goal condition is modified to require the zone to reachp0\.

### 5\.3Replanning Instance Preparation

We only used 49 solved instances from the primary PDDL benchmark for the replanning experiment\. Among those, odd\-indexed instances are selected for the route blockage perturbation strategy, while even\-indexed instances are selected for the evacuee increase perturbation strategy\. For each instance from the primary PDDL benchmark, Algorithm[2](https://arxiv.org/html/2608.20510#alg2)is applied along with the corresponding plan, random surprise time, and changes induced by the selected perturbation\. One odd\-indexed instance failed the required connectivity check and was reclassified as an evacuee increase, yielding a final distribution of 25 evacuee increase and 24 route blockage perturbations\.

Algorithm 2Replanning Instance Generation1:Instance

ℐ\\mathcal\{I\}, Original plan

π0\\pi\_\{0\}, surprise time function

𝒯⁡\(⋅\)\\mathcal\{T\}\(\\cdot\), perturbations

𝒫\\mathcal\{P\}
2:Replanning instance

ℐ′\\mathcal\{I\}^\{\\prime\}
3:

T←𝒯⁡\(π0\)T\\leftarrow\\mathcal\{T\}\(\\pi\_\{0\}\)⊳\\trianglerightSelect surprise time near plan midpoint

4:

S←ReconstructState​\(ℐ,π0,T\)S\\leftarrow\\textsc\{ReconstructState\}\(\\mathcal\{I\},\\pi\_\{0\},T\)
5:

p←Sample​\(𝒫\)p\\leftarrow\\textsc\{Sample\}\(\\mathcal\{P\}\)⊳\\trianglerightSelect perturbation type

6:if

p=Route Blockagep=\\text\{Route Blockage\}then

7:

S←RemoveRouteFacts​\(S\)S\\leftarrow\\textsc\{RemoveRouteFacts\}\(S\)
8:ifdisconnected\(

SS\)then

p←Evacuee Increasep\\leftarrow\\text\{Evacuee Increase\}
9:endif

10:if

p=Evacuee Increasep=\\text\{Evacuee Increase\}then

11:

S←IncreaseEvacuationDemand​\(S\)S\\leftarrow\\textsc\{IncreaseEvacuationDemand\}\(S\)
12:

G←UpdateGoal\(ℐ\.G\)G\\leftarrow\\textsc\{UpdateGoal\}\(\\mathcal\{I\}\.G\)
13:else

14:

G←ℐ\.GG\\leftarrow\\mathcal\{I\}\.G
15:endif

16:

ℐ′←ConstructInstance​\(S,G\)\\mathcal\{I\}^\{\\prime\}\\leftarrow\\textsc\{ConstructInstance\}\(S,G\)
17:return

ℐ′\\mathcal\{I\}^\{\\prime\}

## 6Experimental Results and Analysis

This section evaluates the results of two automated planners on both the primary benchmark and the replanning benchmark of the proposed domain\. The two planners are FAPE and TFD\. The evaluation addresses several questions concerning both initial plan generation and plan adaptation during execution: i\) How reliably does each planner find solutions across instances of increasing complexity? ii\) When both planners succeed, how do the resulting plans compare in quality, both in terms of the number of steps and the total time required to execute them? iii\) How does each planner’s runtime grow as the problems get larger, and at what point does growth become impractical? iv\) When unexpected changes occur during execution, how much effort is required to revise existing plans, and how does the quality of the plans differ? This section addresses the findings\.

### Evaluation Metrics

Three standard metrics are used in the primary evaluation: Coverage, Runtime, and Plan quality\.

- •Coverageis defined as the fraction of benchmark instances for which the planner returns a valid plan within the time limit\.
- •Runtimeis the time from the start of the search until the planner returns a result, measured in seconds\.
- •Plan qualityis assessed along two dimensions:*plan length*and*makespan*\. Plan length is the number of individual actions in the returned plan, and makespan \(Definition[6](https://arxiv.org/html/2608.20510#Thmdefinition6)\) is the total time required to execute it\.

Letπ0<\\pi\_\{0\}^\{<\}denote the subsequence ofπ0\\pi\_\{0\}containing all actions with start time<T<T, andπr\\pi\_\{r\}denote the plan produced for the corresponding re\-planning instance, then–

- •Mr=makespan⁡\(π0<\)\+makespan⁡\(πr\)M\_\{r\}=\\mathrm\{makespan\}\(\\pi\_\{0\}^\{<\}\)\+\\mathrm\{makespan\}\(\\pi\_\{r\}\):*Total replan makespan*, combining the makespan already spent beforeTTwith the planπr\\pi\_\{r\}’s own makespan\.
- •Δ​M=\(Mr−M0\)/M0\\Delta M=\(M\_\{r\}\-M\_\{0\}\)/M\_\{0\}:*Makespan change*relative to the original plan’s makespanM0=makespan⁡\(π0\)M\_\{0\}=\\mathrm\{makespan\}\(\\pi\_\{0\}\)\.
- •Δ​\|π\|\\Delta\|\\pi\|:*Plan\-length change*, comparing the length ofπ0\\pi\_\{0\}against the combined length of the committed pre\-surprise actions \(π0<\\pi\_\{0\}^\{<\}\) and the planπr\\pi\_\{r\}\.
- •rrtr\_\{\\mathrm\{rt\}\}:*Runtime ratio*, re\-plan time divided by original planning time\.

The experiments were conducted on a machine equipped with a 12th Gen Intel Core i7\-12700 CPU, 16GB of 3200 MT/s RAM, and an M\.2 NVMe SSD, running Ubuntu 24\.04 LTS\. Both planners were run with a maximum time limit of 3,600 seconds\. An instance is counted as solved if the planner returns a valid plan within the time limit\.

### 6\.1Results on Primary Benchmark

Planners’ coverage and runtimes are summarized in Table[6](https://arxiv.org/html/2608.20510#S6.T6), clustered by tiers\.

Table 6:Planner coverage and runtime statistics by complexity\. Solved refers to instances solved within the time limit of 3,600 seconds\.Overall, TFD finds solutions faster than FAPE across tiers, and its runtime grows far more slowly as problem size increases\. Figure[5](https://arxiv.org/html/2608.20510#S6.F5)visualizes the cumulative coverage curve\. The TFD’s coverage reaches 98% well before the 20\-second mark\. The FAPE’s curve grows more slowly, plateauing at 86% instances around 2,430 seconds\.

10−310^\{\-3\}10−210^\{\-2\}10−110^\{\-1\}10010^\{0\}10110^\{1\}10210^\{2\}10310^\{3\}10410^\{4\}002020404060608080100100Runtime \(s\)Coverage \(%\)TFD \(PDDL\)FAPE \(ANML\)Figure 5:Percentage of instances solved \(coverage\) within a given runtime\. TFD achieves coverage of 98% within 19\.583 seconds, while FAPE plateaus at 86%\.Figure[6](https://arxiv.org/html/2608.20510#S6.F6)shows the comparison between the planners’ runtimes on the 42 instances that both solved, on a log\-log scale, with points differentiated by tiers\. The dashed diagonal line represents equal runtime\. Every point in this plot lies above the diagonal, which confirms that TFD is consistently faster\. This difference is not surprising based on how these two planners work\. TFD’s heuristic\-based forward search leads toward the goal faster\. In contrast, the cost of FAPE’s maintaining a constraint network and propagating temporal and causal constraints grows with the size of the action space\.

10−310^\{\-3\}10−210^\{\-2\}10−110^\{\-1\}10010^\{0\}10110^\{1\}10−110^\{\-1\}10010^\{0\}10110^\{1\}10210^\{2\}10310^\{3\}TFD Runtime \(s\)FAPE Runtime \(s\)Equal runtimeTier 1Tier 2Tier 3Tier 4Tier 5Figure 6:Log\-log scatter plot of runtime for the instances solved by both planners; shapes distinguish complexity tiers\. Points above the dashed diagonal indicate cases where FAPE is slower than TFD\.Coverage and runtime do not directly reflect the quality of the generated plans\. Table[7](https://arxiv.org/html/2608.20510#S6.T7)presents the distribution of plan quality in terms of the plan length and makespan across the solved instances\. FAPE produces substantially shorter plans with a median of 39 steps, compared to TFD’s median of 57, consistent with FAPE’s planning approach\. However, plan length is a somewhat coarse quality measure\. A plan with*n*steps is not worse than a shorter one if it executes steps concurrently, resulting in a smaller makespan\.

Table 7:Plan quality comparison over the instances solved by planners\. Plan Length denotes the number of plan steps, and Makespan denotes the total temporal span of execution, with smaller values indicating increased parallelism\.Makespan provides a more operationally meaningful measure, as it captures the total duration of execution under concurrency\. Figure[7](https://arxiv.org/html/2608.20510#S6.F7)plots the FAPE makespan against the TFD’s for all the jointly solved instances, with the diagonal line representing equal makespan\. It shows a tendency for FAPE’s makespans to be usually higher than TFD’s\.

002002004004006006008008001,0001\{,\}0001,2001\{,\}2001,4001\{,\}4001,6001\{,\}6001,8001\{,\}8002002004004006006008008001,0001\{,\}0001,2001\{,\}2001,4001\{,\}4001,6001\{,\}6001,8001\{,\}800TFD MakespanFAPE MakespanEqual makespanSolved by bothFigure 7:Plan makespan comparison for the 42 instances solved by both planners\. Most points lie above the diagonal, indicating that FAPE generally produces plans with a higher makespan compared to TFD\.The divergence is mostly visible at the high end\. There are also several instances, points scattered below the diagonal in the lower\-left region, where FAPE produces a shorter makespan than TFD\. The overall picture of plan quality is that neither planner clearly dominates the other\.

Coverage and runtime statistics do not directly reveal how each planner behaves as the problem grows continuously\. The scalability analysis presented in Figure[8](https://arxiv.org/html/2608.20510#S6.F8)addresses this by plotting each solved instance’s runtime against the size of its grounded action space, as the grounded action determines both the branching factor of the search and the size of the constraint network\.

10110^\{1\}10210^\{2\}10310^\{3\}10410^\{4\}10510^\{5\}10−210^\{\-2\}10010^\{0\}10210^\{2\}Estimated Grounded ActionsRuntime \(s\)FAPE \(ANML\)TFD \(PDDL\)Figure 8:Log\-log scatter plot of the scalability of both planners with increasing problem size, measured by the size of the grounded action space\.The points representing the TFD in Figure[8](https://arxiv.org/html/2608.20510#S6.F8)scatter linearly on the log\-log axes\. The overall growth rate is almost polynomial with respect to the size of the action space\. The trend is consistent as the TFD planner relies on a heuristic to keep the effective branching factor low\. On the other hand, points representing the FAPE in Figure[8](https://arxiv.org/html/2608.20510#S6.F8)form a noisier scatter with noticeable variance\. This variance reflects the sensitivity of FAPE’s constraint propagation to the specific structure of each problem, the order in which flaws are encountered and resolved, the depth of the causal chains, and the density of temporal constraints\.

The key distinction is not only speed; it is the variability of FAPE’s runtime within this range compared to TFD\. The runtime of TFD at any given problem size is polynomial and predictable, but the runtime of FAPE is not\. For operational deployment, a predictable runtime is as important as a fast runtime, because an emergency planner is more reliable if it finishes tasks in under a few seconds\.

### 6\.2Results on Replanning Benchmark

The benchmark of replanning instances encoding dynamic changes mid\-execution is used as input to the TFD\. No plan repair or reuse mechanism is used; each perturbed residual problem is solved from scratch\. TFD successfully solved all 49 replanning instances\. Table[8](https://arxiv.org/html/2608.20510#S6.T8)summarizes the aggregate results\. Route blockages generally produced only modest changes in the generated plans, with mean increases of 3\.2% in makespan and 3\.1% in plan length\. Evacuee increases resulted in substantially larger modifications, yielding mean increases of 15\.7% in makespan and 30\.1% in plan length\.

Table 8:Aggregate replanning statistics by perturbation type\. Values are means with medians in parentheses\.Δ​M\\Delta M\(%\) = percentage change in total makespan;Δ​\|π\|\\Delta\|\\pi\|\(%\) = percentage change in plan length;rrtr\_\{\\mathrm\{rt\}\}= re\-plan runtime divided by original runtime\.Across all instances, replanning remained computationally efficient, with a mean runtime ratio ofrrt=0\.79r\_\{\\mathrm\{rt\}\}=0\.79\(median0\.710\.71\), indicating that replanning was typically faster than solving the corresponding original problem\. The comparison between original planning and replanning runtimes is presented in Figure[9](https://arxiv.org/html/2608.20510#S6.F9)on a shared log scale\. Overall, 38 of 49 re\-plans were completed in less time than the original\. The reason is straightforward: the planner inherits a partially executed state, so the subproblem it must search is smaller than the original one\.

115510101515202025253030353540404545505010−310^\{\-3\}10−210^\{\-2\}10−110^\{\-1\}10010^\{0\}10110^\{1\}10210^\{2\}Problem instanceRuntime \(s\)Originalπ0\\pi\_\{0\}Re\-planπr\\pi\_\{r\}Figure 9:Original planning runtime versus re\-planning runtime \(log scale\) for all instances, ordered by problem index\. Overall, 38 of 49 re\-plans were completed faster than the original plan\.Figure[10](https://arxiv.org/html/2608.20510#S6.F10)compares replanning runtime on a logarithmic scale to the number of scheduled actions remaining inπ0≥\\pi\_\{0\}^\{\\geq\}, which is the subsequence ofπ0\\pi\_\{0\}containing all actions with start time≥\\geqsurprise time \(TT\)\. A clear positive trend emerges, indicating that as the number of remaining actions grows linearly, the re\-planning runtime increases exponentially\. Despite this exponential growth trajectory, the absolute runtimes remain highly efficient, proving the system’s viability for real\-time operational deployment\.

202040406060808010010012012010−310^\{\-3\}10−210^\{\-2\}10−110^\{\-1\}10010^\{0\}10110^\{1\}Actions remaining atTT:\|π0≥\|\|\\pi\_\{0\}^\{\\geq\}\|Re\-plan runtime \(s\)Evacuee IncreaseRoute BlockageFigure 10:Re\-planning runtime against residual plan length\|π0≥\|\|\\pi\_\{0\}^\{\\geq\}\|atTT\(log\-scale\)\. The two Re\-planning costs are driven by how much of the plan remains to be reconstructed, not by what kind of perturbation triggered it\.The effect of replanning on plan quality is summarized by the per\-instance makespan changeΔ​M\\Delta Min Figure[11](https://arxiv.org/html/2608.20510#S6.F11)\. Route blockage instances are largely unaffected: the mean increase is only3\.2%3\.2\\%\(median0\.9%0\.9\\%\), with 19 of 24 instances below7%7\\%, because rerouting typically requires only localised vehicle reassignment\.

Evacuee increase perturbations are far more variable: the mean rises to15\.7%15\.7\\%with a standard deviation of33\.7%33\.7\\%, reflecting the wide range of survivor\-count increases imposed across instances\. Notably, several large instances yield*negative*Δ​M\\Delta M: replanning from a mid\-execution state allows the re\-planner to discover a tighter residual schedule than the original plan’s tail, resulting in a lower total makespan\.

1155101015152020252530303535404045455050005050100100Problem instanceMakespan change \(%\)Evacuee IncreaseRoute BlockageFigure 11:Percentage change in total makespan after replanning, relative toπ0\\pi\_\{0\}’s original makespan\. Route blockage perturbations mostly cluster near zero throughout\. Evacuee increase perturbations are far more variable\. The dashed horizontal line marks zero change\.

## 7Discussion

The experimental results on the primary benchmark show that TFD is faster and more predictable than FAPE\. The runtime gaps between the planners are large enough to matter in real\-world deployment\. Though FAPE is slower and fails on harder instances, it produces plans with fewer sequential steps, and its runtimes in small\-scale instances corresponding to neighborhood\-level incidents are acceptable\. But for large\-scale scenarios, corresponding to city\-level incidents, TFD appears to be the more viable option\. FAPE’s lower makespan at the smaller tiers is an advantage also\. A plan that completes intttime units rather thant′t^\{\\prime\}witht′\>tt^\{\\prime\}\>tmay correspond to dozens of additional households served before rising water levels close the last available route\.

The replanning experiment under mid\-execution perturbations extends the findings\. Even under dynamic conditions, TFD remains highly robust and successfully solves all replanning instances\. The results further confirm that replanning is generally faster than initial planning\. In some cases, replanning from a partially executed state produced plans with shorter makespans than the corresponding tails of the original plans\. One possible reason is that the planner identifies alternative coordination patterns that were not selected during the initial planning phase\.

For operational deployment, the most robust approach is to consider the TFD and FAPE in combination, depending on requirements\. For initial planning, the experimental results provide strong support for selecting TFD as the default planner because of its computational efficiency and consistent performance\. FAPE is a viable choice when the scenario is small\-scale, plan quality is the priority, and there is time to do better\. Mid\-execution replanning is a different situation entirely\. The operation is already moving, and what matters is getting a usable plan back quickly\. Under such conditions, TFD appears to be the more suitable choice\.

## 8Conclusion

Can automated planning be applied to produce temporally coherent response plans for floods? This was the central question addressed in this work\. To answer it, a flood\-response framework was developed that captures the full operational cycle of coordinated disaster response, including rescue, medical support, evacuation, and supply delivery\. The proposed framework supports key operational considerations such as prioritization of affected zones, route accessibility, action concurrency, and other real\-world constraints\. The framework also enables mid\-execution replanning under dynamic environmental changes, enhancing its applicability\. To validate the framework, experiments on initial response planning and mid\-execution replanning were conducted using a benchmark set of instances of the proposed framework’s temporal planning domain\. Results indicate that automated planning can generate temporal flood\-response plans while supporting dynamic adaptation during mid\-execution surprises\. However, the findings are based on experiments on the benchmark instances, and additional validation using real\-world flood response data and operational workflows remains necessary to assess practical deployment feasibility\.

Future work could extend the proposed framework to support multi\-objective optimization, such as makespan and resource efficiency, together with post\-processing mechanisms that enable decision\-makers to explore trade\-offs among competing objectives\. In addition, developing an interface that translates planner output into human\-readable schedules or dispatch orders would move the proposed framework from a research prototype toward something usable in an emergency operations center\.

### \\sagesfAuthor Contributions

\{refsize\}

All authors contributed to the conceptualization of the study and the development of the research methodology\. Fazlul Hasan Siddiqui secured the project funding, administered the project, provided the necessary resources, and supervised the research\. Md\. Monjurul Islam conducted the investigation, developed the software, performed the visualization of the results, and prepared the original draft of the manuscript\. Fazlul Hasan Siddiqui and Sabah Binte Noor validated the methodology and research findings\. All authors contributed to the review and editing of the manuscript and approved the final version for publication\.

## Statements and Declarations

### \\sagesfFunding

\{refsize\}

This work was supported by the University Grants Commission of Bangladesh through the Office of the Director \(Research and Extension\), DUET, Gazipur \[grant number DUET\-TRF/2025\-2026/13\]\.

### \\sagesfData Availability

\{refsize\}

The data supporting the findings of this study are available from the corresponding author upon reasonable request\.

### \\sagesfCode Availability

## References

- Ambilyet al\.\(2024\)P\. Ambily, N\. Chithra, and C\. Mohammed FirozA framework for urban pluvial flood resilient spatial planning through blue\-green infrastructure\.International Journal of Disaster Risk Reduction103,pp\. 104342\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p4.1)\.
- Changet al\.\(2007\)M\. Chang, Y\. Tseng, and J\. ChenA scenario planning approach for the flood emergency logistics preparation problem under uncertainty\.Transportation research part E: logistics and transportation review43\(6\),pp\. 737–754\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p4.1)\.
- Fox and Long \(2003\)M\. Fox and D\. LongPDDL2\. 1: an extension to pddl for expressing temporal planning domains\.Journal of artificial intelligence research20,pp\. 61–124\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p7.1),[§2\.1](https://arxiv.org/html/2608.20510#S2.SS1.p4.1),[§2\.1](https://arxiv.org/html/2608.20510#S2.SS1.p5.1),[§2\.2\.1](https://arxiv.org/html/2608.20510#S2.SS2.SSS1.p1.1)\.
- Ghallabet al\.\(1998\)M\. Ghallab, A\. Howe, C\. Knoblock, D\. McDermott, A\. Ram, M\. Veloso, D\. Weld, and D\. WilkinsPddl—the planning domain definition language\.Technical Report, Tech\. Rep\.\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p6.1),[§2\.2\.1](https://arxiv.org/html/2608.20510#S2.SS2.SSS1.p1.1)\.
- Ghallabet al\.\(2004\)M\. Ghallab, D\. Nau, and P\. TraversoAutomated planning: theory and practice\.Elsevier\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p2.1),[§2\.1](https://arxiv.org/html/2608.20510#S2.SS1.p1.1)\.
- Islamet al\.\(2025\)M\. M\. Islam, S\. B\. Noor, and F\. H\. SiddiquiRAPID: resilient automated planning for intelligent disaster response\.In2025 2nd International Conference on Next\-Generation Computing, IoT and Machine Learning \(NCIM\),pp\. 1–6\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p6.1)\.
- Jiaet al\.\(2022\)H\. Jia, F\. Chen, D\. Pan, E\. Du, L\. Wang, N\. Wang, and A\. YangFlood risk management in the yangtze river basin—comparison of 1998 and 2020 events\.International Journal of Disaster Risk Reduction68,pp\. 102724\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p3.1)\.
- Kapucu and Garayev \(2011\)N\. Kapucu and V\. GarayevCollaborative decision\-making in emergency and disaster management\.International Journal of Public Administration34\(6\),pp\. 366–375\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p1.1)\.
- Meyeret al\.\(2012\)V\. Meyer, S\. Priest, and C\. KuhlickeEconomic evaluation of structural and non\-structural flood risk management measures: examples from the mulde river\.Natural Hazards62\(2\),pp\. 301–324\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p1.1)\.
- Rutherfordet al\.\(2024\)G\. Rutherford, J\. Kirkpatrick, A\. Davison, and V\. PrahaladCan a relational cross\-scalar approach to management improve environmental disaster responses? a case study of an unprecedented flood in new south wales, australia\.Australasian Journal of Environmental Management31\(4\),pp\. 431–447\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p1.1)\.
- Sayerset al\.\(2013\)P\. Sayers, L\. Yuanyuan, G\. Galloway, E\. Penning\-Rowsell, S\. Fuxin, W\. Kang, C\. Yiwei, and T\. Le QuesneFlood risk management: a strategic approach\.Asian Development Bank, GIWP, UNESCO and WWF\-UK\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p3.1)\.
- Schanze \(2006\)J\. SchanzeFlood risk management–a basic framework\.InFlood risk management: Hazards, vulnerability and mitigation measures,pp\. 1–20\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p3.1)\.
- Simonovic and Ahmad \(2005\)S\. P\. Simonovic and S\. AhmadComputer\-based model for flood evacuation emergency planning\.Natural Hazards34,pp\. 25–51\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p4.1)\.
- Smithet al\.\(2008\)D\. E\. Smith, J\. Frank, and W\. CushingThe anml language\.InThe ICAPS\-08 Workshop on Knowledge Engineering for Planning and Scheduling \(KEPS\),Vol\.31\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p7.1),[§2\.2\.2](https://arxiv.org/html/2608.20510#S2.SS2.SSS2.p1.1)\.
- Wanget al\.\(2024\)W\. Wang, Y\. Li, Y\. Zhang, and Z\. WuPedestrian evacuation planning under dam\-break flood disaster considering road risk and road pedestrian demand\.International Journal of Disaster Risk Reduction104,pp\. 104355\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p5.1)\.
- Yeet al\.\(2021\)X\. Ye, S\. Wang, Z\. Lu, Y\. Song, and S\. YuTowards an ai\-driven framework for multi\-scale urban flood resilience planning and design\.Computational Urban Science1,pp\. 1–12\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p4.1)\.
- Yinet al\.\(2024\)J\. Yin, Y\. Yang, D\. Yu, N\. Lin, R\. Wilby, S\. Lane, B\. Sun, J\. Bricker, N\. Wright, L\. Yang,et al\.Strategic storm flood evacuation planning for large coastal cities enables more effective transfer of elderly populations\.Nature Water2\(3\),pp\. 274–284\.Cited by:[§1](https://arxiv.org/html/2608.20510#S1.p5.1)\.

Similar Articles

A Temporal Planning Framework for Disruption Aware Dynamic Route Optimization in Heterogeneous Railway Systems

arXiv cs.AI

This paper proposes a temporal planning framework for dynamic route optimization and disruption management in heterogeneous multi-gauge railway systems. It formulates railway operations as a temporal planning problem using PDDL 2.1, generates conflict-free timestamped operational plans, and reduces reliance on manual decision-making, evaluated on benchmark problems with up to 1,000 track points and 120 trains.

Physics-Informed Machine Learning for Short-Term Flood Prediction

arXiv cs.LG

Researchers propose a Physics-Informed Machine Learning (PIML) framework that integrates hydrological constraints into an LSTM loss function to improve short-term flood forecasting, particularly in data-scarce regimes. A 'Trend Alignment' constraint enforcing consistency between precipitation and discharge trends improves Nash-Sutcliffe Efficiency and eliminates unphysical predictions during extreme events.

Finding the Time to Think: Learning Planning Budgets in Real-Time RL

arXiv cs.LG

This paper introduces variable-delay real-time RL, where agents decide how long to deliberate in environments that progress during decision-making, and proposes a lightweight gating policy to select state-dependent planning budgets, outperforming fixed-budget and heuristic baselines in several real-time games.