#3719 PDDL: Planning Domain Definition Language

MIT Invents Neuro-Symbolic LLM Fusion

https://www.youtube.com/watch?v=H2GIhAfRhEo

#3719 Consider the following:

"""PDDL: Planning Definition Language
Domain PDDL file: provides a lifted representation of the underlying rules of the world. It includes a set of predicates that define the state space S and the actions with preconditions and effects (i.e. the transition function f).
Problem PDDL file: provides a list of objects to ground the domain, the problem's initial state s_init and the goal conditision S_G.
Set of Symbolic Planners: implement efficient search algorithms to solve planning problems in PDDL"""

PDDL, which stands for Planning Domain Definition Language, is a standardized language used in artificial intelligence to define planning problems. It allows you to describe a world, the actions possible in that world, and what you want to achieve.

Core Components

PDDL problems are defined using two separate files: the Domain file and the Problem file. Think of it like a board game: the domain file is the rulebook, and the problem file is the specific setup for a single game.

Domain File: The Rules of the World 📖

The domain file describes the general physics and rules of the environment. It doesn't deal with specific objects, but rather the types of things that can exist and the actions that can be performed. It includes:

Predicates: These are properties or relationships that can be true or false. For example, (at ?robot ?location) could represent that a robot is at a certain location, or (holding ?robot ?object) could mean a robot is holding an object.
Actions: These are the rules for changing the world. Each action has:
- Preconditions: The conditions that must be true to perform the action. For instance, to pick up an object, a robot's hand must be empty.
- Effects: The changes that occur after the action is performed. After picking up an object, the robot is now holding it, and its hand is no longer empty.

Problem File: The Specific Scenario 🎲

The problem file sets up a concrete instance of the puzzle you want to solve within the rules defined by the domain file. It contains:

Objects: A list of all the specific items in this particular problem. For example, robot1, roomA, roomB, key1.
Initial State (s_init): This defines what is true at the very beginning of the problem. For example, (at robot1 roomA) and (hand_empty robot1).
Goal (S_G): This describes the desired final state. It's the condition you want the planner to achieve. For example, (at key1 roomB).

Solving the Problem

Once you have both a domain and a problem file, a Symbolic Planner can read them. The planner is a program that uses search algorithms to find a sequence of actions (a "plan") that transforms the initial state into the goal state without violating any of the rules defined in the domain file. It effectively finds a valid path from start to finish.

Provide an example for Tic-Tac-Toe

Of course. Here is a simplified example of how you could model a game of Tic-Tac-Toe using the Planning Domain Definition Language (PDDL).

This example illustrates the core concepts: the domain file sets the rules of the game, and the problem file sets up a specific board state and a goal to achieve.

1. The Domain File: `tictactoe-domain.pddl`

This file defines the fundamental rules of Tic-Tac-Toe. It describes the properties of the game (predicates) and the only action a player can take: placing a mark.

Predicates: These define the possible states of the game. For example, (cell ?c) means "?c is a cell", (empty ?c) means cell "?c" is empty, and (turn ?p) indicates it is player "?p's" turn. (has-mark ?p ?c) means player "?p" has a mark in cell "?c".
Action: (place-mark ?p ?c) is the action of player "?p" placing their mark in cell "?c".
- Preconditions: To place a mark, the cell must be empty, and it must be that player's turn.
- Effects: After placing the mark, the cell is no longer empty, the player has-mark in that cell, and the turn switches to the next player.

;; tictactoe-domain.pddl
;; Defines the rules of the Tic-Tac-Toe game.

(define (domain tictactoe)
  (:requirements :strips)

  (:predicates
    (cell ?c)             ; ?c is a cell on the board
    (player ?p)           ; ?p is a player
    (next-player ?p1 ?p2) ; ?p2's turn is after ?p1's
    (empty ?c)            ; Cell ?c is empty
    (has-mark ?p ?c)      ; Player ?p has a mark in cell ?c
    (turn ?p)             ; It is player ?p's turn
    (line ?c1 ?c2 ?c3)    ; A winning line exists with these three cells
    (win ?p)              ; Player ?p has won
  )

  (:action place-mark
    :parameters (?p ?c)
    :precondition (and
      (player ?p)
      (cell ?c)
      (turn ?p)
      (empty ?c)
    )
    :effect (and
      (not (empty ?c))
      (has-mark ?p ?c)
      (forall (?p2)
        (when (next-player ?p ?p2)
          (and (turn ?p2) (not (turn ?p)))
        )
      )
      ; Check for win condition after placing a mark
      (forall (?c1 ?c2 ?c3)
        (when (and (line ?c1 ?c2 ?c3) (has-mark ?p ?c1) (has-mark ?p ?c2) (has-mark ?p ?c3))
          (win ?p)
        )
      )
    )
  )
)

2. The Problem File: `tictactoe-problem.pddl`

This file defines a specific game scenario. It lists the actual objects (the cells, the players) and sets up the initial board and the goal we want to reach.

Objects: We define our 9 cells (c1 through c9) and our two players (player-x and player-o).
Initial State (:init): This is the setup at the beginning.
- The board is completely empty.
- We define the turn order: player-o comes after player-x.
- We define all possible line combinations for winning.
- It is player-x's turn.
Goal (:goal): This is the condition we want the planner to achieve. In this case, the goal is for player-x to be in a win state.

;; tictactoe-problem.pddl
;; A specific Tic-Tac-Toe scenario where the goal is for Player X to win.

(define (problem tic-tac-toe-win-for-x)
  (:domain tictactoe)

  (:objects
    c1 c2 c3 c4 c5 c6 c7 c8 c9 - cell
    player-x player-o - player
  )

  (:init
    ;; The board is initially empty
    (empty c1) (empty c2) (empty c3)
    (empty c4) (empty c5) (empty c6)
    (empty c7) (empty c8) (empty c9)

    ;; Define turn order
    (next-player player-x player-o)
    (next-player player-o player-x)

    ;; It's player X's turn to start
    (turn player-x)

    ;; Define all winning lines
    (line c1 c2 c3) (line c4 c5 c6) (line c7 c8 c9) ; Rows
    (line c1 c4 c7) (line c2 c5 c8) (line c3 c6 c9) ; Columns
    (line c1 c5 c9) (line c3 c5 c7) ; Diagonals
  )

  (:goal
    (win player-x)
  )
)

What a Symbolic Planner Does

When you give these two files to a symbolic planner, it will search for a sequence of place-mark actions that starts from the initial empty board and ends with the goal state ((win player-x)).

A possible plan it might output would be:

(place-mark player-x c1)
(place-mark player-o c2)
(place-mark player-x c5)
(place-mark player-o c3)
(place-mark player-x c9)

After the 5th step, the condition (and (line c1 c5 c9) (has-mark player-x c1) (has-mark player-x c5) (has-mark player-x c9)) becomes true, triggering the (win player-x) effect and achieving the goal.

Is this syntax similar to Prolog?

Yes, at first glance, PDDL's syntax looks very similar to Prolog, primarily because both are heavily influenced by Lisp and use a parenthetical, prefix notation style. However, while they share a superficial resemblance and roots in logic, their syntax is fundamentally different in structure and purpose.

Here’s a breakdown of the similarities and key differences.

Visual Similarities (The Lisp Influence) 🌲

Parentheses Everywhere: Both languages wrap almost every expression in parentheses. An action in PDDL like (place-mark player-x c1) looks a lot like a goal in Prolog, (member X [1, 2, 3]).
Prefix Notation: In both, the function or predicate name comes first, followed by its arguments. For example, (+ 2 3) instead of 2 + 3.
Symbolic Atoms: Both use symbolic atoms (like player-x or c1) to represent objects and concepts without needing quotes.

Core Syntactic & Structural Differences ↔️

The resemblance is only skin-deep. The underlying grammar and keywords are distinct because they are designed for different tasks: Prolog is for querying a knowledge base, while PDDL is for defining state transition models for planners.

Feature	PDDL (Planning Definition)	Prolog (Logic Programming)
Primary Goal	To describe states, actions, and goals. It's a descriptive language for a planner to read.	To prove queries by searching a database of facts and rules. It's an executable language.
Key Structures	Rigid `(define (domain ...))` and `(define (problem ...))` blocks with specific, required sections.	A flexible collection of facts and rules in a single knowledge base.
Keywords	Uses specific keywords with a colon prefix, like `(:action)`, `(:parameters)`, `(:precondition)`, and `(:effect)`.	Defines rules using the `:-` operator (read as "if"). Facts are simply stated and end with a period.
State	Explicitly models state changes. The `:effect` of an action directly modifies the world by adding and deleting facts.	State is implicit and static. Prolog doesn't model a changing world; it searches for what is true within a fixed set of rules.

Analogy: Blueprint vs. Instruction Manual 🛠️

Think of it this way:

PDDL is like a detailed blueprint for a machine. It defines all the parts (:predicates, :objects), specifies how they can interact (:actions), and what conditions are needed (:precondition). You give this blueprint to an engineer (a planner) who then figures out how to build the machine (the plan).
Prolog is like an instruction manual or an expert you can ask questions. You provide it with a set of facts ("The sky is blue.") and rules ("IF it is daytime AND there are no clouds, THEN the sky is blue."). You then ask it questions (?- is_sky_blue.), and it uses its knowledge to answer "yes" or "no."

In short, while they share a common Lisp-like ancestor, PDDL is a specialized language for defining planning problems with a strict, keyword-driven syntax, whereas Prolog is a general-purpose logic programming language with a more flexible syntax based on facts and rules.

In addition to Tic-Tac-Toe, what are the various other "rules of the world" that could be implemented?

Beyond simple games, PDDL can model a vast range of "rules of the world" for planning problems, from simple robotic tasks to complex logistical operations. The key is that the world must be representable by a set of discrete states and actions that have clear preconditions and effects.

Here are several examples of domains that can be implemented.

Logistics and Robotics 🤖

This is the classic and most common application area for PDDL. The rules govern how objects are moved between locations by agents like robots or vehicles.

Blocks World: A foundational planning problem.
- Rules: A set of blocks are on a table or stacked on each other. A robotic arm can pick up a clear block (one with nothing on top of it) and place it on the table or another clear block. The goal is to achieve a specific stack configuration.
- Predicates: (on ?block1 ?block2), (on-table ?block), (clear ?block), (hand-empty)
Logistics Planning: A more complex version of Blocks World involving transportation.
- Rules: Packages must be moved between different locations in different cities. Trucks can drive between locations within the same city, and airplanes can fly between airports in different cities. A package must be loaded into a vehicle to be moved.
- Predicates: (at ?package ?location), (in ?package ?vehicle), (at ?vehicle ?location)
Robot Navigation: Planning a path for a robot in a grid-like environment.
- Rules: A robot can move between adjacent rooms or cells as long as the path between them is not blocked. Doors might need to be unlocked with specific keys.
- Predicates: (at ?robot ?room), (connected ?room1 ?room2), (door-open ?door), (has-key ?robot)

Puzzles and Games 🧩

Many logic puzzles and turn-based games can be modeled, though complex strategy games with opponents are more challenging.

Towers of Hanoi: The classic recursive puzzle.
- Rules: You can only move one disk at a time. A disk can only be moved if it is the top disk on a stack. A larger disk can never be placed on top of a smaller disk.
- Predicates: (on ?disk1 ?disk2), (clear ?disk), (smaller ?disk1 ?disk2)
Sokoban (Box-Pushing Puzzle): A puzzle involving pushing boxes onto target squares.
- Rules: The player can move to an adjacent empty square. The player can push a single box to an adjacent empty square. The player cannot pull a box or push more than one box at a time.
- Predicates: (player-at ?location), (box-at ?location), (is-goal ?location)

Process and Manufacturing 🏭

PDDL can model workflows, assembly lines, and other sequential processes where the order of operations matters.

Assembly Line: Modeling the steps to build a product.
- Rules: A car chassis must be painted before the doors can be attached. The engine must be installed before the hood is fitted. Each step requires specific tools or parts to be available.
- Predicates: (chassis-painted), (doors-attached), (tool-available ?tool)
Scientific Experiments: Planning a sequence of steps for a biological or chemical experiment.
- Rules: A sample must be heated to a specific temperature before a reagent can be added. A centrifuge must be used to separate components before analysis.
- Predicates: (sample-heated), (reagent-added), (is-separated ?sample)

Essentially, if you can define a world in terms of what is true (predicates) and what you can do to change it (actions with preconditions/effects), you can likely model it in PDDL.

Would Mathematica, along with Wolfram LLM Tool Kit be useful for this activity?

Yes, absolutely. Mathematica, especially when combined with the Wolfram LLM Toolkit, would be a highly effective and powerful environment for working with PDDL.

While not a specialized PDDL planner itself, the Wolfram Language provides an excellent toolkit for building, analyzing, and interacting with planning systems.

How Mathematica Can Be Used

Mathematica's symbolic nature makes it uniquely suited for handling the structure of PDDL.

Parsing and Representation: PDDL's Lisp-like syntax (predicate object1 object2) can be directly and naturally represented as Wolfram Language expressions like predicate[object1, object2]. You could easily write a parser to read .pddl files and convert them into these symbolic expressions for manipulation.
State Management: A state in a PDDL problem is simply a list of true predicates. This is trivial to manage in Mathematica. For example, the initial state of the Tic-Tac-Toe board could be a list: {empty[c1], empty[c2], ..., turn[playerX]}. Applying an action's effects would simply involve adding and removing expressions from this list.
Implementing a Planner: You could implement planning algorithms (like Breadth-First Search or A*) directly in the Wolfram Language. Its powerful functional programming and pattern-matching capabilities would make it an elegant environment for defining the search logic and applying action rules.
Visualization 📊: This is where Mathematica would truly excel. You could write code to take any state (a list of predicates) and generate a visual representation. For the Tic-Tac-Toe example, you could create a function that draws the board based on which has-mark[player, cell] predicates are true. You could then animate the entire solution plan step-by-step, which is invaluable for debugging and understanding.

The Role of the Wolfram LLM Toolkit 🧠

The LLM Toolkit acts as a powerful bridge between natural language and the structured world of PDDL, supercharging the entire activity.

PDDL Generation from Natural Language: This is the killer feature. You could use the LLM to create a "problem generator." Instead of writing meticulous PDDL code, you could prompt it in plain English:
"Generate a PDDL problem file for a Blocks World with 4 blocks labeled A, B, C, D. Initially, all blocks are on the table. The goal is to have A on top of B, and C on top of D."
The LLM would then generate the correctly formatted .pddl file, which your Mathematica code could then parse and solve.
Plan Explanation: After your planner finds a solution (e.g., a list of actions like place-mark[playerX, c1]), you could feed this sequence to the LLM and ask it to explain the plan in a human-readable format:
"Player X starts by placing their mark in cell 1. Player O responds by taking cell 2..."
Interactive Problem Solving: You could build an interactive environment where you describe changes to the world, the LLM updates the PDDL state, Mathematica solves for the next best action, and the cycle continues.

In summary, Mathematica provides the symbolic and computational engine to parse, represent, solve, and visualize the planning problem, while the Wolfram LLM Toolkit provides a brilliant natural language interface to create problems and interpret solutions. Together, they form a comprehensive and highly flexible platform for this kind of AI activity.

Would this support identifying needs and opportunities for improvement in user-specified systems or user groups?

Yes, this approach is an excellent way to identify needs and opportunities for improvement in systems and user workflows.

By modeling a system or a user group's process as a PDDL planning problem, you can use an AI planner to analyze it in a way that humans might miss. The core idea is to treat your current, inefficient process as the initial state and your desired, efficient process as the goal state.

How It Works: Modeling Your Process

In essence, you transform a real-world workflow into a formal puzzle for the AI planner to solve.

The Domain (The Rules of Your System): You define the actions that users or system components can perform. For a helpdesk system, actions could be create_ticket, assign_technician, request_user_info, escalate_issue. Preconditions define what's needed for each action (e.g., a ticket must be assigned before you can request info).
The Problem (A Specific Scenario): You describe the current situation (e.g., a new, unassigned ticket has arrived) as the initial state. The goal is the ideal outcome (e.g., ticket_resolved and customer_notified).

The planner's job is to find the most efficient sequence of defined actions to get from the initial state to the goal. The plan it generates—or its failure to find a plan—is where you find your insights.

Identifying Needs and Opportunities 💡

Analyzing the planner's output can reveal several key areas for improvement:

1. Identifying Bottlenecks and Inefficiencies

If the planner returns a very long and convoluted plan, it mirrors an inefficient real-world process. It might highlight redundant steps or a poor sequence of operations. For example, the plan might show an agent repeatedly requesting information because the initial create_ticket action doesn't gather enough data upfront.

Opportunity: Redesign the initial ticket submission form to be more comprehensive, creating a "shortcut" for the planner and a more efficient path for the user.

2. Discovering Resource Gaps

Sometimes, the planner will report that the goal is unreachable. This is an extremely valuable insight. It means that with the current set of actions and rules, there is no possible way to achieve the desired outcome.

Need: This points to a fundamental gap in your process. You might be missing a necessary tool, a specific user role, or a key procedure. For example, if a ticket can't be resolved because no action exists to handle "corrupted user data," you've identified the need to create a new protocol and train staff on it.

3. Optimizing Workflows

A planner can often find a shorter or more optimal sequence of actions than the one currently being used. It isn't constrained by habit or the "way things have always been done." It simply finds the most direct logical path.

Opportunity: You can compare the planner's optimal solution to your existing standard operating procedures to find shortcuts and eliminate wasted effort.

4. Simulating the Impact of Changes ("What If?")

PDDL allows you to experiment with potential improvements safely and cheaply. Want to know if a new software tool would help? Just add a new action to the domain that represents what the tool does.

Opportunity: You could add an action like run_auto_diagnostic that automatically gathers system info. If the planner now finds much shorter plans or can solve previously unsolvable problems, you have a strong justification for investing in that new tool.

A Quick Example: Hospital Patient Intake

Initial State: (patient_in_waiting_room), (has_no_chart), (is_unregistered)
Goal State: (patient_in_exam_room), (vitals_recorded), (is_registered)
Analysis: If the planner shows that a nurse is always stuck waiting for registration to complete before they can take vitals ((is_registered) is a precondition for take_vitals), you've identified a process bottleneck. The opportunity would be to create a parallel workflow where a medical assistant can take vitals while the patient is still in the waiting room.

While modeling complex human systems in PDDL can be challenging, it forces you to think rigorously about your processes and can uncover deep, actionable insights that would otherwise remain hidden.

Along with Mathematica, can TRIZ methods be applied in useful ways here as well?

Yes, absolutely. Combining PDDL with TRIZ methods is a highly effective and sophisticated strategy. They complement each other perfectly: PDDL helps you find the problem, and TRIZ helps you invent the solution.

In short, PDDL is the diagnostic tool, and TRIZ is the creative engine.

The Synergy: Finding vs. Solving

Think of the roles this way:

PDDL / Mathematica (The Analyst 🕵️‍♀️): This combination is excellent for formally modeling a system and identifying a core problem with mathematical certainty. When the planner fails to find a solution or returns a highly inefficient one, it's not just giving you a hunch; it's proving that a fundamental conflict or bottleneck exists based on the rules you've defined.
TRIZ (The Inventor 💡): TRIZ (the "Theory of Inventive Problem Solving") is a methodology for structured creativity. It excels at resolving contradictions, which are often the root cause of the problems identified by PDDL. Instead of a simple trade-off, TRIZ pushes for an inventive solution that overcomes the conflict.

The planner might tell you, "You can't achieve Goal X." TRIZ helps you answer, "How can we change the rules of the game so that Goal X becomes achievable?"

A Practical Workflow

Here is how you would apply them together to improve a system.

Step 1: Model the System with PDDL

As discussed before, you model your current workflow in PDDL and use the planner in Mathematica to analyze it. Let's use our Hospital Patient Intake example. The planner finds that the process is slow because of a bottleneck at the registration desk.

Step 2: Identify the Contradiction with TRIZ

The problem identified by the planner can be framed as a TRIZ "Technical Contradiction."

The Contradiction: We want to improve the speed of patient processing (a positive feature), but doing so requires more staff or skipping steps, which increases cost or decreases the thoroughness of information gathering (a negative feature). Improving one parameter worsens another.

Step 3: Apply TRIZ Principles to Generate Solutions

Now, you use TRIZ tools, like the 40 Inventive Principles, to brainstorm solutions to this contradiction.

Principle 10: Preliminary Action (or Prior Action)
- Idea: Can we perform part of the registration before the patient arrives?
- Solution: Implement a system where patients can pre-register and fill out forms online via a secure link sent to their phone after making an appointment.
Principle 2: Taking Out (or Extraction)
- Idea: Can we separate the information-gathering part from the physical location?
- Solution: Hire remote administrative staff who call the patient while they are on their way to the hospital to complete the registration process over the phone.
Principle 3: Local Quality
- Idea: Can we make different parts of the process work differently?
- Solution: Instead of one central registration desk, place small registration kiosks or give nurses tablets to perform registration tasks directly in the waiting area or exam room, making the process distributed.

Step 4: Model the New Solution in PDDL

You select the most promising idea (e.g., "Preliminary Action") and translate it back into your PDDL domain. You would create a new action like (pre-register_online ?patient).

Effect: This action would achieve the predicates (is_registered) and (chart_created) without requiring the patient to be at the front desk.

Step 5: Validate the Improvement

You run the planner again with the updated domain. The planner should now return a much shorter, more efficient plan for patient intake, confirming that your TRIZ-inspired solution has successfully resolved the bottleneck.

By combining these methods, you create a powerful cycle: Model → Analyze → Identify Contradiction → Invent Solution → Validate. This approach elevates you from just finding problems to systematically inventing and verifying breakthrough solutions.

Provide a framework and work flow for this activity

Of course. Here is a complete framework and workflow that integrates PDDL, Mathematica, and TRIZ for systemic improvement.

This framework provides a structured, repeatable process for moving from a vaguely defined problem to a validated, inventive solution. It combines AI-driven analysis with systematic creative thinking.

AI-Driven Process Innovation Framework

This framework consists of three core phases: Modeling & Analysis, where you define and diagnose the problem; Creative Problem Solving, where you invent a novel solution; and Validation & Implementation, where you test and plan the rollout of that solution.

Phase 1: Modeling & Analysis (The "As-Is")

The goal of this phase is to create a formal, digital model of your current process and use an AI planner to identify concrete problems.

Step 1: Define Scope and Goal
- Activity: Clearly identify the user system or workflow you want to improve (e.g., customer support ticket lifecycle, new employee onboarding).
- Output: A precise problem statement, including the desired end-state (the goal). For instance, "Reduce the time from ticket submission to final resolution."
Step 2: Model the System in PDDL
- Activity: Using Mathematica as your environment, translate the process into a PDDL model.
  - Domain File: Document all possible actions, roles, and rules (e.g., (assign_ticket), (escalate_issue)).
  - Problem File: Define the initial state of a typical scenario (e.g., a new ticket arrives). Set the goal to your desired outcome (e.g., (ticket_is_resolved)).
- Output: domain.pddl and problem.pddl files loaded as symbolic expressions in Mathematica.
Step 3: Execute Planner & Pinpoint the Problem
- Activity: Run a symbolic planner on your PDDL model.
- Output: A clear, data-backed problem definition. This will be one of two outcomes:
  1. An Inefficient Plan: The plan is very long, indicating bottlenecks or redundant steps.
  2. An Unsolvable Goal: The planner reports failure, proving a resource or process gap makes the goal impossible.

Phase 2: Creative Problem Solving (The "To-Be")

This phase uses the analytical output from Phase 1 as the input for a structured brainstorming process to invent a solution.

Step 4: Frame the Contradiction
- Activity: Translate the planner's finding into a TRIZ contradiction.
  - Inefficient Plan → "The process is too slow because it must be thorough."
  - Unsolvable Goal → "We need to achieve Outcome Y, but our current tools/rules (X) prevent it."
- Output: A clear contradiction statement that defines the core challenge.
Step 5: Apply TRIZ Principles
- Activity: Use the TRIZ Contradiction Matrix and the 40 Inventive Principles to brainstorm novel solutions that resolve the contradiction instead of just compromising.
- Output: A list of 3-5 creative, actionable ideas.
Step 6: Select a Candidate Solution
- Activity: Evaluate the brainstormed ideas based on impact, cost, and feasibility.
- Output: One chosen solution to be modeled and validated.

Phase 3: Validation & Implementation (The Proof)

This final phase uses the digital model to test the proposed solution before committing any real-world resources.

Step 7: Update the PDDL Model
- Activity: Modify your domain.pddl file in Mathematica to reflect the chosen solution. This usually involves adding a new, more powerful action or changing the preconditions/effects of an existing one.
- Output: A new, "To-Be" version of your PDDL domain.
Step 8: Validate with the Planner
- Activity: Re-run the planner using the updated model.
- Output: A successful, highly efficient plan. This serves as quantitative proof that your solution works within the model. You can now compare the new plan's length and complexity to the original.
Step 9: Develop Implementation Roadmap
- Activity: With the solution now validated, translate the abstract PDDL action into a concrete project plan. The PDDL plan itself can serve as a high-level guide to the new Standard Operating Procedure (SOP).
- Output: A project charter, implementation plan, and communication strategy for rolling out the process improvement in the real world.

From <https://gemini.google.com/app/> Google Gemini 2.5 Pro