Conditional Task

The decomposition or execution path of a Conditional Task is not predetermined but is selected based on the evaluation of preconditions against the current world state. This is the core distinction from static task networks.

• Example: A Navigate task may decompose into CallElevator if the agent is inside a building, or WalkToDestination if it is already outside. The planner evaluates the agent-location state variable to choose the correct method.

Conditionality is formally implemented through HTN Methods. Each method provides one possible decomposition for a compound task, guarded by a logical precondition.

• A task like AcquireItem(?item) could have multiple methods:
  • Method 1: Precondition ItemOnShelf(?item) → Subtasks: NavigateToShelf, PickUpItem.
  • Method 2: Precondition ItemInStorage(?item) → Subtasks: RequestFromStockroom, WaitForDelivery. The planner selects the first method whose precondition holds true.

Conditional Tasks are the primary mechanism for introducing branching logic and contingency handling into hierarchical plans. They allow a single high-level goal to be achieved via different action sequences depending on situational context.

• This is critical for robustness in dynamic environments. For instance, an HandleServerAlert task will branch differently if the condition alert-severity == CRITICAL is true versus if it is false, leading to distinct escalation and repair procedures.

While HTN planning is often considered deliberative, Conditional Tasks bridge planning with reactive execution. During plan execution, if a condition for a pending task changes, the system can trigger replanning from that task node.

• This creates a sense of continuous, context-sensitive decision-making. An AssessRisk task that conditionally calls Evacuate or ContinueMission can be re-evaluated if new sensor data updates the world state, making the agent responsive to real-time changes.

It's essential to differentiate a Conditional Task from its sibling concepts in the HTN hierarchy:

• Primitive Task: An executable action (e.g., TurnValve). Has no decomposition.
• Compound Task: A high-level task (e.g., RepairPump) that must be decomposed, but may have only one static method.
• Conditional Task: A type of Compound Task that has two or more alternative methods, where the choice is contingent on state. All conditional tasks are compound, but not all compound tasks are conditional.

Algorithms like SHOP (Simple Hierarchical Ordered Planner) natively support Conditional Tasks. SHOP performs a forward search, interleaving task decomposition with state progression. When it encounters a compound task, it evaluates the preconditions of all its methods in the current state and non-deterministically chooses an applicable one to pursue.

• This makes the planning process itself conditional and state-dependent. The efficiency of HTN planning comes from this directed search through the space of possible decompositions, guided by the preconditions on methods.

A planning formalism that decomposes high-level tasks into networks of subtasks using methods until primitive, directly executable actions are reached. It provides the overarching framework within which a Conditional Task operates.

• Core Principle: Problem-solving via recursive task reduction.
• Contrast with Classical Planning: HTNs specify how to achieve tasks, not just the end state.
• Key Components: Compound tasks, primitive tasks, methods, and preconditions.

A high-level, abstract task in an HTN that must be decomposed into subtasks before it can be executed. A Conditional Task is a specialized type of compound task where the decomposition path is not fixed.

• Abstraction Level: Represents a goal or objective, not a direct action.
• Decomposition Requirement: Cannot be executed; must be broken down via a method.
• Example: AssembleProduct() is a compound task decomposed into FetchComponents(), AttachParts(), and QualityCheck().

A task in an HTN that corresponds directly to an executable action or operator in the planning domain. It is the terminal leaf node in a decomposition tree.

• Executability: Has associated preconditions and effects that directly change the world state.
• Contrast with Conditional/Compound Tasks: Requires no further decomposition.
• Role in Plans: The final sequence of primitive tasks forms the solution plan.

A schema in an HTN that defines a possible way to decompose a compound task into a network of subtasks, given certain preconditions are met. It is the mechanism that enables conditional decomposition.

• Structure: Method(Task, Preconditions, SubtaskNetwork).
• Conditional Logic: Multiple methods can exist for the same compound task, each with different preconditions, creating branching decomposition paths.
• Execution: The planner selects the first method whose preconditions hold in the current state.

A logical condition that must be true in the current world state for a planning operator or HTN method to be applicable. It is the gatekeeper for task decomposition and execution.

• Types: Can be simple (inventory.has(item)) or complex, involving logical conjunctions/disjunctions.
• Role in Conditional Tasks: Determines which decomposition method is valid at runtime.
• Evaluation: Checked during both planning (task decomposition) and plan execution.

The core process in HTN planning where a compound task is recursively replaced by a network of subtasks using applicable methods. This process resolves Conditional Tasks by evaluating preconditions to choose a decomposition path.

• Algorithm: Typically a depth-first, goal-directed search through the space of possible decompositions.
• Output: A decomposition tree or a sequence of primitive tasks (a plan).
• Dynamic Nature: For conditional tasks, the decomposition path can vary each time based on the runtime state.