Does PDDL require a specific planner?

No. It was developed to support shared problem descriptions, but individual planners implement particular subsets and extensions.

Can it express time and numeric resources?

Extensions such as PDDL2.1 provide constructs for temporal and numeric planning. Actual support depends on the selected tool and feature subset.

Is PDDL a general-purpose programming language?

Its main role is declarative planning representation. It specifies a planning model and task rather than an arbitrary application implementation.

AI Glossary / Graphs and symbolic AI / Intermediate

PDDL

Definition

PDDL stands for Planning Domain Definition Language. It is a family of formal languages for describing automated-planning domains and specific planning problems, including actions, their prerequisites and effects, an initial situation and a goal.

What it means

PDDL separates a reusable model of what actions are possible from a particular task to solve. A domain might describe moving objects between locations. A problem then names the actual objects, states where they start and specifies where they should end.

The language describes the problem; a planner searches for a solution using that description. PDDL is therefore not itself a planning algorithm, a natural-language prompt or a direct robot-control command format.

Different versions and extensions support different features. Classical action descriptions, numeric quantities and durative actions do not all imply the same planning capabilities. A file's declared requirements and the chosen planner's support must be checked together.

How it works

A domain definition declares symbols such as types, predicates and action schemas. A predicate represents a condition, while an action schema uses parameters to describe a family of concrete actions. Preconditions say when an action applies; effects describe modeled changes.

A problem definition refers to a domain, lists objects, provides initial facts and states a goal condition. In a common classical setting, unspecified initial facts are treated as false under a closed-world interpretation, and unmentioned facts persist when actions execute unless an effect changes them.

The planner instantiates and reasons with the action model. A plan validator can check whether the proposed actions meet preconditions and achieve the goal under the formal semantics.

Validation against the model is distinct from validation of the model itself. Missing effects, unrealistic preconditions or omitted resource constraints can allow a plan that is formally valid but unsuitable for the real process.

Three practical examples

A researcher expresses benchmark logistics tasks in a common planning language to compare compatible planners.
A workflow prototype describes actions such as reserve, move and release, then asks a planner to reach a desired state.
A robotics project uses symbolic planning above a separate motion-and-control system, with explicit links between modeled actions and executable skills.

Think of it this way

Think of writing the rules and starting position for a puzzle. The rules describe legal moves, and the goal describes what counts as success. A solver still has to find the sequence.

The analogy is limited because PDDL can express richer logical, numeric and temporal structures than a simple puzzle. Also, the formal rules may be an abstraction of a real process. Solving the written puzzle does not prove that the abstraction includes every practical constraint.

Worked example

Consider an invented classical domain with locations A, B and C and one robot R. Facts include At(R,A), Connected(A,B) and Connected(B,C). Assume only the stated directed connections exist.

A Move(r,from,to) action requires At(r,from) and Connected(from,to). Its effects remove At(r,from) and add At(r,to). The goal is At(R,C).

The two-action plan Move(R,A,B), then Move(R,B,C) is valid in this model. After the first step, At(R,A) is false and At(R,B) is true. The second step then has its location precondition satisfied and establishes At(R,C).

Move(R,A,C) is invalid because Connected(A,C) is not provided. If the model accidentally omits the effect removing the old location, it can incorrectly retain several location facts for the same robot. This illustrates why action effects need review as well as plan checking. The notation here explains semantics; it is not a complete runnable PDDL file.

Illustrative case study

The fictional Birch Planning team models a mobile service process in PDDL. Its planner finds a route that appears valid, but the domain has no representation of battery consumption.

Birch adds the relevant resource model using features supported by its chosen planning setup and checks the updated actions against the intended process. It also validates the returned plan before translating symbolic actions into executable operations.

The fictional case demonstrates that a planner cannot enforce a constraint absent from its model. More sophisticated search does not compensate for missing domain knowledge.

Common misconceptions and mistakes

PDDL automatically solves the task. A separate planner interprets the model and searches for a plan.
Every PDDL planner supports every language feature. Support varies by version, requirement and implementation.
A valid plan proves the real workflow will succeed. Formal validity is relative to the model and its assumptions.
Preconditions and effects are interchangeable. Preconditions test applicability; effects describe change.
A goal must describe every fact in the final world. It can state only the conditions required for success.

Business use

PDDL can make planning assumptions explicit and reusable across tasks. It is useful when the organization can describe actions and goals formally and wants to separate domain modeling from search technology.

Before selecting a planner, identify whether the task needs durations, numeric resources, costs, conditional effects or other capabilities. Confirm the exact supported subset instead of relying on the label “PDDL compatible.”

Review model quality using small cases with predictable answers, impossible goals and actions that should be disallowed. Keep domain and problem versions with generated plans. When execution is involved, monitor actual results and reconcile them with symbolic state rather than assuming every modeled effect occurred.

Check your understanding

Why does the worked example need a delete effect for the old At fact?

Answer: Moving should replace the robot's old location with the new one in this model. Without removing At(R,A), later reasoning can incorrectly treat the robot as still being at A as well as at B.

Related terms

Action schema
Precondition
Initial state
Automated planning
planning domain
effect
goal condition
plan validation
STRIPS

Learn next

Describe a tiny domain in plain language before writing syntax. List each action's preconditions and added or removed facts, then manually simulate a short plan. Only afterward encode it in the supported PDDL subset and compare a validator's result with the hand calculation.

Sources

Original PDDL manual; text extraction was unreadable, so language background was checked in Fox and Long: https://homepages.inf.ed.ac.uk/mfourman/tools/propplan/pddl.pdf

Fox and Long describe PDDL background and temporal/numeric extensions: https://arxiv.org/pdf/1106.4561

The three-location model and Birch Planning case are original examples, not a planner compatibility audit.

Previous: PD controller Next: PDE-constrained optimization