Industry and Domain Knowledge

Executive summary

Generic AI patterns fail when you cannot speak the client's industry language, trace money through their value chain, or name the regulators and systems that govern change. Industry and domain knowledge is the capability that turns "we could use RAG here" into a credible proposition: you know how the business makes money, where friction lives, who must approve what, which data is trustworthy, and which AI use cases survive audit—not just demo well.

When to use this page

• You are entering a new industry vertical for the first time (financial services, healthcare, retail, telco, energy, manufacturing, public sector, professional services, SaaS).
• A client uses domain terms you do not yet understand (suitability, loss ratio, prior auth, SKU, churn, NERC, GxP, procurement gateway).
• Stakeholders challenge whether your design reflects how work actually happens—not how a product brochure describes it.
• You need to size controls, data boundaries, and rollout risk to industry norms rather than generic AI risk checklists.
• You are preparing a proposal, discovery workshop, or architecture review and must demonstrate domain credibility in the first meeting.
• You completed topics 01–02 and need to ground strategy and financial framing in a specific sector context.

Executive view

Focus on **Why this matters**, the two industry scenarios, and the **DeliverableBox** outputs. Ask whether the team can explain how the client makes money, name three regulatory constraints, and articulate one AI opportunity that maps to a measurable KPI—not a technology trend.

Technical view

Work through every **Learn** subsection and build the domain glossary, process brief, and regulatory constraint list before proposing architecture. Ban vendor and model names until the problem statement uses industry vocabulary correctly.

Why this matters

An AI Solution Engineer who lacks domain knowledge produces designs that are technically plausible and commercially irrelevant. The failure mode is predictable: you propose a retrieval assistant over documents that are not authoritative, automate a step that compliance forbids, or optimise a metric the business does not manage. Partners and client executives detect this within minutes—they hear generic language, wrong acronyms, or solutions that ignore how money, risk, and approval actually flow.

Domain knowledge is not memorising an industry Wikipedia page. It is the ability to produce artefacts that survive challenge: a glossary your client SME does not correct, a process map operations recognises, a regulatory constraint list risk accepts, and an AI opportunity statement tied to a KPI the CFO already tracks. This is why Stage 1 pairs industry knowledge with business fundamentals and strategy: AI value is always expressed in industry-specific outcomes—loss ratio, readmission rate, fill rate, mean time to repair, case backlog, net revenue retention—not "better UX" or "AI adoption."

On live engagements, domain fluency determines staffing credibility, discovery quality, and scope control. If you know that insurance claims triage is constrained by fair treatment rules and that adjuster notes are often unstructured but legally sensitive, you will not propose unsupervised auto-settlement as a phase-one pilot. If you know that wealth management research assistants must respect inducements and suitability language, you will design citation and escalation paths before model selection. Industry knowledge is the filter that separates viable AI patterns from impressive demos.

Weak domain knowledge also creates delivery risk. Integration assumptions fail when you do not know that the policy admin system is the system of record but the CRM holds the customer narrative. Data science work stalls when you treat "customer" as one entity across banking, insurance, and wealth silos. Change fails when you ignore union rules, clinical governance, or procurement category strategies. Strong domain knowledge front-loads these constraints into discovery so architecture and governance are sized correctly from the start.

Learn

Industry fluency follows a repeatable sequence—economics, value chain, stakeholders, systems and data, regulation, AI opportunities, client proposition—the same seven-part structure used in Domain Knowledge Gathering. Master each cluster below as a subsection you can teach back with a worked example, not a bullet you skimmed once.

Industry economics

Definition. Industry economics describes how organisations in a sector create, capture, and defend value: revenue models, cost structures, margin drivers, capital intensity, competitive dynamics, and the external pressures (regulation, technology, macro cycles) that reshape investment priorities.

Engagement use. Before proposing AI, answer: where does margin come from, and what is under pressure? In retail banking, net interest margin and cost-to-income dominate; in SaaS, net revenue retention and gross margin; in manufacturing, OEE and scrap rate; in healthcare providers, case mix and length of stay. Your opportunity statement must connect to an economic lever the executive committee already discusses. Use public filings, annual reports, industry analyst notes, and client strategy decks—not blog posts—to build a one-page economics summary.

Pitfalls.

• Treating all "financial services" as one economics story (retail banking, insurance, payments, and asset management have different margin drivers).
• Quoting AI ROI without the client's baseline KPI definitions (their "cost per contact" may exclude fraud ops or compliance QA).
• Ignoring capital constraints: regulated industries may prefer OPEX SaaS; public sector may require capex approval paths.
• Assuming growth-stage SaaS economics apply to a mature utility with dividend obligations.

Worked example. A UK general insurer reports combined ratio above 100%—claims and expenses exceed premium. Strategic priority: reduce loss ratio and expense ratio without harming retention. An AI opportunity framed as "GenAI for marketing copy" fails alignment. Framing "FNOL triage assistant reducing leakage and adjuster re-work on 40% of low-complexity claims" connects to economics the board already tracks. You size impact as: claims volume × triage time × loaded adjuster cost × error reduction—not "hours saved typing."

Value chains and operating processes

Definition. The value chain is the end-to-end sequence of activities that delivers the product or service customers pay for—from demand generation through fulfilment, servicing, and renewal or exit. Operating processes are the repeatable workflows, handoffs, controls, and exceptions within that chain.

Engagement use. Map the chain before mapping architecture. Mark each step as customer-facing, operational, risk/control, finance/reporting, or technology-enabled. Identify bottlenecks, rework loops, and manual bridges (spreadsheet exports, email approvals, duplicate data entry). AI opportunities usually sit where high-volume cognitive work meets structured decision rules—but only if the step is allowed to change. Your process brief becomes the backbone for discovery workshops, SIPOC diagrams, and later integration design.

Pitfalls.

• Mapping the ideal process from a policy PDF instead of the messy process from interviews.
• Collapsing front-office and back-office steps that have different owners and SLAs.
• Missing exception paths—which often consume more effort than happy path.
• Proposing automation on a step that exists primarily as a control (four-eyes check, maker-checker).

Worked example. Retail bank servicing chain: contact → authenticate → intent ID → policy lookup → action (payment, dispute, closure) → confirmation → QA sample → complaint escalation. Metrics: average handle time (AHT), first contact resolution (FCR), quality score, complaint rate. AI fit: policy Q&A with citations for Tier-1 agents on lookup-heavy intents (often 30–45% of volume), not autonomous account changes. Process map shows human approval remains on high-risk actions—design respects the control point.

Stakeholders and decision dynamics

Definition. Industry stakeholders are the roles and functions that own outcomes, budgets, risk, data, and operations—with sector-specific titles, incentives, and veto power. Decision dynamics describe who must say yes, who can say no, and who suffers if the project fails quietly.

Engagement use. Build a stakeholder map per industry template. In financial services: business sponsor, CRO/compliance, model risk, data governance, IT security, operations, vendor management. In healthcare: clinical leadership, CMIO, privacy officer, nursing ops, revenue cycle. In manufacturing: plant manager, quality/regulatory affairs, OT security, maintenance, supply chain. Identify the economic buyer, technical buyer, risk approver, and daily users separately—their success metrics conflict by design. AI proposals must address each group's fear: compliance sees conduct risk; ops sees workload disruption; IT sees integration debt.

Pitfalls.

• Single-threading to an enthusiastic sponsor without risk engagement.
• Treating "the business" as one homogenous approver.
• Ignoring middle-management incentives (team leads measured on QA scores may resist "AI assist" that changes scoring).
• Forgetting indirect stakeholders: unions, clinical ethics boards, auditors, reinsurers, OEM partners.

Worked example. Wealth management research assistant: sponsor is Head of Investment Content; risk approver is Compliance (inducements, suitability); users are analysts and advisers; IT owns Microsoft 365 and archive retention. Compliance veto trigger: uncited recommendation language or research ranked by payment-for-research relationships. Design requirement emerges from stakeholders, not from model features: citation to source paragraph, suitability disclaimer templates, audit log of prompts and outputs.

Systems, data and integration reality

Definition. Every industry runs on a portfolio of systems of record, workflow engines, data warehouses, and informal tools (email, spreadsheets, shared drives). Domain knowledge includes knowing which system owns which truth, latency tolerances, API maturity, and where data quality breaks.

Engagement use. Produce a systems-and-data sketch early: core platforms, integration patterns (batch vs event vs API), master data entities, known quality issues, retention rules. AI designs must specify read vs write boundaries—many phase-one solutions are read-only assistants for good reason. Ask: where does the authoritative document live? Who can access it? Is there PII segregation? Does OT/network segmentation block cloud inference?

Pitfalls.

• Assuming the CRM or data lake has clean, current data because a dashboard exists.
• Planning real-time integration where the industry norm is end-of-day batch (common in insurance and legacy manufacturing).
• Underestimating document formats (scanned PDFs, fax-derived images, HL7 messages, EDI).
• Ignoring sector-specific identifiers (LEI, NHS number, policy number vs claim number vs customer golden record).

Worked example. Insurance claims: system of record is claims platform (Guidewire-style); documents in ECM; correspondence in email threads; fraud scores from external bureau. RAG corpus must exclude draft adjuster notes not approved for regulatory disclosure. Integration pattern: assistant reads indexed approved documents + policy terms API; writes nothing to claims platform in phase one. Data sketch prevents "connect GPT to everything" scope creep.

Regulation, risk and compliance constraints

Definition. Regulation and industry standards define lawful operation, customer treatment, safety, privacy, and prudential soundness. Beyond statute, internal policies, audit standards, and model governance frameworks (MRM, clinical governance, GxP) constrain what AI may do and what evidence you must retain.

Engagement use. Maintain a living regulatory constraint list tied to design decisions—not a generic GDPR paragraph. For each constraint: requirement, implication for AI, evidence needed, owner. Financial services: GDPR, FCA/PRA rules, AML, conduct, Consumer Duty, model risk SR 11-7 analogues. Healthcare: HIPAA/GDPR, clinical safety DCB0129/DCB0160 (UK), FDA SaMD if applicable. Energy: NERC CIP, safety cases. Public sector: procurement, accessibility, algorithmic transparency. Size human oversight and explainability to sector expectations—credit decisions and clinical support demand higher bars than internal summarisation.

Pitfalls.

• Copy-pasting a privacy policy instead of analysing processing purpose and lawful basis.
• Treating "human in the loop" as a label without defining who, when, and with what liability.
• Missing sector-specific AI guidance (FCA AI, EU AI Act high-risk categories, NHS DTAC).
• Assuming pilot exemption means production exemption.

Worked example. UK retail bank customer chat assistant: Consumer Duty requires good outcomes; GDPR requires minimisation and DPIA; FCA expects clarity on automated vs human advice boundaries. Constraint list entries: (1) no personalised investment advice without suitability process; (2) retention 7 years aligned with complaints regime; (3) vulnerability detection escalation to trained agents; (4) model change notification to model risk if decision support expands. Each item maps to a design or operating control.

AI opportunities in industry context

Definition. Industry AI opportunities are use cases where cognitive automation, prediction, retrieval, or optimisation moves a sector KPI within regulatory and operating bounds—not generic "chatbot" ideas.

Engagement use. Translate patterns to industry verbs: underwriting triage, prior auth support, demand forecasting, predictive maintenance, KYC document extraction, code review for core banking, network fault correlation. Prioritise with value × data readiness × regulatory risk × adoption complexity—the same lens as AI Opportunity Discovery. Kill ideas that violate constraints identified above. Prefer pilots where failure is contained and measurement is clean.

Pitfalls.

• Starting from technology ("RAG") instead of workflow pain.
• Selecting high-visibility, high-risk autonomy first (full claims adjudication, autonomous trading).
• Ignoring change capacity: nurses and adjusters have finite time for pilot feedback.
• Double-counting benefits already captured by existing rules engines.

Worked example. Telco network ops: high volume of alarm tickets; L1 engineers repeat known runbooks. Opportunity: retrieval over runbooks + similar incident history with citation, integrated into ticket UI. KPI: mean time to restore (MTTR) for L1-resolvable incidents; measure A/B on matched incident classes. Not: autonomous config changes on production routers in phase one—regulatory and OT risk too high.

Client proposition and industry language

Definition. The client proposition is how you explain the solution in the client's vocabulary, tied to their outcomes, constraints, and buying process—so executives hear business impact, risk owners hear controls, and users hear workflow relief.

Engagement use. Build a domain glossary (50–100 terms for a new industry, fewer for a sub-domain). Use client terms in problem statements, slide titles, and RAID logs. Proposition structure: outcome → process → control → measurement → phased rollout. Align to procurement norms: regulated RFP vs SaaS PLG vs framework call-off changes how you write and who signs.

Pitfalls.

• Vendor and consultant jargon ("hallucination," "embeddings") in executive readouts without translation.
• Misusing regulated terms (advice, diagnosis, underwriting decision).
• One-size-fits-all value narrative across regions (US vs EU vs UK compliance framing differs).
• Weak phase naming ("POC" without success criteria tied to industry KPIs).

Worked example. Instead of "We will deploy an LLM agent," say: "We will reduce policy lookup time for Tier-1 servicing agents on payment and balance enquiries, with answers cited to the approved policy library, Consumer Duty-aligned escalation for vulnerability flags, and QA sampling unchanged in phase one." Every noun is industry-native; AI is implicit in the mechanism, not the headline.

Frameworks and methods

Use these frameworks deliberately—each solves a different failure mode in domain learning.

Smart Industry Learning System (seven parts)

Sequence: Economics → Value chain → Stakeholders → Systems and data → Regulation → AI opportunities → Client proposition. Run as a 10-hour industry sprint before deep engagement work. Exit criterion: you can answer the seven executive questions without opening notes.

When to apply: New vertical, new sub-sector (e.g., moving from retail banking to commercial lending), or pre-RFP preparation.

When not to apply: You already maintain a refreshed battlecard for this client sub-segment updated within the last 90 days—extend the existing pack instead.

Industry battlecard

One-page compressed view: economics headline, top five processes, key systems, top regulations, stakeholder map, AI do/don't list, competitor moves. Maintain in your pattern library; version per geography.

When to apply: Internal staffing briefings, proposal kick-offs, junior onboarding to a client account.

SIPOC (Suppliers, Inputs, Process, Outputs, Customers)

Lightweight process boundary tool for workshops. Pair with value chain maps to anchor discovery on measurable inputs/outputs.

When to apply: Workshop facilitation when stakeholders disagree on "where the problem is."

Domain glossary with provenance

Term, definition, client-specific nuance, source (policy ref, SME name, reg citation), forbidden synonyms. Prevents ambiguous AI requirements ("customer" vs "member" vs "policyholder").

When to apply: Every engagement; required before writing user stories or retrieval corpus scope.

Regulatory constraint matrix

Rows: regulation/policy; columns: data use, model use, human oversight, retention, cross-border, audit evidence. Mark RAG/Amber/Green with design implication.

When to apply: Architecture review, DPIA/model risk packs, phase-gate decisions.

AI opportunity scoring (industry-weighted)

Score value, data readiness, regulatory risk, adoption complexity, time to value—weight regulatory risk higher in FS, healthcare, and public sector than in internal SaaS tooling.

When to apply: Portfolio rationalisation when stakeholders bring long wish lists.

Operating model notes for AI in industry context

Domain knowledge shapes how AI lands—not only what it does. Three operating dimensions recur across sectors.

Control placement. Regulated industries embed controls in process (maker-checker, clinical sign-off, four-eyes underwriting). AI operating models must declare whether the model assists, recommends, or decides—and which control step remains human regardless of accuracy metrics. Wealth management and healthcare often require assist modes indefinitely for client-facing outputs; manufacturing may allow recommend for maintenance scheduling if union and safety sign-off exist; retail banking may allow decide only for low-risk internal ops summarisation, never for personalised financial advice without suitability workflow.

Evidence and audit trail. FS model risk expects reproducible inputs, versioned models, and challenger outcomes; healthcare expects clinical safety case artefacts; public sector expects algorithmic impact assessment and explainability to citizens. Your operating model specifies: what is logged (prompt, retrieved chunks, model version, user, outcome), retention period aligned to sector rules, and who may access logs (internal audit, regulator exam, clinical governance).

Change velocity. SaaS companies may ship weekly; banks and insurers often align releases to change advisory boards; healthcare may require validation protocols; OT environments may permit quarterly maintenance windows only. Domain knowledge sets realistic phase plans—promising continuous fine-tuning on production traffic is infeasible where CAB approval takes six weeks.

Industry → Typical AI operating posture (phase one)
─────────────────────────────────────────────────────
Retail banking servicing    Assist + cite; no account action
Commercial insurance UW     Summarise + extract; human quotes
Wealth / investments        Assist research; adviser attestation
Healthcare utilisation      Checklist + cite; nurse decides
Manufacturing maintenance   Recommend work order; tech approves
Public sector permits       Citizen guidance; human decision
Telco L1 network ops        Runbook retrieval; no auto config

Use this table as a starting hypothesis—validate against client policy in week one.

Sector primer: what to learn first

When time is limited, prioritise sub-domain specifics within broad labels:

Sector	Learn first (economics + process)	High-risk AI anti-patterns
Financial services	Margin drivers; KYC/AML; conduct; model risk	Autonomous advice; training on PII without legal basis
Healthcare (payer/provider)	MLR, LOS, clinical governance, HIPAA/GDPR	Auto-deny care; diagnosis language; PHI in shadow IT
Retail / CPG	Margin, inventory turns, returns, promo ROI	Personalisation without consent; pricing collusion optics
Telco	ARPU, churn, MTTR, capex intensity	Autonomous network changes; misleading plan comparisons
Energy / utilities	Safety, NERC CIP, regulated returns, outage cost	Safety-critical control bypass; wrong tariff advice
Manufacturing	OEE, scrap, OT segmentation, quality (IATF)	Cloud-only inference on air-gapped lines without edge plan
Public sector	Mandate outcomes, transparency, procurement	Opaque eligibility automation; bypassing appeals rights
Professional services	Utilisation, leverage, liability, client confidentiality	Client data in public models; work product without review
SaaS / tech	NRR, gross margin, PLG vs enterprise sales	Assuming client is as agile as vendor on data and risk

Run the Domain Knowledge workbook Industry Sprint tab against this table for each new client logo.

Real-world scenarios

Scenario A: Wealth management research assistant (financial services)

A mid-tier UK wealth manager wants "ChatGPT for advisers." Research production involves macro notes, equity initiation reports, model updates, and client-facing summaries. Advisers complain research is hard to search; compliance worries about inducements (MiFID II research unbundling) and suitability language if AI paraphrases analysts.

You run a domain sprint. Economics: revenue from AUM fees and platform charges; pressure on margin from passive flows and compliance cost. Value chain: research production → compliance review → publication to library → adviser consumption → client recommendation → ongoing suitability review. Stakeholders: Head of Research (sponsor), Compliance (veto), advisers (users), IT (M365/SharePoint), Model Risk if ranking signals appear. Systems: SharePoint authoritative library; CRM holds client suitability profiles ( segregated access); email for informal analyst Q&A (not authoritative). Regulation: FCA COBS suitability; inducements rules; record-keeping. AI opportunity: RAG over approved research with paragraph citation; no cross-client personalisation in phase one; block language that resembles personal recommendation without adviser attestation.

Measurable outcome target: cut adviser research search time from 12 minutes average to 6 minutes on tracked enquiry types; compliance review sample shows 100% citations traceable to approved docs. Recommendation explicitly excludes training on client CRM data in phase one. Partner review passes because problem statement uses inducements and suitability correctly—credibility established before architecture choices.

Scenario B: Prior authorisation support (US healthcare payer)

A regional health plan faces prior auth backlog; nurses spend 20+ minutes per case collating clinical notes, policy criteria, and formulary rules. Leadership asks for "AI to auto-approve."

Economics: medical loss ratio and admin expense ratio under employer group pressure; star ratings affected by access delays. Value chain: intake → clinical review → decision → provider notification → appeal → audit. Stakeholders: Chief Medical Officer, Utilization Management ops, Compliance/HIPAA, Provider relations (fears auto-deny backlash), IT (Epic, prior auth platform). Systems: Epic clinical data via restricted interface; medical policy PDFs; pharmacy benefit rules in separate engine. Regulation: HIPAA minimum necessary; state utilization review laws; no practising medicine—decision support only. AI opportunity: summarise case against policy checklist with citations; nurse remains decision-maker; auto-approve only for low-complexity categories explicitly approved by medical policy committee later.

Measurable outcome: reduce nurse prep time by 35% on pilot CPT categories; decision quality maintained via random audit of 10% cases; zero storage of PHI in unapproved environments. You reject the initial "full auto-approval" ask by showing backlog root cause is split systems and incomplete clinical attachments—not only summarisation speed.

Scenario C: Predictive maintenance in discrete manufacturing (stretch context)

Automotive parts plant faces unplanned downtime on CNC lines; maintenance relies on senior technician tacit knowledge. OT network is air-gapped from corporate cloud; union agreement requires maintenance sign-off on schedule changes.

Domain work shows economics: OEE and scrap cost; value chain: schedule → run → inspect → maintain → calibrate; stakeholders: plant manager, maintenance lead, OT security, quality (IATF); systems: SCADA historian, CMMS, paper checklists on some lines; regulation: safety interlocks, ISO records; AI opportunity: anomaly detection on vibration/temperature with explainable features; work order draft in CMMS—not autonomous parameter changes. Edge deployment required; benefits measured in avoided downtime hours × line throughput value.

This scenario shows domain knowledge beyond office workflows: OT constraints, safety culture, and union governance shape AI architecture as much as model accuracy.

Scenario D: Retail grocery demand and waste (retail)

A national grocery chain asks for "AI forecasting" after spoilage rises 9% in fresh categories. Economics: thin net margin; shrink directly hits EBIT; promo wars with discounters. Value chain: demand plan → order → receive → shelf → markdown → waste. Stakeholders: category managers, supply chain, store ops, finance, sustainability (ESG reporting on waste). Systems: ERP, POS, weather feeds, supplier EDI—forecast models in spreadsheets in some regions. Regulation: food safety traceability; GDPR on loyalty data if personalising offers. AI opportunity: improve short-life SKU forecasts at store level using exogenous signals; separate assistant for staff on markdown policy retrieval—not customer-facing dynamic pricing bot in phase one.

Measurable: waste down 5% in pilot stores vs matched control; forecast MAPE improvement on SKUs with <48h shelf life; no personal price discrimination without legal review. Domain knowledge prevents conflating demand forecasting (ops KPI) with personalised pricing (conduct and competition sensitivity).

Practice exercises

Primary exercise: Insurance claims domain pack (3–4 hours)

Choose property and casualty claims (or your client's sub-line if already on an engagement). Produce four artefacts:

1. Domain glossary (minimum 40 terms): Include FNOL, reserve, indemnity, subrogation, leakage, combined ratio, treat-as-customer, fair value, without prejudice, and line-specific terms. Mark which terms must appear in external-facing AI output.

2. Process brief: Map FNOL → triage → investigation → settlement → recovery → closure. Note controls (SIU referral, authority limits, dual approval thresholds). Identify two steps with high manual document handling.

3. Regulatory constraint list (minimum 8 items): UK-focused (FCA/PRA, GDPR, Consumer Duty) or US-focused (state DOI, NAIC) as appropriate to your scenario. Each item: constraint → design implication.

4. One AI opportunity statement: Must NOT be "chatbot." Tie to KPI (e.g., leakage, expense ratio, cycle time). Include phase-one human oversight and measurement plan.

Acceptance criteria: A colleague with insurance experience finds fewer than five material glossary errors; process map matches publicly described insurer operating models; opportunity statement names a control that stays human in phase one.

Stretch exercise: Cross-industry comparison memo (2 hours)

Pick retail banking servicing and P&C claims (or healthcare prior auth). Write a two-page memo comparing: economics driver, primary system of record, top risk approver, typical AI pilot vs anti-pattern, and procurement cycle length. End with a table: "When a stakeholder says X, they usually mean Y" for five phrases per industry.

Acceptance criteria: Memo explains why the same RAG pattern differs in retention, access control, and success metrics across the two industries.

Questions you should be able to answer

1. How does this organisation make money, and which margin or cost line is under the most pressure this year?
2. What are the five most important processes from customer/member/patient entry to outcome—and where is the rework?
3. Who is the economic buyer, and who can veto the project without appearing on the steering committee?
4. What is the system of record for the entity your AI solution references—and what is explicitly not authoritative?
5. Which regulations or internal policies constrain model use, data movement, and automated decisions?
6. What does "good" look like for the target process today—in KPIs with baseline numbers?
7. Which industry terms must appear correctly in the problem statement and user-facing copy?
8. What is the typical procurement and risk approval path for this sector—and how long does it take?
9. Where have similar AI initiatives failed in this industry, and what was the stated reason?
10. Which AI use cases are explicitly out of scope in phase one because of conduct, safety, or OT risk?
11. How does data residency or sector networking (HIPAA, PCI, OT segmentation) constrain deployment topology?
12. What evidence will audit, model risk, or clinical governance require to promote from pilot to production?
13. How do incumbents and startups in this sector describe the same problem—and which vocabulary should you adopt?
14. What operational metric will move first if the pilot succeeds—and how will you measure counterfactual?
15. How would you explain the phased solution to a sceptical domain SME in two minutes without saying "LLM"?

Negative cases

Domain knowledge failure does not always look like ignorance—it often looks like confident genericism. Watch for these breakdown patterns on engagements and in your own artefacts.

Wrong problem, right technology. Team deploys a capable assistant for marketing content when the board priority is loss ratio. Demo succeeds; executive sponsorship dies because the problem was misaligned. Fix: economics and strategy alignment before use-case workshops.

Authoritative source confusion. RAG indexes SharePoint folders including draft policies and superseded manuals. Answers sound fluent; compliance finds incorrect binding guidance. Fix: corpus governance with legal/compliance sign-off on source list; version metadata.

Automation on a control step. AI auto-completes KYC disposition without four-eyes review where regulation requires it. Fix: map controls on the process brief; read-only or draft-only AI in controlled steps.

Stakeholder bypass. Enthusiastic digital lead signs off; Model Risk and Compliance encounter the project at architecture review and halt delivery. Fix: stakeholder map with early risk engagement; pre-reads in their vocabulary.

Integration fantasy. Proposal assumes real-time core banking API access that exists only as overnight batch in the client's reality. Fix: systems-and-data sketch validated with enterprise architects; phase integration explicitly.

Metric mismatch. Success measured on "user satisfaction with AI" while the business cares about AHT and complaint rate. Fix: tie pilot scorecard to existing operational dashboards.

Regional copy-paste. EU GDPR framing applied to UK Consumer Duty outcomes without local policy review. Fix: regulatory matrix per jurisdiction; local SME review.

Underestimating tacit work. Nurses, adjusters, and traders perform edge-case judgement that is not documented—AI fails on long tail. Fix: interview for exceptions; scope pilot to high-volume narrow intents.

Related playbook content

• Industry Solution Engineering — engagement delivery patterns per sector
• Domain Knowledge Gathering — 10-hour sprint method and seven-part system
• Domain Knowledge workbook — downloadable templates for glossaries and battlecards
• Business Learning overview — full Stage 1 practice pack
• Opportunity Discovery — workshop flow once domain context is established
• 8D Framework — stage gates for advancing design with evidence
• Business and consulting foundations — where this topic sits in the competency path
• How to use this Learning Map — reference depth standards and study loop

Output

Expected outputs for this topic:

• Domain glossary (40+ terms with client nuance and sources)
• Process brief (value chain with controls, systems, and KPIs)
• Regulatory constraint list (requirement → design implication)
• Systems and data sketch (systems of record, integration patterns, quality caveats)
• Industry battlecard (one-page economics, stakeholders, AI do/don't)
• AI opportunity statement (industry KPI, phase-one scope, measurement plan)

Practice checklist

• I can explain how the client makes money without naming a vendor or model
• I produced a domain glossary a SME would not materially correct
• I mapped the value chain including at least two control points AI must respect
• I listed regulatory constraints with design implications—not boilerplate
• I identified economic buyer, risk approver, and daily users separately
• I wrote an AI opportunity that is not a generic chatbot and ties to a named KPI
• I completed the primary exercise and filed artefacts in my pattern library
• I attempted the stretch exercise or documented why my engagement industry pair differs

Key takeaways

• Industry knowledge is proven by artefacts that survive SME and risk review—not by reading lists of acronyms.
• Follow economics → value chain → stakeholders → systems → regulation → AI opportunities → client proposition every time you enter a new vertical.
• The same AI pattern changes shape by industry: corpus authority, oversight, integration, and metrics differ materially between wealth management, claims, and clinical utilisation.
• Use industry language in problem statements before discussing models; misuse of regulated terms destroys credibility faster than weak architecture.
• Phase-one scope should respect controls and OT/compliance reality; autonomy is a late-phase privilege earned with evidence.
• File battlecards and glossaries in a personal pattern library so the next engagement in the same sector starts from hour ten, not hour zero.

What to do next

1. Complete the primary practice exercise and store outputs in your pattern library.
2. Run a 10-hour domain sprint for your target industry if you have not already.
3. Continue with Consulting and Problem Solving to structure problems before expanding AI scope.
4. Open Industry Solution Engineering when you move from learning to delivery on a live account.
5. Use the interactive playbook for workshop tools once artefacts are drafted.