Converting Procedures to PDDL or Behavior Trees

The buyer's problem

Language models can paraphrase a procedure, but a planner, a verifier or an executive layer needs something stricter: a representation that can be parsed, checked for consistency and executed step by step. Two families dominate. PDDL describes a planning domain: object types, predicates that describe states, and actions with preconditions and effects. Behavior trees describe control flow: sequences, fallbacks and condition checks over action leaves.

The conversion is a distinct deliverable from text extraction or task graphs. Buyers who request it need to say which target, which fragment of the language and which tests. For the looser, intermediate structure, see task graphs from procedures; for the field-level step record that both targets draw on, see the procedure step schema.

Two targets, two jobs

PDDL was written for the AIPS-98 planning competition; its Version 1.2 report specifies the syntax and, less formally, the semantics of the language (McDermott et al., 1998). A domain file declares types, predicates and actions; a problem file declares objects, an initial state and a goal. A planner then searches for an action sequence. Later versions extend the language, so state which version and which requirements flags the deliverable uses.

Behavior trees are a way to structure switching between tasks in an autonomous agent, yielding modular and reactive systems (Colledanchise and Ogren, 2017). They are executed, not searched: a tree is ticked, conditions are evaluated and actions run. A procedure's recovery logic ("if the indicator stays on, repeat; if it still stays on, escalate") fits a fallback node naturally.

Some projects produce both: PDDL for planning and checking, a behavior tree for execution. Others need only one.

Mapping procedure constructs

The preconditions and postconditions and branching procedures and decision points pages cover how those elements are captured upstream. Conversion depends on their quality: a step with no stated effect cannot become a PDDL action without invention.

Illustrative fragment

Synthetic example for a single-step task, shown to make the deliverable concrete.

;; Illustrative - synthetic domain, not from any real procedure
(define (domain filter_swap)
  (:requirements :strips :typing)
  (:types tool part unit)
  (:predicates (isolated ?u - unit) (open ?u - unit)
               (holding ?t - tool) (filter-installed ?u - unit))
  (:action open-panel
    :parameters (?u - unit ?t - tool)
    :precondition (and (isolated ?u) (holding ?t))
    :effect (open ?u))
  (:action install-filter
    :parameters (?u - unit ?p - part)
    :precondition (and (open ?u))
    :effect (filter-installed ?u)))

# Illustrative - equivalent behavior tree skeleton
tree: swap_filter
root:
  sequence:
    - condition: unit_isolated
    - fallback:
        - condition: panel_open
        - action: open_panel
    - action: install_filter
    - condition: filter_installed

Every name here is invented. Real deliverables need a controlled predicate vocabulary documented alongside, so that "isolated" means one checkable thing across the corpus.

What a planning-oriented prompt shows

Mixed designs are common. ProgPrompt prompts a language model with a program-like specification that lists the available actions and objects, plus example programs, to generate situated robot task plans; it reported strong success on VirtualHome household tasks and was deployed on a physical robot arm for tabletop tasks (Singh et al., 2022). The relevance for buyers is the interface: the action and object lists define the vocabulary a plan can use. A procedure conversion that targets a particular robot stack must be written against that stack's action set, not the document's verbs. See grounding LLM planners with SOPs.

What this data can support, and what it cannot

Formal procedure representations can support:

• Plan verification. A planner can check whether a generated plan reaches the goal, or whether a procedure is internally consistent.
• Evaluation sets. Gold plans enable automatic scoring of ordering and constraint adherence.
• Training or fine-tuning planners on document-to-formal-structure pairs.
• Knowledge structuring, with links to procedural knowledge graphs.

They cannot support:

• Physical control. An action named install-filter is a symbol. How a humanoid does it is a skill that needs robot data, not a procedure.
• Perception. Conditions such as isolated need detectors or sensors that the formalization assumes.
• Fidelity to practice. The formal model encodes the document, including its gaps; it can be perfectly valid and still not match what workers do.
• Open-ended variation. A fixed symbolic domain cannot represent objects or situations outside its vocabulary.

Acceptance tests

• Syntactic validity. Every file parses with a named PDDL parser or behavior-tree runtime. State the tool and version.
• Solvability. Each problem file with the stated initial state and goal returns a plan from a stated planner; unsolvable problems are flagged intentionally, not accidentally.
• Plan-versus-document check. A reviewer compares the produced plan with the original procedure for order, omissions and added steps.
• Mutation tests. Remove a precondition or reorder steps; the checker should catch the violation the procedure forbids.
• Predicate audit. Each predicate has a one-line definition and an observable test.
• Round-trip. Another reviewer reconstructs the procedure from the formal file; differences show lost nuance.
• Held-out documents. If used for training, hold out whole procedures or companies, not individual steps.

Automated conversion with language models is common and fast; error patterns include invented preconditions and merged steps. The validating LLM-extracted procedure steps checklist applies here too.

Limitations and additional preparation

• Information loss. Judgment calls, tacit knowledge and soft warnings do not fit symbolic form; see tacit knowledge gaps in SOPs.
• Granularity decisions. The action level should match the robot's skill library; choose with step granularity in mind.
• Numeric and temporal content. Plain STRIPS-style PDDL handles durations and quantities poorly; specify extensions if needed.
• Annotator expertise. Few annotators know both the trade and the formalism; expect two-person teams.
• Cost scales with documents. Treat this as a targeted deliverable for high-value procedures, not a bulk transform of a corpus.
• Rights. A formal rendering may be a derivative of the source text. Confirm the license covers derivative representations.

Questions to ask providers

1. Which target and version (PDDL requirement flags, or behavior-tree library and node set)?
2. Is there a predicate or condition dictionary with observable definitions?
3. How were conversions produced, by people, models or both, and what was reviewed?
4. Were plans generated and compared with the source procedure?
5. How are loops, numeric limits and warnings handled?
6. Can the action set be aligned to our robot's skill library?
7. Do the supplier's license terms permit derivative formal representations?
8. Which procedures failed conversion, and why?

Discuss your requirements

If you need procedures converted into a formal planning form, describe the target representation, domain and permitted uses to SourceX. SourceX looks for US businesses that hold suitable procedures, checks the data and the supplier's licensing permissions, and coordinates the license and delivery; it can also arrange annotation, scoped case by case. A request does not guarantee a match, and SourceX follows up about potential sources. Start from the humanoid training data guide or the procedures hub. The catalog page on expert annotations and labels describes labeling as a category.

Discuss your humanoid training-data requirements with SourceX

Sources

• PDDL - The Planning Domain Definition Language (Version 1.2) — PDDL syntax and semantics, written for AIPS-98.
• Behavior Trees in Robotics and AI: An Introduction — behavior trees as modular, reactive task structure.
• ProgPrompt: Generating Situated Robot Task Plans using Large Language Models — programmatic prompts with action and object lists.