Distinguishing Automation, Predictive ML, Generative AI, and Foundation Models

Hello, and welcome. This course builds a working mental model of modern AI for evaluating AI-first software at seed stage: what a system is actually doing, what it depends on, and where its product and economic risks sit.

This first module establishes the vocabulary beneath founder claims such as “AI-powered,” “ML-driven,” or “built on a foundation model.” In this lesson, the central point is that these labels describe different dimensions of a system. A product can use rules, predictive machine learning, generative AI, and a foundation model at the same time.

By the end, you should be able to take a software workflow apart and say precisely: what is explicitly programmed, what is learned from data, what generates an artifact, and whether a broadly pretrained model is being reused.

---

Four labels, two different kinds of question

When assessing an AI product, start by resisting a common mistake: treating the following as four rival buckets.

1. Rules-based automation describes how a decision is specified: people write the logic explicitly.
2. Predictive machine learning describes a system that learns a mapping from historical data to a defined target, such as a probability, category, or numerical forecast.
3. Generative AI describes the kind of output: it produces a new artifact, such as text, code, an image, audio, or structured content.
4. Foundation-model use describes the source and reuse pattern of the model: the application builds on a large model pretrained on broad data and adapted to many downstream tasks.

The first three are primarily about what a component does. “Foundation model” is primarily about what model asset the component uses and how it was obtained.

That distinction explains overlap. An LLM-based contract-review assistant may generate a clause summary, so it is generative AI. If it calls GPT, Claude, Gemini, or an open-weight model derived from broad pretraining, it is also using a foundation model. The surrounding application may still contain hard-coded rules: permissions, approval thresholds, data-retention policies, and escalation logic.

A useful diligence habit is to label a system component by component, not company by company. “This is an AI company” is rarely a useful technical description.

---

Rules-based automation: explicit logic, explicit ownership

Rules-based automation is conventional software logic applied to a workflow:

• If an invoice is below $€500$, approve it automatically.
• If a payment originates from a sanctioned jurisdiction, block it.
• If a customer has not completed onboarding after seven days, send a reminder.
• If an uploaded file does not match an allowed format, reject it.

The relevant logic is authored by people. Given the same inputs and system state, the same rules normally yield the same result. An expert system is a more ambitious historical form of this approach: a knowledge base plus many if–then rules intended to emulate domain expertise.

Rules are not inherently unsophisticated. In finance, compliance, access control, accounting controls, and workflow routing, explicit rules may be preferable because they are auditable, stable, inexpensive, and easy to constrain. The issue is not that rules are “old” and ML is “new”; it is whether human-authored logic can plausibly cover the variability of the task.

Google’s Rules of Machine Learning gives a pragmatic framing: begin with a simple heuristic when it is sufficient, instrument the product, and move toward ML when rule complexity becomes the limiting factor.

There is a critical middle ground. A product can use rules around a model without ceasing to be an ML or generative-AI product. Indeed, well-designed AI systems typically use rules to define boundaries:

• Which customers may use a capability
• Which actions require human approval
• Which outputs must be rejected or reformatted
• Which cases receive a model call at all

The more important investment question is therefore not “Does it have rules?” but: Which part of the customer value depends on learned or generative behavior that rules could not economically reproduce?

---

Predictive ML: learn a target from past outcomes

Predictive machine learning begins with a target that can, at least in principle, be checked against reality later. Typical targets include:

• A number: expected revenue, demand next month, likely claim cost
• A category: fraud or legitimate, likely to churn or likely to renew
• A probability or score: probability of default, likelihood that a lead converts
• A ranking: which accounts a sales representative should call first

The model is trained on historical examples. Each example usually has:

• an instance, the item under consideration;
• features, information available about it;
• and, during training, a label, the outcome the system should learn to predict.

For example, a churn model might use account tenure, active users, recent support tickets, and product usage as features. Its label could be whether the account churned in the following 90 days. At deployment, it estimates churn probability for accounts whose eventual outcome is not yet known.

That makes predictive ML different from an ordinary rule. Instead of a manager specifying “accounts with fewer than three active users are at risk,” the system learns a statistical relationship from data. It may discover that declining usage matters only for a particular customer segment, or that support-ticket patterns add predictive signal.

Prediction is not the same as automation

A predictive score does not act by itself. An application must decide what to do with it.

Consider a payments workflow:

Component	What it does	Best label
Fraud model	Estimates whether a transaction is fraudulent	Predictive ML
Threshold policy	Blocks transactions above a specified risk threshold	Rules-based automation
Operations queue	Sends ambiguous cases to an analyst	Workflow and human review
Customer explanation generator	Drafts a message explaining a hold	Generative AI, potentially foundation-model use

This is one system, not four separate products. The model supplies uncertain evidence; the rules convert it into an operational decision; people handle the residual risk; a generative model may communicate the outcome.

For an investor, predictive ML is most credible when the founder can clearly state:

• the target being predicted;
• when the true outcome becomes observable;
• the data available at prediction time;
• the evaluation metric;
• and the action taken at each score range.

A claim to “predict risk with AI” without a well-defined target, reliable labels, and a feedback loop is usually not yet a predictive-ML advantage.

---

Generative AI: creating an artifact rather than forecasting one answer

Generative AI produces a new output that resembles patterns learned from data. The artifact can be prose, software code, an image, an audio clip, a summary, a proposal, or a structured JSON object.

At the product level, the defining question is:

Is the system being asked to forecast a defined real-world outcome, or to synthesize a useful artifact?

A few examples make the distinction clearer:

Task	Primary function
“Which loan applications are likely to default?”	Predictive ML
“Draft a credit memo from these financial statements”	Generative AI
“Will this support ticket breach its service-level agreement?”	Predictive ML
“Write a reply to the ticket in the company’s tone”	Generative AI
“What demand will this SKU have next quarter?”	Predictive ML
“Create product descriptions for the new catalogue”	Generative AI

Generative does not mean frivolous or unconstrained. A system that extracts fields from an insurance claim into a schema may be generating structured output, even though users experience it as “extraction.” It should be evaluated for field accuracy, completeness, consistency, and appropriate escalation, rather than for literary originality.

Nor does generative AI mean that any output is acceptable. A sales email can have many good versions; a legal citation, dosage instruction, or payment-routing field has much tighter correctness requirements. The higher the cost of error, the more the product needs grounding, validation, deterministic checks, or human review. We will return to those design choices later in the course.

The “LLMs are predictive” objection

Technically, a language model generates text by assigning probabilities to possible next tokens and selecting one repeatedly. In that narrow mechanistic sense, it predicts the next token.

But calling an LLM “predictive AI” in a product conversation is often misleading. A churn model’s output is intended as a forecast that becomes true or false. A language model’s token probabilities are the machinery used to construct an answer, draft, summary, or piece of code. Its user-facing function is generative.

Keep both descriptions available:

• Mechanism: next-token probability prediction
• Product function: content generation

This distinction will become more concrete in the next lessons, when we examine training and inference and then inspect next-token probability distributions directly.

---

Foundation models: a reusable base, not a task category

A foundation model is trained at large scale on broad and diverse data, then reused across many downstream tasks. Many current foundation models are transformers trained on text, code, images, audio, or some combination of these modalities.

The key idea is transfer. Rather than training a separate model from scratch for every task, an application can start with a broadly capable model and adapt it through prompting, further training, or application-level context and controls.

Foundation-model use is highly correlated with generative AI today, but they are not identical.

Generative AI without a foundation model

A company might train a relatively narrow model specifically to generate synthetic molecular structures, product designs, or voice variations. Its output is generative, but it may not have begun with a broad, reusable model trained on diverse data. It is generative AI without the usual foundation-model pattern.

Foundation-model use without a generative user experience

A product might use a foundation model to convert documents or images into numerical representations, classify content, rank support tickets, or estimate similarity. The end-user experience may be a score, a filter, or a search result rather than generated prose.

The common case: both

A vertical copilot that submits a prompt and customer context to a general LLM, then returns a drafted investment memo, is both:

• generative AI, because it creates the memo; and
• foundation-model use, because the core capability comes from a pretrained general-purpose model.

The distinction matters commercially. “Generative AI” says something about the interaction and output. “Foundation-model use” raises questions about supplier dependence, quality changes by the model provider, data handling, token costs, and whether the startup’s value lies above the base model.

---

A practical decomposition for product diligence

Consider a hypothetical AI-first workflow for commercial-insurance underwriting:

1. A broker uploads policy documents, loss runs, and notes.
2. A foundation-model-based service extracts and summarizes relevant facts.
3. A predictive model estimates loss probability and expected claim severity.
4. Rules check required fields, referral thresholds, and regulatory exclusions.
5. An underwriter reviews exceptions and approves or modifies the quote.
6. A generative model drafts the broker-facing explanation.

The workflow is not “either traditional software or AI.” It has several layers with different strengths and risks.

Layer	Typical source of value	Principal risk to test
Explicit rules	Control, compliance, repeatability	Coverage gaps and rule-maintenance burden
Predictive model	Better risk selection or prioritisation	Weak labels, changing data, poor calibration
Generative component	Reduced knowledge-work time and improved interface	Incorrect output, inconsistent behavior, weak evaluation
Foundation model	Broad capabilities without training from scratch	Model-provider dependency, cost, privacy, commoditisation
Human review	Risk control and accountability	Hidden manual labour eroding the economics

This structure is more useful than asking whether the company “uses AI.” It identifies what must be true for the company’s claimed advantage to hold.

For example, if the core value is extracting fields from messy documents, the relevant questions are not mainly about the accuracy of the final underwriting decision. They include extraction accuracy across document types, the rate of manual correction, and whether customers will trust the output. If the core value is risk selection, labels and predictive performance matter more. If the product’s differentiation is its polished AI assistant, examine whether a competing team could reproduce the experience with the same foundation-model API and comparable workflow data.

---

The classification card to use in founder conversations

For each consequential component in a product, write four short lines:

Lens	What to identify
Task	Is it applying a rule, predicting a defined outcome, or producing an artifact?
Learning source	Is behavior explicitly programmed, trained on the company’s data, or inherited from a pretrained model?
Action boundary	What does the system do automatically, and where does it defer to a rule or person?
Evidence	What metric demonstrates value: accuracy, calibration, time saved, acceptance rate, conversion, loss ratio, or something else?

This avoids two opposite errors:

• Under-crediting AI: dismissing a valuable product as “just an API wrapper” even when it has deep workflow integration, proprietary feedback, and carefully designed controls.
• Over-crediting AI: accepting “we use an LLM” as a substitute for evidence that the workflow works reliably, economically, and defensibly.

A strong seed-stage founder should be able to explain the boundary between their model-driven behavior and their deterministic product logic. They do not need to have trained a foundation model themselves. But they should know which capabilities are supplied by the base model, which are created by their product, and how they measure failure.

---

Key takeaways

Rules-based automation, predictive ML, generative AI, and foundation-model use are overlapping descriptors, not mutually exclusive categories.

• Rules execute explicit human-authored logic.
• Predictive ML learns from historical data to estimate an observable target.
• Generative AI synthesizes a new artifact, including text, code, images, or structured outputs.
• Foundation models are broadly pretrained models reused and adapted across tasks.

The most revealing unit of analysis is the individual workflow component: identify its task, learning source, action boundary, and evidence of value.

Next, we will follow the lifecycle of an AI model, distinguishing training, validation, deployment, and inference. That distinction is essential for understanding what founders mean when they say a model is “trained,” “in production,” or “improving.”