Precondition

Preconditions are expressed as first-order logic statements or propositional logic assertions that are evaluated against the current world state. They act as guard conditions, preventing the planner from applying an operator or method in an invalid context. For example, a PickUp(Block) operator would have a precondition Clear(Block) ∧ HandEmpty() to ensure the block is accessible and the agent's gripper is free.

The validity of a precondition is strictly dependent on the current world state snapshot. A method that is applicable at one point in the planning process may become inapplicable later if other actions change the state. This dynamic evaluation is central to forward-chaining planners like SHOP, which interleave planning with state progression to ensure every chosen decomposition step is grounded in a reachable world state.

Preconditions exist at two distinct levels in HTNs:

• Operator Preconditions: Guard the execution of primitive tasks (e.g., DriveTo(Location) requires HasFuel(Vehicle)).
• Method Preconditions: Determine when a compound task can be decomposed in a specific way (e.g., the method TravelByCar for the task GoToOffice requires CarAvailable and Not(Raining)). Method preconditions enable context-sensitive decomposition, allowing a single high-level task to be achieved via different subtask networks depending on the situation.

Preconditions and effects define the input-output contract of a planning element. While preconditions specify the required input state, effects describe the resultant output state after application. This {Preconditions → Effects} model is the foundation of the STRIPS planning representation. A complete operator is defined as Operator(parameters, preconditions, effects). Failure to satisfy preconditions leads to an invalid, non-executable plan.

By attaching preconditions to high-level methods, HTNs enforce hierarchical relevance. The planner only considers decompositions that are meaningful in the current context, pruning vast areas of the search space. This is more efficient than classical planners that must reason about all possible low-level action sequences. For instance, a method for AssembleProduct might have a precondition AllComponentsInStock, preventing the planner from even attempting a detailed assembly sequence if parts are missing.

Preconditions are evaluated against a symbolic world state, typically a set of grounded logical facts (e.g., {At(Robot, RoomA), DoorOpen(Door1)}). In modern agentic systems, this state may be maintained by a knowledge base or derived from a perception module. For conditional planning, preconditions can include probabilistic thresholds or sensor-derived predicates, bridging symbolic AI with real-world, uncertain data.

An effect is the formal description of how a planning operator or primitive task changes the world state upon its successful execution. It is the counterpart to a precondition.

• Add Effects: Propositions that become true in the new state (e.g., (block-on-table A)).
• Delete Effects: Propositions that become false (e.g., (holding A)).
• In HTN planning, the planner uses effects to progress the simulated world state forward after applying an operator, which in turn determines the preconditions for subsequent tasks.
• Effects create the causal links in a plan, justifying why a task is placed in a specific order to satisfy another task's precondition.

An operator (or action schema) is the formal representation of an executable, primitive action in a planning domain. It is the atomic unit of change.

• Defined by a name, parameters, a set of preconditions, and a set of effects.
• In HTN planning, operators are the leaves of the decomposition tree. A method's subtask network must ultimately decompose into a sequence of operators.
• Example (Block World):
  • Operator: PickUp(block)
  • Precondition: (clear block), (handempty)
  • Effect: (holding block), ¬(clear block), ¬(handempty)
• The planner's goal is to find an ordered set of operators whose combined effects transform the initial state into one satisfying the goal.

A method is a schema that defines a possible way to decompose a compound (high-level) task into a network of smaller subtasks, provided its preconditions are satisfied in the current state.

• It is the core knowledge element of HTN planning, encoding domain expertise on how to achieve tasks.
• Structure: Method: DecomposeTask(T, C) -> Network N where T is the compound task, C are the method's preconditions, and N is the resulting subtask network.
• Preconditions in Methods: These are state constraints that must hold for that particular decomposition strategy to be applicable. Different methods for the same task may have different preconditions, allowing for context-sensitive planning.
• Example: A method for Travel(Home, Office) might have a precondition (weather-clear) to decompose into [WalkToCar, DriveToOffice], while an alternative method with precondition (weather-stormy) decomposes into [CallTaxi, RideToOffice].

Task decomposition is the recursive process in HTN planning where a high-level, compound task is replaced by a network of subtasks using an applicable method, continuing until only primitive tasks (operators) remain.

• It is a goal-directed search through the space of possible decompositions.
• At each step, the planner must:
  1. Select a non-primitive task in the current network.
  2. Find a method whose preconditions are satisfied in the current state.
  3. Replace the selected task with the method's subtask network.
• Preconditions act as filters during this search, pruning invalid decomposition paths and ensuring the plan is grounded in the achievable world state.
• The result is a hierarchical plan that can be executed as a flat sequence of operators.

Plan verification is the process of formally checking that a generated plan is valid—meaning it is executable from the initial state and achieves the specified goals.

• Verification involves simulating plan execution: starting from the initial state, applying each operator's effects only if its preconditions are satisfied in the current simulated state.
• A plan fails verification if any operator's preconditions are false at the time of execution, indicating a flaw in the planning process (e.g., missing causal link, incorrect ordering).
• In HTN planning, verification ensures the final decomposed sequence of operators respects all preconditions from the original methods and operators.
• This is a critical step for safety-critical systems (e.g., robotics, autonomous manufacturing) where runtime precondition failure could be costly or dangerous.

Constraint Satisfaction Problem (CSP) solving is a related paradigm where the goal is to find an assignment of values to variables that satisfies a set of constraints. Preconditions in planning are a form of state constraint.

• A planning problem can be viewed as a dynamic CSP where:
  • Variables represent fluents (world state properties) over time.
  • Constraints are imposed by operator preconditions and effects (e.g., if effect of action A at time t sets fluent F to true, then precondition of action B at time t+1 requiring F can be satisfied).
• Temporal and Resource Constraints in HTNs (like ordering constraints) are also modeled and solved using CSP/optimization techniques.
• Understanding CSPs helps in designing more expressive precondition languages that include relational constraints (e.g., (distance ?x ?y) < 10) beyond simple Boolean literals.