The Corpus
The corpus is intentionally mixed. Some books are hands-on practice manuals. Some are theory, some are business translation, some are method encyclopedias, and some are service-quality classics that keep the platform from collapsing into design theatre. That blend explains the method library better than any single origin story would. Research planning comes from one corner. Journey craft comes from another. Blueprint rigor, CX maturity, service recovery, orchestration, and profit-chain logic each pull from their own shelves.
The important runtime point is simple: these books are not decorative citations. Their chapter syntheses are part of the served resource space. A client can browse them through MCP the same way it browses article notes, and the method manifests cite them directly in structured provenance. That is why a tool like sd_knowledge can filter by book id, book chapter, or article number without guessing what the source means.
A practical way to read the corpus is to see four layers at once. First come the field manuals: books that tell me how to plan research, run workshops, map journeys, and blueprint services. Then come the theory books that explain value, systems, and emergence, which stops the runtime from becoming a box of workshop rituals with no model of why services behave the way they do. Then come the management and quality texts that keep operations, economics, and frontline reality in the room. Finally come the method catalogs that widen the tactical repertoire when a project needs something more specific than the usual playbook.
| Corpus fact | Current value |
|---|---|
| Books in the served corpus | 20 |
| Chapter files across those books | 159 |
| Book resource URI forms | asd://books/<book> and asd://books/<book>/<chapter> |
| Total MCP resources when article roots are present too | 228 |
| Why the corpus exists | To give method manifests, prompts, and knowledge queries a bounded source base instead of hand-wavy references. |
I like this split because it keeps the platform from sounding smarter than it is. The runtime can answer “which sources ground this method?” because the source base is finite. It can expose chapter resources through MCP because the corpus has already been normalized into book and chapter files. It can refuse unsupported provenance claims because every manifest is supposed to point back to concrete book chapters or article notes, not an inferred school of thought.
asd://books/<book> proves the knowledge is available to the runtime. It does not prove a host executed any specific method against a live project.Books to Methods Map
| Book title | Authors | Corpus span | Representative ASD methods | Primary artifact kinds |
|---|---|---|---|---|
| This Is Service Design Doing | Marc Stickdorn, Adam Lawrence, Markus Hormess, Jakob Schneider | 10 chapters | research-plan-design, stakeholder-mapping, storyboard-authoring, service-blueprinting |
research-plan, stakeholder-map, storyboard, service-blueprint |
| This Is Service Design Thinking | Marc Stickdorn & Jakob Schneider | 6 chapters | stakeholder-mapping, service-safari, story-mapping |
stakeholder-map, insight-set, story-map |
| Service Design: From Insight to Implementation | Andy Polaine, Lavrans Løvlie, Ben Reason | 8 chapters | journey-from-transcripts, service-blueprinting, prototype-ladder-gating, implementation-roadmap |
journey-map, service-blueprint, decision-matrix, roadmap |
| Service Design for Business | Ben Reason, Lavrans Løvlie, Melvin Brand Flu | 8 chapters | stakeholder-mapping, service-standard-authoring, frontline-enablement, raci-definition |
stakeholder-map, service-standard-set, raci-matrix |
| Good Services | Lou Downe | 7 chapters | good-services-audit, good-services-audit-15, experience-audit |
insight-set, experience-audit |
| The Service Innovation Handbook | Lucy Kimbell | 8 chapters | business-model-canvas-build, value-proposition-canvas-build, implementation-roadmap |
business-model-canvas, value-proposition-canvas, roadmap |
| Designing for Service: Key Issues | Daniela Sangiorgi & Alison Prendiville, editors | 8 chapters | co-design-workshop, desirability-testing, experience-audit, service-recovery-design |
concept-set, test-report, experience-audit, recovery-playbook |
| Orchestrating Experiences | Chris Risdon & Patrick Quatromoni | 8 chapters | orchestration-canvas, ecosystem-value-mapping, journey-from-transcripts |
ecosystem-map, journey-map |
| Mapping Experiences | James Kalbach | 8 chapters | experience-mapping, mental-model-alignment, mental-model-diagramming, service-blueprinting |
journey-map, mental-model-map, service-blueprint |
| The User's Journey | Donna Lichaw | 6 chapters | story-mapping, storyboard-authoring, desktop-walkthrough |
story-map, storyboard, walkthrough-script |
| Design Unbound | Ann M. Pendleton-Jullian & John Seely Brown | 10 chapters | opportunity-matrix-2x2, nuf-triple-lens-filter, blueprint-to-backlog |
opportunity-matrix, concept-set, roadmap |
| Service-Dominant Logic | Stephen L. Vargo & Robert F. Lusch | 7 chapters | ecosystem-value-mapping, value-proposition-canvas-build, business-model-canvas-build |
ecosystem-map, value-proposition-canvas, business-model-canvas |
| The Experience Economy | B. Joseph Pine II & James H. Gilmore | 7 chapters | experience-audit, desirability-testing, service-roleplay |
experience-audit, test-report, storyboard |
| Outside In | Harley Manning & Kerry Bodine | 8 chapters | behavioural-personas, experience-audit, cx-maturity-assessment, customer-typology-mapping |
persona-set, experience-audit, maturity-assessment |
| Change by Design | Tim Brown | 11 chapters | bodystorming, hmw-formulation, co-design-workshop, wizard-of-oz |
concept-set, hmw-set, prototype-plan |
| The Design of Business | Roger Martin | 6 chapters | concept-brief-authoring, decision-matrix, wwhtbt-evidence-gate |
concept-set, decision-matrix |
| 101 Design Methods | Vijay Kumar | 9 chapters | hmw-formulation, morphological-concept-matrix, opportunity-matrix-2x2, business-model-canvas-build |
hmw-set, concept-set, opportunity-matrix, business-model-canvas |
| Universal Methods of Design | Bella Martin & Bruce Hanington | 7 chapters | discussion-guide-design, contextual-inquiry, affinity-diagramming, usability-testing-moderated |
interview-guide, insight-set, test-report |
| Service Management and Marketing | Christian Grönroos | 9 chapters | service-blueprinting, service-quality-diagnostic, service-recovery-design, frontline-enablement |
service-blueprint, experience-audit, recovery-playbook, service-standard-set |
| The Service Profit Chain | James L. Heskett, W. Earl Sasser, Leonard A. Schlesinger | 8 chapters | kpi-tree-design, service-profit-chain-mapping, three-tier-measurement, frontline-enablement |
kpi-tree, service-profit-chain, service-standard-set |
The table is not claiming one-to-one ownership. A single method often draws from several books, and a single book often informs several phases. That is the right shape for a living practice. What the table does give me is a dependable spine: if I need journey craft, I know which shelves are strongest; if I need theory of value co-creation, recovery, maturity, or frontline economics, I know where the runtime’s assumptions came from.
I also read the table as a map of tensions inside the practice. This Is Service Design Doing, Service Design: From Insight to Implementation, and Mapping Experiences push the craft toward visible service structure: plans, journeys, blueprints, and prototypes. Service-Dominant Logic and Design Unbound pull the other way. They remind me that value is co-created, systems are adaptive, and neat diagrams can lie if they freeze living service behavior into a static story. ASD works because it keeps both impulses: operational specificity and theoretical humility.
The business-facing books do a different job. Outside In, The Service Profit Chain, and The Design of Business keep the library accountable to growth, capability, and decision quality. Without them, the measurement phase would drift into generic dashboards or satisfaction slogans. With them, methods such as kpi-tree-design, service-profit-chain-mapping, and cx-maturity-assessment can anchor service change to operating consequences the rest of an organization will actually recognize.
Then there are the quality and frontline texts. Good Services and Service Management and Marketing are load-bearing because they force the runtime to respect legibility, recovery, and support operations. Those sources are why the platform cares about standards, service recovery, and evidence-backed audits rather than treating delivery as a vague “handoff to implementation.” When a blueprint reaches the delivery or measurement phase, these are the books that stop it from becoming a polished fiction.
The method encyclopedias matter too. 101 Design Methods and Universal Methods of Design widen the repertoire without breaking the contract model. They do not flood the runtime with every method ever named. Instead, they justify why a specific subset made the cut and why each retained method still has to pass through outputs, acceptance rules, review gates, and provenance. In other words: broad inspiration upstream, strict runtime discipline downstream.
Reading Paths
If I am orienting a new teammate, I rarely tell them to read the whole corpus in order. I give them a path based on the job in front of them. The runtime encourages the same habit. The method manifests cite the exact sources they need, and the MCP resource surface makes those sources fetchable without a scavenger hunt.
There is another way to use these reading paths. I use them to diagnose blind spots in a team. If a workshop-heavy group keeps producing clever concepts with weak measurement logic, I send them toward the business and quality shelves. If a delivery-heavy team has standards and roadmaps but weak evidence, I push them back to the research and synthesis books. If a technically strong team keeps drawing system diagrams without a service view, I hand them the mapping and orchestration cluster.
- For end-to-end service design practice: start with This Is Service Design Doing, then pair it with Service Design: From Insight to Implementation and Mapping Experiences.
- For research craft: move through Universal Methods of Design, This Is Service Design Doing, and the research-heavy chapters of Outside In.
- For multi-channel and systems work: read Orchestrating Experiences, Mapping Experiences, and Service-Dominant Logic together.
- For prototype and concept generation: combine Change by Design, 101 Design Methods, and The User’s Journey.
- For delivery, quality, and operations: use Service Management and Marketing, Good Services, and Service Design for Business.
- For business case and measurement: pull from Outside In, The Service Profit Chain, and The Design of Business.
- For theory and discipline-level framing: read Design Unbound, Service-Dominant Logic, and The Experience Economy.
What I do not recommend is reading only the books that flatter your home discipline. Designers who skip operations and service quality end up with elegant artifacts that fail in contact with frontline work. Operators who skip journeys, personas, and narrative structure end up with efficient systems nobody can navigate. Strategists who skip field research and prototype testing end up with confident abstractions. The corpus is strongest when it is used as a corrective, not a mirror.
That is why Appendix C belongs in this book at all. It turns provenance from a polite bibliography into an inspectable design decision. When a host asks for a prompt, when a method manifest cites a chapter, or when the knowledge tool returns a matching resource, the platform is leaning on this bounded library. That is the quiet contract under the louder runtime features.
That is enough. Appendix C is supposed to be a compass, not a seminar. The core fact to carry forward is that the platform’s method and artifact claims sit on a bounded, inspectable 20-book corpus, and that corpus is available to tools under the same URI space the rest of the runtime already uses.