AI Glossary / Graphs and symbolic AI / Beginner

Add list

Definition

An add list is the part of a STRIPS-style planning action that specifies the facts to be made true in the resulting state. It works with the action's preconditions, which must hold before execution, and its delete list, which identifies facts to remove. Together these describe an action's modeled effect on the world.

What it means

In a simple symbolic planner, a state is represented by a set of facts, such as “file F is approved” or “machine M is available.” An action changes that representation by removing some facts and adding others.

The add list records positive effects. It does not list the things the planner hopes will eventually happen, nor does it establish whether the action is currently allowed. Those questions belong to goals and preconditions respectively.

Although the conventional name says “list,” the usual grounded STRIPS interpretation treats these facts as a set. Repeating a fact does not make it twice as true. The add list may also contain a fact already true before the action; the set update simply ensures that it is present afterward.

How it works

First instantiate an action schema with the particular objects involved. Check its preconditions against the current state. If the action is applicable, form the next state by removing its delete-list facts and including its add-list facts.

Using sets, the update is S′ = (S minus Delete(a)) union Add(a). Under the ordinary STRIPS persistence assumption, facts not changed by the action remain as they were. There is no need to restate the entire world in every action description.

The basic representation assumes that the specified transition captures the action's effects. Real systems may need richer models for uncertain outcomes, duration, numerical resources, or conditional effects. A simple add list alone does not represent all of these.

Review the complete action description for consistency. If an item changes exclusive status, the model may need both a positive effect and a corresponding deletion. Adding the new status without removing the old one can leave an impossible combination in the symbolic state.

Three practical examples

1. A document-planning action approves a draft. Its add list includes approved(document), while its preconditions check the required review and its delete list removes the pending-approval status.

2. A machine-reset action adds ready(machine) after the modeled reset. Whether the machine can be reset now is a separate precondition question.

3. A reservation action adds reserved(room, booking). The model must also represent the effects on availability so that another action cannot incorrectly reserve the same capacity at the same time.

Think of it this way

Think of updating a status board after completing a task: attach the new status cards and remove cards that no longer apply. Cards about unrelated tasks stay in place.

The analogy has limits. A formal add list changes a model, not reality by itself. Writing “ready” on a board cannot repair a machine. A deployed system needs a reliable connection between action execution, observation, and the state used for later planning.

Worked example

Consider an original toy action called approve(F). The starting state is {draft(F), reviewed(F), reviewer_available, printer_ready}. Its preconditions are draft(F) and reviewed(F). Its delete list is {draft(F)}, and its add list is {approved(F), ready_to_publish(F)}.

Both preconditions hold. Remove draft(F), leaving {reviewed(F), reviewer_available, printer_ready}. Add the two positive effects. The resulting state is {reviewed(F), reviewer_available, printer_ready, approved(F), ready_to_publish(F)}.

The unchanged printer_ready fact persists even though it appears in neither effect list. The reviewed(F) fact also persists because this toy model does not delete it. If reviewed(F) were absent initially, the action could not be applied merely because its add list contains desirable results.

This is a deliberately simplified publication workflow. It assumes approval makes the file ready to publish; an actual workflow may require additional checks, which must be represented rather than silently assumed.

Illustrative case study

Fictional case: Rowan Repairs builds a planner for equipment servicing. Its “finish service” action adds available(machine) but forgets to remove under_service(machine). Later planning treats the machine as both available and still being serviced.

The team corrects the delete list and adds a state-consistency review for mutually exclusive statuses. It also checks whether the availability update should follow a successful inspection rather than servicing alone. This invented case shows that reviewing positive effects requires attention to both removed facts and the conditions supporting the update.

Common misconceptions and mistakes

An add list is not a to-do list. It describes results of a modeled action, not the sequence of actions the planner intends to perform.

Preconditions and positive effects are different. A fact can appear in both, but its presence in the add list does not make the precondition true beforehand.

Adding an effect does not establish that every possible real-world consequence has been modeled. Missing effects can produce incorrect plans even if the update formula is implemented perfectly. Also, adding approved(item) does not automatically remove rejected(item); any required relationship must be captured by the action model or other appropriate constraints.

Business use

Add lists make symbolic workflows inspectable. Domain specialists can review exactly which statuses the planner assumes an operation establishes, and compare them with operational procedures.

A useful validation exercise is to apply an action manually to several representative states. Check newly true facts, facts that should disappear, and unrelated facts that should persist. Include a case where a precondition fails. This catches modeling mistakes that a successful-looking final plan may otherwise conceal, especially when several actions depend on one inaccurate status update.

People also ask

Does an add list contain every fact true afterward?

No. Unchanged facts can persist from the previous state without being listed again.

Does adding a fact twice have an extra effect?

Not in the usual set-based STRIPS interpretation; the fact is simply present.

Can the add list make an inapplicable action executable?

No. Preconditions are checked before the action's effects are applied.

Check your understanding

An action adds checked(P), removes unchecked(P), and does not mention stored(P). If stored(P) was true, does it remain true under the standard persistence assumption?

Answer: Yes. The action changes the specified checking facts while the unrelated storage fact remains in the state.

Related terms

• Delete list
• Precondition
• Action schema
• Fluent
• Frame problem
• STRIPS
• state transition
• planning

Learn next

Next, study delete lists and the STRIPS persistence assumption together. Build a small state-transition example and deliberately omit one required deletion to see how an inconsistent plan can arise.

More in Graphs and symbolic AI

• Action cost function - An action cost function assigns a numerical cost to taking an action in a planning or search problem.
• Actor - An actor, in planning, is an entity that performs actions within the modeled environment.
• Adaptive utility - Adaptive utility is a decision-theoretic approach in which uncertainty about preferences can be reduced through experience or information.
• Additive value function - An additive value function evaluates an option by adding separate contributions from its attributes.
• Admissible heuristic - An admissible heuristic is a search estimate that never overestimates the true minimum remaining cost of reaching a goal.
• Adversary argument - An adversary argument is a proof technique that demonstrates a limitation of an algorithm or class of algorithms by constructing difficult inputs or responses.

Sources

Poole, Mackworth, and Goebel, Computational Intelligence, official Chapter 8 slides on STRIPS representation: https://www.cs.ubc.ca/~poole/ci/lectures/ch8/html.html

The authors' description of preconditions, add lists, delete lists, and persistence was read. This entry uses the common set-based grounded STRIPS formulation; all workflow examples are original.

Previous: Add-k Next: Additive color