Addendum to: Summary Information for Reasoning About Hierarchical Plans
Abstract
Hierarchically structured agent plans are important for efficient planning and acting, and they also serve (among other things) to produce “richer” classical plans, composed not just of a sequence of primitive actions, but also “abstract” ones representing the supplied hierarchies. A crucial step for this and other approaches is deriving precondition and effect “summaries” from a given plan hierarchy. This paper provides mechanisms to do this for more pragmatic and conventional hierarchies than in the past. To this end, we formally define the notion of a precondition and an effect for a hierarchical plan; we present data structures and algorithms for automatically deriving this information; and we analyse the properties of the presented algorithms. We conclude the paper by detailing how our algorithms may be used together with a classical planner in order to obtain abstract plans.
Introduction
This paper provides effective techniques for automatically extracting abstract actions and plans from a supplied hierarchical agent planlibrary. Hierarchically structured agent plans are appealing for efficient acting and planning as they embody an expert’s domain control knowledge, which can greatly speed up the reasoning process and cater for nonfunctional requirements. Two popular approaches based on such representations are Hierarchical Task Network (HTN) [8, 11] planning and BeliefDesireIntention (BDI) [19] agentoriented programming. While HTN planners “look ahead” over a supplied collection of hierarchical plans to determine whether a task has a viable decomposition, BDI agents interleave this process with acting in the real world, thereby trading off solution quality for faster responsiveness to environmental changes. Despite these differences, HTN and BDI systems are closely related in both syntax and semantics, making it possible to translate between the two representations [20, 21].
While HTN planning and BDI execution are concerned with decomposing hierarchical structures (offline and online, respectively), one may perform other kinds of reasoning with them that do not necessarily require or amount to decompositions. For example, [6] and [22, 23] perform reasoning to coordinate the execution of abstract steps, so as to preempt potential negative interactions or exploit positive ones. In [7], the authors propose a novel application of such hierarchies to produce “richer” classical plans composed not just of sequences of primitive actions, but also of “abstract” steps. Such abstract plans are particularly appealing in the context of BDI and HTN systems because they respect and reuse the domain control knowledge inherent in such systems, and they provide flexibility and robustness: if a refinement of one abstract step happens to fail, another option may be tried to achieve the step.
A prerequisite for these kinds of reasoning is the availability of meaningful preconditions and effects for abstract steps (i.e., compound tasks in HTN systems or eventgoals in BDI languages). Generally, this information is not supplied explicitly, but embedded within the decompositions of an abstract step. This paper provides techniques for extracting this information automatically. The algorithms we develop are built upon those of [6] and [22, 23], which calculate offline the precondition and effect “summaries” of HTNlike hierarchical structures that define the agents in a multiagent system, and use these summaries at runtime to coordinate the agents or their plans. The most important difference between these existing techniques and ours is that the former are framed in a propositional language, whereas ours allow for firstorder variables. This is fundamental when it comes to practical applicability, as any realistic BDI agent program will make use of variables. A nuance worth mentioning between our work and that of Clement et al. is that the preconditions we synthesise are standard classical precondition formulas (with disjunction), whereas their preconditions are (essentially) two sets of literals: the ones that must hold at the start of any successful execution of the entity, and the ones that must hold at the start of at least one such execution. Yao et al. [26] extend the above two strands of work to allow for concurrent steps within an agent’s plan, though still not firstorder variables.
Perhaps the only work that computes summaries (“external conditions”) of hierarchies specifying firstorder variables is [24]. The authors automatically extract a weaker form of summary information (what we call “mentioned” literals) to inform the task selection strategy of the UMCP HTN planner: tasks that can possibly establish or threaten the applicability of other tasks are explored first. They show that even weak summary information can significantly reduce backtracking and increase planning speed. However, the authors only provide insights into their algorithms for computing summaries.
We note that we are only concerned here with how to extract abstract actions (with corresponding preconditions and effects), and eventually abstract plans, from a hierarchical knowhow structure. Consequently, unlike existing useful and interesting work [12, 9, 2, 1], our approach does not directly involve guiding a planner toward finding a suitable primitive plan. We also do not aim to build new “macro” actions from sample primitive solution plans, as done in [3], for example.
Thus, the contributions of this paper are as follows. First, we develop formal definitions for the notions of a precondition and an effect of an (abstract) eventgoal. Second, we develop algorithms and data structures for deriving precondition and effect summaries from an eventgoal’s hierarchy. Unlike past work, we use a typical BDI agent programming language framework; in doing so, we allow for variables in agent programs—an important requirement in practical systems. Our chosen BDI agent programming language cleanly incorporates the syntax and semantics of HTN planning as a builtin feature, making our work immediately accessible to both communities. Finally, we show how derived eventgoal summaries may be used together with a classical planner in order to obtain abstract plans (which can later be further refined, if desired, to meet certain properties [7]).
The Hierarchical Framework
Our definitions, algorithms, and results are based on the formal machinery provided by the CANPlan [21] language and operational semantics. While designed to capture the essence of BDI agentoriented languages, it directly relates to other hierarchical representations of procedural knowledge, such as HTN planning [8, 11], both in syntax and semantics.
A CANPlan BDI agent is created by the specification of a belief base , i.e., a set of ground atoms, a planlibrary , i.e., a set of planrules, and an actionlibrary , i.e., a set of actionrules. A planrule is of the form , where is an eventgoal, is a vector of distinct variables, is the context condition, and is a planbody or program.^{1}^{1}1In [21] an eventgoal is of the form where is a vector of terms. Here, we replace with and assume WLOG that , where . The latter is made up of the following components: primitive actions () that the agent can execute directly; operations to add () and remove () beliefs; tests for conditions (); and eventgoal programs (), which are simply eventgoals combined with the label “”. These components are composed using the sequencing construct . While the original definition of a planrule also included declarative goals and the ability to specify partially ordered programs [25], we leave out these constructs here and focus only on an AgentSpeaklike [18], typical BDI agent programming language.
There are also additional constructs used by CANPlan internally when attaching semantics to constructs. These are the programs nil, , and . Intuitively, nil is the empty program, which indicates that there is nothing left to execute; program represents the planrules that are relevant for some eventgoal; and program realises failure recovery: program should be tried first, failing which should be tried. The complete language of CAN, then, is described by the grammar
The behaviour of a CANPlan agent is defined by a set of derivation rules in the style of Plotkin’s structural singlestep operational semantics [16]. The transition relation on a configuration is defined using one or more derivation rules. Derivation rules have an antecedent and a conclusion: the antecedent can either be empty, or it can have transitions and auxiliary conditions; the conclusion is a single transition. A transition within a rule denotes that configuration yields configuration in a single execution step, where a configuration is the tuple composed of a belief base , a program , and the sequence of actions executed so far. Construct denotes a transition of type , where ; when no label is specified on a transition both types apply. Intuitively, type transitions are used for the standard BDI execution cycle, and type transitions for (internal) deliberation steps within a planning context. By distinguishing between these two types of transitions, certain rules can be disallowed from being used in a planning context, such as those dealing with BDIstyle failure handling.
We shall describe three of the CANPlan derivation rules. The rule below states that a configuration evolves into a configuration (with no changes to and ) in one  or type execution step, with being the set of all relevant planrules for , i.e., the ones whose handling eventgoal unifies with ; mgu stands for “most general unifier” [13]. From , an applicable planrule—one whose context condition holds in —is selected by another derivation rule and the associated planbody scheduled for execution.
The Plan construct incorporates HTN planning as a builtin feature of the semantics. The main rule defining the construct states that a configuration evolves into a configuration in one type execution step if the following two conditions hold: (i) configuration yields configuration in one type execution step, and (ii) it is possible to reach a final configuration from in a finite number of type execution steps. Thus, executing the single type step necessitates zero or more internal “look ahead” steps that check for a successful HTN execution of .
Unlike planrules, any given action program will have exactly one associated actionrule in the actionlibrary . Like a STRIPS operator, an actionrule is such that is a symbol followed by a vector of distinct variables, and all variables free in , (the add list) and (the delete list) are also free in . We additionally expect any actionrule to be coherent: that is, for all ground instances of , if is consistent, then is consistent. For example, while the rule corresponding to an action with precondition (or ) and postcondition is coherent, the same rule with precondition is not, as there will then be a ground instance of such that its precondition is consistent but its postcondition is not: both its add and delete lists contain the same atom.
Assumptions
We shall now introduce some of the definitions used in the rest of the paper and concretise the rest of our assumptions. As usual, we use and to denote vectors of distinct variables, and to denote a vector of (not necessarily distinct) terms. Moreover, since the language of CANPlan allows variables in programs, we shall frequently make use of the notion of a substitution [13], which is a finite set of elements where are distinct variables and each is a term with . We use to denote the expression obtained from any expression by simultaneously replacing each occurrence of in with , for all .
We assume that the planlibrary does not have recursion. Formally, we assume that a ranking exists for the planlibrary, i.e., that it is always possible to give a child a smaller rank (number) than its parent. We define a ranking as follows.
Definition 1

A ranking for a planlibrary is a function from eventgoal types mentioned in to natural numbers, such that for all eventgoals where is the same type as some , we have that .^{2}^{2}2We define the function , where two eventgoals are the same type if they have the same predicate symbol and arity. The type of an eventgoal is defined as , where .
In addition, we define the following two related notions: first, given an eventgoal type , denotes the rank of in ; and second, given any eventgoal mentioned in , we define (where ), i.e., the rank of an eventgoal is equivalent to the rank of its type. In order that these and other definitions also apply to eventgoal programs, we sometimes blur the distinction between eventgoals and eventgoal programs .
Finally, we assume that context conditions are written with appropriate care. Specifically, if there is no environmental interference, whenever a planrule is applicable it should be possible to successfully execute the associated planbody without any failure and recovery; this disallows rules such as . Our definition makes use of the notion of a projection: given any configuration , we define the projection of the first component of the tuple as , the second as , and the third as .
Definition 2

A planlibrary is coherent if for all rules , ground instances of , and belief bases , whenever (where is ground) there is a successful HTN execution of (relative to ) with . A successful HTNexecution of a program relative to a planlibrary is any finite sequence of configurations such that , , and for all .
Intuitively, the term HTN execution simply denotes a BDI execution in which certain BDIspecific derivation rules associated with failure and recovery have not been used.
Summary Information
We can now start to define what we mean by preconditions and postconditions/effects of eventgoals; some of these definitions are also used later in the algorithms. As a first step we define these notions for our most basic programs.
A basic program is either an atomic program or a primitive program. Formally, a program is an atomic program (or simply atomic) if , and is a primitive program if is an atomic program that is not an eventgoal program. Then, like the postcondition of a STRIPS action, the postcondition of a primitive program is simply the atoms that will be added to and removed from the belief base upon executing the program. Formally, the postcondition of a primitive program relative to an actionlibrary , denoted , is the set of literals
The postcondition of a test condition is the empty set because executing a test condition does not result in an update to the belief base. The postcondition of an action program is the combination of the add list and delete list of the associated actionrule, after applying the appropriate substitution.
While this notion of a postcondition as applied to a primitive program is necessary for our algorithms later, we do not also need the matching notion of a precondition of a primitive program. Such preconditions are already accounted for in context conditions of planrules, by virtue of our assumption (Definition 2) that the latter are coherent. What we do require, however, is the notion of a precondition as applied to an eventgoal. This is defined as any formula such that whenever it holds in some state there is at least one successful HTN execution of the eventgoal from that state.
Definition 3

A formula is said to be a precondition of an eventgoal (relative to a plan and an actionlibrary) if for all ground instances of and belief bases , whenever , there exists a successful HTN execution of , where .
Unlike the postcondition of a primitive program, the postcondition of an eventgoal program—and indeed any arbitrary program —is nondeterministic: it depends on what planrules are chosen to decompose . There are, nonetheless, certain effects that will be brought about irrespective of such choices. We call these must literals: literals that hold at the end of every successful HTN execution of .
Definition 4

Let be a program and a literal where its variables are free in . Then, is a must literal of (relative to a plan and actionlibrary) if for any ground instance of and successful HTN execution of , we have that .
A desirable consequence of the two definitions above is that any given set of must literals of an eventgoal, like the postcondition of an action, is consistent whenever the eventgoal’s precondition is consistent.
Let be an eventgoal, a precondition of (relative to a planlibrary and an actionlibrary ), and a set of must literals of (relative to and ). Then, for all ground instances of , if is consistent for some ground substitution , then so is . Proof. We prove this by contradiction. First, note that since is a set of ground literals (by Definition 4 and because is ground), if is consistent, then for all literals it is the case that (i.e., is not the complement of ). Now let us assume that the theorem does not hold. This means that there must exist a ground instance of , such that is consistent for some ground substitution , but for some .
Since is consistent, there is at least one truth
assignment for its (ground) atoms that satisfies .
Suppose is the set of ground atoms consisting only of those
mentioned in that were assigned the truth
value true. Observe that .
Then, according to Definition 3 (Precondition),
there must exist a successful HTN execution of
such that . Moreover, since are must
literals of and is ground, by Definition 4,
both and are also ground. By the same definition,
and .
However, according to our assumption, ,
and therefore . This
contradicts the fact that , because
is ground due to our assumption in Section
“ASSUMPTIONS” that is coherent.
In addition to must literals, there are two related notions. The first, called may summary conditions in [6], defines literals that hold at the end of at least one successful HTN execution of the program, and the second, weaker notion defines literals that are simply mentioned in the program or in one of its “descendant” programs; such literals may or may not be brought about when the program executes. It is this second notion, called mentioned literals, that we use.
Definition 5

If is a program, its mentioned literals (relative to a planlibrary and an actionlibrary ), denoted , is the set
We use this weaker notion because the stronger notion of a may summary condition in [6] is not suitable for our approach, which reasons about plans that will not be interleaved with one another—i.e., plans that will be scheduled as a sequence. For example, consider the figure below, which shows a planlibrary for going to work on Fridays, possibly one belonging to a larger library from an agentbased simulation. The expressions to the left and right sides of actions/planrules are their preconditions and postconditions, respectively.
Observe that fuelUsed is actually never asserted in the context of the hierarchy shown, because literal (“not intoxicated”) in the context condition of driveHmPlan is contradicted by literal intox. However, the algorithms in [6] will still classify fuelUsed as a may summary condition of plan goToWorkFridaysPlan, because some other plan may have a step asserting —perhaps a step that involves staying overnight in a hotel nearby—that can be ordered to occur between haveDrinks and travelHome.
Since we cannot rely on such steps, we settle for a weaker notion—mentioned literals—than the corresponding definition of a may summary condition. By our definition there can be literals that are mentioned in some planbody but in fact can never be asserted, because of interactions that preclude the particular planbody which asserts that literal from being applied. We avoid the approach of disallowing interactions like the one shown above in order to use the stronger notion of a may summary condition because such interactions are natural in BDI and HTN domains: eventgoals such as travelHome are, intuitively, meant to be selfcontained “modules” that can be “plugged” into any relevant part of a hierarchical structure in order to derive all or just some of their capabilities.
Finally, we conclude this section by combining the above definitions of must and mentioned literals to form the definition of the summary information of a program.
Definition 6

If is a program, its summary information (relative to a planlibrary and an actionlibrary) is a tuple , where is a precondition of if is an eventgoal program, and otherwise; is a set of must literals of ; and is a set of mentioned literals of .
Extracting Summary Information
With the formal definitions now in place, in this section we provide algorithms to extract summary information for eventgoals in a planlibrary. Moreover, we illustrate the algorithms with an example, and analyse their properties.
Basically, we extract summary information from a given planlibrary and actionlibrary by propagating up the summary information of lowerlevel programs, starting from the leaflevel ones in the planlibrary, until we eventually obtain the summary information of all the toplevel eventgoals.
To be able to identify must literals, we need to be able to determine whether a given literal is definitely undone, or must undone, and possibly undone, or may undone in a program. Informally, a literal is must undone in a sequence of atomic programs if the literal’s negation is a must literal of some atomic program in . Formally, then, given a program and the set of summary information of all atomic programs in , a literal is must undone in relative to , denoted , if there exists an atomic program in and a literal , with , such that , that is, is the complement of .
Similarly, we can informally say that a literal is may undone in a program if there is a literal that is a mentioned (or must) literal of some atomic program in such that may become the negation of after variable substitutions. Formally, given a program and the set of summary information of all atomic programs in , a literal is may undone in relative to , denoted , if there exists an atomic program in , a substitution , and a literal ,^{3}^{3}3variables occurring in are renamed to those not occurring in with , such that .
Algorithm 1. This is the toplevel algorithm for computing the summary information of eventgoal types occurring in the planlibrary. The algorithm works bottom up, by summarising first the leaflevel entities of the planlibrary—the primitive programs (line 1)—and then repetitively summarising planbodies (Algorithm 2) and eventgoals (Algorithm 3) in increasing order of their levels of abstraction (lines 36).
Algorithm 2. This algorithm summarises the given planbody by referring to the set containing the summary information tuples of programs in . First, the algorithm obtains the summary information of each eventgoal program in the planbody from the summary information of the corresponding eventgoal types in (line 1). This involves substituting variables occurring in relevant summary information tuples in with the corresponding terms occurring in the eventgoal program being considered. Second, the algorithm computes the set of must literals () and the set of mentioned literals () of the given planbody , by determining, from the must and mentioned literals of atomic programs in , which literals will definitely hold and which ones will only possibly hold on successful executions of (lines 3 and 4). More precisely, a must literal of an atomic program in is classified as a must literal of only if is not may undone in (line 3). Otherwise, is classified as only a mentioned literal of , provided is not also must undone in (line 4). The reason we do not summarise literals that are must undone is to avoid missing must literals in cases where they are possibly undone but then later (definitely) reintroduced, as we illustrate below.
Suppose, on the contrary, that the algorithm does summarise mentioned literals that are must undone. Then, given the planlibrary below, the algorithm would (hypothetically) compute the summary information denoted by the two sets attached to each node, the one on the left being its set of must literals and the one on the right its set of mentioned literals.
Observe that literal asserted by is not recognised as a must literal of simply because it is may undone by mentioned literal of (asserted by ), despite the fact that action of also subsequently adds . On the other hand, our algorithm does recognise as a must literal of by not including in the set of mentioned literals of (line 4).
Algorithm 3. This algorithm summarises the given eventgoal type by referring to the set containing the summary information tuples associated with the planbodies of planrules handling . In lines 2 and 3, the algorithm takes the precondition of the eventgoal as the disjunction of the context conditions of all associated planrules.^{4}^{4}4We do not need to “propagate up” context conditions as we do with planbodies’ summary information because higherlevel context conditions account for lowerlevel ones due to Definition 2. Then, the algorithm obtains the must and mentioned literals of the eventgoal by respectively taking the intersection of the must literals of associated planrules (lines 4 and 7), and the union of the mentioned literals of associated planrules (line 5). Applying substitution in line 4 helps recognise must literals of , by ensuring that variables occurring in the summary information of its associated planbodies have consistent names with respect to .
An illustrative example
We shall illustrate the three algorithms with the example of a simple agent (like the ones in [5]) exploring the surface of Mars. A part of the agent’s domain is depicted as a hierarchy in Figure 1. The hierarchy’s toplevel eventgoal is to explore a given soil location from current location . This is achieved by planrule , which involves navigating to the location and then doing a soil experiment. Navigation is achieved by rules and , which involve moving to the location, possibly after calibrating some of the rover’s instruments. Doing a soil experiment involves the two sequential eventgoals of getting soil results for and transmitting them to the lander. Specifically, the former is refined into actions such as determining moisture content and average soil particle size, and transmitting results involves either establishing a connection with the lander, sending it the results, and then terminating the connection, or if the lander is not within range, navigating to it and uploading the soil results. The table in Figure 1 shows the summary information computed by our algorithms for elements in the figure’s hierarchy. Below, we describe some of the more interesting values in the table.
Program  Must Literals  Mentioned Literals 
calib  cal   
  
  
  
  
  
establishCon  cE   
  
breakCon    
  
  
  
  
  
  
  
cal  
cal  
cal  
Same as    
Same as    
cal  
Same as  Same as  
Same as  Same as 
Planbody Must literals and of are derived from those of , after renaming variables and to respectively and in line 1 of Algorithm 2.
Planbody While is a must literal of ’s primitive action , the literal is must undone by ’s last primitive action . Thus, is not a must (nor mentioned) literal of . On the other hand, literal is indeed a must literal of , along with literals and , both of which are derived from the summary information of eventgoal .
Planbody While is a must literal of eventgoal , it is only a mentioned literal of because it is may undone in eventgoal ; specifically, its mentioned literal is such that for . Similarly, must literal of is also may undone in .
Eventgoal Since literal is a must literal of both of the eventgoal’s associated planbodies and , and also occurs in the eventgoal, the literal is classified as a must literal of the eventgoal. Recall that this means that for any ground instance of the eventgoal, literal holds at the end of any successful HTN execution of .
Soundness and Completeness
We shall now analyse the properties of the algorithms presented. We show that they are sound, and we then discuss completeness. First, it is not difficult to see that the presented algorithms terminate, and that they run in polynomial time.
Algorithm 1 always terminates, and runs in polynomial time on the number of symbols occurring in . Proof. Let be the total number of eventgoal types occurring in and . Since a ranking function does exist for , we can rank it as follows. For each eventgoal type occurring in that does not also occur in a planbody mentioned in , we first set to , and then recursively assign the rank to and to its children eventgoal types that are either not already ranked or have a higher rank.
Since the remaining algorithms are not recursive, the only nontrivial
part is the algorithm for computing a unification in
(where is a literal, is a program and is a set of summary
information). This was shown to be linear on the number of symbols
occurring in the two literals to be unified [14].
\hfill
This result is important when the planlibrary changes over time, e.g. because the agent learns from past experience, and summary information needs to be recomputed frequently, or when it needs to be computed right at the start of HTN planning, as done in [24].
The next result states that whenever Algorithm 1 (Summ) classifies a literal as a must literal of an eventgoal, this is guaranteed to be the case, and that the algorithm correctly computes its precondition and mentioned literals. More specifically, any computed tuple, which includes one eventgoal type , formula and must literals , respects Definitions 3 and 4. Moreover, there is exactly one tuple associated with .
Let be a planlibrary, be an actionlibrary, be an eventgoal
type mentioned in , and let .
There exists one tuple ,
the tuple is the summary information of , and
(recall denotes the mentioned literals of ).
Proof.
We prove this by induction on ’s rank in . First,
from our ranking function we obtain a new one by
making eventgoal ranks “contiguous” and start from .
[Base Case] Let be an event of rank in , that is, . Observe from the definition of a ranking for a planlibrary (Definition 1) that if , then . This entails that for all planrules such that , no eventgoals are mentioned in . There are two cases to consider.
Case 1.1. In the special case where no such planrule exists, then the call to procedure in line 6 of procedure returns tuple , which is indeed the summary information of .
Case 1.2. Now consider the case where there are one or more planrules in such that for all it is the case that but no eventgoals are mentioned in . Let denote the (nonempty) set of all such planbodies. Then, we know from Lemma A that, due to line 1 in the algorithm, there is exactly one tuple for each primitive program mentioned in each planbody , such that the tuple is the summary information of .
Next, observe that before reaching
line 6 of procedure ,
procedure is called
in line 5 for each planbody .
Then, from Lemma A, we know that,
on the completion of line 5, there is exactly one tuple
for each planbody
such that the tuple is the summary information of .
Finally, from Lemmas A and
A, we can conclude that on the
completion of line 6 of the algorithm
(i.e., after calling procedure
), there is exactly
one tuple such
that the tuple is the summary information of .
Therefore, the theorem holds for the base case.
[Induction Hypothesis] Assume that the theorem holds
if , for some .
[Inductive Step] Suppose . Let . There are two cases to consider.
Case 2.1. First, there is no planbody such that there is an eventgoal mentioned in (i.e., all planbodies in mention only primitive programs). Thus, . If , then the proof for this case is the same as Case 1.2 in the Base Case above.
Case 2.2. On the other hand, if , then the proof for this case is the same as Case 1.1 in the Base Case above.
Case 2.3. The third case is that and there exists a planbody such that an eventgoal is mentioned in . Then, let denote the (nonempty) set of eventgoal types of all eventgoals mentioned in all planbodies . From Definition 1 (Ranking), for all eventgoals , . Then, by the induction hypothesis, for each , there is exactly one tuple such that the tuple is the summary information of . It is not difficult to see from procedure Summ that all such tuples exist in because the value returned by procedure is added to set in line 6, for each eventgoal . After this, since has a higher rank than all , procedure will repeat its outer loop at least one more time (note that there may be other eventgoals mentioned in with the same rank as or higher). The procedure will then call , by which point procedure will have already been called for each planbody , and in turn, each such call will only have occurred after procedure is called for each eventgoal .
Then, by Lemmas A and by
A and the induction hypothesis,
it follows that on the completion of the call to
in line 5
for each , there is exactly one tuple such that the tuple is the summary
information of .
Finally, from Lemmas A
and A, we can conclude that after
calling procedure in line 6,
there is exactly one tuple such
that the tuple is the summary information of .
Therefore, the theorem holds.
\hfill
Next, we discuss completeness. The theorem below states that any precondition computed by Algorithm 3 is complete: i.e., given any state from where there is a successful HTN execution of an eventgoal, the precondition extracted for the eventgoal will hold in that state. This theorem only concerns Algorithm 3 because we can compute preconditions of eventgoals without needing to compute preconditions of plans.
Let be a planlibrary, an actionlibrary,
an eventgoal type mentioned in , and let
.
For all ground instances of and belief bases
such that there exists a successful HTN execution
of with ,
it is the case that .
Proof.
If has a successful HTN execution, then there is
also a planrule associated with such that
holds, where
is an appropriate renaming of
variables in . Since is a
disjunct of (line 3 of Algorithm 3),
it follows that .
(See also proof of Lemma 9.)
\hfill
There are, however, situations where the algorithms do not detect all must literals of an eventgoal. The underlying reason for this is that we do not reason about (FOL) precondition formulas; specifically, we do not check entailment, because this is semidecidable in general [10]. In what follows, we use examples to characterise the four cases in which the algorithms are unable to recognise must literals, and show how some of the cases can be averted.
The first case was depicted in our example about going to work on Fridays: by Definition 4, literal is a must literal of goToWorkFridaysPlan, but Algorithm 2 classifies it as only a mentioned literal, as it cannot infer that the context condition of rule driveHmPlan is contradicted by literal intox, and therefore that driveHmPlan can never be applied.
The second case is where a literal is a must literal simply because it is entailed by a context condition. For example, take an eventgoal that is associated with one planrule, whose context condition checks whether package is in truck , i.e., , and whose planbody moves the truck to location . Observe that is a must literal of by definition, but since does not occur in the planbody, Algorithm 2 does not consider the literal. We do not expect this to be an issue in practice, however, because such literals are accounted for by the eventgoal’s (extracted) precondition.
The third case is where must literals are “hidden” due to the particular variable/constant symbols chosen by the domain writer when encoding literals. For example, given the following two planrules for an eventgoal that sends an email from to , literal is only a mentioned literal of according to Algorithm 3 (line 7 in particular), but a must literal of it by definition:
Nonetheless, by changing to , which then mentions the same variable symbol as the first planbody, is identified by the algorithm as a must literal of . In general, such “hidden” must literals can be disclosed by choosing terms with appropriate care.
Finally, while Algorithm 2 “conservatively” classifies any must literal that is may undone as a may literal, it could still be a must literal by definition. For example, given an eventgoal , suppose that the following planrule is the only one relevant for the eventgoal:
Then, by Definition 4, both and are must literals of the eventgoal, but only is its must literal according to Algorithm 2, because it cannot infer that the context condition entails .^{5}^{5}5Note that if the context condition is just , then, by definition, would indeed be the only must literal of the eventgoal, because it would then be possible for and to have the same value, and for to “undo” . While the algorithm does fail to detect some must literals in such domains, this can sometimes be averted by encoding the domain differently. For example, the above rule can be encoded as an actionrule instead, in which case Algorithm 1 (in line 1) will classify (and ) as a must literal of , under the assumption that actionrules are coherent.
An Application to Planning
One application of the algorithms presented is to create abstract planning operators that may be used together with primitive operators and a classical planner in order to obtain abstract (or “hybrid”) plans. While [7] focuses on algorithms for extracting an “ideal” abstract plan from an abstract plan that is supplied, here we give the details regarding how a first abstract plan may be obtained.
To get abstract operators from a planlibrary and an actionlibrary , we take the set and create an (abstract) operator for every summary information tuple . To this end, we take the operator’s name as , appended with its arity and combined with any additional variables occurring in ; the operator’s precondition as ; and its postcondition as the set of must literals .
Since mentioned literals of eventgoals are not included in their associated abstract operators, it is crucial that we ascertain whether these literals will cause unavoidable conflicts in an abstract plan found. For example, consider the classical planning problem with initial state and goal state , and the abstract plan consisting of two eventgoals (or abstract operators). Suppose and have the following planrules:
Notice that the postconditions (must literals) of abstract operators and are respectively and , and that is a classical planning solution for the given planning problem. However, when this plan is executed, if is decomposed using its second planrule, this will cause (mentioned literal) to be brought about, thereby invalidating the context condition of (which requires ).
To check for such cases, we present the following simple polynomialtime algorithm. Suppose that is the program corresponding to a classical planning solution for some planning problem, where each (ground) is either an action or eventgoal. Then, we say that is correct relative to if for any (ground) literal occurring in the precondition of any , the following condition holds: if is not must undone and it is may undone (relative to ) in the preceding subplan by some mentioned literal of a step in the subplan,^{6}^{6}6We rely here on a slightly extended version of the definition of may undone from before, to have the exact step () and literal () responsible for the “undoing”. Moreover, observe that literals and are obtained by applying the same substitution that the planner applied to obtain