Back to Lecture 9

State Representation in Classical Planning

Understanding how states are represented using ground atomic fluents

What is a State in Planning?

Definition: State

A state is a complete description of the world at a particular point in time. It captures everything relevant about the current situation that matters for planning.

Example: In a robot world, a state describes where the robot is, what it's holding, where objects are located, which doors are open, etc. — everything the planner needs to know.

Think of a State as a Snapshot

A state is like taking a photograph of the world at one moment:

  • 📸 Captures current facts about the world
  • ⏱️ Represents one moment in time
  • 📋 Complete information (under planning assumptions)
  • 🔄 Changes when actions are executed
What a State Includes
  • Object locations: Where things are
  • Object properties: Attributes and conditions
  • Relationships: How objects relate to each other
  • Agent status: What the agent is doing/holding

What is State Representation?

Definition: State Representation

State representation is the formal language or notation we use to describe states. It's HOW we write down and encode the information about the world.

Example: Robot Kitchen State

Same state, different representations:

Natural Language

"The robot is in the kitchen."

"The robot is holding a box."

"The book is on the table."

❌ Ambiguous, hard to process
Vector/Array

[1, 0, 0, 1, 0, 1, 0, 0, ...]

❌ No semantic meaning, hard to understand
Logical Representation
At(Robot, Kitchen)
Holding(Robot, Box)
On(Book, Table)
✅ Clear, structured, computable!
Why Logical Representation? Classical planning uses logical (symbolic) representation because it's:
  • ✅ Human-readable: We can understand what each fact means
  • ✅ Structured: Clear predicates and arguments
  • ✅ Modular: Easy to add, remove, or check individual facts
  • ✅ Efficient: Set operations work well for state transitions
1. Search Efficiency

Good representation = faster planning. Set-based representation allows quick membership testing and state comparison.

2. Knowledge Reasoning

Logical representation lets us reason about what's true, what's false, and what actions can be applied.

3. Action Application

Clear representation makes it easy to compute state transitions: add effects, delete effects, check preconditions.

State Transition Example

Watch how representation makes state changes explicit:

State S₀
At(Robot, Kitchen)
Holding(Box)
On(Book, Table)
Action: Move(Kitchen, Bedroom)

Delete: At(Robot, Kitchen)

Add: At(Robot, Bedroom)

State S₁
At(Robot, Bedroom) (new)
Holding(Box)
On(Book, Table)
Notice: The representation makes it crystal clear what changed (At location) and what stayed the same (Holding and On relationships). This is the power of structured state representation!

Concrete Examples of State Representation

Let's see how real planning problems are represented as states

Example 1: Robot Grasping a Box

A robot needs to pick up a box from a table and move it to a target location.

Initial State S₀
State = {
  On(Box, Table),
  Clear(Box),
  Empty(Hand),
  At(Robot, Table)
}
Interpretation:
  • Box is on the table
  • Nothing is on top of the box
  • Robot's hand is empty
  • Robot is at the table
After Grasp: State S₁
State = {
  Holding(Box),
  At(Robot, Table)
}
What Changed:
  • ❌ Deleted: On(Box, Table)
  • ❌ Deleted: Clear(Box)
  • ❌ Deleted: Empty(Hand)
  • ✅ Added: Holding(Box)
Goal State Sₐ
State = {
  On(Box, Target),
  Clear(Box),
  Empty(Hand),
  At(Robot, Target)
}
Goal Achieved:
  • 🎯 Box is on target location
  • ✅ Hand is empty again
  • ✅ Box is accessible (clear)
Key Observations:
Closed-World Assumption (CWA):
  • In S₀: Holding(Box) is FALSE (not in state)
  • In S₁: On(Box, Table) is FALSE (removed)
  • Facts not listed are assumed false!
Unique Names Assumption (UNA):
  • Box ≠ Table ≠ Target
  • Robot ≠ Hand
  • Each name refers to a distinct object

Example 2: Spare Tire Replacement (Saudi Road Trip)

You have a flat tire on your car during a road trip. You need to replace it with the spare tire.

Initial State S₀
State = {
  Tire(Flat, Axle),
  Tire(Spare, Trunk)
}
Interpretation:
  • 🔴 Flat tire is on the axle
  • ⚪ Spare tire is in the trunk
🚗
Axle: 🔴 Flat | Trunk: ⚪ Spare
Intermediate States
State S₁ (After Remove Flat):
State = {
  Tire(Flat, Ground),
  Tire(Spare, Trunk)
}
Axle: (empty) | Ground: 🔴 | Trunk: ⚪
State S₂ (After Remove Spare):
State = {
  Tire(Flat, Ground),
  Tire(Spare, Ground)
}
Axle: (empty) | Ground: 🔴⚪
Goal State S₃
State = {
  Tire(Spare, Axle)
}
Goal Achieved:
  • 🎯 Spare tire is on the axle
  • ✅ Car is ready to drive!
🚗
Axle: ⚪ Spare ✓
Complete State Sequence
S₀
Flat@Axle
Spare@Trunk

Remove(Flat, Axle)
S₁
Flat@Ground
Spare@Trunk

Remove(Spare, Trunk)
S₂
Flat@Ground
Spare@Ground

PutOn(Spare, Axle)
S₃
Spare@Axle
🎯 GOAL!
Important Representation Details:
What we represent:
  • ✅ Tire(Flat, Axle) - Location of flat tire
  • ✅ Tire(Spare, Trunk) - Location of spare
  • ✅ Simple, clear predicate structure
What we DON'T represent:
  • ❌ How to physically remove tire (action details)
  • ❌ Tire pressure, wear level (irrelevant facts)
  • ❌ Continuous positions (only discrete locations)

Comparing the Two Examples

Aspect Robot Grasping Tire Replacement
Number of States 3 states (Initial, After Grasp, Goal) 4 states (Initial, 2 Intermediate, Goal)
Key Predicates On(), Holding(), Clear(), Empty(), At() Tire(object, location)
Number of Objects 4 objects (Robot, Box, Table, Target) 5 objects (Flat, Spare, Axle, Trunk, Ground)
State Complexity 3-4 fluents per state 1-2 fluents per state (simpler!)
CWA Applied If Holding(X) not in state → Robot not holding X If Tire(X, Y) not in state → Tire X not at Y
UNA Applied Box ≠ Table ≠ Target (all different) Flat ≠ Spare, Axle ≠ Trunk ≠ Ground

Connection to First-Order Logic (Lecture 7)

Terminology Note: First-Order Logic (FOL) is also called First-Order Predicate Logic (FOPL) or Predicate Logic. These are all the same formal system! We use "FOL" for short.

Remember knowledge representation from Lecture 7? Planning uses a simplified version!

First-Order Logic / FOPL (Lecture 7)
  • Variables: ∀x, ∃y (universal, existential)
  • Quantifiers: Can express general rules
  • Functions: Father(John)
  • Negation: ¬Hungry(x)
∀x Human(x) ⇒ Mortal(x)
Planning State Representation
  • Ground Atoms Only: No variables!
  • No Quantifiers: Specific facts only
  • No Functions: Only predicates with constants
  • No Negation: Use Closed-World Assumption
At(Robot, Kitchen)
Holding(Box)
Why Simpler? Planning needs EFFICIENT reasoning. Ground atoms with database semantics allow fast state representation and manipulation. We trade expressiveness for computational efficiency!

1. Ground Atomic Fluents

The building blocks of planning states

What is a Ground Atomic Fluent?
  • Atomic: A single predicate (not a complex formula)
    Example: At(Robot, Kitchen) ✓ but not At(Robot, Kitchen) ∧ Holding(Box) ✗
  • Ground: Contains only constants (NO variables!)
    Example: On(Box, Table) ✓ but not On(x, Table) ✗
  • Fluent: Can change over time (unlike static facts)
    Example: At(Robot, Kitchen) can become At(Robot, Bedroom) after an action
Fluents vs Static Facts

Not all predicates are fluents! Some facts about the world never change:

Fluents (Can Change)

These facts can be modified by actions:

✅ At(Robot, Kitchen)

Can change to At(Robot, Bedroom)

✅ Holding(Box)

Can become Empty(Hand)

✅ Open(Door1)

Can become Closed(Door1)
Static Facts (Never Change)

These facts are fixed properties of the world:

❌ Adjacent(Kitchen, Bedroom)

Rooms don't move!

❌ Color(Block1, Red)

Block color is fixed

❌ Distance(Riyadh, Jeddah, 950)

Geography doesn't change
Important Distinction: In planning, we only include fluents in states (things that change). Static facts are typically encoded as preconditions in actions but don't appear in the state representation itself. This keeps states compact and efficient!

Valid Ground Atomic Fluents

✓ At(Robot, Kitchen)

Predicate: At
Constants: Robot, Kitchen

✓ Holding(Box)

Predicate: Holding
Constants: Box

✓ On(Book, Table)

Predicate: On
Constants: Book, Table

✓ Clean(Room1)

Predicate: Clean
Constants: Room1

✓ Empty(Hand)

Predicate: Empty
Constants: Hand

✓ At(Plane, Riyadh)

Predicate: At
Constants: Plane, Riyadh

Invalid Fluents (Not Ground or Not Atomic)

✗ At(x, Kitchen)

Problem: Contains variable 'x' (not ground)

✗ ∀x At(x, Home)

Problem: Contains quantifier (not atomic)

✗ ¬Holding(Box)

Problem: Contains negation (use CWA instead!)

✗ At(Robot, Kitchen) ∧ Clean(Kitchen)

Problem: Complex formula (not atomic)

✗ Location(Father(John))

Problem: Contains function (only constants allowed)

✗ At(x, y)

Problem: Contains variables x and y (not ground)

Interactive Fluent Validator

Test your understanding! Enter a fluent to check if it's valid:

Try these examples:

States as sets of facts (like a database table)

What is Database Semantics?

A planning state is represented as a set of ground atomic fluents, just like a database table stores rows of data.

Example: Robot World State

As a Set (Planning)
State S = {
  At(Robot, Kitchen),
  Holding(Box),
  On(Book, Table),
  Clean(Kitchen)
}
As a Database Table
Predicate Arguments
At Robot, Kitchen
Holding Box
On Book, Table
Clean Kitchen
Key Properties:
  • States are sets (unordered, no duplicates)
  • Adding/removing facts is like INSERT/DELETE in SQL
  • Checking fact membership is like a database query

"What is not known to be true is FALSE"

Understanding CWA

In classical planning, we assume the world is closed: if a fact is not explicitly listed in the state, then it is FALSE. No "unknown" or "maybe"!

Interactive CWA Demonstration

Current State:
State S = {
  At(Robot, Kitchen),
  Holding(Box)
}
Query Facts:
Query In State? Truth Value (CWA)
At(Robot, Kitchen) ✓ YES TRUE
Holding(Box) ✓ YES TRUE
At(Robot, Bedroom) ✗ NO FALSE (by CWA)
Clean(Kitchen) ✗ NO FALSE (by CWA)
Holding(Book) ✗ NO FALSE (by CWA)
Important: Under CWA, we never use negation like ¬At(Robot, Bedroom). Instead, the absence of At(Robot, Bedroom) from the state means it's false!

CWA vs Open-World Assumption

Closed-World (Planning)

Assumption: What's not stated is FALSE

State: {At(Robot, Kitchen)}

Query: At(Robot, Bedroom)

Answer: FALSE

Open-World (General Logic)

Assumption: What's not stated is UNKNOWN

KB: {At(Robot, Kitchen)}

Query: At(Robot, Bedroom)

Answer: UNKNOWN

"Different names refer to different objects"

Understanding UNA

In classical planning, each constant name refers to a unique object. If two names are different, they refer to different things. No aliases!

UNA Examples

✓ Valid under UNA
At(Robot1, Kitchen)
At(Robot2, Bedroom)

Robot1 and Robot2 are different objects. Both can be at different locations simultaneously.

✗ Impossible under UNA
At(Robot, Kitchen)
At(Robot, Bedroom)

Robot cannot be in two places at once! This state would be inconsistent.

Real-World Example: Saudi Cities
Under UNA:
  • Riyadh ≠ Jeddah
  • Riyadh ≠ Dammam
  • Plane1 ≠ Plane2

Each name represents exactly one distinct entity.

What UNA Prevents:
  • ❌ Aliases: Riyadh = CapitalCity
  • ❌ Same object, different names
  • ❌ Identity reasoning like FOL

Keep it simple: one name, one object!

Criterion ✓ VALID (Allowed) ✗ INVALID (Not Allowed)
Ground At(Robot, Kitchen)
Only constants 		At(x, Kitchen)
Contains variable 'x'
Atomic Holding(Box)
Single predicate 		Holding(Box) ∧ Clean(Table)
Complex formula with ∧
No Negation At(Robot, Room1)
Positive fact (use CWA for negation) 		¬At(Robot, Room2)
Explicit negation not allowed
No Quantifiers Clean(Room1)
Clean(Room2)
List each fact explicitly 		∀x Clean(x)
Universal quantifier not allowed
No Functions At(Robot, Location5)
Constants only 		At(Robot, NextRoom(Kitchen))
Function symbols not allowed

Complete Example: Saudi Air Cargo State

State S = {
  At(Plane1, Riyadh),
  At(Plane2, Jeddah),
  At(Cargo1, Riyadh),
  In(Cargo2, Plane2)
}
What This State Tells Us:
  • Ground Fluents: All facts use constants (Plane1, Riyadh, etc.)
  • Database Semantics: State is a simple set of facts
  • CWA Applied: At(Plane1, Jeddah) is FALSE (not in state)
  • UNA Applied: Plane1 ≠ Plane2, Riyadh ≠ Jeddah
Questions We Can Answer:
Q: Is Plane1 at Riyadh?
A: YES ✓ (explicitly in state)
Q: Is Cargo2 in Plane2?
A: YES ✓ (explicitly in state)
Q: Is Plane1 at Jeddah?
A: NO ✗ (not in state, so FALSE by CWA)
Q: Is Cargo1 in any plane?
A: NO ✗ (no In(Cargo1, _) facts)

Key Takeaways

✅ Remember
  1. Ground Atomic Fluents: Constants only, no variables
  2. Database Semantics: States as sets of facts
  3. CWA: Absent = False (no explicit negation)
  4. UNA: Different names = Different objects
🔗 Connection to FOL/FOPL

Planning uses a restricted subset of First-Order Logic (FOL/FOPL):

  • No variables → All ground
  • No quantifiers → Explicit enumeration
  • No functions → Constants only
  • CWA for negation → No ¬ operator
Next: Learn how actions modify these states using STRIPS representation! Continue to STRIPS →