Must an abstraction hierarchy be a simple chain?

No. A system can use several related abstractions, although a chain of progressively detailed representations is an accessible example.

Is hierarchical planning always optimal?

No. Optimality depends on the method and assumptions, not on the presence of levels alone.

Can lower levels change higher-level decisions?

Yes. Discovering an infeasible or unexpectedly costly refinement can justify replanning.

AI Glossary / Graphs and symbolic AI / Intermediate

Abstraction hierarchy

Definition

An abstraction hierarchy is an arrangement of representations at different levels of detail, connected so that a problem can be considered broadly and then examined more precisely. In AI planning, higher levels omit selected details, while lower levels introduce conditions and actions needed to develop an executable solution.

What it means

A single abstraction gives one simplified view. A hierarchy provides several related views, making it possible to move between broad decisions and detailed requirements. The relationship between levels is essential: a collection of unrelated summaries is not automatically a useful abstraction hierarchy.

At a high level, a system might decide which production stages are necessary. A lower level chooses equipment and operations, and a still lower level checks individual settings or movements. What counts as “higher” is relative to the chosen representation, not a claim that one level is more intelligent.

The hierarchy can help organize reasoning, but its usefulness depends on which distinctions are omitted and when they are restored. A broad plan may need revision when lower-level information exposes a problem.

How it works

Define representations for the levels and explain their connections. A detailed state may map to a broader state, and a broad action may correspond to several possible detailed implementations. Specify the assumptions under which those connections are valid.

The planner first searches an appropriate broad representation, then works out supporting details. If a detailed subproblem cannot be solved as expected, that information can move upward and prompt a different broad choice. Refinement is therefore not necessarily a one-way journey toward greater detail.

Some approaches use abstract problems to guide search through cost estimates rather than directly committing to a high-level plan. The guarantees differ across methods. A hierarchy that helps find a feasible plan does not automatically preserve the cheapest possible solution.

Historical work such as Sacerdoti's ABSTRIPS examined planning through successively more detailed abstraction spaces. The general idea remains broader than any one historical planner or software implementation.

Three practical examples

1. A manufacturing planner chooses a sequence of processing stages, then selects machines and checks the detailed conditions for each operation.

2. A maintenance assistant first identifies the subsystem to inspect, then selects diagnostic procedures, and finally specifies individual measurements. Unexpected measurements may force reconsideration of the subsystem choice.

3. A delivery-planning system reasons about regional transfers before choosing particular depots and local routes. Constraints discovered in a local segment can invalidate an otherwise attractive broad itinerary.

Think of it this way

Think of planning a conference at three levels: the overall program, individual sessions, and the equipment and staffing for each session. Each level helps answer different questions while remaining connected to the others.

The analogy stops where an ordinary outline becomes insufficient. An AI hierarchy needs explicit relationships and constraints so that a broad choice can be checked against detailed possibilities. Listing headings and subheadings alone does not establish that the resulting plan can actually work.

Worked example

Consider an original toy production hierarchy. At the broadest level, a job needs preparation followed by finishing. At the next level, preparation can use machine A or B, and finishing can use machine C or D. There are 2 × 2 = 4 machine-pair combinations before detailed compatibility checks.

Suppose A cannot transfer its output to D, and B cannot supply the required material condition for C. Only A - C and B - D remain feasible. Their complete processing times are 7 and 9 minutes respectively, assuming transfers are already included and no waiting occurs.

Under these assumptions, A - C is the faster feasible detailed plan. A broad description that merely says “prepare, then finish” cannot establish that choice because it contains neither machine compatibility nor timing information.

If A later becomes unavailable, the planner must reconsider its earlier refinement and choose B - D. The example illustrates movement between levels; it does not show that every hierarchical planning algorithm will discover the globally fastest plan.

Illustrative case study

Fictional case: Maple Exhibitions uses an assistant to organize event setup. Its broad plan allocates one stage to lighting installation and another to display assembly. Detailed planning reveals that a display blocks the only access needed for a lighting lift.

The assistant returns this dependency to the broader planning level, which changes the stage order. The team records the access constraint so later plans can check it earlier. This invented case demonstrates why lower-level findings must influence upper-level decisions, without claiming a measured improvement in event delivery.

Common misconceptions and mistakes

An abstraction hierarchy is not automatically the same as an organizational reporting chart, a class-inheritance tree, or a task checklist. Those structures may be hierarchical without representing the same problem at connected levels of abstraction.

More levels do not necessarily improve planning. Poorly chosen boundaries can hide important interactions or add refinement work without useful simplification.

A high-level solution is not proof that all details can be completed. Nor does examining one promising refinement establish global optimality. Teams should distinguish the representation hierarchy, the search strategy using it, and any guarantees established for that specific combination.

Business use

The approach can make planning systems easier to inspect. Specialists can review decisions at the level relevant to their responsibilities while retaining links to detailed requirements.

For procurement or deployment, ask how failed refinements are handled. Does the system reconsider broad choices, ask for missing information, or silently substitute a weaker solution? Review examples in which resources, dependencies, or costs cross level boundaries. Those interactions often determine whether a tidy high-level plan survives operational reality.

Check your understanding

A broad plan has three stages, but no available machine can perform the second stage under current constraints. Is the plan executable?

Answer: No. Its broad structure is insufficient. The system must find a valid refinement, revise the broad plan, or report that the current problem has no established solution.

Related terms

Abstraction
State space
Heuristic search
Task decomposition
hierarchical planning
refinement
constraint

Learn next

Study how abstract states map to concrete states. Then compare a hierarchical planner's feasible-solution claim with an optimality claim, identifying the assumptions needed for each.

Sources

Poole and Mackworth, Searching in a Hierarchy of Abstractions: https://artint.info/html1e/ArtInt_67.html

SRI, primary publication record and abstract for Sacerdoti's Planning in a Hierarchy of Abstraction Spaces: https://www.sri.com/publication/planning-in-a-hierarchy-of-abstraction-spaces/

The textbook discussion and publication abstract were read. This entry explains the planning sense; its scenarios and calculations are original, not reported experimental results.

Previous: Abstraction Next: Abstractive Summarization