Can an action have no preconditions?

Yes. An empty conjunction is true, so it imposes no applicability restriction in that model.

Are preconditions always Boolean facts?

No. Expressive planning languages can include numeric comparisons and more complex formulas.

Does satisfying them guarantee real-world success?

Only the modeled applicability is established; omitted requirements, uncertainty or execution failures still matter.

AI Glossary / Graphs and symbolic AI / Advanced

Precondition

Definition

A precondition is a condition that must hold for an action to be applicable in a specified model. In AI planning, it separates actions available in the current state from actions that cannot validly be taken there. Preconditions describe requirements before action execution; effects describe the changes produced by executing the action.

What it means

A delivery robot cannot place a crate into a receiving bay merely because delivery is its goal. It may need to be at the bay, holding the crate and facing an unlocked mechanism. Those requirements belong in the action model. A planner searches for actions that establish them before delivery. Having all modeled preconditions makes delivery available; it does not force the planner to choose it or establish that the model captures every real-world requirement.

How it works

In a simple classical planning model, the state records facts, and an action has preconditions plus effects that add or remove facts. For positive conjunctive preconditions, applicability means every required fact is in the current state. More expressive languages can also represent negation, numeric tests and other conditions.
The planner tests applicability before computing the successor state. It then applies the effects and evaluates the next action against the updated state, rather than against the original starting facts. A previously satisfied condition may no longer hold. With actions that take time, conditions can be required at the start, at the end or over an interval. Checking a condition once at the beginning is different from requiring it to remain true during execution.

Three practical examples

A robot's pickup action requires the robot and crate to be at the rack and the gripper to be empty. Pickup then changes what the robot holds; 'holding the crate' is an effect, not a requirement for that pickup.
A publishing workflow requires a completed review before release. A plan must establish that review condition; a high predicted quality score does not satisfy it unless the workflow explicitly defines that equivalence.
A resource-aware planner allows a travel action only when available energy meets a modeled threshold. Checking the threshold makes the action applicable in the model, while actual execution still depends on the accuracy of energy and consumption estimates.

Think of it this way

A precondition resembles an entry requirement at a checkpoint. Meeting it lets you proceed to the next stage; it is not the result of completing that stage. After you proceed, your situation may change, so the next checkpoint needs its own check.

Worked example

Consider a robot, crate, rack and receiving bay. Initially the robot and crate are at the rack, the gripper is empty, the bay is locked and the crate is not delivered. Actions are sequential and deterministic; facts not changed by an action remain unchanged.
Define Pick with preconditions robot-at-rack, crate-at-rack and empty-gripper. Its effects add holding-crate and remove crate-at-rack and empty-gripper.
Define MoveToBay with precondition robot-at-rack. It adds robot-at-bay and removes robot-at-rack; holding the crate does not prevent this movement in the model.
Define UnlockBay with precondition robot-at-bay. It adds bay-unlocked. Assume the robot can operate the bay's control while carrying the crate.
Define Deliver with preconditions robot-at-bay, holding-crate and bay-unlocked. It adds delivered and empty-gripper and removes holding-crate.
The sequence Pick, MoveToBay, UnlockBay, Deliver is valid. After Pick, the robot holds the crate. After MoveToBay, it is at the bay and still holds it. UnlockBay establishes the remaining delivery requirement. Deliver then achieves the goal and leaves the gripper empty.
The shorter sequence Pick, MoveToBay, Deliver fails at its third step: bay-unlocked is false. Deliver's effects cannot be applied to repair its own missing requirement. Likewise, Pick cannot validly occur a second time immediately after the first, because both crate-at-rack and empty-gripper have become false.
Under these four available action definitions, four actions are necessary: only Pick establishes holding-crate, only MoveToBay establishes robot-at-bay, only UnlockBay establishes bay-unlocked, and only Deliver establishes delivered. This is a statement about the specified toy model, not a universal minimum for delivery robots.

Illustrative case study

In a fictional trial, a planner returns a three-action delivery plan. The team discovers that its Deliver definition omitted bay-unlocked. The planner correctly solved that incomplete model, but the physical bay rejects the operation.
The team adds the missing precondition and the UnlockBay action, then validates the four-action sequence above. It also tests states in which the robot is at the wrong location or already holding something. The investigation separates a modeling defect from a search defect: improving the search algorithm alone would not teach it an omitted physical requirement. Runtime checks are then aligned with the revised model and actual device feedback.

Common misconceptions and mistakes

A goal is not automatically an action precondition. An effect cannot simply be assumed before the action that produces it. Preconditions being satisfied also do not mean an action has occurred.
Checking all requirements only at the start of a plan is insufficient, because earlier actions change the state. In uncertain environments, an unknown condition is not automatically established; the agent may need an observation or a plan valid across its possible states. Finally, preconditions are distinct from invariants. A start requirement and a requirement maintained over time need appropriate separate semantics.

Business use

Preconditions make operational dependencies explicit in workflows, robotic tasks and automated planning. Define them using facts that the system can interpret consistently, and identify how those facts are established and refreshed. Validate plans by replaying their state transitions. Include cases where one required fact is missing, rather than checking only successful runs. For deployment, reconcile the symbolic conditions with observed state: a stored 'bay unlocked' fact may become outdated if another process locks the bay before delivery.

Check your understanding

Why does the three-step delivery sequence fail?

Answer: It never establishes bay-unlocked.

Why is holding-crate not a precondition of Pick here?

Answer: Pick is the action that establishes it from the stated initial situation.

What must be checked before each action?

Answer: Its preconditions in the state reached at that point in the plan.

Related terms

PDDL
Conditional effect
Action model
applicability
effect
state transition
STRIPS
invariant
plan validation
postcondition

Learn next

Add a LockBay action that removes bay-unlocked. Insert it between UnlockBay and Deliver, then explain why the previously valid remainder of the plan becomes invalid.

Sources

Poole and Mackworth, Representing States, Actions, and Goals: https://artint.info/3e/html/ArtInt3e.Ch6.S1.html Fox and Long, PDDL2.1: An Extension to PDDL for Expressing Temporal Planning Domains: https://arxiv.org/pdf/1106.4561 AIMA glossary, precondition: https://github.com/aimacode/aima-glossary/blob/master/glossary.md

Previous: Precomputed Features Next: Precondition axioms