AI Glossary / Graphs and symbolic AI / Beginner

Level of abstraction

Definition

A level of abstraction is a degree of detail at which a system, problem, or action is represented. A higher level groups or omits details to emphasize broader relationships or goals; a lower level exposes more specific states, operations, or mechanisms. In AI, choosing an appropriate level helps make reasoning manageable while retaining the distinctions needed for the task.

What it means

The same activity can be described as “deliver the parcel,” as a sequence of route and handover tasks, or as detailed vehicle-control actions. None of these descriptions is automatically the only correct one. Each supports different questions.
Abstraction is not merely shorter wording. A useful abstraction specifies how a detailed situation maps to a simpler representation and what conclusions remain valid after details are omitted. If two detailed states are treated as equivalent even though one permits an action and the other does not, the abstraction may be inadequate for that decision.

How it works

A designer identifies which information matters to the current reasoning task and constructs a representation that preserves it. State abstraction can group detailed states, while action abstraction can summarize sequences through higher-level actions. A planner may reason at a broad level and refine selected actions into executable details.
The connection between levels is crucial. An abstract plan should not be assumed executable unless its refinement conditions are satisfied. Similarly, an abstract cost estimate may be a lower bound, an upper bound, or an approximation, and these meanings should not be mixed. Different applications need different preservation guarantees, so there is no universally best level of abstraction.

Three practical examples

• A delivery planner first chooses which depot should handle a job before considering a detailed route through local streets.
• A troubleshooting assistant reasons about subsystems before examining individual components and measurements.
• A workflow model represents “prepare report” as one task at a management level and as data collection, checking, and drafting at an execution level.

Think of it this way

Think of viewing the same place on a regional map and a street map. The regional map makes long-distance relationships easier to see, while the street map supplies details needed for a local turn. The analogy is limited because computational abstraction may group states or summarize actions mathematically, and its validity depends on explicit mappings rather than visual scale alone.

Worked example

Consider an invented warehouse robot with detailed state variables for room, exact position, and whether it carries an access card. A high-level map records only the room. Two detailed states both map to “Room A”: in one the robot has the card, and in the other it does not.
Suppose the only door from Room A to Room B requires that card. An abstract action “move from A to B” is feasible from the first detailed state but not the second. If the abstraction treats the move as unconditionally available, an abstract plan may fail when refined for the cardless robot.
One repair is to retain card possession in the abstract state, producing separate states such as (Room A, card) and (Room A, no card). Another is to attach a clearly defined condition or refinement procedure that accounts for obtaining the card before moving.
Now suppose a feasible refinement consists of reaching the door in 3 steps, opening it in 1 step, and crossing in 2 steps. Its cost is 6 unit steps. Calling the entire operation one high-level action does not make its execution cost one. The example shows both a lost feasibility distinction and the difference between the number of abstract actions and primitive execution cost.

Illustrative case study

In a fictional planning project, Maple Logistics uses a high-level action called “transfer stock” to simplify a workflow. The first version omits whether compatible transport is available, so some attractive abstract plans have no feasible detailed realization.
The team adds explicit preconditions and validates refinements on representative cases. It keeps the high-level view for planning while exposing the necessary operational checks. The invented case illustrates abstraction design, not a measured improvement or a claim that every workflow requires a formal hierarchical planner.

Common misconceptions and mistakes

Higher abstraction is not automatically more intelligent, and more detail is not automatically more accurate for every purpose. Excess detail can make reasoning expensive, while excessive simplification can erase essential constraints.
Do not assume an abstract action has a fixed duration or cost just because it occupies one symbol in a plan. Nor should a high-level description be treated as a proof that every possible refinement succeeds. The meaning may concern one feasible refinement, all refinements, or a bound on possible outcomes. These alternatives require explicit semantics when they affect correctness.

Business use

The concept helps teams communicate across strategy, workflow, and implementation without confusing those perspectives. Identify the decision being made at each level and the information that must survive the mapping between levels.
For AI systems, test abstractions using counterexamples: find two detailed situations that look identical at the higher level but require different decisions. Such cases reveal missing distinctions. Also specify how high-level outputs become executable actions and how failures are reported back upward. An abstraction is useful when it reduces unnecessary detail while preserving enough information for the intended decision.

People also ask

Is abstraction just summarization?

Summarization can be one form, but abstraction can also group states, hide implementation details, or represent action sequences as higher-level operations.

Can an abstract plan be impossible to execute?

Yes, if necessary distinctions or refinement conditions are missing.

Does one high-level action equal one unit of cost?

No. Its detailed implementation may require many steps with different costs.

Check your understanding

Why is room identity alone insufficient in the robot example?

Answer: Two robots in the same room can differ in card possession, which determines whether the only door is usable. The abstract state hides a distinction needed to judge the action's feasibility.

Related terms

• Abstraction
• High-level action
• state representation
• hierarchical planning
• refinement
• abstraction mapping
• model fidelity
• primitive action

Learn next

Describe one task at three levels of detail. For each level, state the question it can answer and one important question it cannot. Then identify the conditions needed to turn a high-level action into a valid detailed sequence.

• High-level action

More in Graphs and symbolic AI

• Least-constraining-value - Least-constraining-value is a value-ordering heuristic for constraint satisfaction problems.
• Leiden Community Detection - Leiden community detection is a graph-clustering algorithm that groups nodes by optimizing a chosen measure of community structure.
• Level cost - Level cost is a planning-graph heuristic that assigns a goal literal the index of the first proposition level at which it appears.
• Level sum - Level sum is a planning-graph heuristic that adds the individual level costs of a set of goal literals.
• Lexical ambiguity - Lexical ambiguity occurs when a word or lexical expression has more than one possible interpretation.
• Lexical category - A lexical category is a grammatical class associated with a word or lexical item, such as noun, verb, adjective, or adverb.

Sources

Sources: Marthi, Russell, and Wolfe, Angelic Hierarchical Planning: Optimal and Online Algorithms, original paper on high-level actions and refinement semantics: https://aima.cs.berkeley.edu/~russell/papers/icaps08-hla.pdf

Previous: Level cost Next: Level set