AI Fundamentals

This page sets the vocabulary the rest of the playbook builds on: what AI, machine learning, and generative AI actually mean, how they relate to each other, and how to tell them apart from automation and analytics - two things people frequently confuse them with. It also introduces the three AI mechanisms JMAN uses to classify a use case before picking a platform or an architecture pattern.

Getting this classification right matters more than it looks. The mechanism you pick determines the data you need, the way you evaluate success, the failure modes you need to guard against, and which part of the playbook to read next. A churn model, a document Q&A assistant, and an automated invoice-processing workflow are all "AI," but they are built, tested, and operated in almost entirely different ways.

AI, Machine Learning, and Generative AI

These three terms nest inside each other. Getting the nesting right avoids two common mistakes: calling a rule-based script "AI," and treating "AI" and "generative AI" as synonyms.

• Artificial Intelligence (AI) - the umbrella term for any system that performs a task normally associated with human judgement: recognising a pattern, making a prediction, understanding language, or planning a sequence of actions. This includes machine learning, but also older, non-learning approaches such as rule-based expert systems and search/planning algorithms.
• Machine Learning (ML) - a subset of AI where the system learns its logic from data instead of being explicitly programmed with rules. This covers classification, regression, clustering, and forecasting models, and it is the foundation both traditional data science and generative AI are built on.
• Generative AI - a subset of ML where the model learns to produce new content (text, code, images, audio) rather than just a label or a number. Large language models (LLMs) are the generative AI systems most relevant to this playbook.

Every generative AI system is machine learning, and every machine learning system is AI - but the reverse is not true. A deterministic pricing engine built from if/then rules is sometimes marketed as "AI." It isn't; it's automation, covered below.

The Three AI Mechanisms

Within AI, JMAN groups use cases into three mechanisms based on what goes in and what comes out. This is the practical lens for scoping: before discussing a platform or a model, work out which of the three a use case belongs to.

Where to go deeper: Platform guides for data science, RAG, Agents and Multi-Agent Systems for generative AI, and Autonomous AI for the third.

Data Science is the most mature of the three. It takes structured, numeric input and produces a structured, numeric output - a probability, a score, a forecasted value. Evaluation is straightforward because there is a ground truth to compare against (did the customer actually churn, was the forecast close to actual).

Generative AI takes unstructured language as input and produces language as output - an answer, a summary, an extracted field, a generated report. It excels at consolidating and querying knowledge that is too varied or too unstructured for a fixed query to handle. Evaluation is harder: there is rarely a single correct answer, only a range of acceptable ones.

Autonomous AI takes a signal (an event, a schedule, an inbound document) and drives a sequence of actions across systems, often orchestrating both data science and generative AI steps along the way plus deterministic ones (call an API, update a record, send a notification). It has the biggest potential payoff and the biggest risk of the three, because failures compound across steps.

Most real use cases combine mechanisms - for example, an autonomous invoice-processing workflow that uses generative AI to extract fields from a PDF and a data science model to score fraud risk before an automation step posts the transaction. Classify by the dominant pattern, then check whether sub-steps pull in another mechanism.

JMAN's AI Offerings Across the PE Investment Lifecycle

JMAN's work is anchored in the PE investment lifecycle: Due Diligence, F100, VCP Acceleration, and Exit. Each stage has its own offerings, its own guiding question, and its own commercial outcome, and each leans on a different mix of the three mechanisms above.

This is the same classification used in JMAN's Data Engineering playbook, which frames it as "Three Waves" - Data Science & ML, Generative AI, and Agentic AI - applied to the data platform rather than the PE lifecycle specifically. The two are consistent: same three mechanisms, different lens.

Data Foundations to Deployed AI

The lifecycle above says where AI shows up in an engagement. This says what depends on what. One branch of AI sits at the end of the data chain and each link has to exist before the next one carries weight. The other branch does not.

The AI Layer is the pivot for anything that answers questions about governed business numbers. Intelligent query and AI-enabled reporting sit behind it - they need the single source of truth and the metric definitions the layer governs - so a client asking for conversational BI usually needs foundation work quoted alongside it, and "we already have a warehouse" is not the same as "we are ready for AI".

Generative and agentic solutions over unstructured input are not gated that way. Enrichment, classification, extraction, and workflow automation read their input directly from documents, emails, contracts, and inbound events, so they can be scoped and delivered independently of the foundation programme. The foundation still matters: it gives those solutions reference data to validate against and somewhere to land their output, which improves them rather than authorising them. As the diagram puts it, the AI Layer extends the existing investment upwards rather than replacing it. Treat it as two tracks that can run in parallel, not one queue.

The foundation-dependent track, sequenced against a typical engagement:

The expansion opportunities that open up at the far end are typically data science use cases - predictive churn modelling, price optimisation - rather than more generative AI. Strong foundations are what make those viable. Document and workflow use cases are not on this timeline at all; they run alongside it.

AI vs Traditional Automation vs Traditional Analytics

Three terms get used interchangeably in scoping conversations and shouldn't be: automation, analytics, and AI answer different questions and fail in different ways.

The practical rule: if you can write the complete decision logic as a flowchart today, that's automation, not AI. If you're aggregating and displaying data that already exists, that's analytics. AI earns its place when the input is too varied, too unstructured, or too uncertain for either of those to work.

Common Business Applications

Grounded in the three mechanisms above rather than in press-release use cases.

Data Science

• Customer or portfolio-company churn prediction, scored monthly against actual outcomes
• Revenue and demand forecasting feeding FP&A cycles
• Credit, collections, or counterparty risk scoring
• Anomaly detection on transactions and expenses

Generative AI

• Question-answering over a data room or knowledge base during due diligence (RAG)
• Contract clause extraction, comparison, and summarisation
• First-draft report and meeting-note generation, reviewed by a human before use
• Natural-language querying of a BI semantic model instead of writing SQL

Autonomous AI

• End-to-end invoice processing: extract fields, validate against a PO, flag exceptions, route for approval
• Data-room triage during diligence: classify, extract, and index incoming documents as they land
• Multi-system incident or ticket handling that pulls context from several tools and takes the next action

None of these replace judgement on ambiguous, high-stakes decisions. They remove the repetitive reading, matching, and drafting work that sits in front of that judgement.

Benefits, Limitations, and Misconceptions

Benefits

• Handles unstructured input - free text, scanned PDFs, images - that rule-based systems and fixed queries cannot process
• Generalises beyond explicitly programmed cases, at the cost of occasional error
• Removes repetitive cognitive work (reading, extracting, summarising, first-draft writing) rather than just repetitive keystrokes
• Makes tacit, hard-to-document expertise reusable once a model or prompt is well tuned

Limitations

• Hallucination - generative models produce fluent, plausible, and sometimes entirely false output, with no built-in signal that anything is wrong. Retrieval grounding and citation reduce this; nothing eliminates it.
• Non-determinism - the same prompt or input can produce a different output on different runs. This breaks the assumption of reproducible, unit-testable behaviour that most engineers rely on.
• Cost that scales with usage - generative AI is billed per token, on both input and output, so cost grows with prompt size, context length, and call volume rather than being fixed at build time. See Tokens for the mechanics.
• Evaluation overhead - there is no compiler-equivalent correctness check for a generated paragraph or a model's prediction. You need labelled evaluation sets, human review loops, and ongoing monitoring, and that overhead persists after launch, not just during build.
• Data dependency - output quality is capped by the data the model was trained or grounded on. Poor source data produces confidently wrong output, not an error.
• Limited explainability - some model classes are difficult to justify to auditors or regulators, and an LLM's stated reasoning can be a post-hoc rationalisation rather than the actual basis for its output.

Misconceptions

• "AI replaces the data platform." It doesn't. A model or an agent is only as good as the data foundation underneath it - ingestion, modelling, quality - and building AI on a weak foundation just automates the production of bad answers faster.
• "More AI is a better outcome." The mechanism has to match the problem shape. Using an LLM to forecast a number a regression model would predict more accurately, cheaply, and reproducibly is a worse solution, not a more advanced one.
• "AI can be tested like normal code." Deterministic unit tests don't apply to non-deterministic output. You need evaluation harnesses with acceptance thresholds, not pass/fail asserts.
• "One model fits every use case." Model selection and routing matter - a small, cheap model handles classification and extraction well; save the largest, most expensive model for tasks that need deep reasoning.
• "AI understands the request." A language model predicts a likely continuation given its training and context - it doesn't have goals, common sense in the human sense, or accountability for the outcome. Human review stays in the loop for consequential decisions.

Key Takeaways

• AI is the umbrella term; machine learning is a subset of AI; generative AI is a subset of machine learning. Not everything marketed as "AI" is even machine learning.
• Classify a use case by mechanism first - Data Science (numbers in, numbers out), Generative AI (language in, language out), or Autonomous AI (signal in, action out) - before picking a platform or pattern.
• AI is not automation and not analytics. Automation runs fixed rules on defined triggers; analytics describes historical data; AI infers patterns from data and generalises to new input.
• The real limitations - hallucination, non-determinism, token-driven cost, evaluation overhead - are design constraints to plan around, not reasons to avoid the technology.
• Check what a use case actually depends on before sequencing it. Intelligent query, AI-enabled reporting, and predictive models sit on top of a data foundation and wait for it; generative and agentic solutions over documents and events do not, and can be delivered in parallel. Neither substitutes for the foundation.