Domain Description (HTN)

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.

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.