Conditional Task

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 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.