Two years ago, I wrote a post in this series arguing that service design's dominant tools - journey maps and service blueprints - are constrained graphs. They flatten relational structure, suppress concurrency, and collapse the full network of interactions into linearised sequences. The question was whether understanding these tools as degenerate graphs revealed something useful about what they could and could not do.
That question has become less abstract since. My PhD research concerns the service design of generative decision support systems - systems that recommend, route, or prioritise across complex service networks. The Pathway Generator work at SCÖ was an early encounter with this gap: a machine learning system that represented rehabilitation participants as vectors in a multidimensional space, with service pathways encoded as temporal and relational graph structures, while the design team worked with journey maps and process diagrams that could not express what the algorithm actually did. More recently, practical work on patient flow systems - outpatient appointment scheduling, pathway coordination, waitlist management - has made the same gap visible from the operational side. When an outpatient booking manager needs to see where every patient sits across multiple interdependent services, she is describing a graph traversal problem; the tools available to her represent it as a list or a linear sequence.
The computational systems that support decisions about services do not operate on journey maps or blueprints. They operate on relational data structures: knowledge graphs encoding entities and their relationships, graph embeddings that learn continuous representations from relational structure, and neural networks built directly on graph topologies. The gap between these representational infrastructures and the tools that service designers use has widened, and understanding what that gap means is a practical problem for anyone trying to shape how such systems are designed and deployed.
Knowledge Graphs as Explicit Ontological Infrastructure
A knowledge graph is built from entity-relation-entity triples. A patient (entity) undergoes (relation) a procedure (entity). The procedure results-in (relation) a clinical outcome (entity). Chain enough of these triples together and you have a graph. Nodes are entities; edges are relations. Every fact in the knowledge graph is a triple.
The format looks simple, but the act of building one forces explicit ontological choices. When you build a knowledge graph in a clinical domain, you first define what kinds of entities exist - patients, clinicians, procedures, conditions, medications, outcomes. You define what kinds of relations are meaningful - temporal relations (before, after, during), causal relations (causes, complicates, treats), institutional relations (orders, performs, documents). These commitments are declared, written down, and machine-readable - someone reviewing the schema can see exactly what the system treats as real and what it treats as irrelevant.
Montagna (2024) and Negro & Kus (2025) have shown this in practice across healthcare and other service domains. Patient journey mapping on graphs is not a metaphorical exercise - it is the infrastructure that clinical informatics systems, biomedical research networks, and increasingly public service organisations build on. Schrodt & Dudchenko (2020) conducted a systematic review of how patient data is represented graphically in the literature and found knowledge graphs increasingly central: nodes for patients, events, clinical encounters, conditions, and treatments; edges for temporal sequence, causality, and clinical dependency. Where such systems are operational, they support decisions about resource allocation, treatment pathways, and care prioritisation.
Service design representations make ontological commitments too, but implicitly. A service blueprint declares what swimlanes exist - customer, front-stage staff, backstage. A journey map declares a sequence of touchpoints. The partition into swimlanes happened because it was a useful way to organise visual information, not because someone had analysed whether those are the right categorical boundaries for the service. A designer drawing a blueprint is not asking whether patient or clinician or medication are the foundational entities in the system; they are working with conventions inherited from UX design, which borrowed from business process management. The representations post documented these structural gaps across both product management and service design toolkits.
The difference is that a knowledge graph forces the question. As the objects, entities, and things post established, different conceptual frameworks can treat the same entities as fundamentally different kinds of things. Knowledge graphs require you to confront that choice up front; blueprints let you avoid it.
The practical consequence is that complex service organisations increasingly sit with two separate representational infrastructures. One - the knowledge graph or relational data model - makes explicit ontological commitments about what entities and relations exist in the system. The other - the service design models - works with different commitments, less visibly stated. When the two need to inform each other, the gap is apparent. Promise theory offers a partial bridge: Burgess defines a service as a directed graph of promises between autonomous agents, which is already a graph formalism with explicit ontological commitments about who promises what to whom. The promise graph does not carry the same computational infrastructure as a knowledge graph, but it shares the same structural orientation - entities, directed relations, explicit commitments - and it captures something that neither journey maps nor knowledge graphs foreground: the voluntary commitment architecture that holds a service together.
Patient Journey Mapping: Graphs Versus Design Representations
The term "patient journey mapping" appears in both literatures. It means something almost entirely different in each.
In the knowledge graph and clinical informatics literature, a patient journey is a subgraph of a larger clinical knowledge graph. The patient node is the entry point. From there, edges lead to clinical encounters, diagnoses, treatments, outcomes. The graph preserves the relational structure: temporal ordering (this encounter happened before that one), causal dependency (this treatment was ordered because of this diagnosis), institutional relationships (this clinician performed this procedure in this department). The journey is path-like in the visual sense - it can be drawn as a line through the graph - but the mathematical structure is much richer. Every node is connected not just to its neighbours in the sequence, but potentially to many other nodes. A treatment node connects to the medication knowledge graph, the contraindication graph, the outcome data. A diagnosis node connects to the clinical guideline graph, the epidemiological literature, the coding systems. The patient journey is a subgraph, yes, but it's embedded in a much larger network of relations.
In service design, a patient journey is typically drawn as a linear sequence of touchpoints, often on a single row or a slightly curved path. Experience rises and falls along the path. Emotions are annotated at each point. Opportunities are noted where the customer's experience dips. The temporal sequence is preserved - the order of touchpoints matters. But almost everything else about relational structure has been flattened. There are alternative pathways patients might take, different depending on age, condition, local variation - these are usually noted separately or in footnotes, not woven into the representation. The internal structures of each touchpoint - what's actually happening when a patient arrives for an appointment - tend to be invisible. The broader institutional and clinical network that shapes the pathway, and the patient's interaction with other services, are often out of scope.
Neither representation is wrong on its own terms. A journey map that tried to preserve all relational structure would be unintelligibly dense for most audiences; the design version succeeds because it simplifies. But the choice to linearise, to suppress alternatives, to flatten institutional context - these cost expressiveness, and specifically they cost the ability to represent what the system actually does algorithmically when it tries to route a patient through a service. The promise architecture discussed in the promise theory post sits somewhere between these two: it models the commitment structure - who promises what to whom, and on what basis - as a directed graph, preserving relational structure without requiring the full computational machinery of a knowledge graph. But in practice, service design rarely works with promise graphs either; the dominant tools remain the linearised journey and the layered blueprint.
Montagna (2024) demonstrates how knowledge graphs enable dynamic patient journey personalisation - the ability for systems to adapt pathways in real-time based on relational reasoning about the patient's position in the larger clinical network. The graph structure allows traversal not only of the linear pathway but of semantic associations between conditions, treatments, and outcomes. A service design journey map, by its nature, can't represent this. It's a static representation of a typical or ideal path. The moment you want the system to reason about alternatives, dependencies, and network effects, you need the graph.
Graph Representation Learning and Vector Spaces
Knowledge graphs encode structure, but they remain symbolic - discrete entities and relations, with no native sense of similarity or proximity. The step that connects them to the conceptual spaces formalism discussed earlier in this series is graph representation learning.
Hamilton (2020) published the foundational work on this. The key insight: you can take a graph and transform each node into a dense vector (a point in a continuous space) such that the vector encodes the node's position and relationships in the graph. Two nodes that are nearby in the graph, or that have similar connection patterns, end up with similar vectors. You can learn these representations end-to-end with neural networks. Negro (2021) calls this "feature engineering by structure" - instead of manually deciding what features matter about a node, the system learns features from the graph topology itself.
Gärdenfors's conceptual spaces are continuous geometric models where concepts are located at points and conceptual similarity is determined by distance. Graph representation learning arrives at something structurally similar, but from a different direction: the geometry is derived from relational structure rather than from pre-defined quality dimensions. The vector embedding of a node in a knowledge graph is a position in a continuous space - but one that has been learned from the graph's structure, encoding both the node's attributes and its position in the network. The Pathway Generator's patient vector - with its dimensions for health, social circumstances, employment history, and rehabilitation outcomes - was an early instance of exactly this kind of representation: a point in a learned space where proximity encoded similarity of situation and likely trajectory.
Negro & Kus (2025) describe this vividly: "Graph representation learning automates feature engineering by transforming nodes and edges into dense vector representations. These representations are learned end-to-end through graph neural networks which simultaneously process node features and graph structure". The vector embeddings that emerge are positions in a learned conceptual space, where the geometry is determined by the knowledge graph's topology.
Graph neural networks - networks that operate directly on graph structures rather than converting them to fixed-size vectors first - extend this further. A GNN takes the graph as input (nodes, edges, attributes) and learns a function that outputs predictions, classifications, or new node embeddings. The network learns representations that encode both local neighbourhood information (the immediate connections) and global graph structure (the broader network topology). For service domains, this means a GNN could learn to reason about interactions between conditions and interventions, predict outcomes based on relational patterns, or identify service users at risk by understanding their position in the graph relative to outcome nodes - the kind of reasoning that a pathway coordinator attempting to manage patient flow across multiple interdependent services needs but cannot currently get from a journey map or a waitlist.
Hamilton (2020), Negro (2021), and Negro & Kus (2025) describe how this works in principle; practical implementations are emerging across healthcare, logistics, and other domains where relational reasoning about complex service networks is required.
A service design journey map, set against this, operates in a different representational register altogether - discrete where embeddings are continuous, linear where they are relational, static where learned representations can be used by networks that reason dynamically about alternatives and dependencies. The journey map encodes what a designer understood to matter; the embedding encodes what the system learned from relational structure in the data.
Knowledge Graphs Plus Large Language Models: Explicit Meets Implicit
Earlier posts in the series - on conceptual spaces, on graphs - distinguished between explicit and implicit representation. Explicit representation is declarative: you state what is true. Implicit representation is distributed: knowledge is encoded in the weights of a neural network.
Knowledge graphs are maximally explicit. Every entity, every relation, every semantic commitment is declared, and the ontology is visible. The cost is that building one requires someone to have thought through what kinds of entities and relations exist, and to have encoded that understanding in advance. This is hard, expensive, and brittle - when the world changes or you have misunderstood the domain, the graph needs to be rebuilt.
Large language models work implicitly. They encode knowledge in the distribution of their parameters. If you ask the model about clinical drug interactions, it can respond coherently - but the knowledge is not in a form you can examine, verify, or update directly. You cannot see why the model said what it said; you cannot audit its reasoning; when it hallucinates, it is nearly impossible to locate where the error came from.
Much current research is concentrated on combining the two: knowledge graphs providing explicit structure, LLMs providing implicit learning and reasoning. Retrieval-augmented generation systems use LLMs to interpret queries against explicit knowledge graphs. Decision support systems combine knowledge graphs of domain guidelines with LLM-based reasoning about individual cases. Agentic systems use LLMs to traverse explicit knowledge graphs.
The explicit conceptual structure that the conceptual spaces post described, the ontological commitments that case grammar makes about semantic roles in service interactions - these are what knowledge graphs encode, and what LLMs can now reason over. The convergence is practical, not just theoretical.
Service design is largely absent from this convergence. Not because designers need to implement graph neural networks, but because understanding what graphs, embeddings, and neural networks can represent - and what linearised journey maps cannot - is necessary for design to have a substantive role when these systems are being built.
What This Means for Service Design's Role
If the representational infrastructure of algorithmic decision support systems is graph-based - knowledge graphs for structured information, graph embeddings for learned similarity and reasoning, graph neural networks for relational inference - and service design's primary representational tools are linearised maps, then design is working with a less expressive formalism than the systems it claims to shape. A journey map is a graph - a constrained one. A knowledge graph is a graph - a richer one. A vector embedding derived from a knowledge graph is a different formalism altogether. These are not comparable in a hierarchy; they answer different questions. But when the question is "how should this system route patients through care?", the journey map and the graph embedding are not equivalent tools.
Burgess (2017) argues that "systems thinking requires thinking in terms of the networks and interdependencies that systems comprise". The formalism matters because some formalisms are adequate to the complexity of what they are trying to represent and some are not. The promise theory post and Iqbal's service grammar both attempted to provide service design with graph-native formalisms - promises as directed graphs of commitments, services as compositions of promises about outcomes, experiences, performances, and affordances. Knowledge graphs extend this further: not just what agents promise to each other, but what the system knows about entities, relations, and the structure of the domain itself. Burgess's point stands across all three: you cannot think clearly about networks using tools that suppress network structure.
For service design practice, this means understanding what graphs can represent - relational depth, concurrency, network effects, alternative pathways - because designers need to understand the limits of inherited representational tools. A journey map might be entirely appropriate for designing the customer-facing experience of booking an outpatient appointment. It might be wholly inadequate for reasoning about how a decision support system should distribute scarce appointments across multiple service users whose pathways are interdependent - which is the problem that arises whenever a health system tries to coordinate patient flow across services, and the reason that the pathway management tools I have worked with struggle to move beyond being, as one colleague put it, "a very fancy diagram of the pathway".
But there is also an opportunity. If knowledge graphs and relational data structures are the representational infrastructure that decision support systems use, then service design could work upstream - informing the ontological commitments that shape those structures. What entities and relations does a knowledge graph of service pathways include? What gets represented, and what gets silenced? Who decides what relations are semantically meaningful? These are design questions - questions about what matters, what should be visible, whose interests are served by particular representational choices - just asked in a different register than a typical service design conversation. The series has developed several formalisms that could support this work: statecharts for modelling concurrent service states, promise theory for modelling commitment structures, case grammar for modelling the semantic roles that entities play in service interactions. Knowledge graphs are the computational embodiment of these kinds of ontological commitment, and the design question is who gets to make them. Service design has the orientation - it asks whose interests are served, what gets made visible, what gets silenced. It does not yet have the representational tools to ask those questions in the register that knowledge graphs, graph embeddings, and neural networks operate in. That is the gap.
References
Burgess, M. (2017). A treatise on systems: Being a short treatise on the art and science of effective organization and management of work. Paxus Press.
Gärdenfors, P. (2000). Conceptual spaces: The geometry of thought. MIT Press.
Hamilton, W. L. (2020). Graph Representation Learning. Synthesis Lectures on Artificial Intelligence and Machine Learning. Morgan & Claypool.
Montagna, A. (2024). Knowledge Graphs Applied. Manning Publications.
Negro, A. (2021). Graph-Powered Machine Learning. Manning Publications.
Negro, A. & Kus, V. (2025). Knowledge Graphs and LLMs in Action. Manning Publications.
Schrodt, J. & Dudchenko, A. (2020). Graph-representation of patient data: A systematic literature review. Journal of Medical Systems, 44(4), 86.