Is a state set the same as a list?

No. A list can preserve order and repeated entries; a mathematical set does not.

Can this represent unknown facts?

Not directly in the simple closed-world state interpretation described here. Uncertainty requires an appropriate extended representation or collection of possible states.

Does every SQL query use set semantics?

No. For example, PostgreSQL SELECT preserves duplicates by default, while SELECT DISTINCT eliminates duplicate result rows. Database behavior must be checked for the operation used.

AI Glossary / Graphs and symbolic AI / Intermediate

Set semantics

Definition

Set semantics interprets a collection through set membership: an item is either present or absent, and repeated copies do not add meaning. In this glossary's classical-planning context, a state is represented as a set of ground facts, enabling preconditions and action effects to be interpreted through set operations.

What it means

A ground fact contains no unbound variables. At(Box1, ShelfA), for example, describes a particular box and shelf. A planning state might contain that fact together with facts about a robot's location and whether its gripper is empty.

Under the usual closed-world interpretation of this simple representation, a relevant fact absent from the state is treated as false. The set is therefore a description of one fully specified modeled state, not merely an incomplete collection of observations.

The same words also occur in databases, where set semantics contrasts with bag or multiset semantics that preserves duplicates. The common idea is membership without multiplicity, but the planning meaning additionally concerns how states and actions are represented. It should not be confused with answer-set semantics, a distinct subject in logic programming.

How it works

For a grounded action with positive preconditions, applicability can be checked by asking whether every required fact belongs to the state. If negative preconditions are allowed, the corresponding positive facts must be absent under the stated closed-world interpretation.

An action has an add set and a delete set. Its successor is obtained by removing the delete facts and then inserting the add facts: Result(s, a) = (s minus Del(a)) union Add(a). Facts untouched by the action remain present. This is the basic STRIPS-style transition idea, not a complete account of every PDDL language feature.

Because states are sets, adding an already present fact leaves membership unchanged. It does not increment a quantity. Objects, quantities and resource constraints must therefore be modeled explicitly. The order in which facts are written also has no meaning, although the order of actions in a plan can be crucial.

Three practical examples

A robot-planning exercise checks that a specific object and robot share a location before a pickup action is applicable.
A workflow model changes a document from Prepared to Reviewed by deleting one state fact and adding another, where that exclusivity is intended.
A database report uses distinct customer identifiers to answer who participated, while a separate event report preserves repeated participation records.

Think of it this way

Think of a noticeboard listing which switches are currently on. Writing the same switch name twice does not make it “more on,” and rearranging the names does not change the described configuration.

The analogy applies to membership, not all physical details. A binary noticeboard cannot by itself represent how much power a device consumes, uncertainty about a switch or the history of when it was operated.

Worked example

Moving one box without duplicating it

Consider an invented state s containing At(Box1, A), RobotAt(A) and GripperEmpty. A simplified pickup action requires all three facts. Its delete set contains At(Box1, A) and GripperEmpty; its add set contains Holding(Box1).

Removing the delete facts leaves RobotAt(A). Adding the effect gives the successor set {RobotAt(A), Holding(Box1)}. The robot's location persists because the action did not change it. The box is no longer represented as resting at A.

If an implementation forgets to delete At(Box1, A), it represents the box as both held and still at A. Set semantics does not repair that domain-model mistake. Similarly, inserting Holding(Box1) twice still represents only one fact, not two boxes. A second physical box needs its own identity, such as Box2, or an appropriately designed quantity representation. Attempting the same pickup again is inapplicable because its original preconditions no longer hold.

Illustrative case study

Fictional case study: Maple Planning builds a demonstration for transferring containers between storage positions. To simplify the data, a developer replaces every container identifier with the same generic name.

Several facts then collapse into one identical set member. The planner appears to complete a transfer after moving one representative container, even though the intended task concerns several distinct items. The algorithm has solved the simplified encoding, not the actual task.

Maple restores object identities and checks the state after each action against the intended inventory. The team also records that missing facts mean false in this model; uncertain observations require a different treatment. The fictional lesson is that a clear mathematical representation can still describe the wrong world when identity or completeness assumptions are lost.

Common misconceptions and mistakes

Duplicate facts represent additional units. Sets discard multiplicity; quantities need explicit representation.
Absence always means false in every knowledge system. That interpretation is an assumption of the planning representation here, not a universal rule.
Fact order determines action order. State membership is unordered; a plan's action sequence is a separate object.
Set semantics guarantees physically valid states. Validity also depends on correctly encoded effects, preconditions and domain constraints.

Business use

This concept helps business teams inspect symbolic plans rather than treating a planner's output as opaque. A state description should correspond to the distinctions that matter operationally: which object, where it is, what resources are available and which conditions hold.

Review add and delete effects with domain experts. Check that an action does not leave mutually incompatible facts behind or accidentally merge distinct entities. When working with records, decide whether the question concerns distinct entities or repeated events before removing duplicates. Those two reports can legitimately have different totals.

Check your understanding

A state contains Available(Token), and an action adds Available(Token) again. Does the state now describe two available tokens?

Answer: No. It contains the same single fact. Two distinct tokens or a numeric quantity must be represented explicitly.

Related terms

Learn next

Read action schema and closed-world assumption. Write a three-fact state and an action that changes two facts while preserving the third. Then identify one real-world detail that your representation cannot express without adding information.

Sources

Russell and Norvig, Planning chapter: https://aima.cs.berkeley.edu/newchap11.pdf, for classical state and action representation. The AIMA index locates this term in classical planning: https://aima.cs.berkeley.edu/aima-index.html. PostgreSQL official SELECT documentation, for the separate duplicate-handling comparison: https://www.postgresql.org/docs/current/sql-select.html. Relevant returned source material was reviewed; the box example and fictional case are original illustrations.

Previous: Set redundancy compression Next: SGNS