Paper deep dive
A Temporal Planning Approach for Intelligent Flood Response
Fazlul Hasan Siddiqui, Md. Monjurul Islam, Sabah Binte Noor
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 91%
Last extracted: 8/24/2026, 4:33:15 AM
Summary
This paper presents an intelligent flood-response framework that utilizes temporal planning to coordinate actions across multiple flooded areas under severe resource constraints. The framework models the complete operational life cycle, including priority-driven triage, route accessibility, resource allocation, and supply management, while supporting mid-execution re-planning. It is formulated in both ANML and PDDL 2.1 to ensure compatibility with various temporal planners, demonstrating feasibility and scalability through experimental results.
Entities (7)
Relation Signals (8)
Intelligent Flood-Response Framework → uses → Temporal Planning
confidence 98% · This work presents an intelligent flood-response framework that exploits temporal planning...
Intelligent Flood-Response Framework → formulatedin → ANML
confidence 95% · The framework is formulated both in the Action Notation Modeling Language (ANML)...
Intelligent Flood-Response Framework → formulatedin → PDDL 2.1
confidence 95% · The framework is formulated both in ... the Planning Domain Definition Language (PDDL) 2.1...
Intelligent Flood-Response Framework → supports → Mid-execution re-planning
confidence 92% · ...while also supporting mid-execution re-planning in response to unexpected environmental changes.
RAPID → uses → PDDL+
confidence 90% · RAPID framework ... introduces a disaster response domain using the Planning Domain Definition Language (PDDL)...
Timed Fast Downward → consumes → PDDL 2.1
confidence 85% · The Temporal Fast Downward (TFD) planner used in our evaluation consumes PDDL 2.1.
FAPE → consumes → ANML
confidence 85% · The Flexible Action and Planning Environment (FAPE) used in our evaluation consumes ANML.
RAPID → limitation → Cannot model action scheduling
confidence 85% · RAPID relies on classical PDDL with numeric fluents, and therefore, it cannot model action scheduling or the concurrent overlapping of operations.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
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.
Tags
Links
- Source: https://arxiv.org/abs/2608.20510v1
- Canonical: https://arxiv.org/abs/2608.20510v1
Trouble viewing inline? Open PDF directly →
Full Text
73,320 characters extracted from source content.
Expand or collapse full text
A Temporal Planning Approach for Intelligent Flood Response Fazlul Hasan Siddiqui 1 Md. Monjurul Islam 1,2 and Sabah Binte Noor 1 Email: sabah@duet.ac.bd 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. keywordsFlood Response, Planning, Reasoning, AI and Society †runninghead: Siddiqui, Islam, and Noor†affiliation: 1Department of Computer Science and Engineering, Dhaka University of Engineering & Technology, Gazipur, 1707, Bangladesh 2Department 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. 1 Introduction An effective response to floods requires rapid decision-making and coordinated actions (8). 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). 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). 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). 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). Therefore, strategic flood risk management principles recommend a portfolio of diverse responses rather than relying on a single measure (11). A comparative study of the severe 1998 and 2020 Yangtze River floods by 7 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 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 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 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 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 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 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, which introduces a disaster response domain using the Planning Domain Definition Language (PDDL) (4) 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) and PDDL 2.1 (3), 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. The scenario consists of two safe areas, safeA and safeB, and two affected areas, zoneA and zoneB. The location safeA is 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). Figure 1: An example scenario with two safe areas (safeA and safeB) and two affected zones (zoneA and zoneB). zoneA requires rescue operations, medical support, and 100 units of relief goods, while zoneB requires rescue operations and evacuation of 40 people. Vehicle-dependent travel times range from 11 to 38 time units. Affected area zoneA requires rescue operations, medical support, and 100 units of food, whereas zoneB requires 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 from safeA to zoneA, 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 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 at zoneA at time 23, and both teams disembark from the bus and immediately begin rescue operations (RescueAffectedPeople) and medical support (ProvideMedicalSupport) in parallel at time 28. 0255075100125150175200225250275Time LoadResource(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)50TransportResponseLogistics Figure 2: A temporal plan for the example flood response scenario in Figure 1. 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 at zoneA at time 75, and relief goods are then delivered. Meanwhile, the rescue team is transported and is redeployed to zoneB via bus, where evacuation and rescue operations are carried out across two evacuation sorties (Evacuate at times 77 and 129). Each evacuation sortie is followed by a return trip to safeA to 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. 2 Background 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.1 Automated Planning Automated planning generates sequences of actions (i.e., plans) which transform an initial state into a desired goal state (5). 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) 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. A classical planning task is represented as a tuple Π=⟨F,A,γ,I,G⟩ = F,A,γ,I,G , where: • F is a finite set of propositional facts, • A is a finite set of actions, • γ:A↦ℚ0+γ:A _0^+ is a function assigning a non-negative rational cost to each action, • I⊆FI F represents the initial state, and • G⊆FG F specifies the goal conditions. Each action a∈Aa∈ A is a tuple a=⟨pre(a),add(a),del(a)⟩a= pre(a),add(a),del(a) , where pre(a),add(a),del(a)⊆Fpre(a),add(a),del(a) F denote 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 formally defines a plan. Definition 2. A plan π for a classical planning task Π is an ordered sequence of actions ⟨a1,a2,…,an⟩ a_1,a_2,…,a_n . The plan π is valid if and only if pre(a1)⊆Ipre(a_1) I and the sequential application of actions a1,a2,…,ana_1,a_2,…,a_n successfully yields a state satisfying the goal conditions G. 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). Definition 3. A numeric planning task is defined as a tuple Πn=⟨F,X,A,γ,I,G⟩ _n= F,X,A,γ,I,G , where F, A, and γ retain their definitions from the classical planning paradigm (Definition 1), and X is a finite set of numeric variables bounded over the rational numbers ℚQ, I⊆F∪XI F∪ X is the initial state, and G⊆F∪XG F∪ X specifies 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). Definition 4. A temporal planning task is represented as a tuple Πt=⟨F,X,Ad,γ,I,G⟩ _t= F,X,A^d,γ,I,G , where F, X, γ, I, and G are defined as in a numeric planning task (Definition 3), and AdA^d is a finite set of durative actions. Each action a∈Ada∈ A^d is a tuple as given in (1). a=⟨s(a),o(a),e(a),s(a),e(a),(a)⟩a= \,pre^s(a),\;pre^o(a),\;pre^e(a),\;eff^s(a),\;eff^e(a),\;dur(a)\, (1) where s(a)pre^s(a), o(a)pre^o(a), e(a)pre^e(a) ⊆F∪X F∪ X are the at-start, over-all, and at-end preconditions respectively, s(a)eff^s(a), e(a)eff^e(a) ⊆F∪X F∪ X are the at-start and at-end effects, and (a)∈ℝ+dur(a) ^+ 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). Definition 5. A temporal plan πt _t for a temporal planning task Πt _t is a timed schedule of durative actions represented as a tuple ⟨(t1:a1),(t2:a2),…,(tn:an)⟩ (t_1:a_1),(t_2:a_2),...,(t_n:a_n) , where each ti∈ℝ0+t_i ^+_0 is a time point of the start of some durative action ai∈Ada_i∈ A_d. The schedule πt _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), the total time required to execute a schedule. Definition 6. The makespan of a temporal plan πt=⟨(t1:a1),(t2:a2),…,(tn:an)⟩ _t= (t_1:a_1),(t_2:a_2),…,(t_n:a_n) is the elapsed time between the start of its earliest action and the completion of its latest action, as specified in (2). 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)makespan( _t)\;=\; _1≤ i≤ n (t_i+dur(a_i) )\;-\; _1≤ i≤ 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.2 Planning 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.1 The Planning Domain Definition Language The Planning Domain Definition Language (PDDL) is a standardized formalism for modeling automated planning domains and problems (4). 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), 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 start conditions and effects apply at the instant execution begins, over all conditions must hold throughout the open interval of the action, and at end conditions and effects apply on completion. The Temporal Fast Downward (TFD) planner used in our evaluation consumes PDDL 2.1. 2.2.2 The Action Notation Modeling Language The Action Notation Modeling Language (ANML) is a high-level formalism for modeling planning domains and problems (14). 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’s start and end landmarks, and all denotes the whole execution window. The Flexible Action and Planning Environment (FAPE) used in our evaluation consumes ANML. 3 Proposed 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, as a running example throughout this section. A single safe location S serves as a staging hub containing a transit vehicle T, a freight vehicle F, a rescue team R, a medical team M, and a stock of relief goods (e.g., food=k300). From this safe hub, operations are carried out over two affected zones: Zone A (priority 1) and Zone B (priority 2). Each zone has associated evacuation and relief requirements. A strict triage constraint is imposed through the prior relation: each response operation in Zone A must be completed before the same operation in Zone B can 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. Safe SSTransitVehicle TTFreightVehicle FFRescueTeam RRMedicalSupportTeam MMresource_available(food)=k300Zone A – priority 1evac_level=p60needs_rescueneeds_medical_supportresource_needed(food)=k200Zone B – 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 location S stages a transit vehicle T, a freight vehicle F, a rescue team R, and a medical support team M, together with a stock of relief goods (food=k300). Zone A outranks Zone B via prior. Edge labels give vehicle-specific travel times. 3.1 Task Formulation We present the proposed model using a propositional temporal-planning formulation (Definition 7), following the general formulation introduced in Definition 4. 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. A flood-response planning task is a temporal planning problem Πf=⟨Ff,Xf,Afd,γf,If,Gf⟩ _f= F_f,\,X_f,\,A_f^d,\, _f,\,I_f,\,G_f defined over a flood-response domain, where: • FfF_f is the finite set of grounded propositional facts over the predicate set P, specified in (3). =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_stepP= \ aligned & 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 aligned \ (3) • XfX_f is the finite set of ground numeric fluents (all rigid, i.e. never modified by an action effect) over the set 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 A, specified in (4), instantiated over the typed objects of a given problem instance. =BoardTeam,DisembarkTeam,MoveVehicle,Evacuate,DisembarkEvacuatedPeople,RescueAffectedPeople,LoadResource,DeliverResource,ProvideMedicalSupportA= \ aligned & BoardTeam, DisembarkTeam,\\ & MoveVehicle, Evacuate,\\ & DisembarkEvacuatedPeople,\\ & RescueAffectedPeople,\\ & LoadResource, DeliverResource,\\ & ProvideMedicalSupport aligned \ (4) • γf _f is the action cost function, where γf=1 _f=1 for all a∈Afda∈ A_f^d. • If⊆Ff∪XfI_f F_f∪ X_f is the initial state, grounded over ∪P to describe the initial configuration of vehicles, teams, routes, operational requirements, and milestone levels for a given flood scenario. • Gf⊆FfG_f F_f is the goal condition grounded over P, as formalized in (5). Gf=¬needs_rescue(l),¬evacuating(v),¬needs_medical_support(l),evac_level(l,p0),resource_needed(l,r,k0)G_f= \ aligned & needs\_rescue(l), evacuating(v),\\ & needs\_medical\_support(l),\\ & evac\_level(l, p0),\\ & resource\_needed(l,r, k0) aligned \ (5) for all l∈ℒAl _A, r∈ℛr , and v∈Tv _T, where ℒAL_A denotes the set of affected locations, ℛR is the set of resource types, TV_T is the set of transit vehicles, and p0 and k0 are the base milestone values denoting full evacuation and full resource satisfaction. 3.2 Modeling 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.3 World 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.1 Type 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, and Resource. These root types are further specialized, as presented in (6), to capture the operational structure of flood-response activities as follows: Location Location ⊇AffectedLocation,SafeLocation \ AffectedLocation, SafeLocation\ (6) Vehicle Vehicle ⊇TransitVehicle,FreightVehicle \ TransitVehicle, FreightVehicle\ Team Team ⊇RescueTeam,MedicalSupportTeam \ RescueTeam, MedicalSupportTeam\ • Safe areas and affected zones: The Location type represents all areas within the scenario and is specialized into two distinct subtypes: AffectedLocation and SafeLocation. • Transportation Assets: The Vehicle type models transportation assets and is specialized into two subtypes: TransitVehicle for personnel and evacuee transport and FreightVehicle for relief cargo delivery. • Response Teams: The Team type represents deployable response units and is partitioned into two subtypes: RescueTeam and MedicalSupportTeam. • Consumable Resources: Resource denotes 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 constant NULL represents temporary unassignment of entities during transitional operations such as movement, boarding, loading, and unloading. 3.3.2 State 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 by vehicle_at(v,l), team_at(t,l), and team_in_vehicle(t,v), denoting vehicle locations, team deployment, and team boarding status, respectively. • Vehicle status: Vehicle operations are captured by evacuating(v), route_accessible(v,l1,l2), cargo_full(v), and cargo_loaded(v,r), indicating evacuation activity, cargo status, and route feasibility. • Location requirements and priority: Operational requirements are expressed using needs_rescue(l) and needs_medical_support(l). A priority relation prior(l,pl) enforces that location pl must be served before l, 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: PersonCount with p60≻p40≻p20≻p0 p60 p40 p20 p0, and PackageCount with k200≻k100≻k0 k200 k100 k0, where p0 and k0 denote goal satisfaction. Three predicates operate over evac_level(l,p) (remaining evacuees), resource_needed(l,r,k) (remaining demand), and resource_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 fluent team_size(t) defines team’s boarding and disembarkation durations, travel_time(v,l1,l2) defines vehicle movement durations, while person_count_diff(p_1,p_2) and package_count_diff(k_1,k_2) scale evacuation and delivery durations according to corresponding workload. Vehicle’s capacity constraints are enforced via valid_evac_step(v,p_1,p_2) and valid_supply_step(v,k_1,k_2), which restrict allowed milestone transitions. 3.4 Action 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–3. 3.4.1 Transport Actions The transport actions, BoardTeam, DisembarkTeam, and MoveVehicle (Table 1), govern the movement of teams and vehicles across the locations. BoardTeam and DisembarkTeam are 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 with team_size. MoveVehicle models 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: t denotes a team; l, fromfrom, and toto denote locations; vTv_T denotes a transit vehicle; and T denotes a vehicle. Action Preconditions Effects [Duration] ann. predicate(s) ann. predicate(s) BoardTeam (t,l,vT)(t,l,v_T) Start team_at(t,l)(t,l) Start ¬ _at(t,l)(t,l) [team_size(t)(t)] Over-all vehicle_at(vT,l)(v_T,l), ¬ (vT)(v_T) End team_in_vehicle(t,vT)(t,v_T) DisembarkTeam (t,vT,l)(t,v_T,l) Start team_in_vehicle(t,vT)(t,v_T) Start ¬ _in_vehicle(t,vT)(t,v_T) [team_size(t)(t)] Over-all vehicle_at(vT,l)(v_T,l) End team_at(t,l)(t,l) MoveVehicle (v,from,to)(v,from,to) Start vehicle_at(v,from)(v,from) Start ¬ _at(v,from)(v,from) [travel_time(v,from,to)(v,from,to)] Over-all route_accessible(v,from,to)(v,from,to) End vehicle_at(v,to)(v,to) 3.4.2 Response Actions Response actions are RescueAffectedPeople and ProvideMedicalSupport (Table 2). 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 the prior predicate, which prevents service at a location unless all higher-priority locations have already been fully serviced for the same task type. For instance, Zone A must be cleared before Zone B in Figure 3. 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; plpl denotes a higher-priority affected location; and C denotes a constant value. Action Preconditions Effects ann. predicate(s) ann. predicate(s) RescueAffectedPeople (lA,rescuers,pl)(l_A,rescuers,pl) Start prior(lA,pl)(l_A,pl), ¬ _rescue(pl)(pl), needs_rescue(lA)(l_A) – – Over-all team_at(rescuers,lA)(rescuers,l_A) End ¬ _rescue(lA)(l_A) ProvideMedicalSupport (lA,medics,pl)(l_A,medics,pl) Start prior(lA,pl)(l_A,pl), ¬ _medical_support(pl)(pl), needs_medical_support(lA)(l_A) – – Over-all team_at(medics,lA)(medics,l_A) End ¬ _medical_support(lA)(l_A) Table 3: Logistics action schemas. Parameter shorthands: lAl_A denotes an affected location; vTv_T denotes a transit vehicle; pfpf denotes the initial evacuation milestone; ptpt denotes the final evacuation milestone; plpl denotes a higher-priority affected location than lAl_A; lSl_S denotes a safe location; r denotes a resource; vFv_F denotes a freight vehicle; kfkf denotes the initial resource milestone; ktkt denotes the final resource milestone; and C denotes a constant value. Action Preconditions Effects [Duration] ann. predicate(s) ann. predicate(s) Evacuate (lA,vT,pf,pt,pl)(l_A,v_T,pf,pt,pl) Start prior(lA,pl)(l_A,pl), evac_level(pl,p0)(pl, p0), evac_level(lA,pf)(l_A,pf), ¬ (vT)(v_T) Start†Start ¬ _level(lA,pf)(l_A,pf), evac_level(lA,pt)(l_A,pt), evacuating(vT)(v_T) [person_count_diff(pf,pt)(pf,pt)] Over-all vehicle_at(vT,lA)(v_T,l_A), valid_evac_step(vT,pf,pt)(v_T,pf,pt) – – DisembarkEvacuated-People (vT,lS)(v_T,l_S) Start evacuating(vT)(v_T) – – [C] Over-all vehicle_at(vT,lS)(v_T,l_S) End ¬ (vT)(v_T) LoadResource (r,l,vF,kf,kt)(r,l,v_F,kf,kt) Start resource_available(l,r,kf)(l,r,kf), ¬ _loaded(vF,r)(v_F,r), ¬ _full(vF)(v_F) Start ¬ _available(l,r,kf)(l,r,kf), resource_available(l,r,kt)(l,r,kt) [package_count_diff(kf,kt)(kf,kt)] Over-all vehicle_at(vF,l)(v_F,l), valid_supply_step(vF,kf,kt)(v_F,kf,kt) End cargo_loaded(vF,r)(v_F,r), cargo_full(vF)(v_F) DeliverResource (r,lA,vF,kf,kt,pl)(r,l_A,v_F,kf,kt,pl) Start prior(lA,pl)(l_A,pl), evac_level(pl,p0)(pl, p0), resource_needed(pl,r,k0)(pl,r, k0), resource_needed(lA,r,kf)(l_A,r,kf), cargo_loaded(vF,r)(v_F,r) Start ¬ _needed(lA,r,kf)(l_A,r,kf) [package_count_diff(kf,kt)(kf,kt)] Over-all vehicle_at(vF,lA)(v_F,l_A), valid_supply_step(vF,kf,kt)(v_F,kf,kt) End resource_needed(lA,r,kt)(l_A,r,kt), ¬ _loaded(vF,r)(v_F,r), ¬ _full(vF)(v_F) † Effect applied at action start, enabling concurrent scheduling. 3.4.3 Logistics Actions Logistics actions (Table 3) implement evacuation and supply operations across the same spatial network under shared priority constraints. Evacuate moves civilians in discrete capacity-bounded steps governed by valid_evac_step, updating evacuation milestones and marking vehicles as actively evacuating. To enable concurrency, key milestone updates occur at action start. DisembarkEvacuatedPeople drops off evacuees at safe locations and releases vehicles for reuse. Supply operations are handled by LoadResource and DeliverResource, 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.5 Dependency 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. 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 team at zone medical team at zone team 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 constraint Figure 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. The MoveVehicle action 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.6 Instance 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 _f) in Definition 7. 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 specifies the planning problem corresponding to the representative flood-response scenario in Figure 3, instantiating the objects, initial state (IfI_f), and goal condition (GfG_f) of Definition 7. Table 4: Planning task for the instance of Figure 3, instantiating the objects, initial state (IfI_f), and goal (GfG_f) of Definition 7. Category Predicates / values Objects Location S (SafeLocation); A, B (AffectedLocation) Vehicle T (TransitVehicle); F (FreightVehicle) Team R (RescueTeam); M (MedicalSupportTeam) Resource food PersonCount p0, p20, p40, p60 PackageCount k0, k100, k200, k300 Initial state (IfI_f) Deployment vehicle_at(T,S), vehicle_at(F,S), team_at(R,S), team_at(M,S) Priority prior(B,A) Demands needs_rescue(A), needs_medical_support(A), resource_needed(A,food,k200) Status evac_level(A,p60), evac_level(B,p20) Supplies resource_available(S,food,k300) Static travel_time(T,S,A)=20, travel_time(T,S,B)=30, travel_time(F,S,A)=25, travel_time(F,S,B)=40, … // Static team_size, person_count_diff, package_count_diff, valid_evac_step, and valid_supply_step values are omitted for brevity Goal (GfG_f) Demands ¬ _rescue(A), ¬ _medical_support(A), resource_needed(A,food,k0) Status evac_level(A,p0), evac_level(B,p0), ¬ (T) 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 _f) that can be solved directly by an automated planner. 3.7 Plan Validity A solution to Πf _f is a valid temporal plan πf=⟨(ti:ai)⟩i=1n _f= (t_i:a_i) _i=1^n in the sense of Definition 5: 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 goal GfG_f of Definition 7. Beyond these requirements, the flood-response task imposes one domain-specific condition, priority ordering. For every pair of affected locations ℓ,ℓ′ , with prior(ℓ,ℓ′)∈If prior( , )∈ I_f, no response action may start at ℓ while the corresponding requirement at the higher-priority location ℓ′ remains outstanding. Because this is enforced as a hard at start precondition in every affected action schema (Tables 2 and 3) 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. 4 Dynamic Replanning Our flood response formulation in Definition 7 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 1 Dynamic Replanning Procedure 1: Original Instance ℐI, Original Plan π0 _0, Surprise Time T, Fact Changes C, Goal Changes G, Planner P 2: Replanned Schedule πr _r 3: S←ParseInitialState(ℐ)S← ParseInitialState(I) 4: π0<←SortByTime(a∈π0∣a.time<T) _0^<← SortByTime(a∈ _0 a.time<T) 5: ⊳ Phase 1: Reconstruct execution state 6: for each action a∈π0<a∈ _0^< do 7: S←ApplyActionEffects(S,a)S← ApplyActionEffects(S,a) 8: end for 9: ⊳ Phase 2: Incorporate newly observed information 10: S←UpdateState(S,)S← UpdateState(S,C) 11: G←UpdateGoals(ℐ.goal,)G← UpdateGoals(I.goal,G) 12: ⊳ Phase 3: Construct replanning problem 13: ℐ′.header←ℐ.headerI .header .header 14: ℐ′.objects←ℐ.objectsI .objects .objects 15: ℐ′.init←ConstructInitFacts(S)I .init← ConstructInitFacts(S) 16: ℐ′.goal←GI .goal← G 17: ⊳ Phase 4: Generate adapted schedule 18: πr←Plan(,ℐ′) _r← Plan(P,I ) 19: return πr _r Algorithm 1 represents the replanning process. Given an original planning instance ℐI and its corresponding plan π0 _0, a surprise occurring at time T triggers state reconstruction by simulating all actions whose start times precede T. 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 _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. 5 Benchmark 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.1 Primary 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. 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. Tier Locations Vehicles Teams Estimated Actions 1 2 – 6 2 – 3 2 – 5 60 – 554 2 7 – 11 3 – 6 5 – 7 632 – 2560 3 12 – 15 6 – 8 7 – 10 2917 – 7190 4 17 – 25 8 – 12 10 – 13 8566 – 30632 5 26 – 32 12 – 17 14 – 17 32570 – 84579 5.2 Replanning 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.1 Surprise Time Selection and Perturbation Types Let π0 _0 denote the original plan, and the surprise time T is 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 every AffectedLocation remains reachable from at least one SafeLocation in the residual undirected graph. Instances where blocking would disconnect the graph fall back to the evacuee increase perturbation. • Evacuee Increase: The evac_level of 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 reach p0. 5.3 Replanning 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 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 2 Replanning Instance Generation 1: Instance ℐI, Original plan π0 _0, surprise time function (⋅)T(·), perturbations P 2: Replanning instance ℐ′I 3: T←(π0)T ( _0) ⊳ Select surprise time near plan midpoint 4: S←ReconstructState(ℐ,π0,T)S← ReconstructState(I, _0,T) 5: p←Sample()p← Sample(P) ⊳ Select perturbation type 6: if p=Route Blockagep=Route Blockage then 7: S←RemoveRouteFacts(S)S← RemoveRouteFacts(S) 8: if disconnected(S) then p←Evacuee Increasep Increase 9: end if 10: if p=Evacuee Increasep=Evacuee Increase then 11: S←IncreaseEvacuationDemand(S)S← IncreaseEvacuationDemand(S) 12: G←UpdateGoal(ℐ.G)G← UpdateGoal(I.G) 13: else 14: G←ℐ.G .G 15: end if 16: ℐ′←ConstructInstance(S,G)I ← ConstructInstance(S,G) 17: return ℐ′I 6 Experimental 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? i) 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? i) 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. • Coverage is defined as the fraction of benchmark instances for which the planner returns a valid plan within the time limit. • Runtime is the time from the start of the search until the planner returns a result, measured in seconds. • Plan quality is assessed along two dimensions: plan length and makespan. Plan length is the number of individual actions in the returned plan, and makespan (Definition 6) is the total time required to execute it. Let π0< _0^< denote the subsequence of π0 _0 containing all actions with start time <T<T, and πr _r denote the plan produced for the corresponding re-planning instance, then– • Mr=makespan(π0<)+makespan(πr)M_r=makespan( _0^<)+makespan( _r): Total replan makespan, combining the makespan already spent before T with the plan πr _r’s own makespan. • ΔM=(Mr−M0)/M0 M=(M_r-M_0)/M_0: Makespan change relative to the original plan’s makespan M0=makespan(π0)M_0=makespan( _0). • Δ|π| |π|: Plan-length change, comparing the length of π0 _0 against the combined length of the committed pre-surprise actions (π0< _0^<) and the plan πr _r. • rrtr_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.1 Results on Primary Benchmark Planners’ coverage and runtimes are summarized in Table 6, 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. Tier Planner Solved Runtime (s) Min Median Max Mean 1 FAPE (ANML) 10/10 0.421 0.737 1.709 0.806 TFD (PDDL) 10/10 0.001 0.003 0.007 0.003 2 FAPE (ANML) 10/10 1.213 1.811 3.096 1.845 TFD (PDDL) 10/10 0.005 0.010 0.017 0.010 3 FAPE (ANML) 9/10 6.378 9.242 28.363 11.938 TFD (PDDL) 9/10 0.029 0.046 0.094 0.050 4 FAPE (ANML) 9/10 23.521 87.077 333.685 145.208 TFD (PDDL) 10/10 0.067 0.161 0.433 0.213 5 FAPE (ANML) 5/10 686.735 1487.472 2429.159 1388.416 TFD (PDDL) 10/10 0.655 1.377 19.583 3.868 All FAPE (ANML) 43/50 0.421 6.635 2429.159 194.951 TFD (PDDL) 49/50 0.001 0.046 19.583 0.845 Overall, TFD finds solutions faster than FAPE across tiers, and its runtime grows far more slowly as problem size increases. Figure 5 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^-310−210^-210−110^-110010^010110^110210^210310^310410^4002020404060608080100100Runtime (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 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^-310−210^-210−110^-110010^010110^110−110^-110010^010110^110210^210310^3TFD Runtime (s)FAPE Runtime (s)Equal runtimeTier 1Tier 2Tier 3Tier 4Tier 5 Figure 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 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. Planner Plan Length Makespan Min Mean Median Max Min Mean Median Max All Instances FAPE (ANML) 14 49 39 140 170.0 627.4 533.0 1695.0 TFD (PDDL) 16 71 57 222 222.0 668.5 476.4 3223.8 Jointly Solved FAPE (ANML) 14 49 39 140 170.0 630.6 536.5 1695.0 TFD (PDDL) 16 55 46 161 222.0 483.4 469.1 1519.2 Makespan provides a more operationally meaningful measure, as it captures the total duration of execution under concurrency. Figure 7 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 both Figure 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 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^110210^210310^310410^410510^510−210^-210010^010210^2Estimated 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 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 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.2 Results 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 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 M(%) = percentage change in total makespan; Δ|π| |π|(%) = percentage change in plan length; rrtr_rt = re-plan runtime divided by original runtime. Perturbation Number of Instances ΔM M(%) |π| |π|(%) rtr_ rt Evacuee Increase 25 15.7 (6.6) 30.1 (24.3) 0.78 (0.66) Route Blockage 24 3.2 (0.9) 3.1 (3.1) 0.80 (0.73) Overall 49 9.6 (4.2) 16.9 (7.7) 0.79 (0.71) Across all instances, replanning remained computationally efficient, with a mean runtime ratio of rrt=0.79r_rt=0.79 (median 0.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 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^-310−210^-210−110^-110010^010110^110210^2Problem instanceRuntime (s)Original π0 _0Re-plan πr _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 compares replanning runtime on a logarithmic scale to the number of scheduled actions remaining in π0≥ _0^≥, which is the subsequence of π0 _0 containing all actions with start time ≥ surprise time (T). 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^-310−210^-210−110^-110010^010110^1Actions remaining at T: |π0≥|| _0^≥|Re-plan runtime (s)Evacuee IncreaseRoute Blockage Figure 10: Re-planning runtime against residual plan length |π0≥|| _0^≥| at T (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 M in Figure 11. Route blockage instances are largely unaffected: the mean increase is only 3.2%3.2\% (median 0.9%0.9\%), with 19 of 24 instances below 7%7\%, because rerouting typically requires only localised vehicle reassignment. Evacuee increase perturbations are far more variable: the mean rises to 15.7%15.7\% with a standard deviation of 33.7%33.7\%, reflecting the wide range of survivor-count increases imposed across instances. Notably, several large instances yield negative ΔM 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 Blockage Figure 11: Percentage change in total makespan after replanning, relative to π0 _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. 7 Discussion 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 in t time units rather than t′t with t′>t >t may 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. 8 Conclusion 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. 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 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]. Availability refsize The data supporting the findings of this study are available from the corresponding author upon reasonable request. Availability refsize The source code used in this work is publicly available at the repository https://github.com/islammonjurul/fresched. References Ambily et al. (2024) P. Ambily, N. Chithra, and C. Mohammed Firoz A framework for urban pluvial flood resilient spatial planning through blue-green infrastructure. International Journal of Disaster Risk Reduction 103, p. 104342. Cited by: §1. Chang et al. (2007) M. Chang, Y. Tseng, and J. Chen A scenario planning approach for the flood emergency logistics preparation problem under uncertainty. Transportation research part E: logistics and transportation review 43 (6), p. 737–754. Cited by: §1. Fox and Long (2003) M. Fox and D. Long PDDL2. 1: an extension to pddl for expressing temporal planning domains. Journal of artificial intelligence research 20, p. 61–124. Cited by: §1, §2.1, §2.1, §2.2.1. Ghallab et al. (1998) M. Ghallab, A. Howe, C. Knoblock, D. McDermott, A. Ram, M. Veloso, D. Weld, and D. Wilkins Pddl—the planning domain definition language. Technical Report, Tech. Rep.. Cited by: §1, §2.2.1. Ghallab et al. (2004) M. Ghallab, D. Nau, and P. Traverso Automated planning: theory and practice. Elsevier. Cited by: §1, §2.1. Islam et al. (2025) M. M. Islam, S. B. Noor, and F. H. Siddiqui RAPID: resilient automated planning for intelligent disaster response. In 2025 2nd International Conference on Next-Generation Computing, IoT and Machine Learning (NCIM), p. 1–6. Cited by: §1. Jia et al. (2022) H. Jia, F. Chen, D. Pan, E. Du, L. Wang, N. Wang, and A. Yang Flood risk management in the yangtze river basin—comparison of 1998 and 2020 events. International Journal of Disaster Risk Reduction 68, p. 102724. Cited by: §1. Kapucu and Garayev (2011) N. Kapucu and V. Garayev Collaborative decision-making in emergency and disaster management. International Journal of Public Administration 34 (6), p. 366–375. Cited by: §1. Meyer et al. (2012) V. Meyer, S. Priest, and C. Kuhlicke Economic evaluation of structural and non-structural flood risk management measures: examples from the mulde river. Natural Hazards 62 (2), p. 301–324. Cited by: §1. Rutherford et al. (2024) G. Rutherford, J. Kirkpatrick, A. Davison, and V. Prahalad Can 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 Management 31 (4), p. 431–447. Cited by: §1. Sayers et al. (2013) P. Sayers, L. Yuanyuan, G. Galloway, E. Penning-Rowsell, S. Fuxin, W. Kang, C. Yiwei, and T. Le Quesne Flood risk management: a strategic approach. Asian Development Bank, GIWP, UNESCO and WWF-UK. Cited by: §1. Schanze (2006) J. Schanze Flood risk management–a basic framework. In Flood risk management: Hazards, vulnerability and mitigation measures, p. 1–20. Cited by: §1. Simonovic and Ahmad (2005) S. P. Simonovic and S. Ahmad Computer-based model for flood evacuation emergency planning. Natural Hazards 34, p. 25–51. Cited by: §1. Smith et al. (2008) D. E. Smith, J. Frank, and W. Cushing The anml language. In The ICAPS-08 Workshop on Knowledge Engineering for Planning and Scheduling (KEPS), Vol. 31. Cited by: §1, §2.2.2. Wang et al. (2024) W. Wang, Y. Li, Y. Zhang, and Z. Wu Pedestrian evacuation planning under dam-break flood disaster considering road risk and road pedestrian demand. International Journal of Disaster Risk Reduction 104, p. 104355. Cited by: §1. Ye et al. (2021) X. Ye, S. Wang, Z. Lu, Y. Song, and S. Yu Towards an ai-driven framework for multi-scale urban flood resilience planning and design. Computational Urban Science 1, p. 1–12. Cited by: §1. Yin et 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 Water 2 (3), p. 274–284. Cited by: §1.