Why a Consistent Structure Serves Diverse Professional Contexts
The five walkthroughs that follow this section address roles that differ substantially from one another in the nature of their daily work, the regulatory environment they operate in, the tools they use, the documents they produce, and the compliance obligations they carry. A management consultant working on strategy engagements for corporate clients operates in a fundamentally different professional context from a paralegal supporting litigation practice, a claims analyst assessing insurance losses, a financial analyst producing management reporting, or an operations manager coordinating a complex operational function. The knowledge, the judgment, the professional standards, and the consequences of error differ meaningfully across these five roles.
Despite these differences, the walkthroughs are built around a consistent structure. Each element of that structure is present in every walkthrough, in the same sequence, addressing the same category of information in the same way for each role. This consistency is not an organisational convenience. It reflects a substantive argument about how professionals learn to adapt general principles to specific contexts.
When the same analytical framework is applied consistently to five different professional situations, the reader develops two things simultaneously: a concrete understanding of how the framework applies in each specific role, and an increasingly clear sense of the underlying logic that connects the specific applications to each other and to the framework itself. The management consultant's knowledge base structure is different from the paralegal's, but the principles that govern why each structure takes the form it does are the same. The claims analyst's model selection is different from the financial analyst's, but the four-dimension decision framework that produces those different selections is identical. The operations manager's quality control checklist is different from the consultant's, but the underlying verification logic is common to both.
This layered understanding, where the specific applications of the five roles rest on a common analytical foundation that becomes progressively more visible as the walkthroughs proceed, is what allows a professional whose exact role is not represented in the five to extract the principles relevant to their own situation. An underwriter reading the claims analyst walkthrough will find much that directly applies to their work, and the analytical framework visible beneath the role-specific details will allow them to adapt what does not directly apply. A compliance officer reading the financial analyst walkthrough will be able to map the relevant elements to their own knowledge management needs and workflow patterns. A real estate solicitor reading the paralegal walkthrough will recognise the document management and privilege considerations and be able to apply them to their own practice context.
The consistent structure of the walkthroughs is therefore designed to serve not only the five roles explicitly described, but the much wider range of professional contexts in which the professionals reading this material actually work.
The Eight Elements of Each Walkthrough
Each walkthrough contains eight elements, arranged in a deliberate sequence that moves from the professional's current situation, through the construction of their AI practice, to its operation and the discipline that sustains its quality. The sequence mirrors the process a professional would actually follow in building their own AI practice, which means the walkthroughs function both as illustrations of the finished practice and as guides to the process of building it.
Meet the Professional
The first element introduces a realistic professional persona: a named individual with a specific role, a specific organisational context, a typical working week, and the particular pressures and frustrations that characterise their professional situation. The persona is not a case study of an exceptional practitioner. It is a representative portrait of a competent professional at an intermediate career stage, working in a realistic organisational environment with realistic constraints on time, technical capability, and institutional support for AI adoption.
The purpose of introducing a specific persona rather than describing a generic role is to ground the walkthrough in the texture of actual professional experience. Principles described in the abstract can be understood intellectually without generating a clear sense of what it would feel like to apply them. A specific person, with a specific Monday morning, specific clients, and specific deadlines, makes the abstract concrete in a way that supports practical application rather than merely theoretical understanding.
The persona's organisational context is designed to be representative rather than exceptional. The management consultant works in a mid-sized firm with reasonable but not unlimited access to technology resources. The paralegal works in a firm with established information governance policies that constrain some AI use. The claims analyst works in an insurance organisation whose IT infrastructure is typical of the sector. These are not idealised working environments. They are environments that will feel familiar to most professionals reading the material, which means the AI practices built within them are practices that most professionals can realistically replicate.
The Before State
The second element describes the professional's current working situation before any AI practice is in place: how they manage their files, how they approach their most time-consuming tasks, where they experience the most friction, and what the cumulative cost of their current approach is in terms of time, quality, and professional satisfaction. The before state is described with the same honesty and specificity as the after state. It does not exaggerate the dysfunction of the pre-AI situation in order to make the AI practice appear more dramatic in its impact.
The before state serves two functions. First, it establishes the baseline against which the after state can be assessed. Without a clear picture of how the professional worked before, the time savings and quality improvements described in the after state are figures without context. Second, it identifies the specific pain points in the professional's current workflow that the AI practice is designed to address. This identification is important because it makes explicit the connection between the AI practice elements that follow and the real professional problems they are solving. The knowledge base setup, model selection, and integration choices in each walkthrough are not generic best practices applied indiscriminately. They are specific responses to the specific limitations of the before state.
Knowledge Base Setup
The third element describes the professional's personal knowledge base in the specific terms that make it applicable rather than merely illustrative. This means a specific folder structure, named to reflect the actual categories of work the role involves. Specific file naming conventions, with examples drawn from the actual document types the role produces. Specific context documents, described in enough detail to allow the reader to understand what each one contains and why it matters for the AI-assisted work that follows.
The knowledge base setup described in each walkthrough applies the principles from Module 4.1 to the specific professional context, demonstrating concretely how the general principles of shallow folder hierarchy, consistent naming conventions, README documents, client background documents, project scope documents, terminology glossaries, and decision logs translate into a working system for a specific role. The setup is realistic in scope: it is something a professional could build in a few hours, not something that requires weeks of preparatory work before AI assistance becomes available.
Model and Tool Selection
The fourth element explains the professional's AI model selection and integration configuration, applying the decision frameworks from Modules 4.2 and 4.3 to their specific situation. This element is notable for what it includes alongside the selection itself: the explicit reasoning that connects the professional's task profile, sensitivity requirements, accuracy threshold, and platform integration needs to the model and integration choices they have made. The reasoning is included because the selection for a specific role may not be the right selection for every professional in that role, and the reader needs to understand the logic well enough to assess whether the same choice applies to their own situation or whether their specific context calls for a different configuration.
The model and tool selection element also addresses what the professional has chosen not to do: which integrations they considered and decided against, which AI features they have access to but have not activated, and why. These omissions are as instructive as the inclusions, because they demonstrate the disciplined selectivity that the integration strategy framework from Module 4.3 is designed to produce.
Three Core Workflows
The fifth element is the operational centrepiece of each walkthrough: a step-by-step description of the three AI-assisted workflows that deliver the most value in the professional's working week. The workflows are selected to represent the highest-frequency and highest-value AI-assisted tasks in the role, not the most technically impressive AI applications or the most comprehensive range of use cases. Three workflows is a deliberate constraint. It reflects the principle, established in Module 4.3, that a well-built AI practice begins with a small number of thoroughly understood and reliably executed workflows rather than a large number of partially understood ones.
Each workflow is described with enough procedural specificity to be actionable: the prompt structure, the context documents referenced, the data submitted, the output reviewed, the verification steps applied, and the way the output is incorporated into the professional's work. This specificity is what allows the walkthroughs to function as practical guides rather than conceptual illustrations. A professional reading a workflow description should be able to follow the same steps in their own work, adapting the specific content to their own context while applying the same procedural structure.
Quality Control Checklist
The sixth element addresses how the professional verifies AI outputs before they leave their desk. The quality control checklist is role-specific in its content because the verification requirements for a paralegal reviewing an AI-drafted legal research memo are different from those for a financial analyst reviewing an AI-generated variance commentary, and both are different from those for an operations manager reviewing an AI-drafted team briefing. The checklist for each role reflects the specific accuracy requirements, professional standards, and potential consequences of error that characterise that role's work.
The quality control element is placed before the after state deliberately, because the after state's description of time saved and quality improved is only valid if the quality control practices it rests on are actually being applied. The time savings described in the after state are net of the verification time required by the quality control checklist. A professional who applies the AI workflows without the associated quality control will see different, and likely worse, results than the after state describes, because unverified AI outputs introduced into professional work produce a different outcome from AI outputs that have been appropriately checked.
The After State
The seventh element describes the professional's situation after their AI practice has been in place for a sufficient period to have matured: typically twelve to sixteen weeks of consistent use following the twelve-week build plan described at the close of the module. The after state is specific about what has changed, how much time has been recovered per week, which aspects of work have improved in quality, and which tasks remain entirely outside the AI practice and are still performed manually.
The after state is deliberately modest in its claims. The time savings described are based on the high-frequency, high-value workflows identified in the before state, not on a theoretical maximum of every task the professional performs. The quality improvements described are those that can be attributed specifically to the AI practice, not global claims about the professional's overall output quality. And the list of tasks that remain outside the AI practice is included specifically to counter the tendency to overclaim AI's contribution, maintaining an accurate picture of where professional judgment remains the primary driver of quality.
Common Mistakes
The eighth and final element of each walkthrough addresses the specific errors and pitfalls that professionals in this role most frequently encounter when building or operating an AI practice. These are not the generic integration mistakes addressed in Section 7 of Module 4.3, which apply across all roles. They are role-specific mistakes that arise from the particular characteristics of the work, the particular sensitivities of the data involved, or the particular pressures of the professional context.
Placing common mistakes at the end of each walkthrough rather than at the beginning reflects a deliberate pedagogical choice. Mistakes are most instructive when the reader already has a clear understanding of the correct practice from which the mistakes represent deviations. A list of mistakes presented before the correct practice has been described is a list of abstractions. A list of mistakes presented after the professional, their setup, their workflows, and their quality control practices have been described in detail is a list of specific, recognisable departures from a known standard. The reader who has absorbed the walkthrough in sequence will understand exactly why each mistake matters and precisely what the correct alternative looks like.
How to Use the Walkthroughs Regardless of Your Role
The five roles described in this module cover a significant portion of the professional services workforce, but they do not cover all of it. Many professionals reading this material will work in roles that are adjacent to one of the five, substantially different from all of them, or at a level of seniority or specialisation that the representative personas do not precisely reflect.
For professionals whose role closely resembles one of the five, the relevant walkthrough is a direct model: the specific knowledge base setup, model selection, integration choices, and workflows can be adopted with adaptations for the specifics of the professional's own organisation, tool stack, and working patterns.
For professionals whose role is adjacent to one of the five, the most productive approach is to read the walkthrough for the closest role as a primary model, identify the elements that transfer directly to their own context, and use the underlying framework to derive the elements that need to be adapted or replaced. An underwriter whose work shares significant characteristics with the claims analyst walkthrough will find that the knowledge base setup and quality control principles transfer closely, while the specific workflows and model selection reasoning may need to be adjusted for the different task profile of underwriting work.
For professionals whose role is substantially different from all five, the walkthroughs function primarily as demonstrations of the framework in action. Reading across multiple walkthroughs reveals the analytical logic that connects the specific role-based choices to the general principles of Modules 4.1 through 4.3, and this logic provides the foundation for building a walkthrough-equivalent for their own role. The eight-element structure is the template. The principles from the preceding modules are the building materials. The walkthroughs are five examples of what can be constructed from those materials, not an exhaustive catalogue of the only constructions possible.