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. This precision is illuminating - not because service design should become computational, but because the formalism makes explicit what planning presupposes.
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, and constructing a domain is design work.
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 - how to construct domains from messy real-world situations. That is a different skill, and it is the skill that is needed when planning techniques 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.
Design 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. Two alternatives bear directly on this series, because they appear to sidestep the domain engineering problem - 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.
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.
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. Generative AI makes the computational space a black box. The design work has not been eliminated; it has been performed invisibly by whoever curated the training data and built the model. 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 generative 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. and Norvig, P. (2020). Artificial Intelligence: A Modern Approach (4th ed.). Pearson.