From Durations to Dynamics: Translating Temporal Planning into PDDL+

Schedules break in the small gaps.

A delivery truck leaves at the right time, but the loading dock was not open yet. A watering pump arrives near the plant, but the tap is not being opened by the second worker at the same moment. A rescue boat reaches the correct coordinate, but after the deadline. In normal business language, these are “coordination issues.” In automated planning language, they are temporal constraints, numeric resources, durative actions, invariants, and interference rules.

That translation matters because planning software does not merely choose what to do. It must also decide when actions start, how long they last, what must remain true while they run, and which simultaneous actions are legally allowed to touch the same state variables. This is where elegant diagrams of “AI agents planning workflows” often become less elegant. Time is rude that way.

Andrea Micheli, Enrico Scala, and Alessandro Valentini’s paper, “Compiling Temporal Numeric Planning into Discrete PDDL+,” tackles a problem that had been sitting in the planning literature as a known possibility but not as a practical, fully spelled-out construction: temporal planning with PDDL 2.1 durative actions can be represented in PDDL+, but doing so faithfully is not a matter of renaming syntax.¹ The paper provides a polynomial compilation from PDDL 2.1 level-3 temporal numeric planning into discrete-semantics PDDL+, assuming non-self-overlapping durative actions. It proves soundness and completeness, then tests whether the compilation is useful in practice.

The short version is tempting: “They translate temporal planning into PDDL+ and it works.” That is also the version most likely to miss the point.

The useful contribution is not that PDDL+ can express durative behavior. That was already understood. The useful contribution is the machinery that makes the translation honest: start actions, processes, termination events or actions, clocks, counters, invariant guards, and a lock mechanism that preserves the no-moving-target rule. In other words, the paper is not just about moving a planning model from one language into another. It is about preserving the contract of time.

The real problem is not duration; it is what must remain true during duration

PDDL 2.1 temporal planning represents actions that occupy intervals. A durative action has a start, an end, duration constraints, and conditions that may need to hold throughout the interval. The planner is not allowed to casually violate those conditions in the middle and then repair them before the action ends. That would be convenient. It would also be cheating, which is rarely a good semantics.

PDDL+ has a different worldview. Instead of modeling durative actions directly, it describes systems using instantaneous actions, events, and processes. Processes evolve state over time. Events fire when their conditions become true. Actions are chosen by the planner. This makes PDDL+ attractive for hybrid and dynamic systems, but it also creates a translation problem: how do you make an interval-style durative action behave correctly inside a language built from instantaneous triggers and continuous or discretized dynamics?

The paper’s answer is to turn each temporal action into a small control system.

A fixed-duration durative action becomes a start action, a process that tracks elapsed time, and an event that closes the action exactly when the required duration is reached. A variable-duration action becomes a start action, a process that tracks elapsed time, and a planner-controlled ending action that is only applicable within the allowed duration interval.

That sounds simple until one asks what must be preserved:

This is the paper’s central lesson. The hard part is not representing that an action lasts five minutes. The hard part is making sure every semantic obligation attached to those five minutes survives the journey into PDDL+.

A workflow automation analogy is useful here, but only if we do not stretch it too far. Imagine replacing a “meeting from 2:00 to 3:00” calendar object with three separate system records: meeting-started, meeting-running, meeting-ended. If the system only records the start and end, it might miss that the required attendee left midway, the room was double-booked, or the resource was modified by another process. The interval is not just a length. It is a promise about what is allowed to happen while the interval exists.

The paper formalizes that promise.

The compilation turns each durative action into a small machine

The mechanism is easiest to understand as a staged conversion.

First, the compiled PDDL+ problem keeps the original fluents of the temporal problem. It then adds auxiliary state. There is a global predicate that acts like a validity flag; once violated, it cannot be restored, so any plan prefix that breaks the temporal rules becomes useless. There is a counter for actions that have started but not yet terminated. There is also a time-separation fluent used in the lock-reset construction.

For every durative action, the compiler adds a predicate indicating whether that action is currently running and a numeric fluent that measures elapsed time since the action started. The running predicate handles non-self-overlap. The clock handles duration constraints.

Second, the compiler creates PDDL+ actions corresponding to original instantaneous actions, starts of durative actions, and endings of variable-duration durative actions. Fixed-duration endings are handled differently: they are events, not planner-chosen actions, because the end must occur exactly when the duration is reached.

Third, the compiler creates processes. These are deliberately simple. One family of processes increments the clock of a running durative action. Another process increments the auxiliary time-separation fluent used to reset locks after time has advanced.

Fourth, the compiler creates events. Some events close fixed-duration actions. Some detect invariant violations. Some detect variable-duration actions that exceed their upper bound. One event resets lock predicates after a positive passage of time.

This architecture is not beautiful in the way a one-line theorem is beautiful. It is beautiful in the way a good railway interlocking system is beautiful: many boring safeguards, each preventing exactly one class of disaster. Academic elegance occasionally wears a hard hat.

The most important design move is that the compilation does not rely on the planner being polite. If a bad temporal prefix appears, the compiled model does not merely hope the planner will avoid it. It makes the bad prefix unable to reach the goal.

That is the difference between an encoding that describes intent and an encoding that enforces semantics.

The lock mechanism is the part that prevents silent semantic fraud

The paper’s lock mechanism deserves special attention because it addresses a subtle issue: simultaneous actions.

Temporal planning allows multiple happenings at the same time, but not arbitrary interference. PDDL 2.1 includes the no-moving-target rule: roughly, an action should not read a value at the same time another action changes it in a way that makes the read ambiguous or invalid. Similarly, conflicting writes must be controlled.

The compilation introduces three lock predicates for every fluent. Conceptually, they distinguish whether a fluent has been read, assigned, or incremented in the current superdense time step. When a compiled action reads a fluent, assigns it, or increments it, the corresponding lock state changes. Later actions at the same time point must satisfy lock preconditions, so illegal combinations are blocked.

The point is not merely to prevent “two actions use the same resource.” It is more precise than that.

Reading after assignment is different from incrementing after increment. Assignment and additive numeric updates are not semantically identical. The compilation respects these categories because PDDL temporal semantics does. That distinction may look pedantic until a planning system quietly allows two simultaneous operations to manipulate a numeric resource in an order-dependent way. Then it becomes a production incident with a surprisingly philosophical root cause.

The lock reset is also carefully engineered. Locks must persist within the same time point, but they must be released after time advances. The compiler uses a time-separation fluent increased by a process. Once that fluent is positive, an event resets the locks. This makes the lock state local to the current temporal happening sequence.

That construction explains why the paper uses discrete PDDL+ semantics. Under continuous-time semantics, the reset event could trigger in a way that leads to Zeno behavior: infinitely many event firings in finite time. The authors explicitly identify this issue. Discrete semantics is not a minor implementation preference. It is part of why the construction behaves properly.

So the accepted misconception should be corrected firmly: this is not a trivial syntactic compilation. The paper is solving the small, unpleasant semantic cases that are easy to wave away and hard to repair after a planner has already produced a “valid” but operationally nonsensical schedule.

The proof establishes equivalence, not just plausibility

The theoretical section proves soundness and completeness.

Soundness means that if the compiled PDDL+ problem has a valid plan, the corresponding temporal plan is valid for the original PDDL 2.1 problem. This is the “no fake plans” direction. It is especially important because an expressive target language can easily encode too much. If the compilation accidentally admits behaviors that were illegal in temporal planning, the translated planner may solve the wrong problem very quickly. Fast wrong answers remain popular in software, but they do not become less wrong.

Completeness means that if the original temporal problem has a valid temporal plan, then there exists a sufficiently small discretization step under which the compiled PDDL+ problem has a corresponding valid plan. This is the “no lost plans” direction. The proof relies on choosing a discretization step that aligns with the rational time points in the temporal plan.

The paper also states that the compilation is polynomial in the size of the input problem and that plan length is preserved up to a constant factor, specifically at most doubled. This matters because compilation-based methods are useful only if the translation itself does not become the actual planning problem. A clever encoding that explodes the model is not a bridge. It is a toll road with no exit.

A compact way to read the proof contribution is this:

The proof does not say PDDL+ planning will always be faster. It says the representation bridge is semantically justified. Performance is a separate question, and the paper treats it as such.

That separation is healthy. We could use more of it.

The experiments ask whether the semantic bridge is useful, not whether it wins every race

The experimental section evaluates the compilation on temporal numeric domains where time and numeric reasoning are intertwined. This choice is important. If the test were only on simple temporal scheduling, the experiment would mostly ask whether a compiled PDDL+ approach can compete with planners designed directly for temporal planning. That would be a narrow and arguably unfair framing.

Instead, the paper looks at domains where the representation advantage of PDDL+ might matter.

The benchmark set includes MatchCellar and MAJSP from prior work, plus two new domains: T-Sailing and T-Plant-Watering. T-Sailing extends a sailing rescue domain with deadlines. T-Plant-Watering introduces coordination between two agents: one carries the pump and can water only when another simultaneously opens the tap. This is not “planning” in the toy sense of arranging errands. It is planning where timing, numeric conditions, and concurrency are entangled.

The paper evaluates coverage and runtime. Each domain has 20 instances. ENHSP is used as the PDDL+ planner after compilation, with two engines: lazy greedy best-first search and weighted A*. The comparison includes native temporal planners: ARIES, OPTIC, TAMER, TFLAP, NextFLAP, and Patty. The experiments use an 1800-second timeout and a 20 GB memory limit.

The coverage table is the main evidence, not an ablation. There are no separate ablation experiments isolating the lock mechanism or disabling invariant checks. The table tests the full compiled approach against existing planners.

ENHSP-WA has the highest total coverage, solving 67 out of 80 instances. ARIES follows with 59, and ENHSP-LG with 58. The result is not a clean “compiled PDDL+ dominates temporal planning” story. It is more interesting than that, which means it is less useful for conference-hall chest thumping but more useful for actual system design.

On MatchCellar, ARIES and TFLAP solve all 20 instances, while ENHSP-WA solves 12. Native temporal machinery can still be stronger in some temporally focused settings. On the other hand, ENHSP-WA solves all 20 T-Sailing instances and performs strongly overall on temporal numeric domains. The authors describe complementarity between ARIES and ENHSP-WA: ARIES scales better in MatchCellar, while ENHSP-WA is better on the temporal numeric domains.

That is the business-relevant interpretation. The compilation is not magic dust. It changes which solver capabilities become available for which class of problem. If your domain’s difficulty comes from rich numeric-temporal interaction, compiling into PDDL+ may expose structure that a PDDL+ planner can exploit. If the problem is mainly classic temporal scheduling, a native temporal planner may still be the better tool.

The paper also mentions that the compiler is implemented within the unified_planning library and supports delayed effects and timed initial literals, emulated with events triggered at the proper time. This is an implementation detail with practical importance. Delayed effects and timed initial literals are exactly the kind of feature that can make operational planning models less toy-like. They are also the kind of feature that many planning systems treat as someone else’s problem. Someone else is usually the person maintaining the production workaround.

What this changes for business planning systems

For Cognaptus readers, the value of this paper is not that one can now admire a new compilation theorem from a respectful distance. The value is that it clarifies an architecture pattern for complex decision automation:

When operational time semantics become too rich for one planning formalism, compile the problem into a more expressive execution model — but preserve the original semantics explicitly, not by optimism.

That principle applies beyond academic planning benchmarks.

Consider a business planning system for maintenance crews, warehouse robots, agricultural irrigation, energy assets, hospital equipment, or field-service teams. These systems often include:

• actions that take time;
• resources that change numerically;
• deadlines;
• coordination constraints;
• conditions that must remain true during execution;
• delayed consequences;
• exogenous timed facts;
• concurrency that is helpful in one case and illegal in another.

A planning product built around only instantaneous task selection will eventually invent ad hoc patches for all of these. A planning product built around temporal actions may still struggle when numeric dynamics and events become central. The paper suggests a third route: represent temporal tasks in a language where dynamics, processes, and events are natural, while compiling enough semantic discipline into the model to avoid illegal schedules.

This is not the same as saying every business should adopt PDDL+. That would be a suspiciously academic recommendation, and suspiciously academic recommendations tend to arrive without an implementation budget.

The better inference is architectural:

The most practical lesson is about solver optionality. A company building planning infrastructure should avoid treating “the planner” as a single black box. The representation layer can be a strategic asset. If the same operational problem can be compiled into a target formalism where a different solver performs better, the planner stack becomes more adaptable.

This is especially relevant for AI-enabled operations platforms. LLMs can help users describe constraints, generate draft planning models, explain schedules, or translate business rules into structured representations. But the actual schedule validity still depends on formal machinery. A fluent natural-language explanation does not enforce a no-moving-target rule. It simply describes the mess more elegantly.

The paper is a useful antidote to agentic hand-waving. Planning is not just “the model decides a sequence of tools.” In serious operations, the tool sequence has temporal semantics. If two actions touch the same resource at the same time, the legality of that interaction is not a vibe.

The limitations are not decorative; they define where the bridge stands

The paper is precise about its scope, and the limitations should be read as part of the result.

First, the compilation is presented for PDDL 2.1 level 3. The authors speculate that it could be adapted to level 4, which includes continuous change, but they do not present that extension. This matters because many physical systems are naturally modeled with continuous processes. The current result is therefore strongest for temporal numeric planning without continuous-change level-4 semantics.

Second, the compilation targets discrete PDDL+ semantics. This is not incidental. The lock-reset mechanism relies on discrete-time behavior to avoid the Zeno problem that would arise under continuous-time semantics. The authors explicitly identify continuous-time PDDL+ compilation as future work.

Third, the result assumes non-self-overlapping actions. That assumption is common and often reasonable, but it is still an assumption. Domains that require multiple overlapping instances of the same durative action would need additional modeling care.

Fourth, the experiments are promising but limited. Four domains, 20 instances each, and a specific set of planners provide useful evidence, not universal law. The absence of ablations also means we cannot isolate which part of the compilation contributes most to performance. The lock mechanism is theoretically necessary for faithful semantics, but the experimental section does not separately measure its performance cost or benefit.

Fifth, coverage is not the same as operational ROI. Solving more benchmark instances suggests practical relevance, especially in harder temporal numeric domains, but real deployments also care about modeling cost, maintainability, integration, explainability, and plan robustness under data errors. The paper does not claim to solve those business-layer problems. Good. It already has enough real problems to solve.

The quiet strategic message: compilation is product architecture

The paper’s deeper message is that formal planning systems should not be judged only by the modeling language presented to the user. They should also be judged by the transformations available underneath.

A user may think in tasks, deadlines, resources, and dependencies. A planner may perform better when the problem is represented as processes, events, clocks, and locks. The compiler is the bridge between those mental worlds.

That bridge has product value.

It allows a planning platform to keep a familiar temporal modeling interface while exploiting a different solving backend. It supports richer operational features without forcing every domain engineer to manually encode PDDL+ dynamics. It also makes correctness auditable: the translation has a formal account, not just a collection of modeling recipes copied from an old project folder named final_final_really_final.

This matters because the next generation of business automation will not be limited by whether an AI assistant can produce a plausible plan. It will be limited by whether the plan remains valid after time, resources, deadlines, concurrency, and delayed effects have had their say. Those are not edge cases. They are the job.

Micheli, Scala, and Valentini do not offer a universal planning solver. They offer something more modest and more useful: a way to move temporal numeric planning into discrete PDDL+ while keeping the semantics intact. The experiments then show that this bridge can be practically valuable, especially when numeric and temporal reasoning are tightly coupled.

That is the kind of result business technologists should take seriously. Not because it removes complexity, but because it locates complexity in the right place.

The duration becomes a dynamic system. The dynamic system gets locks, clocks, events, and proof obligations. The planner gets a different route through the problem.

And the schedule, for once, may fail for a real-world reason rather than a modeling shortcut.

Cognaptus: Automate the Present, Incubate the Future.