Task Library

A Task Schema is a template that defines a class of tasks within the library. It specifies the task's name, parameters (variables), and its type—either Primitive Task (directly executable) or Compound Task (requires decomposition). For example, a DeliverPackage(package, location) schema defines the structure for all delivery tasks. Schemas provide the standardized building blocks from which specific planning problems are constructed.

A Method is a rule that defines a possible way to decompose a compound task into a network of subtasks. Each method is associated with a specific compound task schema and contains:

• Preconditions: Logical conditions that must be true in the current world state for this decomposition to be valid.
• Subtasks: The ordered network of (compound or primitive) tasks that implement the parent task. A library contains multiple methods for key compound tasks, enabling the planner to choose context-appropriate strategies. For instance, the AssembleProduct task might have different methods for 'rush order' versus 'standard assembly'.

An Operator is the formal, executable representation of a Primitive Task. It defines the lowest-level action the system can perform. Each operator is grounded by:

• Preconditions: State conditions required for the action to be legally applied.
• Effects: The precise changes the action makes to the world state (e.g., robot_location = warehouse). Operators are the leaves of the Decomposition Tree. A robust library includes operators for all fundamental capabilities, such as Navigate(robot, from, to), Grasp(robot, object), or CallAPI(endpoint, payload).

This component defines the formal language used to express the Preconditions for methods and operators and the Effects of operators. It typically uses a predicate logic (e.g., first-order logic) to represent facts about the world state. For example, a precondition might be At(Robot1, LoadingDock) AND Has(PackageA). An effect might be NOT(At(Robot1, LoadingDock)) AND At(Robot1, StorageRoom). The library's logic framework determines the planner's reasoning power and the complexity of real-world constraints it can model.

Beyond basic preconditions, a task library encodes domain-specific constraints that govern valid task decomposition and ordering. These include:

• Ordering Constraints: Temporal relations (e.g., Task A before Task B).
• Resource Constraints: Limitations on consumables (e.g., battery_level > 20%) or reusable assets (e.g., uses(forklift)).
• Causal Links: Dependencies between tasks where one task produces a state that another requires. These constraints ensure the planner generates feasible, efficient plans that respect real-world operational limits.

A task library is a living codebase requiring systematic curation. This involves:

• Schema Validation: Ensuring new task schemas and methods are consistent and non-contradictory.
• Performance Profiling: Annotating tasks with estimated cost, duration, or reliability metrics to guide the planner.
• Version Control: Managing different library versions for various operational contexts (e.g., warehouse_v1.2, emergency_protocols).
• Modular Design: Organizing the library into reusable, domain-specific modules (e.g., navigation.tlib, manipulation.tlib) that can be composed for complex agents.

The formal specification that defines the universe of a planning problem. It is the complete rulebook for an HTN planner, containing:

• The Task Library: All available task schemas.
• Methods: Rules for decomposing compound tasks.
• Operators: Definitions of primitive actions (preconditions & effects).
• Predicates: The vocabulary for describing world states. The Domain Description provides the static knowledge; the planner uses it to solve dynamic Planning Problems.

A template that defines a class of tasks within the Task Library. It specifies:

• Task Name & Parameters (e.g., Transport(?item, ?from, ?to)).
• Whether it is a Primitive Task (executable) or a Compound Task (requires decomposition).
• For compound tasks, it links to the Methods that define possible decompositions. Schemas provide the standardized interface for the planner to reason about and manipulate tasks.

A decomposition rule stored in the Task Library. It defines one possible way to achieve a compound task. A method consists of:

• Preconditions: Logical conditions that must be true for this method to be applicable.
• Subtasks: The network of (compound or primitive) tasks that implement the parent task.
• Ordering Constraints: Temporal relations between the subtasks. The planner selects an applicable method to break an abstract goal into concrete steps.

The definition of a primitive, executable action within the planning domain. It is the atomic unit of change and is characterized by:

• Parameters: Variables for the action (e.g., ?block).
• Preconditions: Facts that must be true in the world for the action to be legally executed.
• Effects: Additions and deletions to the world state that result from the action's execution. Operators are the leaves of the decomposition tree, directly interfacing with the execution environment.

A specific instance to be solved, combining the static Domain Description with dynamic elements:

1. Initial State: A complete snapshot of the world at the start (e.g., (On A Table), (Clear B)).
2. Initial Task Network: The high-level goal task(s) to be accomplished (e.g., [BuildTower(A, B, C)]). The planner uses the Task Library from the Domain Description to decompose the Initial Task Network into a sequence of Operators that transforms the Initial State into a goal-satisfying state.

A seminal, forward-chaining HTN planning algorithm. SHOP is significant because it interleaves planning with state progression:

• It decomposes tasks in the order they would be executed.
• After decomposing a task to primitive operators, it immediately applies the operator's effects to a simulated world state.
• This allows it to evaluate preconditions of subsequent tasks against the current, projected state, making it highly efficient. The Task Library provides the methods SHOP uses for its depth-first, ordered decomposition.