Operator

Preconditions are the logical conditions that must be true in the current world state for the operator to be legally applicable. They define the operator's guardrails.

• Example: The operator PickUp(BlockA) might have the precondition Clear(BlockA) AND HandEmpty().
• They are evaluated before execution. If any precondition is false, the operator cannot be selected by the planner.
• In HTN planning, primitive tasks are grounded to specific operators, and their preconditions must be satisfied for the decomposition to be valid.

Effects are the changes to the world state that are guaranteed to occur upon the successful execution of the operator. They are the operator's purpose.

• Add Effects: Facts that become true (e.g., Holding(BlockA)).
• Delete Effects: Facts that become false (e.g., HandEmpty()).
• Effects are deterministic in classical planning; the operator's execution reliably transforms the state from preconditions to post-conditions. This predictability is fundamental for forward state-space search and plan verification.

Parameters are the variables of the operator schema that must be instantiated with concrete objects from the domain to create a grounded, executable action.

• Example: The schema Move(Robot, LocationFrom, LocationTo) has parameters ?r, ?from, ?to.
• During planning, the search involves finding valid bindings for these parameters that satisfy preconditions and achieve goals.
• Parameterization allows a single operator schema to represent a vast set of specific actions, making planning domains compact and reusable.

Cost is a numerical value assigned to an operator, representing the resource expenditure (e.g., time, energy, money) required for its execution. It is used by optimal planners.

• Planners like A* search for plans that minimize total sequential cost.
• In real-world domains, cost is critical for generating efficient, practical plans (e.g., minimizing fuel consumption or latency).
• If not specified, operators often have a default uniform cost (e.g., 1).

The Name or Schema is the unique identifier for the class of action the operator represents. It semantically defines the action's type.

• Example: Drive, Assemble, NotifyUser.
• The schema, combined with its parameter list, forms the operator's signature: OperatorName(param1, param2, ...).
• This signature is what appears in the final executable plan sequence, providing a human- and machine-readable record of intended actions.

In Hierarchical Task Networks (HTN), a Primitive Task is a leaf-node task that maps directly to an executable operator.

• The HTN planner's goal is to decompose high-level compound tasks down to a network of primitive tasks.
• Each primitive task must have a corresponding operator in the domain whose preconditions are satisfied at that point in the plan.
• This linkage is what connects abstract planning to concrete execution. The operator provides the 'how' for the primitive task's 'what'.

A Primitive Task is the direct, executable counterpart to an Operator in a Hierarchical Task Network (HTN). It represents a leaf node in the decomposition tree that requires no further breakdown and can be directly executed by the agent or system.

• Direct Mapping: Each primitive task is linked to a single operator in the planning domain.
• Execution Point: When the planner reaches a primitive task during decomposition, it instantiates the corresponding operator, checks its preconditions, and applies its effects to the world state.
• Plan Composition: A complete solution plan is a sequence of primitive tasks, each backed by an executable operator.

A Precondition is a logical condition that must be true in the current world state for a planning Operator (or an HTN method) to be legally applicable. It acts as a guard, ensuring actions are only taken when the context is valid.

• State Validation: Preconditions are evaluated against a symbolic representation of the world (e.g., (has-key agent1), (door-unlocked roomA)).
• Operator Activation: An operator cannot be selected for a plan unless all its preconditions are satisfied.
• Planning Constraint: The planner's search must find a sequence of operators that establishes the preconditions for subsequent actions, creating a chain of causal dependencies.

An Effect defines the changes an Operator makes to the world state upon its successful execution. Effects are the causal mechanism that allows a plan to progress from an initial state toward a goal state.

• Add List: Propositions that become true after the operator executes (e.g., (door-unlocked)).
• Delete List: Propositions that become false after execution (e.g., (has-key)), modeling resource consumption or state changes.
• State Transition: The planner uses effects to simulate the future world state, a process called state progression, to evaluate the consequences of potential action sequences.

A Hierarchical Task Network (HTN) is a planning formalism where an Operator resides at the bottom of a decomposition hierarchy. High-level goals are recursively broken down into networks of subtasks until primitive tasks (linked to operators) are reached.

• Abstraction Layer: HTNs allow planners to reason about abstract Compound Tasks before committing to specific low-level operators.
• Domain Knowledge: The decomposition is guided by Methods, which encode expert knowledge about how to achieve tasks, making planning more efficient than pure state-space search.
• Integration Point: Operators provide the executable 'atoms' that give semantic meaning to the leaves of the HTN decomposition tree.

The Planning Domain Description Language (PDDL) is the standard formal language used to define planning problems, including Operators. An operator in PDDL is defined within a :action block, specifying its parameters, preconditions, and effects.

• Standardized Syntax: (:action unlock-door :parameters (?d - door ?k - key ?a - agent) :precondition (and (has ?a ?k) (locked ?d)) :effect (and (not (locked ?d)) (not (has ?a ?k))))
• Formal Semantics: Provides unambiguous meaning for preconditions (first-order logic) and effects, enabling automated reasoning and plan verification.
• Interoperability: Allows planners like SHOP2 or FastDownward to understand and utilize operator definitions from a shared domain file.

State-Space Search is the fundamental algorithmic process where a planner explores possible sequences of Operators to transform an initial world state into a goal state. Each operator application represents a transition between states in this search graph.

• Node: A world state.
• Edge: An applicable operator whose preconditions are met in the source state and whose effects produce the target state.
• Search Algorithms: Techniques like A*, BFS, or heuristic search are used to navigate this graph efficiently. In HTN planning, search is guided over task decompositions, but the final validation of a plan still depends on the sequential application of operator effects.