<?xml-model href='http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng' schematypens='http://relaxng.org/ns/structure/1.0'?><TEI xmlns="http://www.tei-c.org/ns/1.0">
	<teiHeader>
		<fileDesc>
			<titleStmt><title level='a'>Re-examining the Planning Basis of Goal-driven Autonomy Problems</title></titleStmt>
			<publicationStmt>
				<publisher></publisher>
				<date>2022</date>
			</publicationStmt>
			<sourceDesc>
				<bibl> 
					<idno type="par_id">10337384</idno>
					<idno type="doi"></idno>
					<title level='j'>Proceedings of the Workshop on Integrated Action and Execution at the 32nd International Conference on Automated Planning and Scheduling</title>
<idno></idno>
<biblScope unit="volume"></biblScope>
<biblScope unit="issue"></biblScope>					

					<author>Rogelio E. Cardona-Rivera</author><author>M. Gardone</author><author>Logan Peterson</author><author>Laura M. Hiatt</author><author>Mark Roberts</author>
				</bibl>
			</sourceDesc>
		</fileDesc>
		<profileDesc>
			<abstract><ab><![CDATA[The study of goal-reasoning agents capable of integrated action and execution has received a great deal of attention in recent years. While practical implementations and theoretical insights of such agents have provided a wealth of flexible behavior in a variety of task environments, they tend to focus on complex environments that are far from classical planning assumptions. This paper formalizes classical planning problems where an agent can change its goal(s) during execution. We identify the minimal changes to classical planning and formalize a model that supports "classical goal reasoning."]]></ab></abstract>
		</profileDesc>
	</teiHeader>
	<text><body xmlns="http://www.tei-c.org/ns/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink">
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Introduction</head><p>Allowing an agent to modify its goals during execution challenges several core assumptions of the classical planning model. It is perhaps unsurprising that most studies in goal reasoning (also called goal-driven autonomy) have favored environments that relax the classical assumptions by being partially-observable, non-deterministic (including those with exogenous events) or being open worlds <ref type="bibr">(Aha 2018</ref>). However, there remain problems that are very close to classical ones, especially for deterministic and fully-observable environments.</p><p>Several scholars have developed formal theories of goal reasoning systems. For instance, <ref type="bibr">Hawes (2011)</ref> distilled four reasons why an agent might exhibit goal reasoning, calling for their formalization. Later, <ref type="bibr">Harland et al. (2014)</ref> formalized an operational semantics for a Belief-Desire-Intention (BDI) agent architecture capable of a vast array of goal reasoning mechanisms. More recently, <ref type="bibr">Dannenhauer, Mu&#241;oz-Avila, and Cox (2021)</ref> formalized a comprehensive theory of how goal-driven agents might reformulate goals based on violated expectations. While these models have significantly advanced our understanding of goal-driven autonomy, their studies began with a planning model that was significantly more complex than classical planning.</p><p>There remains a gap somewhere between the full set of classical assumptions (that would only require a classical planner to solve) and the complexity of typical problems studied in goal reasoning research. In this paper we fill that gap by investigating the minimal classical assumptions that must be relaxed to arrive at "classical goal reasoning."</p><p>Contributions We found that we are able to parsimoniously describe classical goal reasoning via what we term a goal transition system-a novel structure that explicitly represents the hypergraph induced by goals over a classical planning problem's state-transition system. Our other contributions include: &#8226; Formalizing the distinction between a closed (goal) problem, typical of classical planning, and an open problem that requires goal reasoning. &#8226; Codifying which classical assumptions must change to support the definition of classical open problems. &#8226; Sketching a goal reasoning system-agnostic language for syntactically defining goal reasoning problems that we call GRUPS: the Goal Reasoner &#8746; Problem Solver. &#8226; Discussing our motivating use-case for classical goal reasoning via a GRUPS-based specification.</p><p>A Motivating Example: Adventure Games Consider the task of designing an AI capable of playing adventure games, a kind of interactive narrative experience wherein the protagonist (typically, a human "player") drives the development of an unfolding plot <ref type="bibr">(Riedl and Bulitko 2013)</ref>. Canonically, these storygames present a verb-based command interface with 9 template commands as in Figure <ref type="figure">1</ref>. Players can OPEN unlocked doors, PICK UP co-located items, DROP items from the inventory, CLOSE unlocked open doors, LOOK AT objects, GO TO cardinally-adjacent locations and through open doors, GIVE inventory items and TALK TO co-located characters, and USE inventory items on other objects (e.g. use keys on locked doors to unlock them). As a task domain, adventure games have a finite set of states and are deterministic. The actions that players can perform (all instances of the template commands) execute instantaneously. The virtual world extends beyond what is visible in Figure <ref type="figure">1</ref>'s interface window, but the standard convention of adventure games is that the plot's time-flow is halted to invite attention on the interplay of elements within a limited area of spacetime <ref type="bibr">(Black 2012)</ref>. Thus, players expect that by default nothing changes beyond what they immediately see or do, making the environment effectively fully observable and static.</p><p>At first glance, all we might need to rely on for the AI's architecture is a classical planner like STRIPS (Fikes and Nils-Figure <ref type="figure">1</ref>: Screenshot from a canonical adventure game, with a verb-based command interface. Although classical planners could ostensibly play these games, the lack of formal semantics for changing goals precludes them from doing so in a systematic manner. son 1971) coupled with a pipelined machine scheduler, especially because the main thing to do in these games are quests-i.e. executing (any sequence of) actions to establish conditions that are distinguished by the game due to their narrative import (Cardona-Rivera, Zagal, and Debus 2020). But despite this task environment meeting nearly all assumptions<ref type="foot">foot_0</ref> that define the classical model, off-the-shelf classical planners would fail to meet this challenge due to their inability to systematically handle a change in goals.</p><p>This kind of problem requires the ability to perform goal reasoning. However, (as mentioned) agents that exhibit this kind of goal-driven autonomy today are built for partiallyobservable and dynamic environments, based on the tacit assumption that these features are intrinsic to the class of goal reasoning problems.</p><p>While modern goal-driven agents would undoubtedly succeed at playing an adventure game, they are mismatched to the task environment at hand. With an excess of capability on one hand, and a lack of capability within classical planning on the other, we are left with the question: might there be a middle ground? We explore an answer to that question by critically unpacking the planning basis that goal-driven autonomy was built upon.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">Related Work</head><p>Goal-driven autonomy is a conceptual model, invented to facilitate developing agents that exhibit goal reasoning dynamics-the adoption, (re)formulation, and abandonment of goals-as a key part of the principles that govern their behavior <ref type="bibr">(Molineaux, Klenk, and Aha 2010)</ref>. It emerged as an extension of the dynamic planning model by <ref type="bibr">Ghallab, Nau, and Traverso (2004)</ref>, which itself describes agents capable of generating goal-directed behavior from a given goal in terms of three elements: (1) the system, representing the agent's task environment, (2) a planner, the agent component responsible for organizing behavior toward satisfying the goal, and (3) a controller, the agent component responsible for manifesting the behavior in the system.</p><p>Today, scholars consider dynamic planning as one of the four capabilities that distinguish goal-driven behavior from other forms of autonomy <ref type="bibr">(Aha 2018)</ref>. The other three defining capabilities are the explicit representation, generation, and selection of goals <ref type="bibr">(Hawes 2011;</ref><ref type="bibr">Dannenhauer, Mu&#241;oz-Avila, and Cox 2021)</ref>. However, work in this area has proceeded with a conflicted understanding of what problem goal-driven autonomy is intended to solve. This conflict has manifested in three ways that threaten systematic progress in research on goal-driven autonomy (GDA).</p><p>First, we cannot yet precisely state what features of a problem would motivate the use of GDA. To date, GDA problems are specified within particular goal reasoning architectures, each handling unique execution-level concerns for the agent. As surveyed by <ref type="bibr">Vattam et al. (2013)</ref>, these concerns include the discovery of new actions, detection of higher-utility opportunities, violation of expectations, and graceful degradation of performance, among several others. But despite the array of capabilities, we have yet to articulate a common ground that would allow us to distinguish situations in which the problem at hand calls for revision of the goal being pursued as opposed to plan repair or replanning. Relatedly, we are unable to specify GDA problems in a domain-independent way-unlike dynamic planning ones, which benefit from several planner-agnostic languages like PDDL <ref type="bibr">(McDermott et al. 1998)</ref>.</p><p>Second, we cannot yet precisely state what a GDA problem represents. GDA problems have been framed as a computational model of problem recognition-the human cognitive process that articulates which goals need solving <ref type="bibr">(Cox 2020)</ref>. Confusingly, all of GDA's defining capabilities can manifest within dynamic planning alone. This is because a planner is responsible for ensuring that an action's preconditions are satisfied and not undone from the moment they are established until they are needed. Every action with unsatisfied preconditions affords the planner's generation of (sub)goals, and the planner must perform a selection of which goals to satisfy first (potentially impacting the time needed to satisfy them all). While classical planners need not reify goals to perform their function, plan space planners do-albeit in terms of flaws that must be refined via fixes (cf. <ref type="bibr">Weld 1994;</ref><ref type="bibr">Kambhampati, Knoblock, and Yang 1995)</ref>. Is this goal-driven autonomy? It would seem so, although based on the available literature, subgoaling on unsatisfied preconditions does not exemplify what is colloquially meant by "goal-driven autonomy."</p><p>Third, we cannot yet precisely state what a GDA problem is. Originally, it was defined as a dynamic planning and execution problem over a partially-observable, non-deterministic, and dynamic system with continuous (i.e. non-discrete) effects, where in addition the agent can change its goals <ref type="bibr">(Molineaux, Klenk, and Aha 2010)</ref>. Today, state-of-the-art approaches to GDA only require the agent be able to observe its environment for discrepancies, hypothesize explanations for them, and formulate goals to resolve the discrepancies that target the hypothesized explanations <ref type="bibr">(Cox 2020;</ref><ref type="bibr">Dannenhauer, Mu&#241;oz-Avila, and Cox 2021)</ref>. This suggests that even within GDA there are different problem classes. Without clarifying what the different problems are, a systematization is out of reach.</p><p>Due to the conflicted understanding of what problem GDA is intended to solve, several scholars have questioned the need to distinguish goal-driven autonomy in its own right, in favor of simply recasting GDA problems as specialized dynamic planning ones. For instance, <ref type="bibr">Harland et al. (2014)</ref> have demonstrated that goal-driven autonomous behavior can be richly specified in terms of Belief-Desire-Intention (BDI) agent architectures. Is a commitment to models of BDI necessary to GDA? In contrast, <ref type="bibr">Paredes and Ruml (2017)</ref> have argued that GDA is tantamount to dynamic planning across multiple levels of abstraction-they contend that this insight obviates the need for goal reasoning altogether. Does that preclude the utility of specifying certain problem classes as problems of goal-driven autonomy? Is there a class of GDA problems that cannot be systematically transformed into dynamic planning?</p><p>In view of this conflicted understanding and the questions that it poses, we propose it is worthwhile to re-examine the planning basis of goal-driven autonomy so that we may better understand its formal basis. In this paper, we do just that.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3">From Classical Planning to Classical Goal</head><p>Reasoning: A Modest Proposal</p><p>Classical planning problems are well-defined: they contain a clear specification of the current situation, the desired end, and the available means to arrive at said end from the current situation <ref type="bibr">(Newell, Shaw, and Simon 1960)</ref>. These problems can be represented via STRIPS as follows.</p><p>Definition 1 (Classical Planning Problem) A tuple of the form P = &#10216;L, I, g, &#923;, f cost &#10217;. L is a set of ground literals drawn from a finite and function-free first-order logical language, I &#8838; L is a closed-world initial state, and g &#8838; L is a set of goal conditions that must be satisfied. &#923; is a set of action templates called operators. Each operator &#955; &#8712; &#923; is a triple &#10216;PRE(&#955;), ADD(&#955;), DEL(&#955;)&#10217; of respective precondition, add, and delete lists, all subsets of L. Each operator has an associated cost to execute, determined by the function</p><p>The STRIPS representation is one way to encode a statetransition system, which specifies how some task environment can change as a result of applying actions in states. Definition 2 (State-transition System) A quadruple of the form &#931; = &#10216;S, A, E, &#947;&#10217;. S is a set of states. A is a set of actions that represent state-transitions under the control of a planner. E is a set of events, or contingent state-transitions; these reflect the internal dynamics of the system not under the planner's control. &#947; : S&#215;A&#215;E &#8594; 2 S is a state-transition function that defines the state space of the system.</p><p>As noted by <ref type="bibr">Ghallab, Nau, and Traverso (2004, hereafter, GNT)</ref>, state-transition systems induce a directed graph that reflects the underlying (set-theoretic) semantics of planning, whereas STRIPS is a kind of syntactic specification. This distinction was introduced as part of GNT's conceptual model for dynamic planning, to indicate that (regardless of implementation) all dynamic planning variants perform operations that can be described in terms of &#931;, making it a useful semantic basis of comparison.</p><p>The classical planning variant operates over a restricted form of the elements in &#931; by adopting a set of 8 simplifying assumptions over the GNT model. These are:</p><p>A3 Fully Observable &#931;: The agent has complete knowledge about the state of &#931;. A4 Deterministic &#931;: &#8704;s &#8712; S, a &#8712; A : |&#947;(s, a)| &#8804; 1. Thus, &#947; maps onto S, instead of 2 S . A5 Restricted Goals: Goals are either an explicit goal state s g &#8712; S or a family of goal states S g &#8838; S, defined as:</p><p>The solution is any sequence of state-transitions that results in s g or s &#8712; S g . A6 Sequential Plans: A solution to a planning problem is a plan &#960;, a linearly ordered finite sequence of actions; i.e. a net in A, written as &#960; : N &#8594; A or &#960; : A N . A7 Implicit Time: Actions A and events E have no duration; they are instantaneous state-transitions. A8 Offline Planning: The planner is not concerned with any change that may occur in &#931; while it is planning (it plans for the given initial and goal states).</p><p>Thus, the classical variant effectively disregards the controller and system in the full GNT model. Given a problem P as in Definition 1, its underlying classical state-transition system &#931;(P) is defined as: S &#8838; 2 L ; A is composed of all &#955; &#8712; &#923;; E = &#8709;; and &#947; is piece-wise:</p><p>The STRIPS classical variant compactly represents P as a search problem over the graph induced by &#931;(P) starting in I &#8712; S and ending in a state s &#8712; S g &#8838; S.</p><p>Further, STRIPS is a specific syntactic specification; i.e. it gives a particular form to classical planning operations, which can be conceptually described via a function &#966; as illustrated in Figure <ref type="figure">2</ref>. In other words, a generic classical planner &#966; performs a mapping as follows: </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1">Classical Execution Problems</head><p>Our motivating example from &#167;1 is not strictly a classical planning problem, as it relaxes assumptions A6 and A8. This re-introduces the task environment that was removed for classical planning, which in turn requires that we be more precise about the interplay between planner and system, as mediated by the controller. For brevity, we refer to what results from these relaxations as classical execution problems.</p><p>Definition 3 (Classical Execution Problem) A tuple of the form X = &#10216;P, &#931;&#10217;, where P is a classical planning problem as in Definition 1, and &#931; is a classical task environment defined as &#931; = &#931;(P).</p><p>Whereas the system &#931; typically represents an analog task environment, Definition 3 admits it as a discrete one; i.e. the virtual world encompassing an adventure game. Conceptually, a classical execution problem X places one additional demand on solution plans: a plan &#960; is a solution plan when its execution trace within &#931; = &#931;(P) yields a system state that satisfies the goal conditions. In order to precisely describe what this means, we must revisit the full GNT model.</p><p>Conceptual Gaps within the GNT Model Originally, the GNT model was presented as a theoretical device and was "...not meant to be directly operational" <ref type="bibr">(Ghallab, Nau, and Traverso 2004, p. 9)</ref>. Our rendition in Figure <ref type="figure">2</ref> is unique in that regard: it foregrounds ambiguities in the GNT model that lead to our motivating example's failure case.</p><p>Per the GNT model, the controller is responsible for observing the system &#931; and using that information to drive the dispatching and monitoring of its given plan as it manifests inside the system. Because of the execution requirement, &#960; is revised to be:</p><p>(3) the current plan action sequence state we're in next action to execute Further, the controller's components are defined as follows.</p><p>Observer This is the controller's capacity to perceive the system. It was originally defined by GNT as a function with corresponding inverse:   :</p><p>a D j R + + i 1 t n 7 T U p 7 6 D l 6 g Y 5 R g L r o D L 1 F 5 6 i P G L p G X 9 A N + u p 9 9 r 5 5 3 7 0 f 6 9 Y t b z N z h P 4 q 7 + c v V a 2 u P Q = = &lt; / l a t e x i t &gt; &#8673; : S ! A Dispatcher This is the controller's capacity to find which action should be executed next according to both &#960; and the current state of &#931; per &#951; -1 .</p><p>The dispatcher was only conceptually described by GNT. We formalize it as a composite dispatch function defined as:</p><p>Observe what state we are in... ...to find the action to do... ...within the current plan.</p><p>Equation 6 effectively maps the observations to the plan's suggested next action. Stated directly:</p><p>Of course, classical executable plans defined via Equation 3 make no use of state information (i.e. S is not in the domain of &#960;), so effectively, the next action to do depends solely on the plan's action structure.</p><p>Monitor This is the controller's capacity to detect when plans fail. It was only conceptually described in the GNT model in terms of a status code, representing a report to the planner about the execution status of the current plan &#960;.</p><p>A status code might prompt the planner to engage in revision and/or re-planning operations. But because this reporting process was not formalized, we discovered an interesting ambiguity: under GNT, plan revision and re-planning would only be necessary if we cannot find in &#960; what to do next.</p><p>In classical execution, this might happen because we have achieved the goal or because the current state was not anticipated. Thus, in addition to looking within &#960;, we also need information from the environment. This motivated our formulation of a monitor function, defined as:</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.2">Classical Execution Agents and Solutions</head><p>Conceptually, a solution plan to a classical execution problem must effect a change within the system &#931; such that when the system is observed by the agent (via &#951; -1 ), the current state that is perceived s current &#8712; S &#8712; &#931;(P) = &#931; satisfies the goal; i.e. s current &#8712; G, where G is defined per Equation <ref type="formula">1</ref>.</p><p>Because solution plans must be constructively assessed by the agent's perceptual abilities over &#931;, we reify the agent as: Definition 4 (Classical Execution Agent) A quadruple of the form &#1009; = &#10216;&#966;, &#951;, &#967;, &#954;&#10217;, where &#966; is a planner function as in Equation <ref type="formula">2</ref>; &#951; is an observer function as in Equation <ref type="formula">4</ref>; &#967; is a dispatcher function as in Equation <ref type="formula">6</ref>; and &#954; is a monitor function as in Equation <ref type="formula">8</ref>.</p><p>A classical execution agent &#1009; has the capacity to effect an executable classical plan &#960; within a classical task environment &#931;. We denote the execution trace of said plan as trace(&#960;, &#1009;, &#931;). An execution trace is the ordered sequence of alternating states and actions starting in the current state s current &#8712; &#931;. The sequence results from the application of action a i obtained via the dispatcher &#967; &#8712; &#1009; to the state s i-1 ; i.e. trace(&#960;, &#1009;, &#931;) = [s current , a 1 , s 1 , ..., a m , s m ].</p><p>An executable classical plan &#960; is a solution to a classical execution problem X = &#10216;P, &#931;&#10217; for agent &#1009; iff its trace(&#960;, &#1009;, &#931;) results in a system &#931; configuration that when perceived via the observer &#951; &#8712; &#1009; yields a state s current &#8712; G as defined in Equation 1 from the goal conditions g &#8712; P.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.3">Toward Classical Goal-driven Autonomy</head><p>Our goal-driven autonomy needs require reasoning about execution dynamics in what is arguably their simplest form: within computer-mediated virtual worlds. As mentioned, existing GDA solutions relax the A2 and A3 assumptions, which unduly complicates the algorithm needed to perform the reasoning we care about. As a comparison: it is as if all we needed was a classical planner and the only option we had available was a probabilistic one better-suited for Partially-observable Markov Decision Processes.</p><p>Instead of simplifying non-classical models, we opt to conservatively expand classical ones to "earn our complexity." To us, the elements within classical execution problems are necessary to justify the need for goal reasoning. At the same time, nothing within classical execution specifies what we actually need: a formal mapping that defines how the planner's input objectives G can systematically change.</p><p>When the goals can change, all potential changes implicitly define a goal hyperspace over &#931; (Cox 2020): the states S G &#8838; S &#8712; &#931; reachable from each other via transitions outside A (or A &#8746; E, as relevant). This makes the semantic specification of state-transition systems insufficient to fully describe goal transitions. To that end, we introduce a goaltransition system as an extension to Definition 2: Definition 5 (Goal-transition System) A tuple of the form &#920; = &#10216;&#931;, G, R, &#946;&#10217;. &#931; is a state-transition system as in Definition 2, G is a set of goal states, R is a set of goal refinements that represent goal transitions, and</p><p>The set of goal refinements R and transition function &#946; are the goal reasoning analogue of state-transition system actions A and transition function &#947;.</p><p>Whereas STRIPS may be used to generate the classical form of the elements in &#931;, we lack such a language to generate the elements in &#920;. Notwithstanding, we define &#920;'s classical form as a restricted goal-transition system that adopts all of the classical execution assumptions and defines its elements as follows:</p><p>&#8226; &#931; = &#10216;S, A, &#947;&#10217; is a classical state-transition system defined from P = &#10216;L, I, g, &#923;, f cost &#10217; as discussed earlier.</p><p>&#8226; G &#8838; 2 S , where S &#8712; &#931;. This reflects the A5 assumption: only families of goal states defined from sets of conditions g &#8838; L as in Equation 1 are admissible.</p><p>&#8226; R contains goal refinements r akin to actions a &#8712; A, each of the form r = &#10216;PRE(r), ADD(r), DEL(r)&#10217;. Instead of state transitions, they are goal transitions: they compactly describe a wide variety of dynamics that depend on PRE-adopted goals that might be transformed (possibly with PREconditions on their transformation), the newly ADDed goals that are adopted, and the DELeted goals that are dropped. Like actions, PRE(r), ADD(r), DEL(r) are all subsets of L. These dynamics manifest in a wide variety of modern goal reasoning systems <ref type="bibr">(Roberts et al. 2014</ref>). &#8226; &#946;, like &#947; &#8712; &#931;, is defined piece-wise:</p><p>The above definitions allow us to describe important classes of goal-transitions in the literature (cf. Cox, Dannenhauer, and Kondrakunta 2017), including:</p><p>Goal Formulation <ref type="bibr">(Paisner et al. 2014)</ref>: when an agent infers a new set of goal conditions from some state. This is a goal-transition of the form &#946;(&#8709;, r, s) = g, where the refinement r = &#10216;&#8709;, g, &#8709;&#10217;.</p><p>Goal Change <ref type="bibr">(Choi 2011)</ref>: when an agent transforms an existing goal into another. This is a goal-transition of the form &#946;(g, r, s) = g &#8242; , where the refinement r = &#10216;g, g &#8242; , g&#10217;.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4">Goal-driven Autonomy</head><p>In the original definition of goal-driven autonomy, Molineaux, Klenk, and Aha (2010) relaxed assumptions A2, A3, A4, A6, A7, and A8. They further relaxed a tacit assumption not codified in the original 8, which we make explicit: It is worth noting that &#920; is not a classical goal-driven autonomy problem per se, much like &#931; is not a classical planning problem. That is, &#931; defines the planning problem space wherein a planner searches for a solution. By analogy, &#920; defines the goal-driven autonomy problem space wherein a goal-reasoning system-what we call a goalie in our conceptual model (Figure <ref type="figure">3</ref>)-searches for a solution.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.1">Goal-driven Autonomy Problem Definition</head><p>The literature on potential reasons that might prompt a goalie to act is vast <ref type="bibr">(Cox 2007;</ref><ref type="bibr">Weber, Mateas, and Jhala 2010;</ref><ref type="bibr">Mu&#241;oz Avila et al. 2010;</ref><ref type="bibr">Talamadupula et al. 2010;</ref><ref type="bibr">Laird, Rosenbloom, and Newell 2012)</ref>. The clearest articulation of a common underlying feature is via work by <ref type="bibr">Vattam et al. (2013)</ref> and <ref type="bibr">Cox (2013)</ref>, who independently argued that goal reasoning dynamics manifest as a consequence of an agent's (domain-specific) anomaly detection mechanisms.</p><p>We propose an alternate, albeit consistent, view: that the situations that would trigger those anomaly detection mechanisms have enough commonality to support their specification in a domain-independent way. We posit that the common ground across goalies is their drive to fix broken invariant conditions I-conditions that collectively define a state of equilibrium the agent must maintain.<ref type="foot">foot_1</ref> If all invariant conditions are maintained, no goal reasoning is necessary. On the other hand, any invariant condition being broken is sufficient to check if goal reasoning is required.</p><p>Conceptually, in order to check against invariant conditions in I being violated during execution, the goalie<ref type="foot">foot_2</ref> must sense what the current state is, which is already carried out by the controller. This suggests to us a natural division of responsibilities: the goalie computes the system &#931; expectations to monitor for based on I and an input description of &#920;, whereas the controller computes the difference between the goalie's expectations and the observed system &#931; state. We term these differences discrepancies and posit that they prompt the goalie to engage in goal reasoning as appropriate. While we cannot formalize all these operations due to space, they are consistent with several goalies to date (cf. <ref type="bibr">Molineaux, Klenk, and Aha 2010;</ref><ref type="bibr">Roberts et al. 2014;</ref><ref type="bibr">Dannenhauer, Mu&#241;oz-Avila, and Cox 2021)</ref>.</p><p>To perform the goal reasoning itself, goalies need access to a collection of "goal operators"-akin to the action operators &#923; in classical planning-to support flexible goal reasoning dynamics. We call these template goal operators modifications, defined as generic forms of the refinements R &#8712; &#920;.</p><p>We can now define the goal-driven autonomy problem that represents the goalie's input description of &#920;, and which can describe our motivating adventure game context. Definition 6 (Classical Goal-driven Autonomy Problem) A tuple of the form G = &#10216;X, I, M &#10217;, where X = &#10216;P, &#931;&#10217; is a classical execution problem as in Definition 3, I &#8838; S &#8838; &#931; is a set of invariant conditions that define states to maintain in the system, and M is a set of template refinements called modifications-each defined as a triple m = &#10216;PRE(m), ADD(m), DEL(m)&#10217; of respective precondition, add, and delete lists, all subsets of L &#8712; P.</p><p>Notably, Definition 6 tracks one goal formula: g &#8712; P. Refinements in M manifest as changes to this goal.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.2">Toward Goalie-independent Problem Specs</head><p>Our proposal to encode invariants as the common feature to goal-driven autonomy paves the way toward a goalieindependent problem specification language akin to STRIPS, which itself affords planner-independent specification of closed problems. To that end, we introduce GRUPS: the Goal Reasoner &#8746; Problem Solver, a speculative STRIPS-like language that aims to afford the expression of classical problems as per Definition 6. Ultimately, this means one may eventually use GRUPS to arrive at a precise origin of the elements in &#920; from Definition 5 much like STRIPS was used to generate those of &#931; from Definition 2. Here, we limit ourselves to illustrating how our motivating example might be encoded via GRUPS.</p><p>A Modest Extension to PDDL GRUPS may be feasible to develop via four extensions to PDDL 3 <ref type="bibr">(Gerevini and Long 2005)</ref>. We review each to explain their intended purpose.</p><p>In PDDL 3, constraints are "over possible actions in the plan and intermediate states reached by the plan." Constraints operate on both binary and numerical values, and (:constraints ...) ; as per PDDL 3 (:goals ...) ; problem-independent goals go here (:action pick-up :parameters (?pc -user ?i -item ?l -loc) :precondition (and (at ?pc ?loc) (at ?i ?loc)) :effect (and (not (at ?i ?loc)) (has ?pc ?i)))</p><p>(:action give :parameters (?g -char ?r -char ?i -item ?l -loc) :precondition (and (at ?g ?l) (at ?r ?l) (has ?r ?i))</p><p>:effect (and (not (has ?r ?i)) (has ?g ?i)))</p><p>(:refinement fetch-quest :parameters (?p -char ?np -char ?i -item ?l -loc) :precondition (and (at ?pc ?l) (at ?npc ?l)) :effect (and (has ?npc ?i)))</p><p>Listing 1: Sample GRUPS goal refinements in PDDL-like syntax. The fetch-quest refinement affords an adventure game AI to adopt a goal from a non-player character. This goal would prompt planning toward obtaining the characterrequested item and giving the item to said character. Listing 2: Sample GRUPS problem file in PDDL-like syntax. Above, the goals keyword affords specifying the goals managed by a GDA agent, as an implicitly disjuncted set of (possibly unary) goal sets. The goal g2 appears as a result of the fetch-quest refinement in Listing 1.</p><p>manifest via several built-in predicates; e.g. always, sometime, within, at-most-once, and several other built-in predicates. Where GRUPS might need to differ from PDDL 3 is for allowing constraints to be defined per-problem as well.</p><p>Problems can define how they must be solved, extending restrictions given to the goalie from the domain. Constraints would then be able to represent invariants as described earlier, and would not require adding a new construct.</p><p>Refinements are a GRUPS-extension to the PDDL 3 spec, as demonstrated in Listing 1. Refinements operate on a goal in ways similar to how actions modify the system state. They are syntactically specified similar to PDDL actions.</p><p>Goals represent the biggest syntactic departure between PDDL 3 and GRUPS. We define goals as a set of goal-s; the latter defined per the original PDDL3 spec as demonstrated in Listing 2. Our sketch here supports managing different goals at a time via one goal formula, and we feel it is sufficiently human-readable to support problem authorship.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5">Discussion</head><p>Dynamic planning problems are semantically closed to new goals because by definition the problem goals are pre-sumed <ref type="bibr">(Ghallab, Nau, and Traverso 2004)</ref>. In contrast, goaldriven autonomy problems are characterized in terms of goals that must be refined and by definition are open to them. Dynamic planning thus targets closed problems, and represent the challenge of articulating how goals are solved, akin to the human cognitive process of problem solving <ref type="bibr">(Newell, Shaw, and Simon 1960)</ref>. In turn, goal-driven autonomy targets open problems, and represent the challenge of articulating which goals need solving, akin to the human cognitive process of problem recognition <ref type="bibr">(Cox 2013)</ref>.</p><p>Notably, we have not yet defined the algorithms that would drive a classical goal-driven agent. While space prevents us from doing so, we briefly sketch the functional mappings that might be added to Definition 3 to support solving classical GDA problems. Let &#969; be a generic goalie function akin to its planner counterpart from Equation <ref type="formula">2</ref>. Its output is three-fold: (1) an initial state based on the system's current one with (2) goals for the planner to pursue, and (3) expectations our controller will be tasked with monitoring.</p><p>This then requires a generic discrepancies detector function, which we denote as &#8486;. Together with &#954;, the overall architecture supports defining systematic ways to decide on whether plan shifts are necessary or if goal shifts are. We conclude our theory sketch with a preliminary formal definition of a goal-driven agent: a tuple, &#936; = &#10216;&#966;, &#951;, &#967;, &#954;, &#969;, &#8486;&#10217;, with elements as defined throughout.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="6">Conclusion</head><p>With this combined theoretical foundation, we discovered several things. First, we articulated a novel and parsimonious problem-based distinction between automated planning and goal reasoning (Definition 3 v. Definition 6). Second, we illustrated how our formulation can potentially reconcile a wide variety of features that presently motivate the wide array of approaches to goal-driven autonomy ( &#167;3). Third, we've identified that core assumptions around GDA are not strictly necessary to define interesting goal reasoning problems; relatedly, goal reasoning is necessary upon relaxing a tacit assumption we made explicit: the static goals (A9) assumption ( &#167;4). Fourth, we defined a novel semantic foundation for GDA via Definition 5. Fifth, in &#167;4 we sketched a new goalie-agnostic language-GRUPS-that we will continue to expand in future work. Finally, we demonstrated a potentially interesting class of GDA problems: those involved in developing an AI capable of playing adventure games. We hope others are encouraged to systematically explore this problem class with us.</p></div><note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="1" xml:id="foot_0"><p>Adventure games do not meet the offline planning assumption, which requires integrated planning and execution.</p></note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="2" xml:id="foot_1"><p>In this light, the anomaly detection mechanisms implemented in goalies to date are implicitly describing specific invariant conditions to be maintained. If this is so, we should be able to formalize these tacit invariants in terms of execution problems and solutions, goal-transition systems, and formal properties thereof. While space limitations preclude our formal development of these ideas, our future work aims to do so.</p></note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="3" xml:id="foot_2"><p>We discuss the goalie as if it were a stand-alone component with a single responsibility (i.e. goal reasoning) working alongside a planner and controller. While this helps us decouple the scope of goalie v. planner v. controller concerns, we do not intend to prescribe the choice of how to implement this architecture in practice.</p></note>
		</body>
		</text>
</TEI>
