Three things converged during my time at SCÖ, a Swedish coordination association for vocational rehabilitation, that set the direction for this series. Each pointed toward the same underlying question: what does it take to build a computational system that can reason about a complex service domain - and what happens when nobody does the work of answering that question before the system is deployed?
The Domain Engineering Problem
The first thing was a project plan built on premises that did not hold. SCÖ had secured funding to pilot the Pathway Generator - an algorithmic decision-support tool developed in Iceland for recommending rehabilitation interventions. I was employed as the service designer who would study and support its implementation. Except the Swedish context lacked the data infrastructure, governance frameworks, and technical capacity that the Icelandic system presupposed. There were no patient records in a form the algorithm could ingest. More fundamentally, there was little or no digital infrastructure, no data gathering processes or practices, and no governance frameworks or data sharing agreements that would support the use of this technology. There was no service catalogue tagged with compatible codes. The project had milestones, deliverables, and timelines - the form of planning - but the plan assumed a world that did not exist.
The second was the algorithm itself, and what it required. The Pathway Generator is a genetic algorithm: given a person's current situation (employment status, health conditions, prior interventions), it evolves candidate rehabilitation pathways across a fitness landscape, optimising toward a goal state (sustained employment, improved function). For the algorithm to operate in a new context, someone has to construct that context's formal domain - what counts as a relevant entity, what states are possible, what transitions or pathways are legitimate, what constitutes a goal. At SCÖ, none of this existed. The algorithm's computational requirements made legible what had been absent all along: the design work that would make such a system possible.
A PhD course in AI at Linköping University was teaching me, concurrently, to think about this design work in formal terms. The course covered planning as a computational problem, using languages like PDDL (Planning Domain Definition Language) where you define the objects that exist, the properties they have, the actions that can change them, and the goals you are trying to reach. PDDL makes the domain engineering problem visible with unusual clarity because the domain file is a separate, inspectable artefact: you can read it and see exactly what ontological commitments the system is making. But the structural requirement is not specific to PDDL or to classical planning. The Pathway Generator's evolutionary approach encodes the domain differently - as fitness functions, chromosome structures, selection criteria - but the underlying design problem is the same: someone has to decide what to represent, at what granularity, through which formalism, for whose purposes.
This problem - the design work of constructing the representational infrastructure that computational systems presuppose - is what the software engineering literature calls domain engineering. Jackson (2021, p. 20) traces the term to Dines Bjørner, who "placed such emphasis on domain modeling that he referred to it as 'domain engineering'", and connects it through Evans's Domain Driven Design to the broader recognition that software design begins with constructing a model of the problem domain, not with implementing a solution. Russell and Norvig (2021, p. 12) describe the same activity under the heading of "knowledge engineering": a process of identifying the task, assembling relevant knowledge, deciding on vocabulary, encoding general knowledge about the domain, and encoding the specifics of any given problem instance. Burns and Hajdukiewicz (2017) call it work domain analysis - systematic modelling of the constraint structures that shape how work actually functions. These are different disciplinary names for the same design challenge: getting domain knowledge into a form that a computational system can use. As Mylopoulos (1980, p. 1) observed over four decades ago, knowledge representation "is a central problem in Artificial Intelligence" precisely because the design paradigm for intelligent systems requires expert knowledge to be in the system, and getting it there is not a trivial matter of transcription but a sustained act of design.
The third convergence was my position as a service designer caught between these two problems - expected by different stakeholders to be variously a miracle worker, a technical fixer, an evangelist for innovation - and increasingly aware that the work I was actually doing bore little resemblance to what anyone had planned for. I spent some months reverse-engineering the Pathway Generator's requirements, conducting a form of algorithm archaeology and applying the discipline of strong typing to its data structures, documenting the gaps between what had been promised and what was possible, producing concept maps and process diagrams that made things visible. The technoimaginary held together at high abstraction; the closer I looked at the material conditions, the more it dissolved.
What Domain Engineering Presupposes
The PDDL formalism is useful here not as the series' governing paradigm but as a diagnostic vocabulary - a way of making explicit what all computational systems require, whether or not they require it in PDDL's particular form. The course materials put the problem directly:
"Compact descriptions of state spaces serve as input to algorithms... algorithms directly operate on compact descriptions which allows automatic reasoning about the problem: reformulation, simplification, abstraction".
The formalism presupposes a great deal. The state space must already be defined: someone has to have specified what counts as a "state", what variables matter, what values they can take, what configurations are possible. The actions must be enumerable: there must be a finite set of action schemas with defined preconditions and effects. And the goals must be specifiable: someone must be able to describe, in the language of the domain, what they are trying to achieve. The algorithm navigates the state space but does not construct it; it chooses between actions but does not invent them; it optimises toward goals but does not discover what the goals should be.
These presuppositions are not unique to classical planning. A genetic algorithm needs a fitness landscape, which presupposes that someone has defined the variables, the value ranges, and the fitness function. A reinforcement learning agent needs an environment specification - observation space, action space, reward function - which presupposes that someone has decided what the agent can perceive, what it can do, and what counts as success.
A large language model trained on clinical text has learned an implicit domain model from its training data, but that training data embodies ontological commitments - which records were included, how conditions were coded, what counted as an outcome - that someone made, whether deliberately or by default. Agentic systems built on top of these models reintroduce the same structural requirements in yet another form: tool schemas define what actions the agent can take, retrieval configurations determine what knowledge is accessible, prompt architectures specify what the system attends to and how it reasons.
Service design's own representational tools make analogous presuppositions, though they are rarely examined in these terms. A journey map presupposes that the service can be decomposed into discrete steps experienced sequentially by a single user; a service blueprint presupposes a clean separation between frontstage and backstage activities with defined lines of visibility and interaction; a service ecology map presupposes that the relevant actors, relationships, and value flows can be identified and bounded. Each of these representations embodies ontological commitments about what a service is - what entities matter, what sequences are possible, where the boundaries fall - that shape what designers can reason about and what remains invisible. In the vocational rehabilitation context at SCÖ, this mattered directly: the service involved overlapping institutional jurisdictions, contested definitions of progress, and outcomes that unfolded over months or years across multiple agencies. No single journey map could capture the concurrent, multi-actor, temporally distributed character of rehabilitation as a process; the representational form itself foreclosed certain kinds of understanding. The point is not that these tools are inadequate - they serve important communicative and analytical purposes - but that they, like PDDL domain files and genetic algorithm fitness functions, encode particular ways of seeing the domain, and those encodings have consequences for what can subsequently be designed or computed or the politics and how power is transacted in those domains.
In every case - whether the domain specification takes the form of a PDDL file, a fitness landscape, a training corpus, an agentic tool schema, or a service blueprint - the system operates within a representational commitment that it did not create. The form of that specification varies across paradigms; the design problem of creating it does not.
Guarino (2002, p. 3) argues that this design problem has an irreducibly ontological dimension: choosing a representation language and populating it with terms is simultaneously making claims about what exists in the domain, what categories are meaningful, what relationships hold. Every representational choice is what Guarino calls an "ontological commitment" - not merely a technical convenience but a substantive claim about the structure of the domain. Heylighen (1988, p. 1) makes the complementary point that constructing a representation is constructing "a system of distinctions, hierarchically organized" - it is the problem of problem-formulation itself.
Flach and Voorhorst (2019, p. 29) bridge these philosophical arguments to the ecological interface design tradition by arguing that "an important goal for design is to construct representations that help to specify smart actions with respect to the functional objectives of the work domain" - whether through training (constructing internal representations, as neural networks do) or through interface design (constructing external representations, as PDDL domain files do). The distinction between internal and external representations maps onto the difference between learned domain models (opaque, distributed, implicit) and engineered domain models (inspectable, explicit, contestable) - and this distinction, as the series will argue, matters for who can participate in the design.
Complexity, Reduction, and the Problem Domain
None of this should be surprising from a systems thinking perspective. The literature on complexity and wicked problems - Rittel and Webber's (1973) observation that the formulation of a wicked problem is the problem, Bronfenbrenner's (1979) nested ecological systems, Checkland's (1981) insistence that human activity systems resist the kind of clean decomposition that formal methods require - has long established that real-world service contexts do not reduce neatly to enumerable states and transitions. The Pathway Generator's domain engineering requirements are not just technically demanding. They are ontologically presumptuous - they assume that vocational rehabilitation can be adequately represented as a set of discrete states, transitions, and goals, when in practice it involves contested meanings, overlapping institutional jurisdictions, biopsychosocial complexity, and outcomes that different stakeholders define in incompatible ways.
But algorithmic systems require formal domain specifications - that is what makes them computationally tractable. And they will be built regardless. Russell and Norvig (2021, p. 14) observe that in "toy" domains the choice of representation is not that important, but "complex domains such as shopping on the Internet or driving a car in traffic require more general and flexible representations". Occupational rehabilitation is not a toy domain. The question is not whether to formalise but who participates in the formalisation, what gets included, what gets excluded, and whether the reduction is made consciously or by default. A domain model is always a simplification. Whether it is a deliberate simplification - informed by contextual understanding of what the reduction costs - or an accidental one, where the constraints of the formalism quietly determine what the system can see, depends on whether anyone with that contextual understanding is involved in constructing it.
Planning and Design as Distinct Cognitive Activities
The distinction between planning and design has been articulated in several traditions. In design theory, it connects to Rittel and Webber's wicked problems and to Schön's (1983) reflective practice. In systems thinking, it connects to the difference between first-order problem solving (optimising within given constraints) and second-order inquiry (questioning what the constraints should be). The most operationally precise articulation I have encountered comes from the military design movement - traced by Jackson (2019) and Zweibelson (2023) through systemic operational design and its subsequent doctrinal adoption - which emerged from operational environments that resisted conventional planning approaches. But the stakes involved in getting the cognitive mode wrong are not unique to military contexts. Healthcare - the domain where I have spent most of my working life - demands comparable rigour. As Jones (2013) observes, healthcare environments "require the use of far more rigorous design and development methods than the contemporary trend in user experience and service design" (2013, p. 11), precisely because the consequences of poor design decisions extend to patient harm. The human factors and cognitive work analysis traditions, developed originally for nuclear power and subsequently applied across healthcare, aviation, and military systems (Stanton and Salmon, 2017), recognise all of these as safety-critical domains where the relationship between formal domain modelling and operational performance is not academic but consequential. The U.S. Army / Marine Corps Counterinsurgency Field Manual (2006) offers a useful articulation of the distinction:
"While both [design and planning] seek to formulate ways to bring about preferable futures, they are cognitively different. 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. In general, planning is problem solving, while design is problem setting".
Planning is problem solving - working within an accepted framework. Design is problem setting - constructing the framework itself. Translated into the domain engineering vocabulary: planning operates within a domain model; design constructs one. The distinction is not about complexity or difficulty; it is about whether the representational infrastructure exists yet.
The manual's second observation is equally relevant:
"When situations do not conform to established frames of reference - when the hardest part of the problem is figuring out what the problem is - planning alone is inadequate and design becomes essential. In these situations, absent a design process to engage the problem's essential nature, planners default to doctrinal norms; they develop plans based on the familiar rather than an understanding of the real situation".
The SCÖ project defaulted to exactly this pattern. It had a plan but no domain model within which that plan could operate; planning was applied to a domain nobody had mapped or understood, and it got nowhere. Meanwhile, the project milestones were quietly redefined as original goals proved unachievable, and the performance of innovation - meetings held, reports filed, workshops facilitated - substituted for the substance of it. The question of why this happened - whose interests the absence of domain engineering work served, and what institutional pressures made planning-without-framework not just tolerable but preferable - is one this series will attend to in due course.
What This Opens Up
The convergence at SCÖ - algorithmic requirements that revealed technoimaginary assumptions about data readiness and institutional capacity, programme leadership that had little grasp of the complexities of data work, and a designer positioned at the intersection who had not been involved in the original project planning and was expected to be the glue holding these disparate assumptions together - raised questions that extend well beyond a single failed project.
Where do domain models come from? In classical AI planning, the domain definition is treated as given - the PDDL file arrives fully formed, and the planner's job is to navigate within it. But this is a pedagogical simplification; in practice, even in classical AI, the knowledge engineering process of constructing the domain file is where the substantive design decisions are made (Russell and Norvig, 2021, p. 12). In machine learning the domain model is inferred from data; in evolutionary approaches it is encoded in fitness functions and chromosome structures; in large language models it is distributed across training data curation, fine-tuning objectives, retrieval configurations, and tool schemas. In each case someone has made consequential choices about what to represent and how.
In organisations, in services, in complex social systems, these questions become harder still - who defines what states are possible? How do those definitions get constructed? What gets included and excluded, and by whom?
On the field manual's account - design as problem setting, planning as problem solving - design is logically prior to planning. The domain model has to exist before navigation within it becomes meaningful. But the field manual's clean separation is a particular conception of design, rooted in the systemic design and military design traditions, and it deserves some reflection. Dubberly (2022) argues that framing design as problem solving at all - even as a complementary counterpart to planning - misrepresents the activity; in practice, "the process of designing leads to the discovery of both alternative means and alternative goals", which means design is not just setting the problem for planning to solve but continuously reframing what the problem is. And Drummond (2021) identifies the more common organisational reality: "by the time we turn our attention to the 'user experience' of the service we are designing, we are often limited in scope because of decisions that were made long before we started". Design rarely arrives with the authority to construct the domain model; it arrives after the plan has been drawn up, the funding secured, the commitments made - and is expected to operate within constraints it had no role in shaping, sometimes by people whose understanding of the problem domain is partial or oversimplified.
What matters here, then, is not the theoretical priority of design over planning but the structural observation that follows from it: organisationally, culturally, institutionally, the work of constructing the domain model is often not recognised as real work. The "real work" is planning and delivery. The consequence is that the most foundational decisions - how the problem domain is understood and represented, what Guarino (2002) would call the ontological commitments - get made implicitly, by whoever happens to be building the system or structuring the programme, or securing its funding.
There is a further dimension here that is worth marking, even if it requires fuller treatment later in the series. The choice of formalism is not a neutral technical decision. The Pathway Generator's evolutionary approach encodes rehabilitation as a population of candidate solutions evolving toward better fitness; a Bayesian network would model it as probabilistic inference over conditional dependencies; a reinforcement learning agent as policy learning from accumulated reward signals; a large language model as pattern completion over clinical text. Each formalism makes different aspects of the domain visible and renders others invisible. Each encodes different assumptions about what rehabilitation is and what kinds of knowledge count as formally representable. The choice shapes what questions get asked, what aspects of the domain become visible, and whose understanding of rehabilitation gets privileged. As the series will argue through engagement with Burns and Hajdukiewicz's (2017) work domain analysis, Gärdenfors's (2000) conceptual spaces, and the formalisation-and-reification problem, these representational choices are simultaneously epistemic (what can be known), political (whose knowledge counts), and practical (what the system can do).
There is also the question of what happens when domain engineering work reveals that the plan is impossible. This is what my concept mapping at SCÖ did. It made visible that the preconditions for the plan did not exist and the likelihood of building enough infrastructure to even prototype a service were limited, or would take a long time. The organisational response - acknowledged but not engaged - is worth examining in its own right.
Why This Matters for Service Design
The questions above - about where domain models come from, about the relationship between planning and design, about what happens when formal representational requirements meet institutional reality - are not only relevant to my experience at SCÖ. They point toward a challenge that service design as a discipline has not yet adequately addressed.
Public services are increasingly shaped by algorithmic and agentic systems. The Pathway Generator at SCÖ was one example, but the same structural requirements operate in risk scoring systems that allocate resources, triage tools that prioritise cases, and the generative and agentic technologies now entering public service delivery. All of these systems presuppose representations of the domains they operate in - entities with properties, states with transitions, events with preconditions and effects - whether those representations are engineered explicitly (as in a PDDL domain file or a knowledge graph schema), inferred from data (as in a machine learning pipeline), or distributed across configurations (as in an agentic system's tool definitions and retrieval architecture). Someone has to construct or interrogate those representations. These are design decisions of the first order; they determine what the system can see, what it can reason about, and what it renders invisible.
Service design has a rich practice tradition for understanding how people experience services, how organisations deliver them, and how both could work better. But the discipline's representational toolkit - journey maps, blueprints, service ecologies - was developed for a different purpose. These tools foreground actions, experiences, and touchpoints. They do not readily express the ontological commitments that computational systems require: what entities exist, what properties they have, how those properties change over time, and what constitutes a legitimate transition between states. When service designers cannot participate in these foundational questions, the most consequential design decisions get made elsewhere - by data scientists choosing features, by engineers defining schemas, by product managers specifying business rules - often without the contextual understanding that design practice provides.
This series is an attempt to build the conceptual infrastructure that would allow service design to engage with these questions - to participate in domain engineering for complex service contexts. It proceeds in layers. The first is ontological: what are public services fundamentally about, what kinds of objects do they engage with, what events change those objects, and how do different traditions - cognitive science, information systems, philosophy, social theory - define these categories? The second is representational: how can these ontological categories be formally expressed, whether through Gärdenfors's conceptual spaces as a geometric framework for meaning, Harel's statecharts as a visual formalism for reactive systems, or the underlying mathematical structure of state spaces? The third is grammatical: what compositional systems - Wilkinson's Grammar of Graphics, Iqbal's service grammar built on Promise Theory, Frost's Atomic Design - allow complex service architectures to be described, analysed, and constructed? A companion series on Language, Frames, and Domain Understanding extends this grammatical layer into the linguistic structures - case grammar, frame semantics, verb-noun distinctions - that shape how services are described and how computational systems parse those descriptions. And the fourth layer is critical: what are the limits and politics of formalisation itself, and what happens when the messy, contested, contextual reality of public services meets the demands of formal representation?
The series draws throughout on what I experienced at SCÖ as empirical material for understanding how domain engineering work operates (and fails to operate) at the boundary between institutional practice and algorithmic reasoning.
The ambition is not to resolve these questions but to equip service designers - and the interdisciplinary teams they work within - with a richer conceptual vocabulary for engaging with the formal and ontological commitments that algorithmic and agentic systems require. If design is to have a substantive role in shaping how public services integrate with these technologies, rather than being confined to the interface layer after the consequential domain engineering decisions have already been made, it needs this kind of infrastructure.
Next: "Objects, Entities, and Things: What Services Act Upon" - what counts as an "object" in the context of public services, and why the answer matters for domain modelling.
References
Bronfenbrenner, U. (1979). The Ecology of Human Development: Experiments by Nature and Design. Harvard University Press.
Burns, C.M. and Hajdukiewicz, J.R. (2017). Ecological Interface Design. CRC Press.
Checkland, P. (1981). Systems Thinking, Systems Practice. Wiley.
Drummond, S. (2021). Full Stack Service. Snook.
Dubberly, H. (2022). Why we should stop describing design as "problem-solving". Dubberly Design Office.
Flach, J.M. and Voorhorst, F. (2019). What Matters? Putting Common Sense to Work. Wright State University.
Gärdenfors, P. (2000). Conceptual Spaces: The Geometry of Thought. MIT Press.
Guarino, N. (2002). Formal ontology, conceptual analysis and knowledge representation. International Journal of Human-Computer Studies, 43(5-6), 625-640.
Heylighen, F. (1988). Formulating the problem of problem-formulation. In R. Trappl (Ed.), Cybernetics and Systems '88. Kluwer Academic.
Jackson, A.P. (2019). A brief history of military design thinking. The Bridgehead.
Jackson, D. (2021). The Essence of Software: Why Concepts Matter for Great Design. Princeton University Press.
Jones, P.H. (2013). Design for Care: Innovating Healthcare Experience. Rosenfeld Media.
Mylopoulos, J. (1980). An overview of knowledge representation. ACM SIGMOD Record, 11(4), 1-11.
Rittel, H.W.J. and Webber, M.M. (1973). Dilemmas in a General Theory of Planning. Policy Sciences, 4(2), 155-169.
Russell, S.J. and Norvig, P. (2021). Artificial Intelligence: A Modern Approach (4th ed.). Pearson.
Schön, D. (1983). The Reflective Practitioner: How Professionals Think in Action. Basic Books.
Stanton, N.A. and Salmon, P.M. (2017). Cognitive Work Analysis: Applications, Extensions and the Future. CRC Press.
U.S. Army/Marine Corps (2006). The U.S. Army/Marine Corps Counterinsurgency Field Manual (FM 3-24). University of Chicago Press.
Zweibelson, B. (2023). Understanding the Military Design Movement: War, Change and Innovation. Routledge.