Primitive Task

A primitive task represents a single, indivisible action within the planning domain. It is the terminal leaf in an HTN's decomposition tree. For example, in a robotic manipulation domain, PickUp(Block_A) and PlaceOn(Block_A, Table) are primitive tasks. They correspond directly to planning operators with defined preconditions and effects that alter the world state.

Each primitive task is formally defined as a planning operator with a precise specification:

• Preconditions: Logical statements that must be true in the current world state for the action to be legally applied. For PickUp(Block_A), a precondition might be IsGripperEmpty() and IsOn(Block_A, Table).
• Effects: The changes the action makes to the world state. The effect of PickUp(Block_A) would be Holding(Block_A) and not IsOn(Block_A, Table). This formal grounding is what allows for automated plan verification.

In the HTN planning process, high-level compound tasks are recursively broken down via methods until only primitive tasks remain. A primitive task is the point where decomposition stops. It is the bridge between abstract planning and concrete execution. The resulting solution plan is a sequence of these primitive tasks, such as [NavigateTo(Kitchen), Open(Fridge), Grasp(Milk), NavigateTo(Counter)].

A primitive task must have a clear correspondence to an executable command in the target system. This could be:

• A low-level API call (e.g., POST /api/transaction).
• A robotic motor command (e.g., SetJointAngle(arm, 45deg)).
• A database operation (e.g., UPDATE inventory SET quantity = quantity - 1). This mapping is defined in the domain description and is invoked during the plan execution phase.

Understanding primitive tasks requires contrasting them with compound tasks:

• Primitive Task: Executable action. No further decomposition. Defined by preconditions/effects.
• Compound Task: Abstract objective (e.g., ServeCoffee). Requires decomposition via methods into a network of subtasks (which may be other compound tasks or primitive tasks). The initial task network given to an HTN planner consists of compound tasks; the planner's job is to replace them all with primitive tasks.

Because primitive tasks have formal preconditions, a planner can simulate their execution in a world model to check plan validity before real-world execution. By applying the sequence of primitive tasks to the initial state, the planner can verify that all preconditions are met at each step and that the final state satisfies the goal. This enables replanning if a precondition fails during simulated execution, a core feature of robust agentic cognitive architectures.

A high-level, abstract task in an HTN that must be decomposed into subtasks before it can be executed. It represents a goal, not an action.

• Contrast with Primitive Task: While a primitive task is an executable action, a compound task is a goal that requires planning.
• Example: Assemble Product is a compound task. The HTN planner must find a method to decompose it into subtasks like Fetch Components, Attach Part A to B, and Apply Fasteners.

A decomposition rule that defines a possible way to break down a compound task into a network of subtasks, given specific preconditions are met.

• Mechanism: A method is a schema: Task + Preconditions -> Subtask Network.
• Role: It provides the 'how-to' knowledge for the planner. A single compound task may have multiple applicable methods.
• Example: For the compound task Navigate to Room, one method might decompose it into [Open Door, Move Through, Close Door], while another method for an open doorway might be simply [Move Through].

The formal, logic-based representation of an executable action in a planning domain, defined by its preconditions and effects. A primitive task is grounded by an operator.

• Relationship: A primitive task is the planning-level node; an operator is its formal semantic definition.
• Components: An operator specifies:
  • Preconditions: Logical statements that must be true in the world state for the action to be performed.
  • Effects: How the action changes the world state (adds or deletes facts).
• Example: The primitive task PickUp(BlockA) is executed by applying the PickUp operator, which has a precondition clear(BlockA) and an effect holding(BlockA).

The core algorithmic process in HTN planning where a compound task is recursively replaced by a network of subtasks using applicable methods, until only primitive tasks remain.

• Process: It transforms an abstract goal into a concrete, executable plan.
• Output: The result is a decomposition tree (or hierarchy) showing the breakdown from the initial task to primitive actions.
• Analogy: Similar to a programmer calling a function (compound task) which is compiled down to machine instructions (primitive tasks).

A seminal, forward-chaining HTN planning algorithm that performs task decomposition in a depth-first manner, interleaving planning with state progression.

• Key Innovation: It plans in the same order tasks will be executed, making it highly efficient.
• Relevance to Primitives: SHOP's execution loop directly identifies when a task in the network is primitive and can apply its corresponding operator to progress the simulated world state.
• Use Case: Foundational for many modern agentic planning systems and game AI.

A partially specified plan generated during HTN planning, containing a mix of compound and primitive tasks. It requires further refinement through decomposition.

• Status: It is an intermediate product of the planning process.
• Content: May contain high-level compound tasks (placeholders for future decomposition) alongside already-resolved primitive tasks.
• Evolution: Through iterative plan refinement, abstract tasks in the skeletal plan are replaced with concrete subtasks until a fully executable sequence of primitives is achieved.