Classical AI Planning

What it demonstrates

This is the page to open when someone asks whether a system without a model can actually reason. It can, and this page shows the working.

The rules go in as twenty-one English sentences through the same turn entry point the chat page uses. No special planner input format. Then you say solve it.

What comes back is not a stored answer. Change the disk count and press solve again and it searches afresh. Three disks take seven moves, four take fifteen, and the page will tell you it found the shortest one.

A panel on the right prints the plan twice. Once as a PDDL problem, the standard planning-domain format, and once as OWL triples. Both are generated from the plan, not written alongside it.

• A transport bar steps through the solution one move at a time.
• A facts panel shows the board as triples at the current step.
• A board-question dock lets you ask about the position rather than read it.
• A chat dock lets you assert something and see whether the board agrees.

Chat you can replay

These are corpus rows. Each one is a test that runs on every build, so the wording is the engine's, not ours.

Teach the lesson, set a goal, solve. Seven moves, and it says why it could.

tmct> the goal is that every disk rests on peg-c.
noted — the goal is that every disk rests on peg-c
tmct> solve it
plan found — 7 moves (shortest):
1. move disk-1 onto peg-c
...
7. move disk-1 onto disk-2
because — you taught me the "move onto" rule

Corpus row planning-hanoi-solve-finds-the-7-move-optimum-with-the-plan-attached in test/corpus/planning.jsonl.

Ask what is legal right now and it answers from one step of grounding, without searching.

tmct> what moves are legal now?
2 legal moves from here:

Corpus row planning-legal-moves-answers-one-ply-without-search in test/corpus/planning.jsonl.

Walk the plan with next. At the end it checks the goal against what is actually written, and says that is what it did.

tmct> next
(seven times)
done — every disk rests on peg-c (checked against board@step7's written facts, not assumed).

Corpus row planning-next-walks-the-plan-and-confirms-the-goal-from-written-facts in test/corpus/planning.jsonl.

Ask it to solve with no rules taught and it names the gap instead of trying.

tmct> disk-1 rests on disk-2.
tmct> solve it
no action rules taught yet — teach the game first

Corpus row planning-solve-without-action-rules-declines-naming-the-gap in test/corpus/planning.jsonl.

What it looks like

The board mid-solve, the move list, and the PDDL panel.

What it works out

The search. findActionPath in src/domain/planning.mjs is a bounded, cycle-safe breadth-first search. Breadth-first is why the answer is the shortest plan rather than any plan. It is capped by a depth limit, and it returns nothing when it exhausts the cap. Nothing is a miss. It never returns a partial plan dressed up as a solution.

The state. A state is a flat list of triples. There is no special planner data structure underneath.

• disk-1 mgx:rest-on disk-2
• disk-3 mgx:rest-on peg-a
• disk-1 mgx:smaller-than disk-2

The moves. Successors come from grounding the taught action rules against the current state. That grounding has its own budget. Past it, the engine raises a budget error rather than searching without bound. A taught rule inherits the STRIPS assumption: whatever its effect does not mention, the plan assumes stays unchanged.

The goal. A goal spec compiles into a predicate over states. Universally quantified goals work, which is why “every disk rests on peg-c” is a goal rather than three goals.

The PDDL. Each action's precondition and effect are a mechanical diff between two consecutive snapshots of the plan. Nothing is inferred beyond what actually changed between them:

(:action move-onto-step1
  :label "move disk-1 onto peg-c"
  :subject disk-1
  :target peg-c
  :precondition (and
    (mgx:rest-on disk-1 disk-2)
  )
  :effect (and
    (not (mgx:rest-on disk-1 disk-2))
    (mgx:rest-on disk-1 peg-c)
  )
)

The OWL. The problem's ontology block emits real rdf:type and rdfs:subClassOf rows off the domain's class membership. A member that is itself a declared class becomes a subclass edge; anything else becomes a type edge.

(rdf:type disk-1 disk)
(rdf:type peg-c peg)
(rdfs:subClassOf disk game-piece)
(rdfs:subClassOf peg place)

What the board dock retrieves. A step's position is projected into rows the ordinary question engine can walk: direct support, the support chain chased down to the peg, a derived top-disk edge, and the size ordering. So you can ask about the board with the same grammar you use to ask about anything else.

How it is built

src/domain/hanoi-lesson.mjs generates the teaching sentences for any disk count. The site build and the live browser session both use it, so what the deployed page ships and what your click produces run the same path.

src/surfaces/web/plan-browser-entry.mjs opens a session, teaches the lesson, and solves. src/services/chat.mjs routes solve it to the planner. src/domain/planning.mjs does the search.

src/services/plan-pddl.mjs writes the PDDL. src/domain/hanoi-board.mjs projects a board position into queryable rows. src/services/plan-viz.mjs lays out the page and draws the board.

The site build runs the solve in process at build time and embeds the result, then the page's own controls re-solve live. There is no second code path for “how the site built it” versus “how a re-solve works”.

Related work

Planning has a long published record, and this page sits squarely in it.

• Fikes and Nilsson, “STRIPS: A New Approach to the Application of Theorem Proving to Problem Solving”, Artificial Intelligence 2(3–4), 1971.The add/delete effect model. The precondition and effect blocks above are the same idea.
• McDermott et al., PDDL: The Planning Domain Definition Language, Yale CVC TR-98-003, 1998.The format the plan panel writes. Fox and Long's PDDL 2.1, JAIR 20, 2003, extends it.
• Fikes and Nilsson, “STRIPS, a retrospective”, Artificial Intelligence 59(1–2), 1993.The authors on what the original got right and wrong.
• Ghallab, Nau and Traverso, Automated Planning and Acting, 2016.The standing textbook. The repository's planning notes are indexed against it in docs/references/planning/.
• Tate, Project Planning Using a Hierarchic Non-linear Planner, DAI Research Report 25, Edinburgh, 1976; and “Generating Project Networks”, IJCAI-77, pp. 888–893.Nonlin, and the hierarchical line this repository keeps notes on.
• McAllester and Rosenblitt, “Systematic Nonlinear Planning”, AAAI-91; Penberthy and Weld, “UCPOP”, 1992.Partial order planning, noted in docs/references/planning/PARTIAL_ORDER_PLANNING.md.
• Reiter, “On Closed World Data Bases”, in Logic and Data Bases, Plenum, 1978.Why an exhausted search reports no plan rather than reporting that no plan exists.
• Aristotle, Prior Analytics I.1 (24b18–20).Cited in the repository for the syllogistic core the inference lane rests on.

Credits and further reading

Notes and reading in the repository itself.

• docs/references/planning/STRIPS_PDDL.md, the repository's own working notes on STRIPS and PDDL.
• docs/references/planning/NONLIN.md, on Tate's Nonlin and SHOP2.
• docs/references/planning/PARTIAL_ORDER_PLANNING.md and BDI_GOAL_DRIVEN_AUTONOMY.md.
• README for the full bibliography.