The previous post explored state spaces geometrically - as coordinate systems with dimensions, where trajectories trace paths through abstract space. This post approaches state spaces from a different angle: topologically, as graphs. The shift matters because each representation reveals something different about the same underlying structure.
Russell and Norvig's textbook, which I worked through during the AI course at Linköping University, presents this transition plainly: "The state space can be represented as a graph in which the vertices are states and the directed edges between them are actions". It's a straightforward move, but a consequential one - where the geometric view emphasises continuous trajectories and distance, the graph view emphasises connectivity and the discrete actions that move between states. Each is valid; each conceals as much as it reveals.
Graphs as Relational Formalisms
A graph is the simplest formal structure that preserves relational information while discarding everything else. Two nodes, one edge. That's all a graph requires. The geometry doesn't matter - whether the nodes are close together or far apart on a drawing has no meaning in the graph itself. What matters is which nodes are connected to which, and in what direction.
This simplicity is also what gives graphs their computational power. Most systems that handle networked data - from citation indices to neural networks to relational databases - represent that data as graphs internally. It's not a metaphor. When you store information about who knows whom, or which states can be reached from which other states, or how different services interact, you're building a graph structure. The formalism directly mirrors the structure you're trying to represent.
In a directed graph, edges have direction. An action moves from state A to state B, not bidirectionally. If you weight the edges - assigning numbers to them - you can represent costs, probabilities, or capacities. If you add attributes to nodes and edges themselves, you get what's called a property graph, where a node representing a "customer" might carry attributes like name, age, service history; an edge representing "uses" might carry attributes like frequency, satisfaction, duration. This is still a graph, but a richer one.
A graph is a data structure - it's how relational information gets stored and processed computationally. Representing something "as a graph" is not a metaphor but a formal commitment about what information we're keeping and what we're discarding.
From Flat Graphs to Hierarchical Ones
But most real systems aren't flat - they have structure within structure. Services involve sub-services, states contain sub-states, and multiple processes may occur in parallel. A flat graph loses all of this.
David Harel introduced higraphs in the 1980s precisely to address this problem. A higraph is a graph extended with two additional properties. First, depth - the capacity for containment and hierarchy. One node can be inside another. Second, orthogonality - the ability to represent concurrent, independent subsystems. The formalism is sometimes summarised as: Higraph = Graph + Depth + Orthogonality.
What makes Harel's work particularly relevant to service design is how he framed it. He called higraphs "topo-visual formalisms", emphasising that the approach preserves "non-metric topological connectedness as opposed to pure geometric distance". This is the inverse of what geometry offers: where geometry says distance matters, topology says only connectivity matters - which nodes are reachable from which other nodes, without regard to how far apart they appear on a diagram. For representing service systems, where what matters is who can interact with whom, and whether processes can overlap, this topological orientation is more appropriate than geometric precision.
Service Design's Constrained Representations
Service design has well-established tools for representing services - the customer journey map and the service blueprint are the dominant ones, ubiquitous in practice. In a formal sense, both are degenerate graphs.
A service blueprint organises information into horizontal swimlanes - one for the customer, one for front-stage staff, one for back-stage processes, one for support systems. Within each lane, activities are listed, often chronologically. The connections between swimlanes show where actors interact. This is a graph, but a constrained one. The partition into fixed swimlanes imposes a kind of hierarchy - but a very specific, shallow one. It prevents you from representing deep nesting (a sub-service within a service within a larger system). It suppresses orthogonality - concurrent processes that aren't neatly aligned can be hard to show. Most critically, it collapses the full relational structure. A service blueprint flattens what could be a complex network of interactions into a linear sequence within constrained boundaries.
Journey maps work differently but face similar constraints. They plot a customer's progression through a service, usually over time. The path through the service becomes the entire representation. This is useful - seeing a customer's experiential trajectory matters. But by centring the path, the representation obscures everything else: the alternative routes not taken, the parallel processes the customer never encounters, the relationships between different services the customer doesn't interact with directly, the internal structures within each touchpoint. As with blueprints, what's omitted is relational complexity.
The argument is not that these tools should be abandoned - journey maps communicate effectively to stakeholders, blueprints help coordinate teams, or help align front and backstage processes. But understanding them as graphs, specifically as graphs with severe structural constraints, makes visible what those constraints exclude. Blomberg and Darrah, writing about anthropological approaches to services, note that journey maps achieve "a higher level of synthesis" but with "corresponding loss of granular detail". Mages and Neely find that current mapping approaches are fundamentally limited. Penin and Prendiville observe that service blueprints "potentially oversimplify service dynamics". Matthews points out that neither journey maps nor service blueprints adequately express "detailed experiential outcome". These are not criticisms of the tools' usefulness but observations that the representations trade away information for clarity. Once you name what's being traded - relational depth, concurrency, the full network of interactions - you can ask whether different tools might preserve more of that information.
Promise Theory as Graph Formalism
The next post in this series introduces Mark Burgess's Promise Theory. I mention it here because the connection is direct. Burgess defines a promise model explicitly as a directed graph. Nodes are agents - autonomous entities in a system. Edges are promises - directional commitments one agent makes to another. The graph is not incidental to the theory - it is the theory. The entire framework for thinking about cooperation, reliability, and service in distributed systems is built on the structure of directed graphs.
Taking graphs seriously is not an abstract exercise. There are established formal frameworks - developed over decades in computer science and systems thinking - that treat graph structure as foundational: Promise Theory is one, Harel's statecharts (which a later post in this series explores) another. Systems researchers built these tools because they needed ways to represent relational structure that the tools available to them didn't capture.
What This Means for Service Representation
The series so far has established that services are processes, that they occur in state spaces, and that state spaces can be understood topologically as graphs. This post has argued that service design's dominant representational tools work with graphs, but highly constrained ones - flattened by fixed partitions, or collapsed into single paths, or limited in their hierarchical depth.
The subsequent posts explore statecharts, service states, and eventually systems grammars - each a more expressive way of working with graph-based representations, preserving more of the relational structure (depth, concurrency, the full network of possible interactions) at the cost of being harder to use and requiring more training to read. They can represent things that journey maps cannot.
The argument across the series is that as we try to understand more complex service systems - systems with parallel processes, deep hierarchies, distributed decision-making, interaction between multiple services - we need representational tools adequate to that complexity. Understanding blueprints and journey maps as constrained graphs is the necessary first step: it lets you see what those constraints buy you (simplicity, communicability) and what they cost you (relational depth, concurrency, full expressiveness), and from there make informed decisions about when simpler representations are appropriate and when you need something more formal.
References
Blomberg, J. & Darrah, C. (2015). An Anthropology of Services: Toward a Practice Approach to Digital Service Design. Morgan & Claypool.
Burgess, M. (2017). A Treatise on Systems. Paxus Press.
Harel, D. (1988). On Visual Formalisms. Communications of the ACM, 31(5), 514-530.
Mages, M. A. & Neely, S. (2023). Mapping Temporal Experience: Accounting for Felt Time in Service Design Representations.
Matthews, T. (2021). Exploring Sacred Service Design. PhD thesis.
Penin, L. & Prendiville, A. (Eds.) (2025). The Bloomsbury Handbook of Service Design. Bloomsbury Academic.
Russell, S. & Norvig, P. (2021). Artificial Intelligence: A Modern Approach (4th ed.). Pearson.
Next: Promise Theory: A Grammar of Cooperation - Mark Burgess's formal framework for thinking about cooperation between autonomous agents, built explicitly on directed graphs of promises.