Thinking Forward and Backward: Effective Backward Planning with Large Language Models

## Abstract

Abstract Large language models (LLMs) have exhibited remarkable reasoning and planning capabilities.
Most prior work in this area has used LLMs to reason through steps from an initial to a goal state or criterion, thereby effectively reasoning in a forward direction.
Nonetheless, many planning problems exhibit an inherent asymmetry such that planning backward from the goal is significantly easier — for example, if there are bottlenecks close to the goal.
We take inspiration from this observation and demonstrate that this bias holds for LLM planning as well: planning performance in one direction correlates with the planning complexity of the problem in that direction. However, our experiments also reveal systematic biases which lead to poor planning in the backward direction.
With this knowledge, we propose a backward planning algorithm for LLMs that first flips the problem and then plans forward in the flipped problem. This helps avoid the backward bias, generate more diverse candidate plans, and exploit asymmetries between the forward and backward directions in planning problems — we find that combining planning in both directions with self-verification improves the overall planning success rates by 4-24% in three planning domains.
Code: github.com/irom-princeton/llm-backward .

## 1 Introduction

Large Language Models (LLMs) are increasingly capable in reasoning tasks — they can perform commonsense reasoning in a broad set of contexts (Kojima et al., ), reason about abstract patterns in data (Mirchandani et al., ), and learn to reason from human feedback (Liang et al., ). Such capabilities also open up the possibility of LLMs performing long-horizon planning (Valmeekam et al., ), where the model needs to reason about how the initial state and final goal of the problem can be connected through intermediate steps.
Most existing work has explored such problems by asking the model to reason in the *forward* direction, i.e., generating intermediate steps from the initial state to the final goal.
However, in many planning problems, there is an inherent *asymmetry*: generating the correct last steps leading to the goal can be much easier than generating the correct steps from the beginning.
This leads to the question: *can LLMs plan better if they also reason in the backward direction?*

As an example, consider a robot navigating in a room (Fig. 1): if the final goal is the bedroom at the end of a long and narrow hallway, it is natural to connect the bedroom with the beginning of the hallway first in the plan, and then search for the path that connects the hallway to the initial state. In this example, there is a “bottleneck" that causes the asymmetry: the number of possibilities when planning backward from the goal is constrained by the bottleneck (hallway), while the possibilities fan out quickly when planning from the start. Such bottlenecks are ubiquitous in planning problems; for example, in proving mathematical theorems (Loveland, ), there may be many possible steps to start a proof of a theorem, but the final steps can be much more closely related to the theorem statement and thus easier to choose. In our experiments, we quantify this bottleneck effect by comparing the exact number of search steps used by common forward-search algorithm (e.g., Breadth-First Search) when applied in the forward and backward directions on the underlying graph of the planning problem (Fig. 1).

Figure: Figure 1: (Left) In planning problems such as navigation, it can often be easier to plan in the backward direction, especially when a “bottleneck” state (red node) exists and it is easier to find it from the goal rather than from the initial state. We consider Graph Planning, where the LLM needs to plan the shortest path from the initial node to the goal. (Right) Two other planning domains: Array Transformation, where an integer array is manipulated through different functions to the desired array, and Blocksworld, where stacks of blocks are re-oriented to the goal state.
Refer to caption: x1.png

The goals of this paper are twofold. First, we perform extensive experiments on three classical planning problems (Section 2) and examine whether LLM-based planning is significantly impacted by the asymmetry described above, i.e., if LLMs achieve higher planning success rates in the direction (forward/backward) where fewer computations are needed. Second, we study whether LLMs can exploit bottleneck effects by effectively planning backward (Section 3).
Our results provide strong evidence for the first hypothesis. However, unfortunately, we find that LLMs exhibit a systematic bias of performing worse when planning backward; this may be attributed to the forward autoregressive nature of LLM output generation, as well as biases from the training dataset.

Addressing the backward reasoning bias, we propose a simple solution (Section 4): many problems can be transformed such that the original goal becomes the initial state and the original initial state becomes the goal — we ask LLMs to first “flip” the problem, and then plan in the forward direction (corresponding to the original backward direction). Given a planning problem, we ask LLMs to sample possible plans in the forward direction of both the original problem and the flipped one, and then self-verify (Stechly et al., ) all the plans before choosing the final one. We find that this simple setup allows LLMs to generate many more diverse candidate plans and exploit the bottleneck structure of the problems, improving the overall success rate in multiple planning domains by 4-24% (Section 5). Perhaps surprisingly, we also present evidence that in certain settings LLMs can also *reason whether to flip* the problem or not by examining the problem structure.

## 2 Formulation and Planning Domains

We define a (text-based) planning problem as $P=(\mathcal{S},\mathcal{A}_{\mathcal{S}},s_{0},g,T_{\text{max}},f)$, where $\mathcal{S}$ is the space of possible states, $\mathcal{A}_{\mathcal{S}}=\{\mathcal{A}_{s}\}_{s\in\mathcal{S}}$ includes the space of possible actions (planned steps) at each state $s\in\mathcal{S}$, $s_{0}\in\mathcal{S}$ is the initial state, $g\in\mathcal{S}$ is the goal, $T_{\text{max}}$ is the maximum allowable steps, and $f$ is a ground-truth solution verifier that determines if a plan solves $P$, i.e., whether a plan connects $s_{0}$ to $g$, and possibly, is of optimal length.
The generated plan $A=(a_{0},...,a_{T})_{T\leq(T_{\text{max}}-1)}$ is verified by $f$ based on these rules. Each action $a_{t}$ converts state $s_{t}$ to $s_{t+1}$, and we denote this as $s_{t}\xrightarrow{a_{t}}s_{t+1}$.

We denote pre-trained LLMs with parameters $\theta$ as $p_{\theta}$. Instead of the usual token-level generation, for convenience we consider LLMs generating the next step in a plan by sampling $a_{t}\sim p_{\theta}(a_{t}|s_{0},g,\{a_{0},...,a_{t-1}\},q)$, where $q$ denotes the rest of the text prompt (e.g., few-shot exemplars and instructions). For convenience, from now on we also assume that $q$ includes text descriptions of $s_{0}$, $g$, and $(a_{0},...,a_{t-1})$. During planning, LLMs may also generate other intermediaries such as the estimated states along the plan $(\hat{s}_{1},...,\hat{s}_{t})$, which might help the LLM reason about the next step given the current estimated state.

Next we introduce the three different planning domains (Fig. 1) considered in our work. Appendix A provides more details on the design of these domains.

#### Graph Planning.

In Graph Planning, each problem consists of a graph with $N$ nodes (labeled with a number $1,...,N$). Each pair of nodes is connected with an edge with probability $\rho$; we consider both undirected and directed graphs. The initial state $s_{0}$ and goal $g$ are two different nodes. In order to vary difficulty, randomly generated graphs are filtered such that the shortest path from $s_{0}$ to $g$ has length $K$. In this domain, we consider a plan correct if it is optimal, i.e., shortest among paths between $s_{0}$ and $g$. We use a text-based *incident representation* for graphs (e.g., “Node 1 is connected to 2, 3”), which has been shown to be effective in the context of LLMs solving graph problems (Fatemi et al., ).

#### Array Transformation.

In Array Transformation, the LLM is asked to convert an initial array of integers of length $N$ to a goal array, e.g., from $[0,1,3]$ to $[1,0,3,1,0,3]$, using a set of array functions. We consider functions including: repeat to repeat the array once, cut to cut the array in half if the first half matches the second half, shift_left and shift_right to shift the array to the left by one (e.g., $[0,1,3]\rightarrow[1,3,0]$) or to the right, reverse to reverse the array, and swap to swap the first and last elements. Notice that each function has an inverse. We generate the problems by randomly sampling an initial array and a set of $K$ functions which are applied to obtain the final array. We consider a plan correct if it is valid, i.e., if planned functions convert the initial array to the goal. This domain can also be seen as a form of probabilistic context-free grammar (PCFG) (Sipser, ).

#### Blocksworld.

Blocksworld is part of the PlanBench benchmark introduced by Valmeekam et al. () for examining the overall planning capabilities of LLMs. In each problem, there are four blocks colored red, yellow, blue, or orange. The initial and goal states involve different possible stacks of the blocks, and the possible actions include unstack <color> block from <color> block, pick up <color> block (from table), put <color> block on <table>/<color> block.
We consider a plan correct if it is valid, i.e., if the planned steps move the initial stack to the goal.

## 3 LLMs Cannot Plan Backward As Effectively As Forward

As described in Section 1, many planning problems have an asymmetry that makes a given direction (forward vs. backward) easier for classical planning algorithms such as breadth-first search (BFS). Here, we examine whether the planning performance of LLMs is similarly impacted, and if the LLM’s performance in a given planning direction can be predicted by the number of search steps required by BFS in that direction.
If this is the case, it opens up the possibility of improving LLM-based planning by planing backward when the backward direction is favorable. Below we first introduce the backward planning algorithm we use for LLMs before showing the experimental results.

Figure: Figure 2: Sampling in forward or backward direction and then self-verifying the plans in Array Transformation.
Refer to caption: x2.png

### 3.1 Backward planning

During backward planning, the LLM is given the same initial and goal states, but the prompt $q$ asks it to generate the plan $A$ in the reversed order. For example, consider an instance of Graph Planning where the shortest path from Node $1$ to Node $3$ is $(1,5,2,3)$; then, the LLM should first output the backward plan as $(3,2,5,1)$ and reverse the order before it proposes the plan to the verifier.
As described in Section 1, backward planning can be useful when the search space from the goal is smaller than from the initial state. We can quantify the asymmetry between forward and backward planning by computing the number of search steps used by algorithms such as BFS in either direction.

### 3.2 Algorithm: Sample forward (backward) then self-verify

While the basic version of LLM planning involves asking it to generate a single plan, we consider a more robust version where the LLM first samples multiple candidate solutions in one direction, and then self-verifies them to choose the final solution; then the verifier $f$ checks the final plan.
In both stages, the LLM is shown few-shot exemplars to familiarize itself with the problem and to learn to verify the candidate plans step by step. The overall algorithm is illustrated in Fig. 2. Given the maximum number of attempts $M$, the sampling temperature of the LLM is set to be 0 0 for the first attempt, and nonzero for the later ones. Self-verification works differently depending on the domain: in Graph Planning, since the solution needs to be optimal, we save all the unique candidate plans $\{A_{j}\}$ after all $M$ attempts, and then present all of them to the LLM and ask it to verify them as well as to choose the optimal one; in Array Transformation and Blocksworld, since the solution does not need to be optimal, the LLM verifies each candidate plan as soon as it is sampled, and either stops when it deems one plan correct or after all attempts. For all the experiments, we use the GPT-4o model from OpenAI unless noted otherwise.

### 3.3 Results

#### LLM plans better in the easier direction.

Here we run experiments with both directed and undirected graphs in Graph Planning, and ask the LLM to plan either forward or backward. We also compute the number of search steps used by BFS in both directions. Fig. 3 shows the planning success rates achieved by forward and backward planning at different levels of forward/backward difficulty (as quantified by BFS computations).
For either direction, the success rate is generally higher when the number of computations is lower in that direction. This finding suggests that LLM planning is akin to a forward-search algorithm such as BFS in terms of the difficulty of planning in a given direction, and thus can be potentially improved by planning backward when it is easier. We also find similar results with Array Transformation shown in Appendix B.

Figure: Figure 3: Success rates achieved by forward and backward planning in Graph Planning vs. difference between forward and backward BFS computations. The LLM plans better in the direction of fewer computations needed, but the forward direction outperforms backward in general.
Refer to caption: x3.png

**Table 1: Average planning success rate in forward vs. backward direction in each setting.**
| Domain | Forward | Backward |
| --- | --- | --- |
| Graph Planning (undirected) | 82.5<br>$\pm$2.7<br>% | 76.7<br>$\pm$3.0<br>% |
| Graph Planning (directed) | 38.5<br>$\pm$3.4<br>% | 29.7<br>$\pm$3.2<br>% |
| Array Transformation | 67.5<br>$\pm$3.3<br>% | 62.2<br>$\pm$3.4<br>% |
| Blocksworld | 39.5<br>$\pm$3.5<br>% | 20.5<br>$\pm$2.9<br>% |

#### LLM plans worse in the backward direction.

Next, we study the effectiveness of backward planning by examining whether the LLM can achieve the same level of planning success in the backward direction as compared to forward. We find that this is not the case. Fig. 3 shows that the backward success rate is consistently lower than forward. We also calculate the average planning success rates for all four settings (from experiments in Section 5) — as shown in Table 1, the LLM consistently plans worse in the backward direction. We conjecture that this bias may be attributed to the forward (i.e., left to right) autoregressive nature of LLM output generation, as well as biases from the training dataset. Next we propose a solution to such backward bias and allow LLMs to plan effectively in the backward direction (*Flip* in Fig. 3).

## 4 Proposed Solution: Plan Backward by Flipping the Problem

If the LLM cannot plan backward as well as forward, how can it effectively exploit the backward direction in planning? We propose a simple solution: *flip* the problem such that the original goal becomes the new initial state and vice versa. The LLM can then plan in the forward direction for the flipped problem, which corresponds to the backward direction of the original problem. This avoids the bias of weak LLM planning in the backward direction. However, there are a few subtleties that must be taken care of when flipping the planning problem.

#### Change of the state-dependent action space.

In some cases, $\mathcal{A}_{\mathcal{S}}$ needs to be adjusted for the flipped problem. For example, with a directed graph, an edge from Node $1$ to Node $3$ in the original problem corresponds to an edge from Node $3$ to Node $1$ in the flipped problem — Node $3$ might not be reachable from Node $1$ in the flipped problem. In contrast, there is no change needed for undirected graphs, Array Transformation, and Blocksworld. With directed graphs, we prompt the LLM to first generate the new text representation of the graph (Fig. 4 right), and then generate a plan for the flipped problem.

#### Flipping back the plan.

After the plan $A^{\prime}$ for the flipped problem is generated, steps within it need to be reversed in order and also often “flipped back” to generate a forward plan for the original problem:

$$ $\text{Flip back the plan:}\ A^{\prime}=\{a^{\prime}_{0},...,a^{\prime}_{T}\} \mapsto A=\{a_{T},...,a_{0}\},\text{where}\ s_{t}\xrightarrow{a^{\prime}_{t}}s _{t+1},s_{t+1}\xrightarrow{a_{t}}s_{t}.$ (1) $$

We assume that each action $a\in\mathcal{A}_{s}$ can be inverted, i.e., if $s\xrightarrow{a}s^{\prime}$, there exists $a^{\prime}\in\mathcal{A}_{s^{\prime}}$ such that $s^{\prime}\xrightarrow{a^{\prime}}s$.
In practice, we prompt the LLM to generate the corresponding $a_{t}$ after it generates $a^{\prime}_{t}$. Fig. 4 left shows an example for Blocksworld: the action “put yellow on red” is flipped back to “unstack yellow from red”, after the order of the plan is flipped.

Figure: Figure 4: Flipping the problem and then plan in the new forward direction in Blocksworld (left) and Graph Planning with directed graph (Right).
Refer to caption: x4.png

#### Algorithm: Sample forward and flipped plans, then self-verify.

Extending the algorithm from Section 3.2 where multiple plans in the forward or backward directions are sampled before self-verifying them, we can now sample in the forward direction of the flipped problem, instead of sampling backward in the original problem. Sampling forward with the original *and the flipped* problem generates more diverse solutions for self-verification, while avoiding the backward bias and potentially exploiting asymmetries. We can either randomly sample the problem (original or flipped) at each attempt, or prompt the LLM to reason which direction is favorable.

## 5 Experiments with flipping the problem

With experiments in the three planning domains introduced in Section 2, we investigate the following questions in the corresponding subsections below:

- Q1:
Does flipping the problem help improve the planning success rate?
- Q2:
When does flipping the problem help the most?
- Q3:
How well can the LLM reason about when to flip the problem?

#### Baselines.

We compare a few different ways to sample candidate solutions before self-verification: (1) Fwd: only planning in the forward direction; (2) Back: only planning in the backward direction; (3) Flip: only planning in the forward direction of the flipped problem; (4) Fwd-Back: randomly choose either forward or backward direction and then plan; (5) Fwd-Flip: randomly choose either forward direction of the original problem or forward direction of the flipped problem and then plan; (6) Fwd-Flip-Reason: have the LLM reason whether to plan forward in the original or flipped problem and then plan.
We expect our proposed Fwd-Flip to outperform Fwd, Back, Flip, Fwd-Flip.

### 5.1 Backward planning with the flipped problem helps improve success rate

In order to test whether flipping the problem can help planning success rate, we run extensive experiments with the three planning domains and compare Fwd, Back, Flip, Fwd-Back, and Fwd-Flip. We use a maximum $M=6$ attempts for all experiments. Table 2 shows each result averaged over 200 trials. Flip outperforms Back and matches Fwd performance; we also see the similar trends in Fig. 3. In addition, Fwd-Flip consistently leads to the highest planning success rate, improving by 4-24% over Fwd, except for one setting where all baselines achieve close to 100% success. These results corroborate that flipping the problem mitigates the backward bias.

**Table 2: Planning success rate averaged over 200 trials for the five methods in the three planning domains. Flip matches Fwd. Fwd-Flip generally achieves the highest success rate.**
| Domain | Fwd | Back | Flip | Fwd-Back | Fwd-Flip |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Graph Planning | Directed? | $\rho$ | $N$ |  |  |  |  |  |
| No | 0.2 | 12 | 82.5<br>$\pm$2.7<br>% | 74.5<br>$\pm$3.1<br>% | 84.5<br>$\pm$2.6<br>% | 91.0<br>$\pm$2.0<br>% | 93.5<br>$\pm$1.7<br>% |  |
| No | 0.2 | 10 | 89.5<br>$\pm$2.2<br>% | 78.0<br>$\pm$2.9<br>% | 88.0<br>$\pm$2.3<br>% | 93.0<br>$\pm$1.8<br>% | 96.5<br>$\pm$1.3<br>% |  |
| No | 0.3 | 10 | 90.5<br>$\pm$2.1<br>% | 77.0<br>$\pm$3.0<br>% | 91.0<br>$\pm$2.0<br>% | 93.0<br>$\pm$1.8<br>% | 94.5<br>$\pm$1.6<br>% |  |
| Yes | 0.2 | 12 | 62.5<br>$\pm$3.4<br>% | 29.0<br>$\pm$3.2<br>% | 67.0<br>$\pm$3.3<br>% | 76.0<br>$\pm$3.0<br>% | 80.0<br>$\pm$2.8<br>% |  |
| Yes | 0.2 | 10 | 73.0<br>$\pm$3.1<br>% | 36.5<br>$\pm$3.4<br>% | 73.5<br>$\pm$3.1<br>% | 79.5<br>$\pm$2.9<br>% | 88.5<br>$\pm$2.3<br>% |  |
| Yes | 0.3 | 10 | 69.5<br>$\pm$3.3<br>% | 23.5<br>$\pm$3.0<br>% | 64.0<br>$\pm$3.4<br>% | 68.5<br>$\pm$3.3<br>% | 86.5<br>$\pm$2.4<br>% |  |
| Array Transformation | Functions |  |  |  |  |  |  |  |
| shift,<br>repeat,<br>cut | 99.0<br>$\pm$0.7<br>% | 98.5<br>$\pm$00.9<br>% | 99.0<br>$\pm$0.7<br>% | 100.0<br>$\pm$0.0<br>% | 99.5<br>$\pm$0.5<br>% |  |  |  |
| shift, reverse, swap | 50.0<br>$\pm$3.5<br>% | 36.0<br>$\pm$3.4<br>% | 52.0<br>$\pm$3.5<br>% | 46.0<br>$\pm$3.5<br>% | 56.0<br>$\pm$3.5<br>% |  |  |  |
| repeat, cut, reverse, swap | 53.5<br>$\pm$3.5<br>% | 52.0<br>$\pm$3.5<br>% | 53.0<br>$\pm$3.5<br>% | 54.5<br>$\pm$3.5<br>% | 56.5<br>$\pm$3.5<br>% |  |  |  |
| Blocksworld | - | 39.5<br>$\pm$3.5<br>% | 20.5<br>$\pm$2.9<br>% | 34.5<br>$\pm$3.4<br>% | 27.0<br>$\pm$3.1<br>% | 48.5<br>$\pm$3.5<br>% |  |  |

Figure: Figure 5: Fwd-Flip plans well even when the forward direction is difficult.
Refer to caption: extracted/5975387/figures/fwd-flip-diff.png

#### Fwd-Flip exploits asymmetries in the problems.

One of the main motivations of planning backward is that many planning problems have a bottleneck structure: there exists a less connected part of the state space near the initial state or the goal — this makes it easier to plan from the end closer to the bottleneck. In Fig. 5, we calculate the difference between forward vs. backward computations for BFS in Graph Planning, bin them, and find the success rate of each bin for Fwd and Fwd-Flip— the plot shows the average success rate over the three directed graph settings (shades show the minimum and maximum over the three). We find that Fwd tends to perform worse when the forward computations needed are higher, meaning that it cannot plan as effectively when the forward direction is more difficult. In contrast, Fwd-Flip maintains a similar level of success regardless of forward vs. backward planning difficulty.

#### Flipping the problem generates more diverse candidate solutions.

The improved performance of Fwd-Flip over Fwd can also be partly attributed to the generation of more diverse solutions.
Fig. 6 compares Fwd vs. Fwd-Back vs. Fwd-Flip in Array Transformation and shows both the average number of unique candidate solutions generated (top) and the planning success rate (bottom) vs. the number of planning attempts, $M$. Fwd-Flip generates a higher number of unique candidates, and improves the planning success rate by a large margin. Fig. 7 (left) shows an example where Fwd fails to solve the block task due to a persistent error (trying to move a block before “unstacking” it, which is not allowed by the rules of Blocksworld) even with significant sampling temperature (0.4), while Fwd-Flip generates a different solution and avoids the error.

Figure: Figure 6: Fwd-Flip generates diverse solutions and improves success rate.
Refer to caption: extracted/5975387/figures/diversity_success.png

### 5.2 Improvement from flipping the problem varies

#### Effect of backward success rate without flipping.

While in Section 5.1 we have shown that flipping the problem helps the LLM exploit asymmetries between forward and backward planning, we tend to find that the performance difference between Fwd-Flip and Fwd-Back varies substantially in Array Transformation (Table 2). When functions repeat and cut are used, Back does not perform significantly worse than Fwd— we believe this is due to the backward step being easily recognizable by Back (Fig. 7 right) when the initial and goal array sizes differ (since repeat and cut change them). In this case, Fwd-Flip does not improve much over Fwd-Back. With functions shift_left|right, reverse, swap that do not change array sizes,
we see a much more significant backward bias (53.5% vs. 36% between Fwd and Back) and there is a bigger margin between Fwd-Flip and Fwd-Back (56% vs. 46%).

Figure: Figure 7: (Left) Flipping the problem helps LLM avoid persistent error in one direction. (Right) With functions cut and repeat used in Array Transformation that change the array size, it can become obvious that one of them has to be used, which makes backward planning easier.
Refer to caption: x5.png

#### Effect of LLM capability.

We also hypothesize that the effect of planning in the flipped problem also depends on the inherent capability of the LLM. First, regardless of the choice of the LLM, Fwd-Flip should consistently improve the success rate. In Fig. 8 we run GPT-3.5-turbo and GPT-4-turbo besides GPT-4o with a directed graph setting and in Blocksworld, and we see that Fwd-Flip consistently outperforms Fwd. We also find that the design choices of the algorithm can affect the performance, and we highlight two aspects below:

Figure: Figure 8: Planning performance of different LLMs with Fwd and Fwd-Flip in (directed) Graph Planning and Blocksworld. Flipping the problem helps all LLMs plan better, and better LLMs reduce errors when executing the algorithm.
Refer to caption: x6.png

- •
Reliability of self-verification: while we allow the LLM to generate multiple candidates (in either direction), it can only present a single solution after it self-verifies the candidates. Hence, the LLM needs to reliably self-verify the candidate plans to achieve a high success rate. In addition to the success rate, Fig. 8 shows the self-verification error rate. We find that the self-verification error reduces as the LLM becomes more capable. In Blocksworld, we find that GPT-3.5-turbo always self-verifies its sampled plan to be correct, leading to close to zero success rate.
- •
Reliability of flipping the state-dependent action space: in Section 4 we described how flipping the problem requires flipping back the plan and possibly changing the state-dependent action space. While we find that the LLM can flip back the plan itself without error, sometimes it can be error-prone when flipping the action space, affecting the performance of Flip and Fwd-Flip. In Graph Planning with directed graphs, flipping the problem involves flipping the edges and re-ordering them — Fig. 9 shows an example. Possible errors in re-ordering the edges cause Flip to under-perform Fwd in some of the directed graph settings, while Flip always matches Fwd with undirected graphs.

Figure: Figure 9: When flipping the directed graph, we find it is helpful to re-order the flipped edges such that they appear in the order of “Node 0”, “Node 1”, etc., to achieve better success rate. However, this also introduces possible error, causing Flip to under-perform Fwd sometimes and affecting Fwd-Flip.
Refer to caption: x7.png

Nonetheless, as Fig. 8 illustrates, these errors are reduced with better LLMs. Flipping the problem improves success rates significantly even with improvements in the underlying LLM, demonstrating the scalability of our method.

#### Effect of initial/goal asymmetry.

We also notice that in Blocksworld, Flip under-performs Fwd (Table 2). The reason is that while the initial states of the problems are completely specified (e.g., “yellow block on red block, orange block on blue block”), the goal can be partially specified (e.g., “red block on orange block”). This means that when the initial and goal states are flipped, the LLM needs to first generate a complete flipped initial state from the original goal state — planning with full initial and goal states can be more challenging than with full initial and partial goal states.

Figure: Figure 10: Fwd-Flip performs better given more planning attempts.
Refer to caption: extracted/5975387/figures/block_attempts.png

#### Effect of the number of planning attempts.

Lastly, we also find that the maximum number of planning attempts, $M$, can affect the relative performance between Fwd and Fwd-Flip— this is particularly true when Flip under-performs Fwd such as in Blocksworld due to the inital/goal asymmetry mentioned above. In Fig. 10 we show Fwd vs. Fwd-Flip as $M$ varies from 1 to 6 — Fwd-Flip under-performs Fwd slightly at $M=1$, but out-performs Fwd with $M>1$ with increasing improvements.

### 5.3 LLM can reason when to flip in certain settings

Figure: Figure 11: LLM can analyze the graph and choose the easier direction for planning in zero-shot.
Refer to caption: x8.png

With Fwd-Flip we randomly choose between the original and the flipped problem for each candidate solution. We now explore whether the LLM can also reason when to flip the problem — we hypothesize that the LLM can analyze the problem structure to some extent and reason whether the backward direction can be easier. We run experiments with one setting from each of the planning domains (Table 3); unlike previous experiments, here we use $M=1$ as we find that the LLM is often certain about the direction. We find that Fwd-Flip-Reason out-performs Fwd and Flip in undirected graphs. Fig. 11 shows an example where the LLM identifies the bottleneck near the goal and chooses to plan backward, leading to the correct answer. We then calculate the rate at which the LLM chooses the direction where the number of computations is lower and find that the LLM can choose the easier direction 78.5% of the time with undirected graphs and 60.5% of the time with directed graphs. However, with directed graphs, the LLM suffers from possible errors when flipping the problem, and thus Fwd-Flip-Reason with $M=1$ does not perform better than Fwd.

In Array Transformation and Blocksworld, since the problem asymmetry is less clear, we do not expect the LLM to find a better direction in general, and thus Fwd-Flip-Reason does not out-perform Fwd or Flip. Appendix A provides details on the prompts used to elicit LLM reasoning.

**Table 3: Planning success rate averaged over 200 trials for the five methods in the three planning domains when the LLM is asked to choose the direction to reason in. The maximum planning attempt $M$ is set to 1.**
| Domain | Fwd | Flip | Fwd-Flip-Reason |
| --- | --- | --- | --- |
| Graph Planning (Undirected) | 79.0<br>$\pm$2.9<br>% | 78.5<br>$\pm$2.9<br>% | 87.5<br>$\pm$2.3<br>% |
| Graph Planning (Directed) | 50.5<br>$\pm$3.5<br>% | 46.0<br>$\pm$3.5<br>% | 50.5<br>$\pm$3.5<br>% |
| Array transformation (shift, reverse, swap) | 18.5<br>$\pm$2.7<br>% | 19.5<br>$\pm$2.8<br>% | 16.5<br>$\pm$2.6<br>% |
| Blocksworld | 33.0<br>$\pm$3.3<br>% | 21.5<br>$\pm$2.9<br>% | 27.0<br>$\pm$3.1<br>% |

## 6 Related Work

#### Bidirectional planning.

It is well known in classical planning (LaValle, ) that searching and planning from the backward direction can often reduce the computations needed. Bi-directional search has been incorporated into popular sampling-based planners (e.g., rapidly-exploring random trees) (Jordan & Perez, ) and heuristics-based techniques (e.g., A*) (Kuroiwa & Fukunaga, ) to improve efficiency.

#### Planning with LLMs.

LLMs have been widely applied in different planning problems () such as text games (Yao et al., ; Wang et al., ), robot planning (Huang et al., ; Ahn et al., ; Ren et al., ), scientific experimentation (Wang et al., ), and web navigation (Deng et al., ) — their strong planning capabilities originate from pre-training with enormous amounts of text data, which elicits reasoning capabilities (Wei et al., ). Beyond simple zero- or few-shot learning, LLMs have also been combined with classical planners (Liu et al., ; Silver et al., ) and external tools (Zeng et al., ) to further boost performance. However, no previous work has systematically studied asymmetries between forward and backward planning for LLMs, or leveraged backward reasoning to improve LLM planning.

#### Backward reasoning in LLMs.

Despite not being applied in planning problems, backward reasoning has been used with LLMs for self-verifying forward-sampled solutions to math problems (Jiang et al., ). Another line of work (Kazemi et al., ; Lee & Hwang, ) applies backward chaining, which recursively breaks the target into sub-targets based on defined rules, mostly for verifying a statement or proof. Our work instead proposes a general solution to planning problems using both forward and backward reasoning, and is motivated by a systematic examination of asymmetries in forward and backward planning for LLMs.

## 7 Conclusion and Future Work

In this work, we investigate how to enable LLMs to effectively plan in the backward direction from the desired goal to improve the overall planning success rate. First, our experiments reveal consistently worse performance of LLMs when planning backward. To address this, we propose instructing the LLM to flip the problem first and then plan forward in the flipped problem. Combined with self-verification, we find that generating candidate solutions from both directions improves planning success rates by 4-24% over forward-only planning in three different domains.

One immediate future direction is to better teach LLMs to reason and plan backward, e.g., by fine-tuning with correct forward and *backward* reasoning traces (Zelikman et al., ). We also believe that our framework of combining forward and backward reasoning can be extended to general reasoning problems, e.g.,
allowing LLMs to generate more diverse reasoning traces from the backward direction (Yao et al., ), or, enforcing reasoning self-consistency from both forward and backward directions (Wang et al., ).

## Acknowledgments

This work was partially supported by the Sloan Fellowship, NSF CAREER Award [#2044149], and the Office of Naval Research [N00014-23-1-2148].

## Appendix A Appendix - Planning Domains

We provide all codes needed to replicate the experiments in the attached supplementary materials.

### A.1 Graph Planning

#### Configurations.

To generate the desired graphs, we use gnp_random_graph function from the networkx package, with which we specify $N$, the number of nodes, $\rho$, the probability of two nodes are connected with an edge, and whether the edges are directed or not. We also apply rejection sampling to ensure the shortest path involves a total of five nodes. The the initial and goal nodes are sampled randomly from the graph.

#### Prompts.

For both the prompts for sampling the candidate plans and self-verifying them, we randomly generate three similar graphs as few-shot examples (LABEL:listing:graph-sample-prompt, LABEL:listing:graph-verify-prompt). With directed graph, we also prompt the model to re-order the flipped edges such that the graph still starts with “Node 0 points to …” instead of “Node 7, 9 points to 0”, if the original problem has “Node 0 points to 7, 9.” ( LABEL:listing:graph-reorder-prompt), which we find improve the planning success with the flipped problem. LABEL:listing:graph-reason-prompt shows the prompt used for eliciting LLM’s preference over the planning directions in zero-shot. We use temperature $T=0$ for re-ordering, self-verifying, eliciting preference, and the first planning attempt, and $T=0.5$ for the rest of planning attempts.

Figure: Listing 1: Sample prompt used in Graph Planning for sampling candidate solution. We use “is connected to” for edges in undirected graphs, and “points to” for edges in directed graph. For backward planning, we use “Plan the shortest path from goal to initial node…” as the final instruction.

Figure: Listing 2: Sample prompt used in Graph Planning for self-verifying the candidate solutions.

Figure: Listing 3: Sample prompt used in Graph Planning for re-ordering the flipped directed graph. The example here is the same for all problems

Figure: Listing 4: Sample prompt used in Graph Planning for eliciting LLM’s preference over the planning directions in zero-shot.

### A.2 Array Transformation

#### Configurations.

There are six possible functions used: repeat, cut, shift_left, shift_right, reverse, and swap. Depending on the set of functions used (e.g., {repeat, cut, shift_left, shift_right}), we first sample an random array of size 4 as the initial array, sample a random set of three functions, and then apply these functions to the initial array to get the goal one — if cut is sampled, we then first invert all the functions, reverse the order, apply the functions, and then reverse the initial and goal arrays. We limit that repeat can appear only once among the three to ensure the goal array is not too long.

#### Prompts.

The prompts used for sampling candidate solutions and self-verifying them are shown in LABEL:listing:array-header-prompt, LABEL:listing:array-plan-prompt, and LABEL:listing:array-verify-prompt. LABEL:listing:array-reason-prompt shows the prompt used for eliciting LLM’s preference over the planning directions in zero-shot. We use temperature $T=0$ for self-verifying, eliciting preference, and the first planning attempt, and $T=0.5$ for the rest of planning attempts.

Figure: Listing 5: Header used in the prompt for Array Transformation. The functions shown depend on the set of functions used.

Figure: Listing 6: Sample prompt used in Array Transformation for planning candidate solutions, excluding the header.

Figure: Listing 7: Sample prompt used in Array Transformation for self-verifying the candidate solutions, excluding the header.

Figure: Listing 8: Sample prompt used in Array Transformation for eliciting LLM’s preference over the planning directions in zero-shot, excluding the header.

### A.3 Blocksworld

#### Configurations.

We use the problems from the task_1_plan_generation task (validity) in the PlanBench benchmark (Valmeekam et al., ) without modifying them.

#### Prompts.

LABEL:listing:block-original-prompt shows the original prompt from the benchmark. However, we find LLM often struggle to plan by following the examples in the original prompt, often mistaking the correct initial state. Instead, we use a two-step approach where LLM first summarizes the initial conditions into short format (e.g., “yellow on red; blue; orange”) (LABEL:listing:block-summarize-prompt), and then plan — during planning, LLM generates intermediate states in short form to help it reason the next steps (LABEL:listing:block-plan-prompt). LABEL:listing:block-reason-prompt shows the prompt used for eliciting LLM’s preference over the planning directions in zero-shot. We use temperature $T=0$ for self-verifying, eliciting preference, and the first planning attempt, and $T=0.4$ for the rest of planning attempts.

Figure: Listing 9: Original prompt (header, example, and current problem) from the PlanBench benchmark used in Blocksworld. Notice that the goal state can be partial.

Figure: Listing 10: Sample prompt used in Blocksworld to summarize the initial and goal state, excluding the header.

Figure: Listing 11: Sample prompt used in Blocksworld to plan the steps.

Figure: Listing 12: Sample prompt used in Blocksworld to elicit LLM’s preference over the planning directions in zero-shot, excluding the header.

## Appendix B Appendix - Additional Results

Figure: Figure 12: Success rates achieved by forward and backward planning in Array Transformation vs. difference between forward and backward BFS computations. In general LLM plans better in the direction of fewer computations needed, but the forward direction outperforms backward. In the last set of experiments, we find Back works well by recognizing arrays that should be repeated or cut, and thus there is no visible difference between Fwd and Back.
Refer to caption: x9.png

## Peer Reviews

confidence: 4
contribution: 2
initial_rating: 3
presentation: 2
questions: 1. Are the results of Flip related methods based on the solution to the flipped problem or the original problem? If it is w.r.t the original problem, how are the errors distributed between the solution of the flipped problem being wrong and the flipping of the plan being wrong?

2. Is the flipped initial state in Blocksworld verified given that the LLM is generating a full state from the partial goal state?
soundness: 2
strengths: The paper conducts a thorough set of experiments to test whether flipping the initial and goal states of problems improves LLM performance. The authors also examine whether the LLM can reason about whether or not to flip the problem.
summary: The authors propose a method that uses large language models (LLMs) for planning by “flipping” the problem. In this approach, the initial and goal states are reversed, a plan is generated by the LLM, and then this plan is reversed to solve the original problem. The authors demonstrate that this method can enhance the planning performance of LLMs.
weaknesses: The impact of the proposed approach is somewhat unclear. For example, prior research [1] has shown that LLM planning performance significantly deteriorates when the syntax of the planning domain is obfuscated, even when the causal structure remains intact (referred to as “Mystery” domains in [1]). It would have been insightful to see how this approach performs in such obfuscated domains. This also suggests that the computational complexity of the underlying domain doesn’t necessarily affect LLM performance. Therefore, flipping the problem’s initial and goal states to reduce computational complexity might not necessarily benefit LLMs, as they may not be sensitive to these complexity reductions in the same way formal planners are.

Based on my understanding, the method described in Section 4 (always flipping the original problem) aligns with the “Flip” approach in Section 5. Flip performs worse than “Fwd” planning, contrary to what is suggested in Section 5. The proposed approach mentioned in Section 5 appears to be “FwdFlip,” where the decision to flip is made at random. It would be helpful to clarify the exact nature of the proposed approach. Additionally, it would be valuable to see details within the FwdFlip method, such as the success rates within Fwd and Flip respectively.

---

confidence: 4
contribution: 2
initial_rating: 5
presentation: 3
questions: 1.   What is it about some actions that make them non-invertible?  How does this affect your proposed method (which assumes that all actions are invertible)?
2.   Is it important that inverse actions are actually feasible actions that respect physics and make sense?  (e.g. if an action is to “drill a hole”, you can’t really un-drill a hole; does this even matter?).
3.	Bi-directional search is mentioned in related work, but it’s not mentioned at all in the text.  The approaches that involve both forward and backward planning seem very similar to bi-directional search and may warrant more discussion in the paper.  Are there lessons from bi-directional search that are relevant here?
4.	Doesn’t the Graph Planning domain have built in bias for directed graphs?  Meaning they may only be solvable in one direction?
5.	In the description of how planning problems are flipped; the authors assume that every action has an inverse action.  It’s not clear that this would always be true.  Could you please include discussion of this?  Could you give examples where there is not an inverse action?  (e.g. if an action is to “drill a hole”, you can’t really un-drill a hole can you)?
soundness: 2
strengths: The idea of flipping the problem has merit for some problems.  With more careful consideration of the general claims about the capabilities of LLMs (many of which actually seem problem dependent) and a more clear definition of which problems this will work for and which it will not, and why (including a discussion of what makes some actions non-invertible), this would be a strong paper.
summary: This paper uses LLMs for planning.  In particular it looks at the difference between planning forward (from initial state to the goal) vs planning backward (from the goal to the initial state), and notes that backward planning may work better for some problems.  For problems where backward planning is more efficient, the paper introduces a method for flipping the problem so that forward planning can be used from the goal to the initial state.  This leads to the question: Can LLMs plan better if they reason in the backward direction?”
weaknesses: Overall: Many general claims are made about the capabilities of LLMs (e.g. they exhibit a systematic bias towards forward planning), and these claims are backed by experiments.  However, it's not clear that the experimental results justify these broad claims.  Many of the experimental results seem very domain-dependent.  For example, Directed Graph Planning has a built in directional bias. 

1.	The paper uses the term “backward planning” but all the planning is actually in the forward direction, it’s just that sometimes they “flip” the problem (making the old goal the new initial state and the old initial state the new goal). 
2.  The method proposed for flipping the problem assumes that all actions can be inverted, and it is not clear that this is always the case (so the applicability of “flipping” will depend on whether or not the actions in the domain are, in fact, invertible). 
3.	Regarding the claims that “LLM exhibit a systematic bias of performing worse when planning backwards” may be attributed to the forward auto-regressive nature of LLM output generation or training data biases:  There is not enough evidence to support this as a general claim.  Experiments were conducted with only three domains, and at least one (Graph Planning) has by its very nature a built in bias in the forward direction.
4.	Figure 2 as an algorithmic description is not clear, and does not seem to match up with the text in lines 168-17.
5.	The general conclusions about LLMs drawn from the data presented in Figure 3 (LLMs plan better in the forward direction, and that flip solves this bias) seem suspect given that the directed case in this domain has a built in bias to forward planning so it’s not surprising at all that flip would do well in this case.  
6.	Also, regarding Figure 3; most of the cases where flip outperforms forward planning are also cases where backward planning already also outperformed forward planning.

---

confidence: 5
contribution: 1
initial_rating: 1
presentation: 2
questions: Question 1. What are the problem statistics of the three problem domains? They are all classical planning problems so we could see the action schema, and the number of state predicates to have a sense of the difficulty of the problem. What problem instances were tested? How many objects were tried? How the initial states and the goals were determined? It is not difficult to write down PDDL specifications for those problems.

Question 2. Given a state observation, how the next actions are generated? Are the next actions sound and applicable to each state always? 
How the next state is generated? How the goal test was done? 

Question 3. How the natural language reasoning version of the classical planning problems are obtained, for the graph planning an array transformation? Are they a natural description of the problem? Or is it utilizing artificial patterns? 

Question 4. Blocksworld problem would be the only single problem domain that has multiple goal states.
In regression planning, the difficulty is to maintain a set of states instead of a single state if we proceed to perform a search. 
The experiment results also confirm such known issues. In the other two domains, regression modes are claimed to perform well. But I think it depends on the distribution of the initial state and the goal state, not the goal states here. I think if we simply flip the initial state and the goal state, we will obtain the opposite results. Could you explain this?
soundness: 1
strengths: This paper explores regression planning with LLMs. It seems like the authors are not aware of the literature on automated planning and classical AI, from what's written. so it is an attempt to re-invent the known results in the 70s to 90s in the context of large language models.
summary: This paper investigates the possible usage of LLMs as an automated planner for solving classical planning tasks (deterministic, fully observable). Especially, the paper studies the regression planning approach. The paper also proposes a heuristic approach that switches the initial state and the goal depending on the progress of solving the problem. Overall, experiments were conducted on path finding in graphs, array transformation, and the blocksworld domains.
weaknesses: This paper mentions bidirectional search in the related work. However, it is mentioned nowhere in the paper about regression planning. "Thinking forward and backward" reminds me of a fancy title "Thinking fast and slow" and the title also shows effective backward planning. However, it is doubtful if that's the case.
If we hold back and remove the LLM portion, then the paper suggests solving planning problems by alternating the initial state and the goals. In general, goals are not a single state as the initial state in most of the problems. It is doubtful how such a switching strategy can lead to systematic improvement as we can always choose one of the goal states as a new initial state in a different problem. 
One of the weaknesses here is the lack of coverage of the relevant literature.

There are several misleading statements such as 
"classical planning algorithms such as BFS" line 141. ==> BFS is not a classical planning algorithm
"bottleneck" reminds me of the concept of information bottleneck in information theory. However, it is not relevant to this context.
It is not clear whether the "bottleneck effect" is relevant in this context.


The details of the implementation of the planner are vague. 
How possible actions are generated? How the next state will be generated given actions?

---

confidence: 4
contribution: 2
initial_rating: 3
presentation: 2
questions: 1. "We expect our proposed Fwd-Flip to outperform Fwd, Back, Flip, Fwd-Flip." I think the last Fwd-Flip is a typo - it should be Fwd-Back right?
2. The method written in the introduction - "Given a planning problem, we ask LLMs to sample possible plans in the forward direction of both the original problem and the flipped one, and then self-verify (Stechly et al., 2024) all the plans before choosing the final one", is different from what was presented as the main method, which is **Fwd-Flip**. The description of **Fwd-Flip** given in the experiments is "randomly choose either forward direction of the original problem or forward direction of the flipped problem and then plan". This is very confusing because these are two totally different methods. I'd like the authors to clarify which is their main proposed method.
soundness: 2
strengths: 1. The paper's approach in developing the main method is, to a certain extent, systematic. It first verifies that some planning problems are easier solved from the backwards direction (due to smaller action spaces) then show that LLMs perform better in the direction which is easier. However, the paper also found that LLMs cannot plan well directly in the backward direction. Combining these two observations, the paper then introduces its method of flipping the backward problem.

2. The experimental results are laid out in a systematic manner, where each section tries to explain a certain statement or claim in the paper.  The experimental setup is also done well, although I have some comments about how the authors tried to link the results with certain claims (see next section).
summary: The paper first investigates the performance of LLMs on a set of planning problems where both forward and backwards planning can be done (3 domains are given in the paper: shortest path in graphs, array and Blocksworld). The paper measures the difficulty of planning in a particular direction with the size of search space (in that direction). Based on this, the authors empirically observe and claim in Sec. 3.3 that 1) LLMs, in general, plan better in the "easier" planning direction and 2) ceteris paribus, LLMs plan worse in the backwards direction as compared to the forward direction. The authors hypothesize that 2) "... may be attributed to the forward autoregressive nature of LLM output generation, as well as biases from the training dataset."

Then, the paper, in Sec. 4, proposes a method which flips the problem backwards and plan forward (while handling some subtleties) for the flipped problem. Combined with self-verification and some sampling, the experiments show that their method outperforms other baselines over the 3 planning domains.
weaknesses: I have several concerns regarding how claims in the papers are supported by the experiments. These concerns also impact the novelty and soundness of the authors' main method (**Fwd-Flip**).


1. The authors mentioned that **Fwd** is the standard forward planning method, **Flip** is applying the forward planning method to the flipped problem, and **Fwd-Flip** is "randomly choose either forward direction of the original problem or forward direction of the flipped problem and then plan". Therefore, the only difference between **Fwd-Flip** and **Fwd**/**Flip** is that instead of deciding which direction to plan, the planning direction is randomly selected. However, the experimental results in Table 2 show that **Fwd-Flip** achieves much higher success rate than **Fwd** or **Flip**. To me, this is result is questionable because if **Fwd-Flip** is just selecting **Fwd** or **Flip** randomly, how can it perform much better? In fact, I would expect, with just random sampling, **Fwd-Flip** to perform exactly the average of **Fwd** and **Flip**? I also noticed also that Fwd-Flip is different from what was written in the introduction, which is "Given a planning problem, we ask LLMs to sample possible plans in the forward direction of both the original problem and the flipped one, and then self-verify (Stechly et al., 2024) all the plans before choosing the final one". Could the authors clarify?


2. I also noticed that both **Fwd** and **Flip** (on their own) have similar performances over all planning tasks in Table 2. This implies that on average, flipping the problem has no benefits over the direct forward planning method. While I understand that the authors observed that certain planning directions could be easier in some tasks (due to difference in action spaces), it is clear from the experiment results that a particular planning direction is not inherently better in any of the tasks. Hence, I argue that the paper's main method, **Fwd-Flip** does not actually exploit this observation effectively. I have a suggestion on how the method can be improved: during test-time, we can cleverly decide whether the problem is easier if we flipped it (using some simple heuristics). Then, we can either apply **Fwd** or **Flip** based on our heuristic; this is more sound than **Fwd-Flip** proposed in this paper, which is simply selecting **Fwd** or **Flip** *randomly*. In later experiments, the authors do use the LLM to reason about which planning direction to use, but its effectiveness seems to be restricted to Undirected Graph Planning.


3. Some claims in the papers are briefly stated in words but are not clearly substantiated from the experiments. For example:
* Sec. 4 claims that flipping the problem "... avoids the bias of weak LLM planning in the backward direction." However, Figure 3 shows that for Directed Graphs, for problems with no difference in forward and backward computations, flipping still performs worse than the forward problem. So, it is unclear if flipping the problem entirely avoids the bias.
* There are results such as Figure 3 and Figure 10 that are used to justify the paper's claims that "... LLM plans better in the direction
of fewer computations needed, but the forward direction outperforms backward in general ...". However, they are only shown for one planning task (instead of the 3 domains which the paper claims its focus is on). Since the paper mainly relies on empirical observations to justify its claims, I think the same figure should be replicated for other tasks as well (especially that I noticed there are additional space available in the main paper).
* Table 3 tries to show that making the LLM decide which planning direction to use during test-time could improve performance. But somehow the table does not have the results for **Fwd-Flip**, the author's main proposed method for us to compare **Fwd-Flip-Reason** to. We also cannot just look at the previous results for **Fwd-Flip** because the authors mentioned that they used a different hyperparameter $M$ as compared to that in Table 2.

Meta-review: The paper explores the use of large language models for classical planning tasks. The authors propose a method where planning problems are "flipped" by reversing the initial and goal states. This approach, combined with self-verification and sampling, aims to improve planning performance by addressing perceived limitations of LLMs in backward planning. The authors conduct experiments across three planning domains: graph pathfinding, array transformations, and Blocksworld.

While this paper attempts to identify the challenges of backward planning in LLMs and proposes an intuitive solution (flipping problems) based on empirical observations, the reviewers raised several concerns:

- R1, R4 noted inconsistencies in the description of the proposed method.
- R3 pointed out that the method largely resembles classical planning techniques. R2, R4 also noted the absence of bi-directional search discussions, which are closely related to the proposed approach.
- Several general claims are not well-supported by experimental results (R2, R4).
- R4 raised concerns about experimental validity.
- The paper assumes invertibility of actions, which is a critical limitation (R2, R3).

Decision: Reject