The previous posts built up conceptual foundations: conceptual spaces, state spaces, promises, grammars, statecharts, service states, and boundary objects. Now we can address the question that started this series: what is planning, and how does it relate to design?
This post takes a computational view. In AI, planning has a precise meaning: finding a sequence of actions that transforms an initial state into a goal state. The value of examining this formalism in detail is not that service design should become computational but that PDDL - the Planning Domain Definition Language - provides the clearest illustration of what domain engineering involves, because it forces every design decision to be explicit. The domain file is a separate, inspectable artefact; you can read it and see exactly what ontological commitments the system is making. This transparency makes it a useful diagnostic vocabulary for understanding what all computational systems require, whether or not they require it in PDDL's particular form.
The Planning Problem
In AI, a planning problem consists of a state space (all possible configurations the world can be in), an initial state (where we are starting from), a goal state or goal condition (where we want to get to), and actions (operations that transform one state into another). The planning problem is: given these inputs, find a sequence of actions - a plan - that leads from the initial state to a state satisfying the goal.
This is search. The state space is (implicitly) a graph. States are nodes. Actions are edges. Planning is finding a path from the initial node to a goal node. The elegance is that once you have formalised the problem this way, algorithms can solve it. You do not need to manually figure out the sequence of actions; you specify the problem, and the planner computes the solution.
PDDL: A Language for Planning
PDDL - the Planning Domain Definition Language - is the standard formalism for specifying planning problems. It separates the problem into two parts. The domain specifies what kinds of things exist and what kinds of actions are possible - the general structure that applies to any problem in this domain. The problem specifies what specific things exist, what the initial state is, and what the goal is - a particular instance of the domain.
The domain file specifies types (categories of objects such as block, location, robot), predicates (properties and relations such as on(x, y), clear(x), holding(x)), and actions (operations with preconditions and effects). An action schema specifies what must be true for the action to apply and what changes as a result: to pick up a block, it must be clear with nothing on top, on the table, and the robot arm must be empty; after picking up, we are holding the block, it is no longer on the table, and it is no longer clear. The problem file specifies the specific objects that exist, the initial state (what is true at the start), and the goal (what we want to be true). Given these specifications, a PDDL planner searches for an action sequence that achieves the goal.
What Planning Presupposes
The domain file is not a planning problem. It is a design artefact. The planner finds paths through a state space. But someone had to construct that state space first. Someone had to decide what objects exist - and in the blocks world, we model blocks but not the table's material, the room's temperature, or the robot's battery level; these exclusions are not neutral, as they determine what the planner can reason about. Someone had to decide what properties matter - the predicates define the vocabulary for describing states, and the choice of predicates shapes what distinctions the planner can make. Someone had to decide what actions are possible - which actions to include, what preconditions to require - and these are design choices that shape what plans are possible. And someone had to decide what the goal is - framing goals requires having the predicates to express them, so if "stability" is not a predicate, you cannot specify "make the structure stable" as a goal.
The planner takes all this as given. It is input. The planner's job is to search efficiently, not to question whether the domain is well-specified. But for real-world problems, the domain specification is the hard part. The blocks world has a natural, obvious structure. Vocational rehabilitation does not.
The Blocks World vs. The Real World
The blocks world is a classic planning domain because it is simple enough to be tractable but complex enough to illustrate key concepts. The domain has a small, fixed set of object types, a small, fixed set of predicates, a small, fixed set of actions, and clear, deterministic effects. These properties make the domain amenable to automated planning. The state space is large but structured. The actions are well-defined. The physics is simple. Real-world domains have none of these properties.
Consider vocational rehabilitation - the domain I was supposed to be working in at SCÖ. What would a PDDL domain look like? What are the objects? Patients, but patients are not uniform - they have different conditions, capacities, histories. Services, but services vary by provider, by region, by eligibility criteria. Caseworkers, employers, benefits - the object ontology is not obvious. What properties and relations matter? There is no standard vocabulary, and different stakeholders would propose different predicates. What are the interventions, and what are their preconditions and effects? This is contested, uncertain, context-dependent. What is the goal state? "Employed" sounds simple, but employed where, for how long, at what quality of life, with what accommodations? The goal is multidimensional and value-laden.
The blocks world has a domain because someone designed one. It is a toy domain precisely because it is simple enough to specify completely. Real-world domains resist this kind of specification.
The Hidden Design Work
This is the point I keep returning to: planning presupposes a domain model, and constructing that model is domain engineering - the design work of building the representational infrastructure that the computational system requires.
In AI courses, the domain is provided. Students learn to write problem files and invoke planners. The domain file is just there - part of the exercise setup. The intellectual challenge is in the algorithm, not the ontology. In real-world applications, the domain is the challenge. Before you can plan, you need to answer what you are modelling, what entities matter, what properties distinguish one state from another, what actions are possible and under what conditions, and what counts as success. These questions do not have algorithmic answers. They require judgment, negotiation, expertise, values. They are design questions.
The TDDC17 course I mentioned in the first post taught planning algorithms. It did not teach domain engineering - what Russell and Norvig (2021, p. 12) call "knowledge engineering" - the process of constructing domain models from messy real-world situations. That is a different skill, and it is the skill that is needed when computational systems of any kind are applied outside of toy domains.
Planning as Navigation
Planning is navigation within a state space. Given a map (the domain), a starting point (initial state), and a destination (goal), the planner finds a route. The planner is a navigator. It is very good at finding paths - optimal paths, efficient paths, paths that avoid obstacles. But the navigator does not draw the map. The map has to exist before navigation can begin.
Domain engineering is cartography - constructing the map. Before you can navigate, someone has to decide what the terrain looks like: what are the landmarks (objects), what are the paths (actions), what are the passable routes (valid transitions), what areas are off-limits (preconditions not met). This cartographic work is invisible in planning formalisms because the formalism assumes the map is given. But in practice, the map is the hard part.
Judea Pearl's work on counterfactual reasoning sharpens this point. Pearl showed that planning requires the capacity to imagine alternatives - to ask "what would happen if I did differently?" - and that this capacity requires a causal model that cannot be derived from data alone (Pearl and Mackenzie, 2018). The planner's domain file is that causal model: it specifies what entities exist, what actions change what, what effects follow from what causes. In an earlier post on counterfactual thinking, I explored Pearl's Ladder of Causation - the distinction between seeing (observing patterns), doing (predicting effects of interventions), and imagining (counterfactual reasoning). Planning operates at all three levels, but the domain that makes planning possible requires the third: the capacity to imagine a state space that does not yet exist in data.
Beyond Classical Planning
The picture above describes classical planning - explicit state spaces, deterministic actions, PDDL domain files. But not all computational approaches to finding good solutions work this way. Several alternatives bear directly on this series, because they appear to sidestep the domain engineering problem that the opening post identified as the series' central subject - and in doing so, reveal it from a different angle.
The JANUS Pathway Generator - the system I was supposed to be helping adapt for Sweden at SCÖ - is not a classical planner. It is a predictive model. Where classical planning searches for action sequences through a state space, the Pathway Generator uses Random Forest classifiers to predict rehabilitation outcomes from patient data (Haraldsson, Brynjolfsdottir and Woodward, 2017). Each patient is represented as a vector of health, psychological, and employment variables; the system then predicts the likelihood of successful rehabilitation, dropout probability, and expected treatment length. A Genetic Improvement layer uses evolutionary strategies - population-based search with selection and mutation - to continuously improve the predictor software itself as new outcome data arrives (Haraldsson et al., 2018). The evolutionary computation operates on the model rather than on candidate rehabilitation pathways; the system predicts which patients will benefit from which interventions, rather than evolving novel pathway combinations through a generative search.
There is no explicit state space here, no action schemas with preconditions and effects, no goal condition. The planning problem has been recast as a prediction problem. But the design work has not disappeared - it has shifted. Someone had to decide what goes in the patient vector, and as I documented in the earlier data archaeology, even identifying what the variables were required substantial investigation: two different depression measures appeared without explanation, and the relationship between raw data, standardised instruments, and vector dimensions was nowhere documented. Someone had to define the outcome variable - what counts as successful rehabilitation, over what timeframe, by what measure. Someone had to specify the service vector - what interventions exist, how they are categorised, what combinations the system should consider. The model predicts; the design work determines what it predicts and from what.
Reinforcement learning agents appear to sidestep the domain engineering problem from yet another direction. An RL agent learns a policy - a mapping from states to actions - through interaction with an environment, accumulating reward signals that guide it toward effective behaviour. No one writes a domain file; the agent discovers its own state representations through experience. This is genuinely different from classical planning. But the domain engineering has not disappeared; it has moved. Someone has to design the environment: what the agent can observe (the observation space), what it can do (the action space), what counts as success (the reward function), and what counts as an episode boundary. The observation space is a state-space definition by another name - it determines what the agent can perceive and therefore what it can reason about. The reward function is a goal specification - it encodes what success looks like and whose values determine that definition. The action space enumerates available transitions. An RL agent that learns to optimise rehabilitation pathways would need someone to define what patient observations are available, what interventions the agent can recommend, and what outcome metric the reward function optimises. These choices are consequential, contested, and require exactly the kind of domain understanding that the classical planning vocabulary makes explicit.
Large language models appear to dissolve the domain engineering problem altogether. You do not write a PDDL file or define a fitness function - you describe the situation in natural language and the model generates a plan. For something like rehabilitation, you would describe the patient's circumstances, the available services, and the desired outcome, and the model would propose a pathway.
This does not bypass the design work. It conceals it. The model's implicit "domain" is whatever patterns exist in its training data - which patients got which services, what professionals wrote in case notes, what the literature recommends. This implicit domain has all the properties of an explicit one (objects, predicates, actions, goals) but none of them are inspectable or negotiable. You cannot examine the model's assumptions about what variables matter, what transitions are possible, or what success looks like - not in the way you can examine a PDDL domain file or a patient vector specification. And the consistency and rigour of the text representations of descriptions of the notes is what determines the effectiveness of the model.
The domain engineering problem resurfaces in specific and identifiable ways across the LLM stack. In retrieval-augmented generation, someone must decide which documents to index, how to chunk them, what embedding model to use, and how to ground the model's output in retrieved context - each a domain engineering decision about what knowledge counts and how it is structured. In fine-tuning, someone curates the training examples that will shape the model's behaviour in a specific domain, and the selection of those examples embodies assumptions about what the domain is and what competent performance looks like. In prompt engineering, the prompt itself functions as a lightweight domain specification - it tells the model what roles exist, what constraints apply, what format to use - and poorly specified prompts produce the same problems as poorly specified PDDL domains: ambiguous states, missing preconditions, underspecified goals.
Agentic systems - tool-using LLMs, workflow orchestration, MCP-based architectures - make this most explicit. An agent needs to know what tools exist, what parameters they accept, what states they produce, and what sequences of tool use accomplish goals. The tool schema is a domain file in contemporary form: it specifies the actions available, their preconditions (required parameters, authentication, access), and their effects (what the tool returns, what state changes). An MCP server definition that describes a database query tool with typed parameters and structured outputs is doing the same work as a PDDL action schema that specifies preconditions and effects - but it is distributed across configuration files, API specifications, and system prompts rather than collected in a single inspectable domain file. The domain engineering problem is the same; the legibility is worse.
The difference between classical planning and these modern approaches is not that one requires domain engineering and the others do not. It is that classical planning makes the domain engineering visible and inspectable - the domain file is a separate artefact that can be examined, contested, and revised - while modern approaches distribute it across training data pipelines, reward function specifications, prompt templates, tool schemas, and embedding configurations, making it harder to see, harder to contest, and harder to redesign. For the question this series is building toward - bridging human and computational representation of services - this opacity matters. The geometric alignment between conceptual spaces and embedding spaces requires being able to inspect both. The design work has not been eliminated by any of these approaches; it has been performed at different points in the stack, often invisibly, by whoever curated the training data, designed the reward function, wrote the prompt template, or configured the tool schema. Whether that invisible design reflects the domain as any particular set of stakeholders would recognise it is precisely the kind of question classical planning formalisms force you to ask - and that modern systems allow you to avoid.
Implications for Service Design
Most service design operates without explicit state space models. Journey maps and blueprints are sketches, not PDDL domains. They do not enumerate all possible states. They do not specify preconditions and effects. They do not define what actions are possible. This informality has both benefits and costs. The benefits include flexibility, accessibility, room for ambiguity that supports creative exploration, and a low bar for entry - you do not need to nail everything down before you can have useful conversations. The costs emerge when it is time to implement: developers need to know exactly what states are possible, systems need to know what actions are valid, and the informal sketch does not provide this, so implementers fill in the gaps with their own assumptions or the constraints the systems or platforms impose, which may not match the designers' intent.
What would it look like to apply planning thinking to services? First, you would need a domain - a specification of what entities the service involves, what properties describe their states, what actions can occur and under what conditions, and what transitions result from those actions. This is the work Iqbal's 16x frame begins to do: it provides a vocabulary and a structure, but it does not go all the way to executable specification. Second, you would need problems: specific customers in specific initial states with specific goals. The planner could then compute service paths - sequences of touchpoints, interventions, actions that move the customer from initial state to goal. Third, you would need to handle uncertainty. Real services are not deterministic like the blocks world. Actions might fail. States might be uncertain. This requires probabilistic planning or contingent planning - more sophisticated formalisms than classical PDDL.
Is this practical? For some services, maybe. Highly structured services with clear states and transitions might benefit from formal planning approaches. For others, the overhead of formal specification might not pay off. But even without full formalisation, planning thinking offers a useful lens. It forces you to ask: what is the state space? What are the actions? What are the preconditions? These questions clarify design even if you never write a PDDL file.
This post has presented planning as a computational problem: navigation within a state space. The key insight is that planning presupposes a domain - and constructing that domain is design work. The next post examines how this insight emerged in a very different context: military operations. The US military, confronting complex environments that resisted traditional planning approaches, developed a distinction between planning and design that resonates with the computational view: "Planning applies established procedures to solve a largely understood problem within an accepted framework. Design inquires into the nature of a problem to conceive a framework for solving that problem".
Next: "Planning vs Design" - how the US military came to distinguish design from planning, and why it matters.
References
Haraldsson, S.O., Brynjolfsdottir, R.D. and Woodward, J.R. (2017). The use of predictive models in dynamic treatment planning. In Proceedings of the Genetic and Evolutionary Computation Conference Companion. ACM.
Haraldsson, S.O., Brynjolfsdottir, R.D., Gudnason, V., Tomasson, K. and Siggeirsdottir, K. (2018). Predicting changes in quality of life for patients in vocational rehabilitation. In Proceedings of the IEEE Congress on Evolutionary Computation. IEEE.
Haslum, P., Lipovetzky, N., Magazzeni, D. and Muise, C. (2019). An Introduction to the Planning Domain Definition Language, Morgan & Claypool Publishers
McDermott, D. et al. (1998). PDDL - The Planning Domain Definition Language. Technical Report, Yale Center for Computational Vision and Control.
Pearl, J. and Mackenzie, D. (2018). The Book of Why: The New Science of Cause and Effect. Basic Books.
Russell, S.J. and Norvig, P. (2021). Artificial Intelligence: A Modern Approach (4th ed.). Pearson.