# Iterative Planning with Plan-Space Explanations: A Tool and User Study

Rebecca Eifler and Jörg Hoffmann
Saarland University, Saarland Informatics Campus, Germany
{eifler<EMAIL_ADDRESS>
###### Abstract

In a variety of application settings, the user preference for a planning task
– the precise optimization objective – is difficult to elicit. One possible
remedy is planning as an iterative process, allowing the user to iteratively
refine and modify example plans. A key step to support such a process are
explanations, answering user questions about the current plan. In particular,
a relevant kind of question is “Why does the plan you suggest not satisfy
$p$?”, where $p$ is a _plan property_ desirable to the user. Note that such a
question pertains to plan space, i. e., the set of possible alternative plans.
Adopting the recent approach to answer such questions in terms of _plan-
property dependencies_ , here we implement a tool and user interface for
human-guided iterative planning including plan-space explanations. The tool
runs in standard Web browsers, and provides simple user interfaces for both
developers and users. We conduct a first user study, whose outcome indicates
the usefulness of plan-property dependency explanations in iterative planning.

##  1 Introduction

In many real life settings, like space mission control, production planning in
Industry 4.0, or robot-aided disaster recovery, typically not all goals,
constraints and preferences are known from the beginning. There may even be
different user groups with different preferences. Take for instance
researchers from different fields in a mission control center, who all have to
be satisfied with the plan. Given this setting, the traditional planning
workflow – select a set of goals, compute a plan, execute – is not adequate.
Instead, planning should support the users in making up their minds, exploring
plan space until they are satisfied.

PlannerPlan(s)UserGoalsConstraintsPreferencesPlan PropertiesMultipleQual.
distinctPlansPlanExplanationPlan Property Dependencies Figure 1:  Planning
viewed as an iterative process of plan revision under constraints. black:
generic description by Smith (?); red: our instantiation.

A natural framework for the latter is _planning as an iterative process_ (?),
as illustrated in Figure 1. This allows the human users to iteratively refine
their preferences and goals based on example plans. The possibility to provide
explanations, answering user questions about the current plan, is a key
feature in this setting. In particular, user questions of the form “Why does
the suggested plan $\pi$ not satisfy preference $p$?” are relevant. Such
explanations allow the user to develop a deeper understanding of the space of
plans. This in turn enables the user to refine his goals and preferences
accordingly.

Eifler et al. (?; ?), henceforth referred to as _Eif20_ , introduced a
framework addressing the problem of generating explanations via plan-property
entailments. A plan property $p$ is a Boolean function on plans, and $p$
entails $q$ if all plans that satisfy $p$ also satisfy $q$. The above stated
question could then be answered with “Because if you achieve $p$ you have to
forego $p^{\prime}$” . This is a form of contrastive explanation (?). Some
other works (?; ?; ?; ?) propose to answer such questions by highlighting the
differences between a plan $\pi$ not satisfying $p$ and an alternative plan
$\pi^{\prime}$ that does. Observe that both approaches naturally shed light on
the trade-off between different user preferences.

Eif20 assume that the set $P$ of plan properties is given as an input. They
then address oversubscription planning (OSP) (?; ?) where not all of $P$ can
be satisfied. Based on exclusion dependencies of the form $\bigwedge_{p\in
X}p\Rightarrow\neg\bigwedge_{p\in Y}p$ where $X,Y\subseteq P$, they are able
to answer the type of questions stated above. They also propose an _online_
version which allows to adapt the set $P$ during planning. Arguably, this
framework perfectly fits the iterative planning workflow described by Smith
(?). The goals, constraints and preferences can be expressed as plan
properties. Given this representation, the explanations are then naturally
given as plan property dependencies.

Here we contribute a Web-based iterative planning tool, realizing the workflow
suggested by (?) and instantiating the explanation part with Eif20’s
framework. The tool enables users to perform iterative planning with plan
properties representing goals and preferences. One can enforce selected plan
properties reflecting changing preferences across planning iterations, one can
ask questions about the iteratively refined plans, and one can add new plan
properties to hone in on new issues that become apparent during the iterative
planning process. To accommodate layperson users unfamiliar with planning, our
tool comprises a simplified version, with a fixed set of plan properties, and
with an enriched visualization of the planning task. The tool runs in standard
Web browsers, and provides simple user interfaces for both, case-study
developers and users.

We furthermore conduct a first user study evaluating our tool and therewith
providing the first user-based evaluation of Eif20’s framework. Specifically,
we evaluate the usefulness of Eif20’s explanation facilities, by comparing the
use of our tool with vs. without these facilities. While the user study is
small and preliminary, its outcome is encouraging, indicating the usefulness
of plan-property dependency explanations in iterative planning.

Section 2 gives some background on the planning formalism and Eif20’s
framework. Section 3 describes the tool implementation. The preliminary user
study is described and evaluated in Section 4. Section 5 lists work we want to
address in the future and concludes the paper.

##  2 Background

### Oversubscription Planning

Our framework is based on a finite-domain variable variant of oversubscription
planning (OSP) (?; ?). An OSP task is a tuple $\tau=(V,\allowbreak
A,\allowbreak{c},\allowbreak I,\allowbreak G^{\text{{hard}}},\allowbreak
G^{\text{{soft}}},\allowbreak{b})$ where $V$ is the set of variables, $A$ is
the set of actions, ${c}:A\to{\mathbb{R}}^{+}_{0}$ is the action cost
function, $I$ is the initial state, $G^{\text{{hard}}}$ ($G^{\text{{soft}}}$)
is the hard (soft) goal, and ${b}\in{\mathbb{R}}^{+}_{0}$ is the cost bound. A
state is a complete assignment to $V$; $G^{\text{{hard}}}$ and
$G^{\text{{soft}}}$ are partial assignments to $V$, defined on disjoint sets
of variables; each action $a\in A$ has a precondition $\mathit{pre}_{a}$ and
an effect $\mathit{eff}_{a}$, both partial assignments to $V$. We refer to
variable-value pairs $v=d$ as facts, and we identify partial variable
assignments with sets of facts. An action $a$ is applicable in a state $s$ if
$\mathit{pre}_{a}\subseteq s$. The outcome state $s[[a]]$ is the same as $s$
except that $s[[a]](v)=\mathit{eff}_{a}(v)$ for those $v$ on which
$\mathit{eff}_{a}$ is defined. The outcome state of an iteratively applicable
action sequence $\pi$ is denoted by $s[[\pi]]$. A plan is an action sequence
$\pi$ whose summed-up cost is $\leq{b}$ and where $G^{\text{{hard}}}\subseteq
I[[\pi]]$.

We follow Eif20 in not defining a plan utility over $G^{\text{{soft}}}$.
Instead, $G^{\text{{soft}}}$ is a set of plan properties – including more
general plan properties compiled into goal facts – and the analysis we provide
identifies dependencies between these plan properties. The underlying
assumption is that the user’s preferences over $G^{\text{{soft}}}$ are
difficult to elicitate, and not expressable in a utility function.

As our running example, consider the OSP task illustrated in Figure 2, based
on the IPC NoMystery domain where packages must be delivered respecting
limited fuel. The figure depicts the initial locations of trucks and packages.
Both trucks have initially 3 fuel units and each road section consumes 1 unit
of fuel. This is also the example we use in our preliminary user study.

01234 Figure 2: An illustrative NoMystery example.

### Eifler et al.’s Framework

Eif20 introduce a framework for plan-property dependency analysis in OSP
tasks, and algorithms for a specific instantiation of that framework. For the
work presented in the following, we only consider that instantiation,
simplifying Eif20’s concepts accordingly. In the next section, we outline the
definitions that build the foundation of our contribution.

Assume an OSP task $\tau=(V,\allowbreak A,\allowbreak{c},\allowbreak
I,\allowbreak G^{\text{{hard}}},\allowbreak
G^{\text{{soft}}},\allowbreak{b})$. In general, a plan property is a function
$p$ mapping action sequences $\pi$ in $\tau$ to Boolean values. Eif20’s
implementation only, considers plan properties $p$ that can be compiled into
goal facts. A plan $\pi$ satisfies a property $p$ iff the corresponding goal
fact $g_{p}$ is true in $I[[\pi]]$. They are interested in conjunctions
$\bigwedge_{g\in X}g$ of such plan properties, and specifically in exclusion
dependencies where $\bigwedge_{g\in X}g$ “entails” $\neg\bigwedge_{g\in
Y}g~{}~{}(X,Y\subset P)$.

Entailment here is intended as entailment _in the space of plans_. It is often
the case that all _plans_ which satisfy $X$ cannot satisfy $Y$. We denote by
$\Pi$ the set of plans for $\tau$. We say that $\pi\in\Pi$ satisfies a formula
$\phi$ over $G^{\text{{soft}}}$, written $\pi\models\phi$, if $\phi$ evaluates
to true under the truth value assignment where $g\in G^{\text{{soft}}}$ is
$\mathit{true}$ iff $g\in I[[\pi]]$. We denote by ${\cal
M}_{\Pi}(\phi):=\\{\pi\mid\pi\in\Pi,\pi\models\phi\\}$ the subset of plans
that satisfy $\phi$. We say that $\phi$ $\Pi$-entails $\psi$ if ${\cal
M}_{\Pi}(\phi)\subseteq{\cal M}_{\Pi}(\psi)$.

Applied to exclusion dependencies, this means that $\bigwedge_{g\in X}g$
$\Pi$-entails $\neg\bigwedge_{g\in Y}g$ if all action sequences in $\tau$
whose cost is within the bound $b$, that achieve $G^{\text{{hard}}}$, and that
achieve all $g\in X$, do not achieve at least one $g\in Y$.

The problem now is to compute all exclusion dependencies over
$G^{\text{{soft}}}$. This corresponds to preparing answers to all questions of
the form “Why does the plan not satisfy the properties in $X$?”.

To this end, observe that $\bigwedge_{g\in X}g$ $\Pi$-entails
$\neg\bigwedge_{g\in Y}g$ iff $\bigwedge_{g\in X\cup Y}g$ is unsolvable in
$\tau$. Observe further that, in this case, the same is true for every
$X^{\prime}\supseteq X$ and $Y^{\prime}\supseteq Y$, i. e., the exclusion
dependency is strongest for set-inclusion minimal $X$ and $Y$. Given these
observations, the problem boils down to computing all minimal unsolvable goal
subsets (MUGS): all sets $G\subseteq G^{\text{{soft}}}$ where $G$ cannot be
achieved but every $G^{\prime}\subsetneq G$ can.

The question “Why is the task not solvable?” can be seen as a special case of
goal exclusion $\bigwedge_{g\in X}g$ entails $\neg\bigwedge_{g\in Y}g$, where
$X$ is empty. In general the answer is constituted of all MUGS $\subseteq
G^{\text{{hard}}}$. In iterative planning setting an explanation focusing on
the latest changes leading to unsolvability, allows the user to precisely
evaluate his decision. Those are the MUGS $\subseteq G^{\text{{hard}}}_{i}$
which contain at least one plan property $p\in G^{\text{{hard}}}_{i}\setminus
G^{\text{{hard}}}_{i-1}$, where $G^{\text{{hard}}}_{i}$ are the hard goals in
iteration $i$.

For our example we consider the following plan properties:

  1. 1.

Package $0$ is delivered to the blue house.

  2. 2.

Package $1$ is delivered to the green house.

  3. 3.

Package $2$ is delivered to the blue house.

  4. 4.

Package $3$ is delivered to the orange house.

  5. 5.

Package $4$ is delivered to the post office.

  6. 6.

Package $4$ is delivered to the packing station.

  7. 7.

The road between the cafe and the packing station is not used by the red
truck.

  8. 8.

The same truck is used for package 0 and 2.

  9. 9.

The same truck is used for package 2 and 3.

  10. 10.

The blue truck visits the cafe.

  11. 11.

Package 0 is delivered before package 1.

The first six of these are standard goal facts; 7 to 11 can be expressed in
LTL, which can be compiled into goal facts using well-known techniques (?; ?;
?); 7 to 10 can also be expressed in a simple LTL fragment named _action set
properties_ by Eif20, for which a very compact compilation into goal facts is
possible (and that Eif20 use in their implementation whenever possible).

The MUGS in this example are
$\\{2,4,9\\},\allowbreak\\{2,6\\},\allowbreak\\{3,6,9\\},\allowbreak\\{3,8\\},\allowbreak\\{4,6,9,10\\},\allowbreak\\{4,7,9\\},\allowbreak\\{5,6\\},\allowbreak\\{5,7\\},\allowbreak\\{6,8,10\\},\allowbreak\\{7,8\\}\allowbreak$.
So, for example, the answer to the user question ”Why don’t you avoid driving
from the packing station to the cafe?”, could be answered using MUGS
$\\{7,8\\}$ ”Because then you can not deliver package 0 and 2 with the same
truck.”.

##  3 Tool Description

Figure 3: Tool overview: Iterative planning.

We implemented a Web based iterative planning tool. As a planner we use Fast
Downward (?) and as an explanation generator the implementation of Eif20. The
translation of plan properties to goal facts is realized using Eif20’s
definitions and implementations for LTL and action-set plan properties. A
demonstration of the platform can be found here https://youtu.be/M958F14HL8I.

#### Users

The tool is designed for two different user groups. Technically versed users,
familiar with computer science or AI planning; and layperson users, with no
computer science background. The adaptations for layperson users focus mainly
on the visualization of the planning task and plan properties. The part of the
tool dedicated to layperson users is designed to give the possibility to
conduct user studies.

### Overview

First, we want to give a general overview of the tool structure and the
provided functionalities. The tool has three main components, _projects_ ,
_demos_ and _user studies_.

A project consists of a planning task definition and plan properties
reflecting the goals and user preferences. It provides the full functionality
for iterative planning with online computed explanations. This includes:

  * •

enforcing selected plan properties reflecting changing preferences across
planning iterations

  * •

asking questions about the iteratively refined plans

  * •

adding new plan properties to hone in on new issues that become apparent
during the iterative planning process

A demo provides iterative planning with a fixed set of plan properties as a
simplified version to accommodate layperson users unfamiliar with planning. To
provide a graphical visualization of the planning task and plan you can add a
picture and a domain dependent animation respectively.

The platform supports conducting user studies with the online recruitment
platform Prolific (?). For user study developers it provides interfaces for
setting up and evaluating an user study. A user study can be composed of
multiple demos, links to external questionnaires and additional descriptions
and instructions.

### Input

Except for the visualization extensions for layer persons, the implementation
is domain independent.

#### Planning Task

The task definition is given by a standard PDDL (?) domain and problem file.
The problem file only defines the initial state. The definition of goals is
handled separately using plan properties. It is not possible to modify the
initial state or the action definitions during the iterative planning process.

#### Plan Properties

The plan properties reflect the goals, constraints and user preferences. They
have to be defined by a user. The platform offers two ways to define plan
properties. Firstly, users familiar with LTLf can define plan properties by
explicitly stating the corresponding LTLf formula and action sets.

Secondly, a domain expert can define domain dependent templates for plan
properties. These have to be provided with the domain and problem file. A
template maps a predefined natural language representation to the
corresponding LTLf formula. For example, the interface for the plan property
template ”The road between $L_{i}$ and $L_{j}$ is used with truck $T_{i}$” is
given in Figure 4. For every variable the type can be specified. Furthermore,
it is possible to impose constraints between the variables, like $L_{i}$ and
$L_{j}$ have to be connected. This allows to define plan properties more
easily as one only has to select the concrete instantiation.

Figure 4: Interface plan property creation.

Independent of their meaning, e.g. goals, constraints, preferences, all plan
properties are handled the same in the computation of plans and explanations.
Therefore, the interface does not differentiates between different types of
plan properties.

Initially, plan properties representing the already known goals and
constraints have to be provided by the user. As these might change or new
preferences might form during planning, it is possible to add more plan
properties reflecting these changes during planning.

A plan property can be declared as a global hard goal. Such plan properties
are preselected as hard goals for every planning iteration. In our example the
delivery of package 0 is a global hard goal representing a priority package.

### Iterative Planning

An overview of the iterative planning interface is given by Figure 3. It is
divided into four columns. The first column contains the graphical
representation of the planning task. The hard goals and the additionally
satisfied soft goals of the selected plan are listed in the second column.
Explanations for the current plan are provided in the third column. The fourth
column hosts the interface for selecting the hard goals for the next
iteration. This interface is used by end users and test persons for iterative
planning. The different interface parts will be explained in more detail in
the next sections.

#### Plan Step

To compute a plan, the user has to select the hard goals. The global hard
goals are automatically added. All not selected plan properties are treated as
soft goals. The corresponding interface for the example task is shown in
Figure 5. At the top the global hard goals are listed. The plan properties
which can be selected by the user as additional hard goals are enumerated
below. After confirming the choice, a plan for the selection is computed.

Figure 5: Interface to select plan properties as hard goals.

For a solvable selection of hard goals, the tool provides the following
result:

  * •

the selected hard goals

  * •

the soft goals which are additionally satisfied although not enforced

  * •

the unsatisfied soft goals

  * •

the plan as a sequence of actions

  * •

the plan as an animation

Figure 6 depicts the representation of a plan for which no other hard goals
than the global hard goals have been selected. In this instance two additional
soft goals are satisfied although not enforced.

Figure 6: Information about the computed plan.

If the task is unsolvable, this is explicitly stated to the user and only the
hard goals are depicted.

#### Explanation

In order to get more insights into the space of plan, the user can ask
questions about the current plan. More specifically, he can select a subset
$P_{N}$ of the plan properties not satisfied by the current plan. The
selection is then interpreted as the question: ”Why are the plan properties in
$P_{N}$ not satisfied?”. The interface to ask a question is depicted in Figure
7. The resulting question would be: ”Why does the blue truck not visit the
cafe?”

The answer is then provided as shown in Figure 8. It is a list of all MUGS
containing one of the plan properties in the question. Within the answer, only
plan properties which are currently satisfied by the plan (enforced or by
chance) are considered. The answer depicted in Figure 8 can be summarized as:
”If the blue truck visits the cafe, then either package 3 can not be delivered
or package 2 and 3 are not transported with the same truck.”

Figure 7: Interface to ask a question. Figure 8: Answer to the question of
Figure 7.

If a selection of hard goals is not solvable, the user can ask “Why?”. The
answer is given as all minimal unsolvable subsets of the hard goals.

### User Study Support

To allow a layperson user to understand the planning task, the plan properties
and the generated plans more easily, we implemented the following adaptations.
The initial state of the planning task is visualized with an image. The plan
actions can be substituted with domain dependent natural language sentences.
Additionally, a domain dependent animation for each plan can be added. Also
the natural language representation of plan properties can be task dependent.
In the example this allows to take the map of the task into account, instead
of using generic location names.

To conduct a user study with a feasible amount of delay and robustness there
exists the possibility to compute a _demo_ from a project. To do so, the
available plan properties have to be fixed and all MUGS are precomputed. To
further reduce delay it could also be possible to precompute all plans. Due to
the large number of combinations of hard goals, this approach might oftentimes
not be feasible and is therefore not implemented by the tool.

Given such a demo, the iterative planning workflow can be further restricted
for a user study: The possibility to ask questions can be enabled or disabled.
Furthermore, the amount of time and/or the number of iterations available to
the user can be restricted. In addition, the size of the question a user can
ask can be limited.

If iterative planning is performed in the setting of a user study, the time a
test person spends with each interface part is measured. This includes for
example, how much time she spends with asking questions or selecting the hard
goals for the next iteration.

##  4 User Study

We evaluated the usefulness of the explanations provided by the framework of
Eif20 in the setting of iterative planning in a small preliminary user study.

### User Preferences

The main purpose of the tool and the explanations is to support a user in the
process of finding and understanding a plan which satisfies _her preferences_.
In many domains only an expert user in the field has such intrinsic
preferences. But such test persons are very difficult to recruit. To conduct a
reasonable user study in a crowd sourcing setting, it is necessary to provide
artificial preferences to the user. Otherwise, the lack of own user
preferences leads to meaningless plan properties and plan differences for the
user. Therefore, we decided to assign a utility as an integer value to each
plan property. This is actually a contradiction to our assumption, that user
preferences are difficult to elicitat, and not expressable in a utility
function. But it is essential for a successful user study, as it provides the
following two features. First of all, it gives the user different preferences
for the different plan properties. Additionally, it is possible to motivate
the user to find good plans, reflected by a high utility. This can be achieved
by rewarding the user based on the best plan utility he was able to
accomplish. In order to make use of this feature, the utility of each plan
property in association with its natural language description, is shown to the
user as depicted in Figure 7.

### Setup

The test persons were 6 planning researchers from the FAI Group of Saarland
University. They were all familiar with the framework, but not with the
example and they used the tool for the first time. The user study was split
into three parts. First, the test persons were provided with a manual of the
tool and had time to understand the functionality provided by it. Then, they
could familiarize themselves with the planning task in Figure 2, and the plan
properties listed in Section 2. The delivery of package 0 was fixed as a
global hard goal.

In the second part, each plan property was assigned a utility between 1 and 3.
All test persons were asked to maximize the overall utility of the plan
properties satisfied by a plan. The maximal possible utility was 14. Again,
this is solely done in order to provide some extrinsic motivation.

To be able to evaluate the _usefulness_ of the explanations, the test persons
are split into two groups of size 3 each. Group GQ+ was allowed to ask
questions, group GQ- was not. The maximum number of iterations was fixed to 10
and the maximal question size to 1. The test persons were not able to ask
questions about an unsolvable task. 111This is only due to the fact that this
feature had not been yet implemented at the time the study was conducted.

In the third part, the test persons who could ask questions had to answer a
small questionnaire with respect to the helpfulness of the provided
explanations.

The questionnaire was constituted of the following questions:

  1. 1.

How helpful were the provided explanations in the setting of iterative
planning?

  2. 2.

How helpful were the provided explanations to understand the space of plans?

The questions could be answered using a discrete linear scale reaching from 1
(Didn’t help at all) to 5 (Helped a lot). Additionally, there was a free text
question asking for any feedback with respect to the provided explanations and
the implementation of the tool itself.

### Evaluation

Given the small number of test persons the resulting quantitative evaluation
has to be interpreted with care. Nevertheless, the data can give some idea of
the general tendency.

#### Numeric Evaluation

$0$$1$$2$$3$$4$$5$$6$$7$$8$$9$02468iterationutilityGQ-↯↯↯↯↯↯↯↯↯↯↯↯↯↯↯

$0$$1$$2$$3$$4$$5$$6$$7$$8$$9$02468utilityGQ+↯↯↯↯↯↯↯↯

$0$$1$$2$$3$$4$$5$$6$$7$$8$$9$0123iteration#questions↯↯↯↯↯↯↯↯

Figure 9: Plan utility and #questions per iteration. The different colors
correspond to the different test persons. Dashed lines indicate max number of
used iterations. ↯ indicates that the selected hard goals were unsolvable in
this iteration.

The top two graphics in Figure 9 depict the overall utility achieved per
iteration per test persons with and without explanations. Based on the
selection of test persons a statistical analysis is not adequate.
Nevertheless, For the sake of completeness, we give the $95\%$ confidence
interval for every expected value for the utility and the number of
iterations. One of the test persons in GQ- quit after 5 iterations without
reaching a reasonable high utility. Therefore, we will evaluate GQ- without
the blue test person. The test persons in GQ-, on average, achieved a plan
utility of $8.5$ $[7.69,9.30]$ (7.3, when including the blue test person).
Both test persons in GQ- used all $10$ iterations (when including the blue
test person, on average $8.3$). All test persons in GQ+ achieved a maximal
plan utility of $9$. They came up with their final plan within $6.3$
$[4.63,8.03]$ iterations on average. The average number of questions asked in
total was 4. The bottom graphic in Figure 9 depicts the number of questions
per iteration per test person. Although, the strategy of all test persons
varied a lot, the questions helped to achieve a higher utility with less
iterations. In addition, being able to ask questions led to a smaller amount
of unsolvable tasks.

The results for both questions in the questionnaire are on average $3.66$ with
a variance of $0.24$ on a scale from 1 (Didn’t help at all) to 5 (Helped a
lot).

#### Free Text Feedback

In the following we evaluate and summarize the feedback given in the free text
question. In general, the test persons found the possibility tho ask questions
useful, as it allowed them to select plan properties more strategically.

In order to expose the functionality provided by the framework in an even more
user friendly way, the interface should be further improved. For example, all
participants agreed, that the interface displaying the answer needs some
improvement. Especially, in situations where the answer represents multiple
MUGS it has to be arranged more clearly. Some proposed to use a small guided
introduction task to clearly outline the task and how the explanations could
help the user.

One test person stated, that the answer should only point out the plan
properties which are enforced in the plan and not only satisfied by chance.

In this user study the question size was fixed to one although larger
questions are possible in general. All participants agreed, that in some cases
larger questions with a size up to three would be more useful. In this case,
the interface representing the answer would have to clearly indicate the
influence of the different plan properties in the question.

Almost all test persons started with an unsolvable selection of hard goals.
The questions we currently support are all based on a given plan. This has the
effect that the functionality of asking questions can only be exploited after
a plan for a solvable selection of hard goals is found. As a consequence, most
of the test persons complained, that the possibility of asking a question like
”Why is this selection of hard goals unsolvable?” was missing.

##  5 Conclusion and Future Work

Eif20 introduced a framework using plan properties and their dependencies to
compute plan space explanations. We implemented a Web tool using this
framework in the setting of iterative planning as proposed by (?).
Additionally, we conducted a small user study showing that in general the
provided questions are useful in the setting of iterative planning.

Our next goal is to run a user study with more test persons outside the
community. One of the challenges will be the selection of domains, that are
suitable for the target audience of test persons. Besides the logistics domain
we plan to use a mars rover mission control domain as another example from the
planning benchmarks. Ideally, a test person has its own preferences with
respect to the domain. Consider for example students, which have to schedule
their courses for the next term as used by (?). As a domain a vast majority of
people is familiar with, we intend to use the task of driving home from work
and taking care of some household duties like shopping or disposing the waste
paper. We will also consider further metrics proposed by (?) to evaluate the
explanation framework.

One interesting question for the future is the combination with the framework
of (?). Their framework is based on explanations based on examples. The
combination of both frameworks will allow us to evaluate the better
explanation for specific situations and to combine them accordingly.

## Acknowledgments

This material is based upon work supported by the Air Force Office of
Scientific Research under award number FA9550-18-1-0245. Rebecca Eifler was
also supported by the German Research Foundation (DFG) as part of CRC 248 (see
perspicuous-computing.science).

## References

  * [Baier and McIlraith 2006] Baier, J. A., and McIlraith, S. A.  2006\.  Planning with first-order temporally extended goals using heuristic search.  In Proc. AAAI, 788–795.
  * [Cashmore et al. 2019] Cashmore, M.; Collins, A.; Krarup, B.; Krivic, S.; Magazzeni, D.; and Smith, D.  2019\.  Towards explainable AI planning as a service.  In ICAPS XAIP.
  * [Domshlak and Mirkis 2015] Domshlak, C., and Mirkis, V.  2015\.  Deterministic oversubscription planning as heuristic search: Abstractions and reformulations.  JAIR 52:97–169.
  * [Edelkamp 2006] Edelkamp, S.  2006\.  On the compilation of plan constraints and preferences.  In ICAPS, 374–377.
  * [Eifler et al. 2020a] Eifler, R.; Cashmore, M.; Hoffmann, J.; Magazzeni, D.; and Steinmetz, M.  2020a.  A new approach to plan-space explanation: Analyzing plan-property dependencies in oversubscription planning.  In AAAI.
  * [Eifler et al. 2020b] Eifler, R.; Steinmetz, M.; Torralba, A.; and Hoffmann, J.  2020b.  Plan-space explanation via plan-property dependencies: Faster algorithms & more powerful properties.  In IJCAI, 4091–4097.
  * [Fox, Long, and Magazzeni 2017] Fox, M.; Long, D.; and Magazzeni, D.  2017\.  Explainable planning.  In ICAI XAI.
  * [Grover et al. 2020] Grover, S.; Sengupta, S.; Chakraborti, T.; Mishra, A. P.; and Kambhampati, S.  2020\.  Radar: automated task planning for proactive decision support.  Human–Computer Interaction 1–26.
  * [Helmert 2006] Helmert, M.  2006\.  The Fast Downward planning system.  JAIR 26:191–246.
  * [Hoffman et al. 2018] Hoffman, R. R.; Mueller, S. T.; Klein, G.; and Litman, J.  2018\.  Metrics for explainable ai: Challenges and prospects.  arXiv preprint arXiv:1812.04608.
  * [Krarup et al. 2019] Krarup, B.; Cashmore, M.; Magazzeni, D.; and Miller, T.  2019\.  Towards model-based contrastive explanations for explainable planning.  In ICAPS XAIP.
  * [McDermott et al. 1998] McDermott, D.; Ghallab, M.; Howe, A.; Knoblock, C.; Ram, A.; Veloso, M.; Weld, D.; and Wilkins, D.  1998\.  The PDDL Planning Domain Definition Language.  The AIPS-98 Planning Competition Comitee.
  * [Miller 2019] Miller, T.  2019\.  Explanation in artificial intelligence: Insights from the social sciences.  AI 267:1–38.
  * [Palan and Schitter 2018] Palan, S., and Schitter, C.  2018\.  Prolific.ac — a subject pool for online experiments.  Journal of Behavioral and Experimental Finance 17:22–27.
  * [Smith 2004] Smith, D. E.  2004\.  Choosing objectives in over-subscription planning.  In ICAPS, 393–401.
  * [Smith 2012] Smith, D.  2012\.  Planning as an iterative process.  In AAAI, 2180–2185.