Domain Description (HTN)

Task schemas are templates that define the classes of tasks the planner can reason about. They are the fundamental building blocks of the domain.

• Primitive Task Schemas define directly executable actions, analogous to operators in classical planning. Example: drive(vehicle, location_a, location_b).
• Compound Task Schemas define high-level, abstract goals that require decomposition. Example: deliver_package(package, destination). Each schema includes a name and a set of typed parameters, establishing the vocabulary for the planning problem.

Operators provide the executable semantics for primitive tasks. An operator is a grounded instance of a primitive task schema, defined by:

• Preconditions: Logical conditions that must be true in the current world state for the action to be applicable. Example: At(vehicle, location_a) ∧ HasFuel(vehicle).
• Effects: The changes applied to the world state upon successful execution. Effects add and delete predicates. Example: Add: At(vehicle, location_b); Delete: At(vehicle, location_a). Operators are the leaves of the decomposition tree, representing the actual steps in a final executable plan.

Methods are the core decomposition rules for compound tasks. A method specifies one way to achieve a high-level goal by breaking it into a network of smaller subtasks.

• Each method is associated with a specific compound task schema.
• It contains method preconditions that must hold for this decomposition to be valid.
• Its body is a task network: a set of subtasks (which can be compound or primitive) and ordering constraints between them. For the compound task deliver_package(pkg, dest), a method might decompose it into: 1. load(pkg, truck) → 2. drive(truck, warehouse, dest) → 3. unload(pkg, truck).

These components define a specific planning problem instance within the domain.

• Initial State: A complete snapshot of the world before planning begins, expressed as a set of grounded, true logical predicates. Example: {At(Truck1, Depot), In(PackageA, Warehouse), HasFuel(Truck1)}.
• Initial Task Network (ITN): The goal specification for the planner. It is the set of high-level compound tasks that need to be accomplished. For a simple goal, the ITN might contain a single task like [deliver_package(PackageA, CustomerSite)]. The planner's job is to decompose this ITN into a sequence of executable operators.

Constraints impose necessary relationships and limitations on the planning process, ensuring generated plans are logically consistent and feasible.

• Ordering Constraints: Specify temporal precedence between subtasks within a method's network (e.g., A < B meaning A must precede B).
• Logical Constraints (Preconditions): Ensure tasks and methods are only applied in valid states.
• Resource Constraints: (In extended HTN formulations) Limit the use of consumable or reusable assets (e.g., battery_level > 20, uses(robot, gripper)). These constraints are evaluated during decomposition to prune invalid search paths.

A critical distinction in HTN planning separates the reusable domain knowledge from the specific scenario.

• Domain Description: The permanent rulebook containing the task schemas, operators, and methods. It encodes the know-how for a field (e.g., logistics).
• Planning Problem: The transient instance combining the domain with a specific initial state and initial task network. It asks: "Given these rules and this starting situation, how do I achieve this goal?" This separation allows a single, well-engineered domain description to solve an infinite variety of specific problems.

A Planning Problem is the complete formal instance given to an HTN planner. It consists of three core components:

• Domain Description: The library of tasks, methods, and operators.
• Initial State: A snapshot of the world's starting conditions (e.g., RobotAt(Kitchen), CoffeeBeansAvailable).
• Initial Task Network: The high-level goal task(s) to be decomposed (e.g., DeliverCoffee(Office)). The planner's job is to use the domain's rules to transform the initial task network into an executable sequence of actions, given the initial state.

A Task Library is the curated collection of all task schemas, methods, and operators for a specific application domain. It is the reusable knowledge base of an HTN system.

• Encodes Domain Expertise: It captures the known procedures for achieving goals in that domain (e.g., manufacturing, logistics, software deployment).
• Promotes Modularity: Libraries can be versioned, shared, and extended. A KitchenOperations library might be imported into a larger HomeAssistant domain.
• Defines Capability Boundaries: The planner can only generate plans using the tasks and decompositions defined in the library, ensuring solutions are grounded in known, safe procedures.

An Operator is the formal representation of a primitive, executable action. It is the atomic unit of change in the planning world.

• Preconditions: Logical statements that must be true for the action to be legal (e.g., Has(robot, package) to execute Unload(robot, package)).
• Effects: The changes applied to the world state upon execution. Effects add new facts (At(package, destination)) and delete outdated ones (~Has(robot, package)). In HTN planning, operators are the leaves of the decomposition tree. A plan is only executable when all abstract tasks have been decomposed down to a sequence of operators.

A Task Schema is a template that defines a class of tasks, abstracting over specific instances. It specifies the task's name and parameters.

• Parameterized Definition: Navigate(robot, from, to) is a schema. Navigate(Robot1, Kitchen, Office) is an instance.
• Unifies Representation: Both primitive and compound tasks are defined by schemas. The domain description declares whether a schema is primitive (mapped to an operator) or compound (decomposed by methods).
• Enables Constraint Propagation: Constraints on parameters (e.g., from != to) defined in the schema can be propagated during decomposition to prune invalid plans early.

A Skeletal Plan is a partially specified, hierarchical plan generated during the intermediate stages of HTN decomposition. It contains a mix of:

• Primitive Actions: Already-resolved operators.
• Abstract (Compound) Tasks: High-level tasks that still require further decomposition.
• Ordering & Binding Constraints: Temporal relations and variable assignments established so far. Skeletal plans are refined iteratively. They represent the planner's current hypothesis about the plan's structure before all details are finalized, allowing for flexible refinement and repair.

Plan Verification is the formal process of checking that a generated plan is valid. For an HTN-derived plan, this involves verifying:

• Executive Validity: Every primitive action's preconditions are satisfied at the moment of execution, given the predicted state progression.
• Goal Achievement: The final state after executing the plan satisfies the goals implicit in the initial task network.
• Constraint Satisfaction: All ordering, resource, and binding constraints in the fully decomposed plan are respected. Verification provides a critical safety check, ensuring the plan is not just syntactically correct but will work as intended when executed.