We spent twelve years teaching a generation to be slower, more expensive versions of machines that now fit in their pockets. The machines arrived. The students were not prepared for what their arrival actually required — not obsolescence, but its opposite. Machines that are superhuman at pattern recognition, fact retrieval, and syntactic correctness should have freed humans to concentrate on what machines cannot do. Instead, the curriculum kept teaching humans to do what machines do. We are watching, in slow motion, the consequences.
The Irreducibly Human series gives that failure a precise anatomy. It maps the full range of human intelligence — sorted by what AI can and cannot do — and finds a consistent pattern: the intelligences schools optimize for are exactly the ones where machines are strongest. The intelligences that go unscaffolded are the ones no algorithm reaches. Interpretive judgment. Causal reasoning. Knowing what the result means in this context, for these people, under these stakes. Practical wisdom — the capacity to know not just what to do, but when, and what it costs. These require being alive, mortal, and situated in time. No training data substitutes for that.
But here is the thing the taxonomy does not say loudly enough: most of that development doesn’t happen in class.
It happens in the hours around class. It happens when the student taking the same course number in London rather than Boston has to figure out how to eat, navigate, disagree with someone in a second language, recover from a mistake without the social infrastructure that usually catches them. It happens during the co-op, the clinical rotation, the internship, the semester abroad — not in the scheduled reflection sessions, but in the Tuesday afternoon when something went wrong at work and no one explained why. The classroom is the occasion. The world is where the learning lives.
This has always been true. What’s new is that we have the tools to do something about it — and that most institutions are using those tools for the wrong half of the problem.
AI deployed in content delivery is already doing what machines do well. That work is real and the Irreducibly Human series addresses it directly. But there is a second deployment problem that the curriculum reform conversation has barely touched: what happens to the consequential experience that goes unreflected? The six-month co-op that produces a resume line instead of practical wisdom. The semester abroad that produces photographs instead of perspective. The clinical rotation that produces procedural competence and leaves the judgment that should accompany it undeveloped.
Not because the experiences lacked value. Because the reflection infrastructure was never built.
One advisor with two hundred students cannot provide the depth of reflective engagement that turns six months of consequential action into lasting practical wisdom. This has always been true. Until recently, it was also unsolvable.
The AI Sherpa is the infrastructure.
Not a teacher. Not a coach. A Sherpa — the oldest model for this kind of relationship there is. The Sherpa does not climb the mountain for you. It carries what you cannot carry alone, reads the terrain you don’t yet know how to read, and asks the question that makes you stop and see what you’ve been walking past. The machine reads the journal. The human does the interpreting. The machine asks what surprised you. The human sits with the answer and decides what it means.
This is what the Irreducibly Human framework implies and what this book makes operational. The AI that writes the student’s analysis is working against human development. The Sherpa that asks what did you commit to, and what did you actually do is working for it. Same tools. Different relationship to the intelligence the machine cannot supply.
The distinction isn’t classroom versus field. It’s structured content delivery versus learning that happens in the world — which includes the world that wraps around the classroom, the city the student is living in for the first time, the workplace where the theory either holds or it doesn’t. Wherever that learning is happening, the reflection infrastructure either exists or it doesn’t. When it doesn’t, the experience teaches less than it could. When it does, the experience teaches what no classroom ever could.
The mountain still has to be climbed.
Tags: AI Sherpa experiential learning, irreducibly human framework, practical wisdom reflective infrastructure, co-op clinical rotation study abroad, AI companion not teacher
THE BOOK
Most students complete a co-op, clinical rotation, or semester abroad and come home with a resume line. The developmental potential of the experience — the practical wisdom, the judgment, the professional identity that only forms under real stakes — goes unrealized. Not because the experience lacked value. Because the reflection infrastructure was never built.
One advisor with 200 students cannot provide the depth of reflective engagement that develops practical wisdom in each of them. Until recently, this was an unsolvable structural constraint. It no longer is.
The AI Sherpa gives experiential learning professionals the infrastructure to close the gap: an experience map that matches developmental need to placement type, a living journal that builds the reflection architecture the student cannot build alone, and an AI Sherpa — a developmental companion that holds longitudinal context and asks the questions that turn six months of consequential action into lasting practical wisdom, at a scale no single advisor could achieve alone.
THE THESIS
AI deployed in experiential learning is categorically different from AI in the classroom. It is a Sherpa relationship, not a teaching relationship. A Sherpa does not climb the mountain for you. It guides, asks, and carries what you cannot carry alone. Every classroom AI tool imported into an experiential learning program produces the wrong relationship — and the cost is not just inefficiency but the active undermining of the developmental process that makes consequential experience educative in the first place.
WHO THIS BOOK IS FOR
Co-op coordinators. Study abroad advisors. Clinical placement directors. Apprenticeship program managers. Corporate early career program leads. Anyone who sends students or early professionals into the world to learn by doing — and who has watched most of them come home with less than the experience was capable of giving them.
This book is not for: Classroom instructors looking for AI tools for course delivery, content generation, or assessment automation. For that, Mollick (2024) is a better starting point. This book is about a different kind of learning entirely.
THE TABLE OF CONTENTS
PART ONE — FOUNDATIONS: THE ARGUMENT Ch. 1 — The Gap: Why Having an Experience Is Not the Same as Learning from One Ch. 2 — The Framework: Ricoeur, Kolb, and the Three Movements of Experiential Learning
PART TWO — THE EXPERIENCE MAP Ch. 3 — The Taxonomy: Profiling What a Student Needs to Develop Ch. 4 — The Experience Map: Matching Developmental Need to Placement Type Ch. 5 — Pre-Experience Preparation: The Question to Carry In
PART THREE — THE LIVING JOURNAL Ch. 6 — The Living Journal: What It Is and Why Visual Matters Ch. 7 — The MVAL Protocol: Structuring Reflection for Practical Wisdom Ch. 8 — Failure as First-Class Artifact: Documenting What Went Wrong
PART FOUR — THE AI SHERPA IN PRACTICE Ch. 9 — The Sherpa Before: Profile, Map, and Focused Attention Ch. 10 — The Sherpa During: Companion, Not Coach Ch. 11 — The Sherpa After: Refiguration and the Capstone Narrative Ch. 12 — What the Sherpa Cannot Do: The Boundary That Makes Development Possible Ch. 13 — The Advisor Shift: From Gap-Filling to Strategy
PART FIVE — THE FIELD GUIDES (Enter at your domain — each chapter fully self-contained) Ch. 14 — The Co-op Coordinator’s Field Guide Ch. 15 — The Study Abroad Advisor’s Field Guide Ch. 16 — The Clinical Placement Director’s Field Guide Ch. 17 — The Workforce Development Coordinator’s Field Guide Ch. 18 — The Corporate Early Career Program Manager’s Field Guide
WHAT THIS BOOK IS NOT
A classroom AI tool guide
A platform manual or vendor recommendation
A research monograph arguing for experiential learning’s value (Kuh already made that case)
A book that requires students to read it (students interact with the outputs — the journal, the Sherpa prompts — not with this book)
A book about AI replacing the human advisor (it does not — it changes what the advisor’s attention is for)
HOW IT DIFFERS FROM WHAT YOU ARE ALREADY USING
Kolb describes the cycle. This book builds the infrastructure to make the cycle reliable. Schön describes what expert practitioners do. This book develops that capacity in students at scale. Kuh proves experiential learning works. This book addresses why it sometimes doesn’t — and gives practitioners the tools to close the gap.
PEDAGOGICAL FEATURES
Two-mode structure: Chapters 1–13 as a sequential professional development curriculum; Chapters 14–18 as standalone domain field guides
Professional development facilitator guides in every foundational chapter — 13 sessions, runnable without the author
Implementation checklists in every field guide chapter — binary completion criteria, three phases
Downloadable templates: MVAL reference card, experience map, Sherpa configuration, capstone reflection protocol
Assessable exercises: 54 total — at least one Apply-level, one produce-from-own-context, and one cohort-usable per chapter
Start Here index: One-page front-matter reference mapping practitioner role to entry chapter
THE AI SHERPA: A PRACTITIONER’S GUIDE FOR EXPERIENTIAL LEARNING
Full Table of Contents — Working Draft
Compiled by: Tic TOC Version: 1.0 Date: 2026-03-21 Status: Complete draft — ready for /g2 audit and author review
COMPLETENESS CHECK
Before compiling, confirming all required sections are present:
SectionStatusBook Concept Summary and Thesis✓ Confirmed /i1, /i4Book Type and Deployment Specification✓ Confirmed /i2Learner Profile and Prerequisite Map✓ Confirmed /i3, /l4Central Argument and Field Positioning✓ Confirmed /i4Learning Outcomes (Bloom’s, testable)✓ Confirmed /l1Sequencing Logic✓ Confirmed /l2Three-Act Learning Arc✓ Confirmed /l3Prerequisite Map — chapter by chapter✓ Confirmed /l4Chapter-by-Chapter Documentation✓ Confirmed /c1 (18 chapters)Chapter Anatomy Templates✓ Confirmed /c2Case Study Strategy✓ Confirmed /c3Hard Topics, Contested Claims, Aging Risk✓ Confirmed /c4Market Positioning✓ Confirmed /m1Feature List with Priority Tagging✓ Confirmed /m2Out of Scope✓ Confirmed /m3Adoption Risk Register✓ Confirmed /m4Publisher Proposal✓ Confirmed /p1Open Questions Log15 items open — compiled below
All sections present. Compiling.
DOCUMENT METADATA
FieldContentWorking titleThe AI Sherpa: A Practitioner’s Guide for Experiential LearningVersion1.0Date2026-03-21Author[Author name]TOC architectTic TOCStatusFull draft — pending /g2 auditOpen questions15 (see Section 9)Chapters18 across 5 partsBook typePractitioner handbook — hybrid structure
SECTION 1: BOOK CONCEPT SUMMARY AND THESIS
Concept Summary
This book teaches experiential learning professionals to use AI as a structured developmental companion — before, during, and after the experience — filling the gap left by Kolb (theoretical framework, no AI infrastructure), Schön (reflection model, no scalable tool), and every institutional assessment rubric that produces a form instead of a living document. It succeeds if the reader can design and deploy an AI-assisted reflection infrastructure — experience map, living journal, and AI Sherpa — that develops practical wisdom in students at a scale and depth no single advisor could achieve alone.
Thesis
“This book argues that AI deployed in experiential learning contexts is categorically different from AI deployed in classroom contexts — it is a Sherpa, not a teacher — which means that every design principle imported from AI-in-education literature into experiential learning programs produces the wrong tool for the wrong relationship, and this matters because the cost is not just inefficiency but the active undermining of the developmental process that makes consequential experience educative in the first place.”
The Payoff
When the Sherpa relationship is correctly understood and correctly designed, the developmental potential of experiential learning — practical wisdom, narrative identity, judgment under real stakes — can be realized at scale for the first time. Not because AI replaces the human advisor, but because AI carries the reflection infrastructure that no single human advisor could carry for 200 students simultaneously, freeing the advisor to do the interpretive and strategic work that only a human who knows the student as a person can do.
SECTION 2: LEARNER PROFILE
Primary Reader
An experiential learning professional at a university, professional school, or corporate early career program — co-op coordinator, study abroad advisor, clinical placement director, apprenticeship program manager, experiential learning faculty lead, career development professional.
What they already know: Kolb’s four-stage cycle by reflex; reflection frameworks and debrief protocols; their institution’s placement infrastructure and constraints; that some students extract enormous developmental value from placements while others complete the same experience and learn almost nothing.
What they do not know: What AI can actually do in a non-classroom context; that AI can hold longitudinal context across a student’s journal; that the placement decision itself can be made analytically against a developmental profile; that their advisor role changes — does not disappear — when a Sherpa handles the scaffolding at scale.
Prior misconceptions to dismantle:
“AI gives every student the same response” — the generic chatbot problem
“The same experience works for everyone who wants it” — optimizing for preference rather than developmental fit
“AI is a student-facing tool” — missing the advisor-facing half of the system
Motivation type: Professional with a mission. Will tolerate theory only if immediately connected to practice.
Secondary Reader
Graduate students in higher education administration, student affairs, and instructional design who encounter this book in a course. The book works for this reader but is not designed for them.
SECTION 3: THREE-ACT LEARNING ARC OVERVIEW
The Arc Statement
“This book takes the practitioner from the recognition that most students’ experiential learning potential is lost to a design failure — by first naming the failure and diagnosing why the wrong tools make it worse, then building the three-part infrastructure that constitutes the right tool, then demonstrating the judgment the system requires at its hardest moments: the end of the experience, the boundary the Sherpa must not cross, and the advisor conversation that the system makes possible.”
The Pebble
A student completes a six-month co-op at a Boston financial services firm. Well-evaluated. Offered a return position. Her co-op coordinator asks what she learned. She says: “I got really good at Excel modeling.” Three years later she is struggling with exactly the judgment problems — organizational navigation, advocacy for her own analysis, responding to being wrong in public — that the co-op had six months to develop. It did not. This is not a student failure. It is a design failure. The book is built on that sentence.
Act Structure
ActChaptersWhat it doesAct One — The Problem1–2Establishes the design failure; names the wrong model; introduces the frameworkAct Two — The Infrastructure3–10Builds the complete Sherpa system: taxonomy, experience map, living journal, MVAL, failure documentation, Sherpa Before and DuringAct Three — The Synthesis11–13Refiguration protocol; the thesis boundary; the advisor shiftOutside arc — Demonstration14–18Five domain field guides; the arc running under domain-specific constraints
Transition Conditions
Act One → Act Two: The practitioner holds three commitments: the developmental gap is a design failure (not a student failure), AI’s role is categorically a Sherpa relationship (not a teaching relationship), and they are willing to challenge a student’s placement preference on developmental grounds. Without these three, the Act Two tools are misused.
Act Two → Act Three: The practitioner can produce a developmental profile, design a living journal calibrated to that profile, configure and deploy Sherpa Before and During, and distinguish a Sherpa response that supports reflection from one that substitutes for it. Without these, Chapter 12 (the thesis chapter) lands as a warning, not an argument.
SECTION 4: CHAPTER-BY-CHAPTER TABLE OF CONTENTS
NAVIGATION NOTE FOR READERS
This book has two modes. Chapters 1–13 build the complete foundational argument and the full Sherpa infrastructure — read in sequence for professional development, staff onboarding, or graduate coursework. Chapters 14–18 are fully self-contained domain field guides — enter at the chapter written for your role. A Construct Quick Reference at the opening of each field guide chapter provides the operational definitions you need to begin immediately.
PART ONE — FOUNDATIONS: THE ARGUMENT
Sequential read. Two chapters. Makes the case and gives the diagnostic framework.
Chapter 1
The Gap: Why Having an Experience Is Not the Same as Learning from One
One-line descriptor: The practitioner diagnoses the design failure that converts developmental potential into resume lines — and names the 200-student structural constraint that no single advisor has ever been able to solve alone.
Arc position: Act One Two-sided learner flag: Practitioner-facing
Learning outcomes: 1.1 Distinguish between an experience that produces a resume line and one that produces practical wisdom — by naming the specific infrastructure conditions that determine which outcome occurs (Analyze) 1.2 Diagnose the reflection gap in their own program — identify where the infrastructure breaks down and what students are losing (Analyze) 1.3 Articulate why classroom AI tools are the wrong model for experiential learning, in terms specific enough for a conversation with a dean (Understand) 1.4 Name the 200-student problem and connect it to a specific failure they have observed in their own practice (Apply)
Opening case: The Boston co-op student — six months, well-evaluated, Excel skills instead of judgment. The recognition case. Worked example domain: University co-op, engineering discipline — thirty end-of-semester reflections, two that are different, one advisor who recognizes the difference and cannot produce more of it. Bridge: “Naming the failure is not enough. To build the solution, we need a framework precise enough to design against...”
Chapter 2
The Framework: Ricoeur, Kolb, and the Three Movements of Experiential Learning
One-line descriptor: The practitioner maps a student’s experience arc onto Ricoeur’s three phases and identifies where in Kolb’s cycle their program infrastructure is strongest and where it breaks down.
Arc position: Act One (closes with Act One → Act Two transition condition) Two-sided learner flag: Practitioner-facing Author briefing: Dropout risk chapter. Student narrative precedes framework name. Theory earns its place through recognition, not instruction.
Learning outcomes: 2.1 Map a specific student’s experience arc onto Ricoeur’s three phases (Apply) 2.2 Identify where in Kolb’s four-stage cycle their program infrastructure breaks down (Analyze) 2.3 Explain the refiguration concept to a student in motivating language — without using Ricoeur’s terminology (Apply) 2.4 Design a reflection prompt for each of Ricoeur’s three phases (Create)
Opening case: A nursing student who said “I just knew what to do” after a code — and could not articulate the knowing that saved a patient’s life. Prefiguration / configuration / refiguration named through her story before the terms appear. Worked example domain: Study abroad, liberal arts college — reflection essays rich with description, thin on analysis; director reframes “not developmentally ready” as “asked the wrong question.” Spiral construct: First encounter with Ricoeur’s three phases. Spiral returns in Chapter 11. Bridge: Act One transition condition stated explicitly before the reader turns to Chapter 3.
PART TWO — THE EXPERIENCE MAP
Sequential in professional development context; re-enterable by task.
Chapter 3
The Taxonomy: Profiling What a Student Needs to Develop
One-line descriptor: The practitioner applies the seven-tier taxonomy to produce a developmental profile — the information no interest inventory provides and no placement decision should be made without.
Arc position: Act Two (most load-bearing chapter in the book — its absence degrades the entire system) Two-sided learner flag: Practitioner-facing
Learning outcomes: 3.1 Apply the seven-tier taxonomy to profile a specific student — naming current strengths and capacity gaps (Apply) 3.2 Identify what a standard interest inventory reveals and what it conceals about developmental needs (Analyze) 3.3 Distinguish between a student who is underdeveloped in a capacity and one who has never been exposed to the conditions that develop it (Analyze) 3.4 Design a profiling conversation that surfaces developmental gaps a student would not self-report on a form (Create)
Opening case: Two students, same major, same GPA, same expressed interest — interest inventory produces identical recommendations; the taxonomy produces a profile that reveals why they are not the same. Worked example domain: University co-op, business discipline — second-cycle student whose performance review said “excellent” and whose developmental profile said “half-formed.” Production note: Chapter 3’s final exercise must produce a working developmental profile. Chapter 4 opens by using one. Bridge: “The developmental profile names what the student needs to build. The next question is: which experience builds it?”
Chapter 4
The Experience Map: Matching Developmental Need to Placement Type
One-line descriptor: The practitioner builds a structured placement recommendation — an experience map — that translates a developmental profile into a specific placement choice with reasoning the student can understand and the advisor can defend.
Arc position: Act Two Two-sided learner flag: Practitioner-facing (instrument); student-facing (the recommendation the practitioner delivers)
Learning outcomes: 4.1 Build an experience map for a specific student (Create) 4.2 Make the case to a student for a placement they would not have chosen for themselves — using their developmental profile as the argument (Apply) 4.3 Evaluate two placement options against a student’s developmental profile with explicit trade-off analysis (Evaluate) 4.4 Identify placement recommendation patterns driven by availability rather than developmental fit — and name the cost (Analyze)
Opening case: The London case — US student whose developmental profile indicates London but who wants Boston. The advisor has the experience map. Does the advisor have the language? Worked example domain: Study abroad program — the London case documented as the experience map in action. Bridge: “The experience map tells the student where to go and why. But arriving at the right place is not enough. What the student pays attention to when they get there determines what they bring back.”
Chapter 5
Pre-Experience Preparation: The Question to Carry In
One-line descriptor: The practitioner designs a pre-experience preparation protocol that translates the developmental profile into one or two focused developmental questions — and configures the Sherpa for the work before the experience begins.
Arc position: Act Two / Pivot chapter (last primarily conceptual chapter) Two-sided learner flag: Hybrid — practitioner designs; student carries the question
Learning outcomes: 5.1 Design a pre-experience preparation protocol that translates the developmental profile into focused developmental questions (Create) 5.2 Distinguish between orientation and developmental preparation (Analyze) 5.3 Brief a student on what the Sherpa will be watching for — in a way that increases attentiveness without producing performance anxiety (Apply) 5.4 Configure the Sherpa for a specific student’s pre-experience profile (Apply)
Opening case: Two students, same London employer, different preparation — one leaves with a checklist, one leaves with a question. Six months later, different journals. Worked example domain: Clinical placement, social work — second-year student whose focused question is “Where do I notice that I am managing my own distress rather than being present to the client’s?” Bridge: “The preparation is complete... What is not yet running is the companion that reads the journal, recognizes the patterns, and asks the questions that turn documentation into development.”
PART THREE — THE LIVING JOURNAL
Sequential in professional development context; re-enterable as implementation reference.
Chapter 6
The Living Journal: What It Is and Why Visual Matters
One-line descriptor: The practitioner designs a living journal structure that captures the texture of lived experience — visual, integrated, honest — and understands why the visual dimension is developmental, not decorative.
Arc position: Act Two Two-sided learner flag: Student-facing infrastructure (practitioner designs; student keeps)
Learning outcomes: 6.1 Distinguish a living journal from current documentation formats — naming what it captures that current formats do not (Analyze) 6.2 Explain the developmental function of visual documentation to a student who has never kept a visual journal (Apply) 6.3 Design a living journal structure for a specific deployment context (Create) 6.4 Evaluate a sample student journal against the living journal criteria (Evaluate)
Opening case: A study abroad student’s text journal vs. the photograph she took in the Makola market — and the analytical precision the image held that the text did not produce until she was asked about it. Worked example domain: Electrical trades apprenticeship — the panel sketch with the error circled, the question about the journeyman’s hands. Bridge: “Documentation without structure produces narrative, not analysis. The next chapter introduces the MVAL protocol...”
Chapter 7
The MVAL Protocol: Structuring Reflection for Practical Wisdom
One-line descriptor: The practitioner applies the MVAL protocol to structure student journal entries into analysis — and teaches the protocol to students in a way that produces internalization rather than mechanical compliance.
Arc position: Act Two Two-sided learner flag: Both — practitioner uses MVAL to read entries; teaches it to students to apply themselves Author briefing: Must position MVAL as an adaptation of a broader class of structured reflection protocols, not as a Boyle System advertisement (OQ-009).
Learning outcomes: 7.1 Apply the MVAL protocol to a specific student entry — producing an analysis of developmental progress and Sherpa probe direction (Apply) 7.2 Teach the MVAL protocol to a student in a way that produces internalization (Apply) 7.3 Diagnose what is missing from a student’s MVAL entry and design a Sherpa prompt that addresses the gap without naming it prescriptively (Analyze) 7.4 Adapt the MVAL protocol for a specific deployment domain (Create)
MVAL fields: What happened / Why it mattered / How you responded / Environment / Results / Questions
Opening case: The client meeting — same event, unstructured entry vs. MVAL-structured entry. The unstructured entry produces a note to self. The MVAL entry produces the question the student will still be thinking about next week. Worked example domain: Corporate early career rotational program — first-year analyst whose “environment” field consistently describes the room rather than the organizational dynamics. Bridge: “MVAL gives the student a structure for documenting what happened and why it mattered. But there is one category of event that MVAL alone cannot address — not because the protocol fails, but because the student’s instinct is to omit the event entirely.”
Chapter 8
Failure as First-Class Artifact: Documenting What Went Wrong
One-line descriptor: The practitioner designs a failure documentation protocol that creates structural safety for honest reflection — because failures are the primary raw material for the learning that only consequential experience can produce.
Arc position: Act Two Two-sided learner flag: Both — practitioner designs structural conditions; protocol shapes student documentation Author briefing: This chapter is affirmative, not remedial. Failure documentation is not the medicine you take when things go wrong. It is the practice that determines whether consequential experience produces wisdom.
Learning outcomes: 8.1 Design a failure documentation protocol with genuine structural safety (Create) 8.2 Distinguish a failure entry that produces developmental reflection from one that produces self-criticism without analysis — and design Sherpa prompts that move students from the latter to the former (Analyze) 8.3 Identify program design features that discourage failure documentation and propose one structural change (Evaluate) 8.4 Use a student’s failure documentation to identify a developmental pattern not visible from success entries alone (Analyze)
Opening case: A senior co-op student with two journals — the official one (the highlight reel) and the personal notebook (the developmental record). He kept two because the official one was not safe for the honest material. That is not a student failure. That is a program design failure. Worked example domain: Clinical placement, nursing — the medication error documented procedurally in the official journal, developmentally in the private section. Primary documented failure case: This chapter’s worked example is the book’s primary documented failure case — the infrastructure failed to create safety, and the result is a journal that cannot teach. Bridge: “The infrastructure is built... What is not yet running is the companion that reads the journal, recognizes the patterns, and asks the questions that turn documentation into development.”
PART FOUR — THE AI SHERPA IN PRACTICE
Sequential in professional development context; re-enterable as deployment reference. Five chapters covering Act Two deployment (Chapters 9–10) and Act Three synthesis (Chapters 11–13).
Chapter 9
The Sherpa Before: Profile, Map, and Focused Attention
One-line descriptor: The practitioner configures the Sherpa for a specific student’s pre-experience profile — translating the developmental map into Sherpa parameters before the experience begins.
Arc position: Act Two (most prerequisite-dense chapter; first deployment chapter) Two-sided learner flag: Practitioner-facing Production note: “Getting Started” minimum viable deployment note must be present in this chapter (OQ-013).
Learning outcomes: 9.1 Configure a Sherpa for a specific student’s pre-experience profile — translating the experience map into Sherpa parameters (Apply) 9.2 Design the pre-experience Sherpa conversation sequence for a student entering a high-stakes placement (Create) 9.3 Distinguish between a Sherpa that prepares a student for an experience and one that reduces the experience’s developmental challenge (Analyze)
Opening case: The practitioner who configured the same generic Sherpa for 200 students and found it producing the same three prompts for everyone — and the specific configuration that changes that. Worked example domain: Northeastern co-op, business analytics — second-cycle student, Tier 5 and Tier 6 focus, pattern recognition flags for attribution patterns. Spiral construct: First operational encounter with the Sherpa — introduced conceptually in Chapters 1–2, deployed here. Bridge: “The Sherpa is configured. The experience has begun... The question now is: what does the Sherpa do when a journal entry arrives that tells it something important is happening?”
Chapter 10
The Sherpa During: Companion, Not Coach
One-line descriptor: The practitioner deploys the Sherpa’s core during-experience function — pattern recognition and Socratic question — and masters the distinction between a Sherpa response that supports reflection and one that substitutes for it.
Arc position: Act Two (closes Act Two; opens Act Three’s threshold) Two-sided learner flag: Both — practitioner designs and monitors; Sherpa interacts with students Author briefing: The worked example is load-bearing. The London student’s Week 3 entry and the Sherpa’s single-sentence response is the moment the “question not answer” principle becomes operational. If this example is generic, the principle stays theoretical.
Learning outcomes: 10.1 Design a Sherpa prompt sequence for a student whose journal entries suggest avoidance of a developmental challenge (Create) 10.2 Distinguish between a Sherpa response that supports reflection and one that substitutes for it (Analyze) 10.3 Apply the three core Sherpa prompts — What surprised you? What did you commit to? What would you do differently? — to a specific student entry (Apply) 10.4 Identify the point in a student’s experience arc where the Sherpa should escalate to a human advisor (Evaluate)
Opening case: Same journal entry, two Sherpa responses. Response A gives advice (three sentences). Response B asks “What did you start to say?” One produces strategy. One produces the judgment the student withheld. Worked example domain: Study abroad, the London student — Week 3, the team meeting where she went invisible, the Sherpa’s one-sentence prompt, and Week 3 Entry 8 written two days later. Bridge: Act Two → Act Three transition stated explicitly: “The experience is ending... Most of the time that reflection will produce a summary. Occasionally — in programs with the right infrastructure — it will produce something different.”
Chapter 11
The Sherpa After: Refiguration and the Capstone Narrative
One-line descriptor: The practitioner designs the post-experience Sherpa sequence that guides a student through Ricoeur’s third phase — from the raw material of the journal to a coherent narrative of what changed and why.
Arc position: Act Three Two-sided learner flag: Both — practitioner designs the sequence; student writes the capstone Spiral return: Ricoeur’s three phases — escalation from recognition (Chapter 2) to designing the conditions that make refiguration happen reliably. Must explicitly name the escalation. Domain note: Chapter 11 opening should use a corporate early career domain (per OQ-008 — clinical domain at three-case cap). Character Thread D (the business junior) is the primary longitudinal case for this chapter.
Learning outcomes: 11.1 Design a post-experience Sherpa sequence that guides a student through Ricoeur’s refiguration phase (Create) 11.2 Evaluate a student’s capstone reflection against the refiguration criteria — distinguishing integration from summary (Evaluate) 11.3 Design a capstone reflection protocol for their specific deployment context (Create)
Opening case: [Corporate early career domain — per OQ-008. Character Thread D’s capstone documented: “I spent the first two months of this placement reporting what happened in rooms. In the third month I started reporting what I did in rooms.”] Spiral opening: “Chapter 2 introduced Ricoeur’s three phases as a framework for understanding what is happening when an experience becomes formative. This chapter asks a harder question: how do you design the conditions that make refiguration happen reliably, rather than waiting to see if it happens on its own?” Capstone criteria: Specific journal evidence / self-revision / forward projection / unresolved questions Bridge: “The student has refigured... And somewhere in that process — in the before, the during, or the after — there were moments where the Sherpa could have done something it shouldn’t have.”
Chapter 12
What the Sherpa Cannot Do: The Boundary That Makes Development Possible
One-line descriptor: The practitioner identifies and corrects Sherpa dependency — and understands why the boundary between guidance and doing is not a limitation of the tool but the condition that makes the developmental process work.
Arc position: Act Three — THESIS CHAPTER Two-sided learner flag: Both — practitioner designs against dependency; boundary is visible in student behavior Author briefing (fourth and final): This chapter is written as argument, not disclaimer. The boundary is not a risk to manage. It is the design principle that makes the system work. Every sentence defends that claim. Written by the lead author, not a contributor. First chapter reviewed by the editor after drafting.
Learning outcomes: 12.1 Identify Sherpa dependency — recognize journal entry patterns and student behaviors signaling avoidance of judgment rather than development of it (Analyze) 12.2 Redesign a Sherpa prompt that is producing dependency — transform a response that answers into a question that requires the student to answer (Apply) 12.3 Articulate the boundary to a student who is frustrated by the Sherpa’s refusal to give answers (Apply) 12.4 Evaluate their deployed Sherpa configuration against the dependency risk criteria (Evaluate)
Opening case: The clinical rotation student whose entries became shorter and more question-shaped until she was writing to get an answer rather than to do analysis. “The Sherpa keeps asking me questions instead of helping me.” Her frustration is honest. Her misunderstanding is architectural. Five dependency patterns: Entry length decreasing / entries question-shaped / MVAL “questions” field dominant / emotional escalation at Sherpa questions / waiting rather than deciding Primary documented failure case: The clinical student’s dependency as infrastructure failure — the Sherpa produced an unintended outcome; the chapter documents the diagnostic and redesign. Bridge: “The Sherpa is doing what it was designed to do... What remains is the practitioner’s own role in this system — not the Sherpa’s role, but the human advisor’s.”
Chapter 13
The Advisor Shift: From Gap-Filling to Strategy
One-line descriptor: The practitioner redesigns their advising protocol for a Sherpa-supported context — and discovers that the advisor role, freed from scaffolding work the Sherpa now carries, becomes more powerful, not smaller.
Arc position: Act Three — Arc resolution Two-sided learner flag: Practitioner-facing throughout Closing note: Chapter 13 is the arc resolution. The practitioner who has deployed the full infrastructure returns to their advising practice transformed. The liberation reframe must be structural, not inspirational — demonstrated through the redesigned conversation protocol and the caseload management system, not through aspirational language.
Learning outcomes: 13.1 Redesign their advising conversation protocol for a Sherpa-supported context (Create) 13.2 Distinguish between a gap-filling advising conversation and a strategic one (Analyze) 13.3 Use the Sherpa’s journal pattern summary as the opening document for an advising conversation (Apply) 13.4 Design a caseload management protocol for a Sherpa-supported advising context (Create)
Opening case: The same co-op coordinator with the same student across two cycles. First cycle: “what happened, what did you learn.” Second cycle with the Sherpa: “the Sherpa flagged three recurring patterns. The one I want to talk about is this one. Tell me what you think it means for where you go next.” Worked example domain: Co-op program — Character Thread D’s second cycle debrief, using the Sherpa’s pattern summary as the opening document. Bridge to Part Five: “The argument is complete... What remains is the demonstration — not the proof, which is already made, but the showing: what the full system looks like when it is running in five different domains.”
PART FIVE — THE FIELD GUIDES
Outside the arc. Domain demonstration. Fully self-contained. Enter at your chapter.
Shared structure for all five chapters:
“If you are starting here” navigation note
Construct Quick Reference (six constructs, one page, identical closing line)
Domain context (2–3 pages — specific enough for practitioner recognition in paragraph 1)
Full system deployment guide (pre-experience / during / after)
Domain-specific failure modes (3–5, domain-specific)
Stakeholder section (includes at least one stakeholder conflict)
Implementation checklist (12–18 items, binary completion criteria)
Three domain-specific assessable exercises
Further resources (5–8 annotated sources)
Chapter 14
The Co-op Coordinator’s Field Guide
One-line descriptor: Full system deployment for six-month university co-op placements — including multi-cycle developmental arcs, employer partner relationships, and the Northeastern model as the flagship case.
Domain context: Six-month placements, multi-cycle structure, employer evaluation integration, Northeastern model as benchmark. The specific challenge: employer is a stakeholder in performance evaluation; journal privacy must be designed, not assumed.
Learning outcomes: 14.1 Deploy the full Sherpa infrastructure for a six-month co-op placement (Apply) 14.2 Design a multi-cycle developmental arc across two or three placements (Create) 14.3 Adapt the Sherpa configuration for employer relationship complexity (Apply) 14.4 Evaluate developmental outcomes of a co-op cohort using journal pattern data (Evaluate) 14.5 Make the case to an employer partner for the living journal and Sherpa infrastructure (Apply)
Flagship case: Three-cycle arc — Character Thread D, Northeastern co-op model, first cycle abroad through senior-year strategy placement. Domain-specific failure modes: Employer-visibility suppression of failure documentation; multi-cycle profile drift (each advisor starts from scratch); the return-offer trap (strong performance review concealing developmental plateau). Stakeholder conflict: Employer’s evaluation interest vs. student journal privacy — explicitly designed and resolved.
Chapter 15
The Study Abroad Advisor’s Field Guide
One-line descriptor: Full system deployment for international placements — with specific configuration for cross-cultural disorientation as a developmental resource and re-entry as a designed protocol, not an afterthought.
Domain context: Highest density of Tier 3 developmental opportunity; highest rate of unrealized potential. The specific challenge: disorientation is a developmental resource, not a logistical problem. Re-entry is the most underdesigned phase.
Learning outcomes: 15.1 Deploy the full Sherpa infrastructure for a study abroad placement with cross-cultural disorientation configuration (Apply) 15.2 Design an experience map that makes the developmental case for a specific international placement (Create) 15.3 Configure Sherpa prompts for the disorientation phase (Apply) 15.4 Design a re-entry protocol that prevents developmental gains from dissipating in the transition home (Create) 15.5 Evaluate a study abroad student’s journal for evidence of cross-cultural capacity development — distinguishing observation of cultural difference from genuine perspective-taking (Evaluate)
Flagship case: Character Thread C — the London student, full arc from experience map through refiguration. Domain-specific failure modes: Disorientation managed as logistical problem rather than developmental resource; re-entry without designed integration (refiguration abandoned at the airport); the tourist journal (rich description, zero perspective-taking).
Chapter 16
The Clinical Placement Director’s Field Guide
One-line descriptor: Full system deployment in the highest-stakes experiential learning context — with specific design for failure documentation under liability constraints, clinical error processing, and professional identity formation under evaluation pressure.
Domain context: Nursing, medicine, allied health, social work, law. Errors have real consequences. Failure documentation carries liability. Student is being evaluated for professional licensure. The specific challenge: clinical errors are simultaneously the most important developmental artifacts and the most likely to be suppressed or documented defensively.
Learning outcomes: 16.1 Deploy the full Sherpa infrastructure in a clinical placement context with failure documentation safety design (Apply) 16.2 Design a failure documentation protocol for a clinical context that satisfies reflection and does not conflict with mandatory reporting (Create) 16.3 Configure Sherpa prompts for a student processing a clinical error or near-miss (Apply) 16.4 Distinguish between a student developing clinical judgment and one developing clinical compliance — using journal entries as evidence (Analyze) 16.5 Adapt the capstone reflection protocol for clinical professional identity formation (Create)
Flagship longitudinal case: Character Thread B — the nursing student from Chapter 2, full clinical arc through professional identity formation. Critical production note: Mandatory reporting boundary language requires institutional legal review before publication (OQ-006). Privacy boundary template must not be released before legal review is complete. Domain-specific failure modes: Mandatory reporting conflict with private documentation; clinical error suppression under evaluation pressure; the compliance-not-judgment development pattern.
Chapter 17
The Workforce Development Coordinator’s Field Guide
One-line descriptor: Full system deployment in trades and apprenticeship contexts — with specific adaptations for embodied skill development, the master-apprentice relationship, and the living journal as a visual document of physical learning.
Domain context: Electricians, plumbers, HVAC, welding, construction. The primary learning is in the hands. The master-apprentice relationship is the oldest Sherpa relationship in human history. The specific challenge: a text-only journal is inadequate for capturing embodied skill development; the visual dimension is not an enhancement here — it is the primary documentation mode.
Learning outcomes: 17.1 Deploy the full Sherpa infrastructure in a trades apprenticeship context with embodied skill adaptations (Apply) 17.2 Design a living journal format appropriate for embodied skill development (Create) 17.3 Configure Sherpa prompts for the master-apprentice relationship (Apply) 17.4 Make the case for Sherpa infrastructure to a trades program administrator skeptical of documentation approaches (Apply) 17.5 Adapt the experience map for workforce development contexts (Create)
Flagship case: Character Thread E — the electrical apprentice, full deployment from taxonomy profile through multi-year apprenticeship arc. Theoretical connection: The Pirsig tradition (Zen and the Art of Motorcycle Maintenance) and the AI and the Art of Motorcycle Maintenance companion volume — quality as a relationship between the craftsperson and the work. Author briefing: The trades chapter is not simplified content for less-educated learners. Trades apprentices develop expert judgment in domains requiring both physical precision and conceptual mastery. The adaptation is translation, not simplification.
Chapter 18
The Corporate Early Career Program Manager’s Field Guide
One-line descriptor: Full system deployment for rotational programs and first assignments — with specific adaptations for organizational culture navigation, the student-to-professional transition, and the dual-use refiguration document.
Domain context: Structured rotational programs, first assignments, transition from student to professional. The specific challenge: organizational culture navigation is the primary developmental variable and the thing most likely to be documented around rather than through. The dual-use tension: employee developmental ownership vs. program talent development data.
Learning outcomes: 18.1 Deploy the full Sherpa infrastructure in a corporate early career context with organizational culture navigation configuration (Apply) 18.2 Design an experience map for a corporate rotational program (Create) 18.3 Configure the Sherpa for organizational culture navigation without producing political risk (Apply) 18.4 Adapt the refiguration protocol for a dual-use corporate context (Create) 18.5 Evaluate developmental outcomes of an early career cohort using journal pattern data and produce a program-level recommendation (Evaluate)
Flagship case: Corporate rotational analyst — organizational culture as the developmental variable that no case study could have taught. Critical production note: Dual-use refiguration document requires explicit program policy and consent framework design (OQ-007). The tension between employee ownership and program data interest must be named honestly — not resolved by clever document design. Domain-specific failure modes: Culture navigation documented around rather than through; dual-use document eroding employee developmental ownership; rotation sequence optimized for organizational exposure rather than developmental arc.