Effect

An Effect is a set of logical propositions that become true or false in the world state after a Primitive Task or Operator is successfully executed. It is the formal, declarative representation of an action's outcome.

• Add List: Propositions added to the state (e.g., (object-in-hand BALL)).
• Delete List: Propositions removed from the state (e.g., (object-on-table BALL)).
• Conditional Effects: Effects that only fire if specific runtime conditions hold.

Effects define the planner's model of action outcomes.

• Deterministic Effects: Standard in classical HTN planning. Execution guarantees the specified state change (e.g., pick-up(BALL) always results in holding(BALL)).
• Probabilistic Effects: Used in more advanced models. Represent multiple possible outcomes with associated probabilities, requiring planners to reason about uncertainty (e.g., a grasp action has an 80% chance of success).

Effects and Preconditions form the complete definition of a planning operator.

• Preconditions: Logical conditions that must be true in the current state for the operator to be applicable.
• Effects: Logical changes applied to create the next state after the operator is executed.

This creates a State Transition: State(S) + Preconditions_Met + Operator_Execution → State(S') where State(S') = State(S) + Effects - Deletions.

Effects are critical for validating and simulating plans.

• Plan Verification: A planner or verifier simulates executing the plan's primitive actions in sequence, applying each action's effects to a running world state model. The plan is valid if all preconditions are met at execution time and the final state satisfies the goal.
• Execution Monitoring: During real-world execution, a system compares the predicted effects of an action with the observed state change. A mismatch triggers Replanning.

Effects are typically expressed in a first-order logic language like the Planning Domain Definition Language (PDDL). This allows for abstraction and parameterization.

Example PDDL Operator for stack:

lispCopy
(:action stack
 :parameters (?x ?y - block)
 :precondition (and (clear ?y) (holding ?x))
 :effect (and (not (holding ?x))
              (not (clear ?y))
              (clear ?x)
              (on ?x ?y)
              (handempty))
)

The :effect clause precisely defines the post-state.

It is crucial to distinguish the role of effects from the process of task decomposition.

• Effects belong to Primitive Tasks/Operators. They are the leaves of the Decomposition Tree, directly altering the state.
• Methods belong to Compound Tasks. They define how to break down a task but do not themselves have effects. Their purpose is structural reorganization, not state change.

A Hierarchical Plan is not executable until all compound tasks are decomposed into a sequence of primitive operators whose chained effects transform the initial state into a goal state.

The formal representation of an executable, primitive action in a planning domain. An operator is defined by its preconditions (conditions that must be true for it to be applied) and its effects (the changes it makes to the world state). It is the atomic unit of action that an agent can directly perform.

• Structure: Operator(Action, Parameters, Preconditions, Effects)
• Example: An operator for PickUp(Block, Location) would have a precondition BlockAt(Block, Location) and effects Holding(Block) and not BlockAt(Block, Location).

A task in an HTN that corresponds directly to an executable operator. It is a leaf node in the decomposition tree and cannot be broken down further by the planner. The execution of a primitive task invokes its associated operator, applying its effects to change the world state.

• Contrast with Compound Task: A primitive task is an action; a compound task is a goal requiring decomposition.
• Role in Planning: The planner's goal is to decompose high-level tasks into a sequence of primitive tasks whose preconditions are met and whose effects collectively achieve the goal.

A logical condition that must be true in the current world state for a planning operator or HTN method to be applicable. Preconditions are checked before an action is taken or a task is decomposed. They represent the safety or feasibility requirements for an action.

• Logical Form: Often expressed in first-order logic or a propositional representation (e.g., DoorIsOpen, RobotHasBattery > 20%).
• Relationship to Effect: Preconditions define the required input state; effects define the resulting output state. A planner must ensure all preconditions are satisfied by the effects of preceding actions.

A snapshot representation of the environment at a given point in time, comprising the values of all relevant variables, properties, and relationships. The world state is the data structure that preconditions query and effects modify. Planning is the search for a sequence of operators that transforms the initial state into a goal state.

• Representation: Often a set of logical propositions or a key-value store.
• State Progression: The computational process of applying an operator's effects to a current world state to calculate the successor state. This is fundamental to forward-chaining planners like SHOP.

A seminal, forward-chaining HTN planning algorithm. SHOP performs task decomposition in a depth-first manner, interleaving planning with state progression. As it decomposes tasks, it immediately applies the effects of chosen primitive actions to a simulated world state to check the preconditions of subsequent tasks.

• Key Mechanism: Maintains a current state simulation. When a primitive task is added to the plan, its operator's effects are applied to this simulated state.
• Efficiency: This interleaving allows it to prune dead-ends early, as it can immediately detect if an action's preconditions fail in the new simulated state.

The formal process of checking that a generated plan—a sequence of primitive tasks—is valid. Verification confirms that, starting from the initial state, each action's preconditions are satisfied by the world state resulting from all previous actions' effects, and that the final state meets the goal conditions.

• Static vs. Dynamic: Static verification analyzes the plan offline. Dynamic verification (monitoring) occurs during plan execution.
• Role of Effects: The verifier simulates plan execution by sequentially applying each operator's effects to a running world state model, checking preconditions at each step.