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 and the service pathways available to them as vectors in a multidimensional space, intended to predict which pathways were most likely to succeed for a given participant. As the project's only designer, I had journey maps and linear representations that could not express what the algorithm did - tools that figured a participant as a body moving along a fixed pathway, where the system figured the same person as a point in a constructed vector space whose proximity to other points was used to predict rehabilitation trajectory. More recent 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, they are describing a graph traversal problem, while the tools available to them represent it as a list or a linear sequence.
Computational systems that support decisions about services 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. Understanding the gap between these infrastructures and the tools service designers work with 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 encodes, as inspectable relational structure, the ontological commitments that the opening post in this series argued all computational systems must make: what entities exist, what relationships hold between them, what properties they have, and how they change over time. The basic unit is an entity-relation-entity triple - a patient (entity) undergoes (relation) a procedure (entity); the procedure results-in (relation) a clinical outcome (entity). Chained together, these triples form a graph in which nodes are entities and edges are relations.
This entity-relation-entity structure is the noun-verb question made computational. Posts earlier in this series, on services as verbs and when nouns surface as verbs, worked through the linguistic move from noun-shaped service representations toward verb-shaped ones; a knowledge graph requires both - typed nouns as entities and typed verbs as relations - to be specified in advance. Enterprise ontology platforms make this explicit: in Krishnaswamy's (2024) account of the Palantir Ontology, an Ontology is constructed from object types and action types, with the action types carrying the relational and process semantics that journey-based representations leave implicit.
The simplicity of the format conceals the difficulty of building one. Constructing a clinical knowledge graph means declaring what entities exist, what relations are meaningful between them, and what properties matter. These commitments are written down and machine-readable; someone reviewing the schema can see what the system treats as real and what it treats as irrelevant. Schrodt and Dudchenko's (2020) systematic review found this kind of representation increasingly central in the clinical literature, and Montagna (2024) has documented its use across healthcare more broadly.
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 blueprint with its line of visibility was developed by Lynn Shostack in services marketing in the early 1980s and adopted into service design from there (Segelström, 2010, p. 31); business process management later borrowed similar conventions back from blueprinting (Hewing, 2013, p. 4), and swim lanes themselves trace further back to multi-column process charts in 1945 US government process analysis (Covert, 2022, p. 79). What stuck was a useful visual logic for organising information rather than an analysed account of which categorical boundaries best fit a service. The representations post documented the structural gaps this leaves across both product management and service design toolkits.
A knowledge graph forces the question that a blueprint allows you to defer. As the objects, entities, and things post established, different conceptual frameworks treat the same entities as categorically different kinds of things; the graph requires that choice to be confronted up front.
Complex service organisations now sit with two representational infrastructures running in parallel. The relational data model makes explicit ontological commitments about what entities and relations exist; the service design models work with different commitments, less visibly stated. Promise theory offers a partial bridge - Burgess defines a service as a directed graph of promises between autonomous agents, with explicit commitments about who promises what to whom. The promise graph does not carry the same computational machinery as a knowledge graph, but it shares the structural orientation: entities, directed relations, declared commitments.
Patient Journey Mapping: Graphs Versus Design Representations
The term "patient journey mapping" means almost entirely different things in the two literatures. In the clinical informatics literature, a patient journey is a subgraph of a larger clinical knowledge graph: the patient node is the entry point, with edges leading to encounters, diagnoses, treatments, and outcomes. The graph preserves temporal ordering, causal dependency, and institutional relationships, and every node connects outward to the rest of the network - a treatment connects to medications and contraindications, a diagnosis connects to clinical guidelines and coding systems. The journey is path-like in the visual sense, but the mathematical structure is much richer.
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. Temporal sequence is preserved, but almost everything else about relational structure has been flattened. Alternative pathways for different ages, conditions, or local variations are usually noted in footnotes rather than woven in. The internal structure of each touchpoint, and the broader institutional and clinical network shaping the pathway, are often out of scope.
A journey map that tried to preserve all relational structure would be unintelligibly dense for most audiences; the design version succeeds because it simplifies. The choice to linearise, suppress alternatives, and flatten institutional context costs the ability to represent what the system does algorithmically when it tries to route a patient through a service. Montagna (2024) demonstrates how knowledge graphs enable dynamic patient journey personalisation - systems adapting pathways in real time based on relational reasoning about the patient's position in the larger clinical network. A service design journey map cannot represent this; it is a static representation of a typical or ideal path. The moment the system needs to reason about alternatives, dependencies, and network effects, it needs the graph.
Graph Representation Learning and Vector Spaces
Knowledge graphs encode structure but remain symbolic - discrete entities and relations, with no native sense of similarity or proximity. Graph representation learning is the step that connects them to the conceptual spaces formalism discussed earlier in this series.
Hamilton (2020) describes how each node in a graph is transformed 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 nearby in the graph, or with similar connection patterns, end up with similar vectors. Negro (2021, p. 10) describes how a graph "embeds more information than the original datasets... the most important of which is the structural or topological information of the data relationships" - the system can learn features from this topology rather than from features that someone has decided manually.
Gärdenfors's conceptual spaces, discussed previously (Gärdenfors, 2000), are continuous geometric models in which concepts are located at points and conceptual similarity is determined by distance. Graph representation learning arrives at something structurally similar from a different direction: the geometry is derived from relational structure rather than from pre-defined quality dimensions of the vector space. The Pathway Generator's patient vector was an early encounter with this kind of representation in my own work, though its ~80 dimensions - covering demographics, education, income and housing, physical and psychological health, service engagement, and a battery of self-assessed capabilities (self-discipline, creativity, technical aptitude, time management, empowerment, resourcefulness) - were hand-engineered rather than learned from data. It sits closer to Gärdenfors's conceptual-space construction than to graph representation learning, but the operative move is the same: proximity in the vector space stands in for similarity of situation and likely trajectory.
Graph neural networks 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, encoding both local neighbourhood information and global graph structure (Negro & Kus, 2025). For service domains, a network can learn to reason about interactions between conditions and interventions, predict outcomes from relational patterns, or identify service users at risk by their position in the graph relative to outcome nodes - the kind of reasoning that a pathway coordinator managing patient flow across multiple interdependent services needs but cannot get from a journey map or a waitlist.
A service design journey map operates in a different representational register altogether: discrete where embeddings are continuous, linear where they are relational, static where learned representations support reasoning 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
Earlier posts in the series, on conceptual spaces and on graphs, distinguished between explicit and implicit representation. Explicit representation is declarative; implicit representation is distributed in the weights of a neural network.
Knowledge graphs sit at the explicit end of this distinction; every entity, every relation, every semantic commitment is declared, and the ontology is visible. Building one requires someone to have thought through what kinds of entities and relations exist and to have encoded that understanding in advance - a hard, expensive, and brittle business when the domain is misunderstood or the world changes.
Large language models work implicitly, encoding knowledge in the distribution of their parameters. Asked about clinical drug interactions, a model can respond coherently, but the knowledge is in a form that is difficult to examine, verify, or update directly; when the model hallucinates, locating the source of the error is much harder than with an explicit knowledge representation.
Much current research combines the two. 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, and the ontological commitments the companion series on case grammar makes about semantic roles in service interactions, are what knowledge graphs encode and what LLMs can now reason over.
Service design is largely absent from this convergence. Designers do not need to implement graph neural networks themselves, but having a substantive role in how these systems are built requires understanding what graphs, embeddings, and neural networks can represent, and what linearised journey maps and simplified systemic representations cannot.
What This Means for Service Design's Role
If the representational infrastructure of algorithmic decision support systems is graph-based and service design's primary tools are linearised maps, design is working with a less expressive formalism than the systems it claims to shape. The journey map and the graph embedding are not equivalent tools when the question is "how should this system route patients through care?".
Burgess (2017, p. 255) argues that "a system must be analyzed in terms of its dependencies to understand its behaviour at that scale". Some formalisms are adequate to the complexity they represent and some are not. The promise theory post and Iqbal's service grammar both attempted to give service design graph-native formalisms - promises as directed graphs of commitments, services as compositions of promises about outcomes, experiences, performances, and affordances. Knowledge graphs extend the move further: where promise theory encodes the commitment structure between agents, the knowledge graph encodes the system's understanding of entities, relations, and the structure of the domain itself.
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 their inherited tools. A journey map might be appropriate for designing the customer-facing experience of booking an outpatient appointment; it is wholly inadequate for reasoning about how a decision support system should distribute scarce appointments across service users whose pathways are interdependent. That problem arises whenever a health system tries to coordinate patient flow across services, and it is the reason 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".
If knowledge graphs and relational data structures are the representational infrastructure decision support systems use, service design could work upstream of them, 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 which relations are semantically meaningful? These are design questions - questions about what matters, what should be visible, whose interests are served by particular representational choices - asked in a different register than a typical service design conversation. Other posts in this series have developed graph-native formalisms - statecharts, promise theory, and case grammar - that could support this kind of upstream work, but they sit outside the design toolkit as it is currently practised. Service design has the orientation; it does not yet have the representational tools to ask its questions in the register that knowledge graphs, graph embeddings, and neural networks operate in.
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.
Covert, A. (2022). Stuck? Diagrams Help. Sense & Respond 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.
Hewing, M. (2013). Business Process Blueprinting: A Method for Customer-Oriented Business Process Modeling. Springer.
Krishnaswamy, A. (2024, January 4). Connecting AI to decisions with the Palantir Ontology. Palantir Blog. https://blog.palantir.com/connecting-ai-to-decisions-with-the-palantir-ontology-c73f7b0a1a72
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.
Segelström, F. (2010). Visualisations in Service Design. Licentiate Thesis, Linköping University.