Is an action schema the same as a plan?

No. A schema defines a type of step; a plan arranges action instances to achieve a goal.

Does every schema use only Boolean facts?

No. Richer planning languages can represent additional features such as numeric values and duration.

Can a valid modeled action fail in reality?

Yes. Unmodeled conditions, stale information or execution failures can prevent the predicted result.

AI Glossary / Data engineering and architecture / Intermediate

Action schema

Definition

An action schema is a parameterized description of a type of action in an AI planning model. It specifies the action's arguments, the conditions required for applying it and the effects it has on the represented state. Substituting particular objects for its parameters produces a specific action instance.

What it means

A planner may need to move many objects between many places. Rather than writing a separate definition for every possible move, the modeler writes one schema with variables for the object, origin and destination.

The schema is a description of how the planner believes the world changes. It is not necessarily executable program code, an API definition or a guarantee about what a physical machine will do. A separate execution system must connect the planned action to actual operations.

This term belongs to planning and knowledge representation even when it appears in a data architecture glossary. Its meaning differs from a database schema, which describes the organization of stored data.

How it works

In a simple classical planning representation, the schema has a name and parameters, preconditions and effects. Preconditions state what must hold before the action is applicable. Effects describe which represented facts become true or false after it is applied.

Grounding replaces variables with specific objects. A Move(crate, origin, destination) schema might become Move(Box7, ShelfA, ShelfB). The planner checks the resulting preconditions against the current modeled state before considering that instance as a possible step.

In a basic STRIPS-style state update, effects add specified facts and remove specified facts. Other facts persist under the representation's assumptions. Forgetting a deletion can therefore leave a moved object represented at its old location as well as its new one.

Planning languages can support richer conditions, conditional effects, numeric quantities or duration. Those features require appropriate semantics and planner support; the simple instantaneous schema is not a complete model of every real-world action.

Three practical examples

A warehouse planner defines a reusable movement action with parameters for a container and two locations, rather than separate definitions for every container.
A scheduling model defines an assign action whose preconditions include the represented availability of a resource and whose effects reserve it.
An automated workflow planner defines a publish action that requires an approved draft and changes its represented publication status, with execution handled separately.

Think of it this way

Think of a blank recipe card that names ingredients by role: filling, wrapper and tray. Filling in those roles creates a particular cooking task, while the preparation requirements explain when it can begin.

The analogy is limited because planning schemas specify formal state conditions and changes, rather than merely offering helpful instructions. A recipe's outcome also depends on many unmodeled circumstances. In the same way, a planning model's predicted effect should not be mistaken for an observed real-world result.

Worked example

One schema, two moves

Consider a toy world with Box7 at ShelfA and a clear ShelfB. The Move schema requires At(box, origin), Clear(destination) and an allowed connection from origin to destination. Its effects remove At(box, origin), add At(box, destination), make the origin clear and mark the destination occupied. Assume each shelf holds at most one box and the model has no other relevant conditions.

The instance Move(Box7, ShelfA, ShelfB) is applicable if the connection exists. After application, Box7 is at ShelfB, ShelfA is clear and ShelfB is occupied. The old At(Box7, ShelfA) fact is removed.

Move(Box7, ShelfA, ShelfC) is not applicable if ShelfC is occupied, even though it follows the same schema. Grounding creates a candidate action; it does not establish that the candidate's preconditions hold.

The example omits time, weight and equipment. A production model would add the constraints that matter for its decisions rather than assuming a successful toy move covers them.

Illustrative case study

A fictional team prototypes a planner that turns approved drafts into published articles. Its Publish schema adds Published(article), but fails to remove Draft(article). Later steps treat the same article as both a published item and a draft awaiting first publication.

The team clarifies whether these labels are intended to be mutually exclusive. It revises the effects for that model and tests short plans, including attempted repeat publication. It also separates an accepted publishing request from confirmation that the website actually contains the article.

The case illustrates two distinct checks: the schema must produce a coherent predicted state, and the execution system must establish whether the predicted change happened.

Common misconceptions and mistakes

An action schema is one concrete action. It describes a family; specific parameter values produce instances.
Satisfied preconditions mean the planner must choose the action. They make it applicable, while the goal and search process determine whether it is useful.
Listing only positive effects is always enough. State facts that cease to hold may need explicit deletion or another appropriate update mechanism.

Business use

Action schemas help teams make automation assumptions visible. They expose what must be true before a step and what the system expects afterward. This supports discussion among experts and engineers.

Start with a small vocabulary of meaningful conditions. For each action, test an applicable case, an inapplicable case and a case where a missing effect would leave contradictory state. Check whether the model represents permission, capacity and dependencies at the level the application needs.

When an AI assistant proposes a plan, schema-based validation can reject steps that violate the represented rules. Its reliability still depends on model completeness and current state information. During execution, compare observations with predicted effects and update or replan when they diverge.

Check your understanding

A Move schema has parameters box, origin and destination. What does replacing them with Box7, ShelfA and ShelfB accomplish?

Answer: It produces a ground action instance. The planner must still check that this instance's preconditions hold before applying it in the model.

Related terms

Grounding
Precondition
PDDL
Frame problem
Automated planning
action instance
effect
STRIPS
state transition

Learn next

Read STRIPS state updates. Write a small move schema, instantiate it with two different destinations and manually check both the preconditions and the facts added or removed.

Sources

Stuart Russell and Peter Norvig, planning chapter: https://aima.cs.berkeley.edu/newchap11.pdf. Primary textbook material defining action schemas and instantiated actions.

David Poole and Alan Mackworth, Representing States, Actions, and Goals: https://artint.info/3e/html/ArtInt3e.Ch6.S1.html. Primary textbook treatment of action representations.

Drew McDermott and contributors, PDDL specification: https://planning.wiki/_citedpapers/pddl1998.pdf. Original language specification. The shelf and publishing examples are original illustrations.

Previous: Action monitoring Next: Action space