Is total duration always the sum of action durations?

Only under appropriate sequential-execution assumptions. Overlap can make makespan smaller than that sum.

Can duration depend on the state?

Yes, if the planning model supports and defines such dependence.

Does a fast planner produce a short-duration plan?

Not necessarily. Computation time and the planned activities' elapsed time are different quantities and may be optimized separately.

AI Glossary / Graphs and symbolic AI / Intermediate

Duration

Definition

Duration is the amount of time an action or activity takes between its start and end. In temporal AI planning, duration helps determine when conditions must hold, when effects occur, and whether actions can overlap. It is different from how long the planning algorithm itself takes to compute a plan.

What it means

A plan that lists actions in a sensible order may still be impossible to schedule. Equipment can be occupied for several minutes, a resource may remain unavailable until an action finishes, or two independent activities may run together. Representing duration makes those temporal requirements explicit.
Some models assign each action a fixed duration. Others allow a range or compute duration from state variables, such as a distance and a specified speed. The meaning depends on the modeling language and domain. A planner's chosen duration should not be confused with a guarantee about uncertain real-world execution time.

How it works

A temporal model associates an action instance with a start time and an end time, whose difference gives its duration. It specifies requirements at relevant times, including conditions that must remain true throughout an interval, and defines effects at the appropriate points.
The planner combines these requirements with ordering and resource constraints. It can then test whether proposed overlaps are valid and evaluate objectives such as total completion time. In languages such as PDDL2.1, durative actions make temporal structure part of the formal model. The exact treatment of simultaneous endpoints and continuous effects must follow the language's semantics rather than informal assumptions about a timeline.

Three practical examples

A workshop planner assigns a machine to a task for its modeled processing duration before another task can use it.
A robot simulation represents a movement action as taking time, so later operations depend on arrival rather than merely on selecting the move.
A document-processing workflow schedules two independent preparation steps in parallel before a final step that requires both results.

Think of it this way

Think of calendar blocks whose widths show how long activities occupy time. Overlapping blocks can be acceptable when they use different resources, but impossible when both require exclusive use of one resource. The analogy is limited because a formal temporal plan also tracks changing conditions and effects; drawing nonoverlapping rectangles alone does not prove a plan valid.

Worked example

Consider three tasks with fixed durations. A takes four minutes, B takes three, and C takes two. C requires both A and B to finish. A and B have no dependency on each other and initially use different resources.
Starting A and B at time zero finishes them at times four and three. C starts at four and finishes at six, so the makespan is six minutes. The sum of durations is nine minutes, but that is not the elapsed completion time because A and B overlap.
Now suppose A and B require the same exclusive machine. They must run sequentially. Either order finishes both after seven minutes, and C then finishes at nine. This simplified scheduling example treats endpoints as compatible for immediate handoff, assumes no setup or travel time, and contains no uncertainty. A particular planning formalism may require explicit endpoint separation or additional constraints. The calculation shows how the same action durations can lead to different makespans when resource assumptions change.

Illustrative case study

At fictional Fern Workflows, an AI planning prototype estimates completion by adding every task's duration. Reviewers find independent tasks that can overlap and others that compete for one scanner. They replace the simple sum with a schedule that reflects those dependencies and resource intervals.
They keep estimated task durations separate from observed completion times so deviations can be examined later. This fictional case illustrates temporal modeling, without claiming a measured reduction in turnaround time or perfect prediction of real work.

Common misconceptions and mistakes

Duration is not start time, deadline, or makespan. Start time locates an action on the timeline, a deadline limits when a requirement must be met, and makespan measures overall plan completion under a chosen origin.
Do not assume two actions can overlap merely because neither explicitly precedes the other. They may compete for resources or interfere with each other's conditions. Conversely, a long action need not block every other activity. Deterministic durations are modeling assumptions; variable real execution may require monitoring, slack, contingent decisions, or replanning. The appropriate response depends on the application's uncertainty and commitments.

Business use

Businesses should document what each duration includes: active processing, waiting, setup, travel, or some defined combination. Use consistent units and distinguish estimates from guaranteed limits. Check shared resources and dependencies before presenting a completion forecast. Compare planned and observed intervals to improve the model, while retaining reasons for unusual cases. A plan with fewer actions can still take longer than a plan with more actions if their durations and overlap opportunities differ.

Check your understanding

Two independent tasks take five and eight minutes, can start together, and use separate resources. With no other constraints, when are both complete?

Answer: After eight minutes, the maximum of their durations. Adding them would incorrectly assume sequential execution in this example.

Related terms

Makespan
Scheduling
Resource constraint
Temporal planning
durative action
start time
end time
invariant condition

Learn next

Add a one-minute setup before task B in the worked example, requiring the same machine as B. Draw both the separate-resource and shared-resource schedules. State whether setup is included inside B's duration or represented as its own action, and avoid counting it twice.

Sources

Fox and Long, PDDL2.1: An Extension to PDDL for Expressing Temporal Planning Domains, original research: https://arxiv.org/abs/1106.4561 Fox and Long, original JAIR discussion of durative-action semantics: https://www.cs.cmu.edu/afs/cs/project/jair/pub/volume27/fox06a-html/node31.html

Previous: Durability (database systems) Next: Durbin test