## 3 Problem Definition
### Planning Domain Knowledge  
Planning domain knowledge encompasses all the necessary information and rules that guide the HTN planning process, enabling effective task decomposition and plan reasoning. Unlike classical HTN planning, this paper expands the planning domain knowledge into the partially observable domain for high-quality plans. We first define it and define the components as follows. The planning domain knowledge is defined as below. **Definition 3**. : _(Planning domain knowledge) The planning domain knowledge is defined as \(D=(O_{act},O_{sense},M)\), where_  
* \(O_{act}\) _is a finite set of actuation operators;_
* \(O_{sense}\) _is a finite set of sensing operators;_
* \(M\) _is a finite set of methods._  
Sensing actions aim to observe the planning environment and obtain observations regarding uncertain information. Note that sensing actions do not transform any ground states. Sensing actions are classified as actions, but they should be differentiated from other actions that do change the states of the objective environment. Therefore, in this paper, we designate the actions that change the states and lack sensing capability as actuation actions. Sensing actions lack positive and negative effects. The accessorial portion, however, is embodied in the observation. As the result of sensing, observation presents the real situation perceived by the agent in the partially observable environment and is treated as the precondition of the conditional plan, which means that if the agent senses an observation, then it executes the corresponding plan. Consequently, the two types of operators are defined as below. **Definition 4**. : _(Actuation operator) An actuation operator is a four-tuple \(O_{act}=\big{(}head,pre,effect,cost\big{)}\) where_  
* _head is the actuation operator's head and should unify with an actuation primitive task that can be completed by the action;_
* \(pre\) _is the precondition that must hold;_
* \(effect\) _is the positive and negative effect of the actuation operator;_
* \(cost\) _is the cost function of the operator._  
Some works for high-quality plans in HTN planning [24] assign operators a constant cost. This assumption, however, has limitations. Since the operators are an abstract form of actions, different actuation actions instantiated from one actuation operator should have different costs. We take the ZenoTravel [42] domain as an example. ZenoTravel describes a problem in which passengers are transported by airplane between cities. The actuation operator!fly describes an airplane flying from one city to another city. Its cost is considered as the consumption of fuel during the voyage. The longer the flight route is, the more fuel is consumed. Hence, in this paper, the cost of the actuation operator is modeled as a function of variables or an if-else statement. When it is instantiated into an action, it has a real sense. For example, the fuel cost of the actuation operator!fly can be calculated by a linear function of the flying route between two cities. As in uncertain environments some states are not deterministic, the cost of an actuation operator can be formalized as an if-else statement function of grounds states. For instance, when the airplane lands at an airport, it can be refueled by the oil supplier there. But it is uncertain whether the oil supplier is occupied. The time cost of the operator!refuel should be 40 if the supplier is available but 100 if it is occupied. **Definition 5**. : _(Sensing operator) A sensing operator is a three-tuple \(O_{sense}=(head,pre,obs)\), where_  
* _head is the sensing operator's head, which should unify with a sensing primitive task;_
* _pre is the precondition;_
* _obs is a set of mutually exclusive observations that denote all the possible outcomes after the execution of the sensing action. An observation is a belief state._  
In partially observable environments, the real outcome of a sensing action can only be determined at the execution time.