Iterative Task

An iterative task is a specialized compound task defined by a loop body (a subtask or task network) and a termination condition. The planner repeatedly decomposes and executes the loop body, evaluating the condition after each iteration. It is formally represented in the domain description alongside other tasks and methods. This structure is essential for modeling repetitive processes like data validation or search until a goal is met.

The loop's halt is governed by a logical termination condition, which is evaluated against the dynamic world state. Common conditions include:

• State-Based: A specific fact becomes true (e.g., inventory_count == 0).
• Resource-Based: A consumable resource is exhausted (e.g., budget < cost).
• Iteration Limit: A maximum count is reached (e.g., attempts >= 10).
• Goal Achievement: The desired high-level goal is satisfied. The condition must be carefully designed to prevent infinite loops.

Within Hierarchical Task Network (HTN) planning, an iterative task is a compound task requiring a dedicated decomposition method. This method specifies how to unroll a single iteration, generating the loop body's subtasks. Planners like SHOP interleave this decomposition with state progression, allowing the termination condition to be re-evaluated with updated world facts after each iteration's effects are applied, enabling dynamic loop control.

Unlike a loop written in imperative code (e.g., a while loop), an HTN iterative task is declarative and plan-time. The planner reasons about the iteration, not just executing it. This allows for:

• Optimization: The planner may reorder or interleave loop iterations with other tasks if constraints allow.
• Verification: The plan can be verified for correctness (e.g., guaranteed termination) before execution.
• Explanation: The decomposition tree provides a transparent audit trail of the iterative process.

Iterative tasks model real-world processes requiring repetition until a criterion is met.

• Data Processing: "Clean records until no invalid entries remain."
• Search & Optimization: "Refine solution parameters until error < 0.01%."
• Diagnostic Systems: "Run test A, if inconclusive, run test B, repeat until fault identified."
• Resource Gathering: "Collect units until the required quantity is met." These are foundational for building robust autonomous agents that handle open-ended problems.

Iterative tasks often interact with other HTN control structures.

• Conditional Tasks: The loop body may contain conditional tasks that branch execution based on state, making each iteration adaptable.
• Parallel Tasks: Subtasks within the loop body may be designated for parallel execution, subject to resource constraints, to improve efficiency.
• Recursive Decomposition: An iterative task's loop body can itself contain another iterative task, enabling nested loops for complex multi-phase processes.

A task whose decomposition or execution is contingent on the runtime evaluation of specific world state conditions. This is a fundamental mechanism for implementing the termination logic of an iterative task.

• Key Role: Enables branching logic within a plan. The planner or executor checks a condition to decide which method to apply or whether to continue a loop.
• Example: A Navigate task may decompose into Drive if the destination is far, or Walk if it is near. An iterative PolishSurface task continues its subtask only while the SurfaceRoughness metric is above a threshold.

A logical condition that must be true in the current world state for a planning operator or HTN method to be applicable. For iterative tasks, preconditions often encode the termination condition.

• Mechanism: A method that decomposes an iterative task will have a precondition that, when evaluated as false, prevents its application, thereby ending the iteration.
• Contrast with Effects: While effects change the state, preconditions are checked before an action or decomposition to ensure validity. A loop continues only while the precondition for its continuation method holds.

The iterative process in HTN planning of replacing abstract tasks in a skeletal plan with more concrete subtasks or primitive actions. Executing an iterative task is a form of runtime plan refinement.

• Process: The planner or executive agent begins with a high-level iterative task. Through refinement, it repeatedly applies decomposition methods, generating concrete subtask instances until the termination condition is met.
• Link to Execution: In online planning or interleaved planning and execution, refinement happens in real-time. The agent refines the iterative loop, executes a subtask, evaluates the state, and decides whether to refine another iteration.

The process of generating a new plan when the execution of the current plan fails or the world state changes unexpectedly. Iterative tasks must be robust to replanning if an iteration fails.

• Failure Context: If an iteration's subtask fails (e.g., a GraspObject action drops the item), the system may need to replan. This could involve retrying the same iterative task with modified parameters or choosing a different decomposition method altogether.
• System Resilience: A well-designed iterative task within an HTN provides clear replanning hooks. The system can backtrack to the level of the iterative task and attempt a different strategy for the remaining iterations.

A seminal HTN planning algorithm that performs task decomposition in a forward, depth-first manner, interleaving planning with state progression. SHOP naturally handles iterative tasks through recursive method application.

• Algorithm Behavior: SHOP starts with a task list, picks the first task, and finds an applicable method or operator. It then recursively decomposes compound tasks. For an iterative task, this means the planner will repeatedly apply the same decomposition method, progressing the simulated world state each time, until the method's preconditions are no longer met.
• Practical Impact: SHOP's approach demonstrates how iterative logic is embedded in the domain description (via methods with state-dependent preconditions) rather than as a separate control construct in the planning algorithm itself.

A tree structure that visually represents the hierarchical breakdown of a high-level task into its constituent subtasks during HTN planning. An iterative task creates a repeating pattern within this tree.

• Visualizing Iteration: In the tree, a node for an iterative task will have multiple, structurally similar subtrees as children, each representing one cycle of the loop. The tree expands horizontally at that level with each iteration.
• Debugging Aid: The decomposition tree is a crucial tool for plan verification and debugging. It allows engineers to see how many times an iterative task was decomposed and inspect the state conditions that led to each decomposition step.