Task Schema

The task name is a unique identifier for the class of task (e.g., deliver-package). Parameters are typed variables that define the task's specific instance (e.g., ?package, ?destination). These parameters are bound to concrete objects during planning and execution, allowing the same schema to be reused for different scenarios.

Preconditions are logical predicates that must be true in the current world state for the task to be applicable. They define the contextual requirements for execution or decomposition.

• For a primitive task drive-to(?location), a precondition might be (vehicle-fuel-level > 0).
• For a compound task, preconditions on a method determine if that decomposition path is valid.

Effects describe the changes to the world state that result from successfully executing a primitive task. They are the formal specification of the task's outcome.

• Add Effects: Facts that become true (e.g., (package-at ?package ?destination)).
• Delete Effects: Facts that become false (e.g., (package-at ?package ?origin)). Compound tasks have no direct effects; their impact is defined by the effects of their decomposed primitive subtasks.

This core component defines how a compound task is broken down. It is not a single step but a set of methods, each providing a possible decomposition recipe.

• A method contains a subtask network: an ordered or partially-ordered set of child tasks.
• The schema specifies the task's type (primitive or compound), which dictates whether it requires decomposition or maps directly to an executable action.

Constraints impose logical and temporal restrictions on task execution and decomposition. They ensure the generated plan is feasible and correct.

• Ordering Constraints: Specify that subtask A must precede subtask B.
• Resource Constraints: Limit the use of consumables (e.g., (battery-capacity >= 15%)).
• Binding Constraints: Enforce variable equality or inequality between parameters of different subtasks.

A task schema does not exist in isolation. It is part of a domain-specific task library, a curated collection of schemas, methods, and operators. The schema's parameters and effects must be consistent with the ontology of this library. This integration allows the HTN planner to reason about interactions between different tasks and reuse modular components across complex plans.

A planning formalism where the solution is generated by recursively decomposing high-level, abstract tasks into networks of subtasks using decomposition methods until a sequence of primitive, executable actions is found. Unlike classical planners that search for sequences of actions, HTN planners search for sequences of decompositions.

• Core Principle: Knowledge-based planning. The domain's 'how-to' knowledge is encoded in methods.
• Key Advantage: Efficiently solves complex problems by leveraging domain-specific decomposition strategies.

A schema that defines a possible way to decompose a specific compound task into a network of subtasks. A method is only applicable if its preconditions are satisfied by the current world state. It is the primary knowledge element that guides the HTN planner.

• Structure: Method(Task, Preconditions, Subtask Network)
• Example: A Method(CookDinner, {haveIngredients=true}, [PrepareIngredients, CookMainCourse, SetTable]).
• Role: Provides the 'recipes' for achieving abstract goals.

A task in an HTN that corresponds directly to an executable action or operator in the planning domain. It is a leaf node in the decomposition tree and cannot be broken down further by the planner. Its execution has defined effects on the world state.

• Contrast with Compound Task: A primitive task is an action (e.g., PickUp(BlockA)), while a compound task is a goal (e.g., BuildTower).
• Representation: Often modeled as a STRIPS-like operator with preconditions and effects.

A high-level, abstract task in an HTN that must be decomposed into subtasks (which can be other compound tasks or primitive tasks) before it can be executed. It represents a goal or an activity requiring multiple steps.

• Role: Serves as an entry point for planning. The initial task network is composed of compound tasks.
• Decomposition: Each compound task has one or more associated methods that define how to achieve it under different conditions.
• Example: AssembleFurniture, DiagnoseSystemFault, PlanMarketingCampaign.

The core algorithmic process in HTN planning where a compound task is recursively replaced by a network of subtasks using an applicable method. This process continues until the entire task network consists only of primitive tasks, resulting in an executable plan.

• Process: 1. Select a non-primitive task. 2. Choose an applicable method. 3. Replace the task with the method's subtask network. 4. Repeat.
• Output: Creates a decomposition tree that records the hierarchical breakdown.

The formal specification of an HTN planning problem. It is the knowledge base that defines the planner's capabilities and the rules of the domain. A complete domain description includes:

• Task Schemas: Definitions for all compound and primitive tasks.
• Methods: All decomposition rules for compound tasks.
• Operators: The definitions (preconditions/effects) for all primitive tasks.
• Predicates: The vocabulary for describing world states.

This description, combined with an initial state and initial task network, defines a planning problem.