Case-based learning without sacrificing technical depth

An AI case should require students to formulate and test a model, not merely discuss an organizational story.
Technical depth and managerial interpretation are different layers of the same case, not competing educational philosophies.
A strong case exposes ambiguity while preserving enough structure for assumptions, calculations, and decisions to be evaluated.

The False Choice

Technical programs sometimes treat cases as light discussion. Management programs sometimes treat mathematics as detail that interrupts strategic thinking.

Both approaches miss the educational opportunity.

An AI decision exists because a formal model meets an institutional context. Remove the model and the case becomes opinion. Remove the context and the exercise becomes technique without consequence.

A complete case can be represented as

where $\mathcal Q$ is the question, $\mathcal D$ the data, $\mathcal H$ assumptions, $\mathcal M$ model, $\mathcal A$ algorithm, $\mathcal V$ validation, and $\mathcal U$ the decision utility.

Case-based learning should require students to connect all seven.

Story, Exercise, and Case

Table 1. Technical layers of a rigorous AI case

Form	Structure supplied	Student responsibility
Story	Narrative and conclusion	Interpret or remember
Technical exercise	Model, data, and target	Execute correctly
Case	Context, incomplete evidence, competing constraints	Formulate, compare, and defend
Research case	Open evidence and unresolved claim	Create and criticize the structure

A story can motivate. An exercise can build technique. A case tests whether the student knows which technique belongs and how strong the resulting claim can be.

The Mathematical Spine

Every technical AI case should have a mathematical spine even when students are not asked to perform every derivation.

Suppose a firm wants to reduce customer churn. The predictive object is

but the action concerns an intervention. The relevant benefit may be

where $Y_i(a)$ is churn under action $a$.

If intervention costs $c_i$ and the budget is $B$, allocation becomes

A case discussion that stops at “target high-risk customers” misses the difference between risk, treatment effect, value, and constraint.

Productive Ambiguity

Cases need ambiguity, but ambiguity should be designed.

Unproductive ambiguity leaves students guessing what the instructor wants. Productive ambiguity presents several defensible models and enough evidence to compare them.

A case may leave uncertain:

• the correct target;
• the mechanism generating missing labels;
• the deployment population;
• the relative cost of errors;
• whether an association is causal; or
• which operational constraint binds.

The case should state which facts are known, which are contested, and which must be assumed.

Multiple Technical Layers

One case can support different program levels.

Read as a diagnostic rather than a second scorecard, the framework becomes clear: Interpretive — Student task: Identify target, assumptions, risks, and decision owner. Analytical — Student task: Derive metrics, compare models, and interpret uncertainty. Computational — Student task: Build a reproducible pipeline and perform stress tests. Research — Student task: Challenge identification, extend the model, or collect new evidence.

This makes case-based teaching compatible with differentiated programs.

A management student may not derive a doubly robust estimator but should understand why a prediction score does not identify intervention benefit. An MSc student should be able to formalize and test that distinction.

Case Construction from a Real Problem

A real problem is usually too large and poorly documented for teaching. Case design requires reduction.

The instructor chooses a boundary:

Only information in $\mathcal I_t$ should be available for the initial decision. Later evidence can be released in stages.

A well-constructed case package may include:

1. an institutional memorandum;
2. a data dictionary and sample;
3. a timeline;
4. stakeholder objectives;
5. a flawed prior analysis;
6. a constraint or cost table; and
7. a later outcome or distribution shift.

The package should be rich enough to support reconstruction and small enough to make the intended concepts visible.

A Staged Case Sequence

Cases are strongest when information arrives over time.

Stage 1: Formulation. Students define the unit, target, population, and decision.

Stage 2: Data audit. They inspect selection, missingness, timing, and measurement.

Stage 3: Model comparison. They establish a baseline and justify alternatives.

Stage 4: Decision. They choose metrics, thresholds, actions, and constraints.

Stage 5: Shock. The instructor changes a policy, population, feature, or cost.

Stage 6: Correction. Students identify which parts of the original solution survive.

The shock transforms a project into a test of transfer.

Example: An A/B Test That Is Not Simple

Suppose a platform randomly assigns a message:

and observes purchase $Y_i$.

The difference in means estimates

The initial exercise is straightforward. The case then adds:

• users appear on multiple devices;
• messages can be shared;
• assignment probabilities differ by market;
• the experiment stops early after a favorable dashboard;
• revenue has a heavy-tailed distribution; and
• rollout changes competitor behavior.

Each detail connects to a technical issue: dependence, interference, weighting, sequential testing, robust estimation, and external validity.

The case remains one organizational decision while its mathematical structure deepens.

Baselines Prevent Theatrical Complexity

Cases can tempt students to demonstrate every method they know. A disciplined case requires a baseline:

The advanced model should answer:

Does it improve prediction under the relevant split? Does it change the selected action? Does it remain stable? Is the gain large enough to justify implementation and monitoring?

If not, complexity may be technically interesting and decisionally irrelevant.

The Case Memorandum

Students should not submit only code or slides. A case memorandum can require:

1. decision and target;
2. DGP and evidence limitations;
3. mathematical formulation;
4. model comparison;
5. validation and uncertainty;
6. recommendation under constraints;
7. failure conditions; and
8. revision after the shock.

Expressed as a practical comparison rather than another table, the distinctions are clear: Question — Weak submission: Repeats the label; Strong submission: Defines estimand and decision. Model — Weak submission: Names an algorithm; Strong submission: Connects representation to assumptions. Evidence — Weak submission: Describes columns; Strong submission: Explains selection and timing. Validation — Weak submission: Reports one score; Strong submission: Tests plausible deployment failures. Decision — Weak submission: Recommends the highest score; Strong submission: Uses value, cost, and constraint. Revision — Weak submission: Defends the original; Strong submission: Changes the claim when evidence changes.

The memorandum forces technical work to become an argument.

Discussion Is a Form of Model Comparison

Case discussion should not reward confidence or rhetorical fluency. It should expose competing structures.

An instructor can ask each team to state:

• its target;
• strongest assumption;
• preferred model;
• evidence against that model;
• decision threshold; and
• condition that would reverse the recommendation.

The class can then compare models rather than personalities.

Written preparation remains essential. Discussion is most useful after students have committed to a structure that can be criticized.

The Technical Answer Key

An open case may permit several defensible recommendations, but it still needs an answer architecture.

The instructor's technical key should identify:

• admissible target definitions;
• assumptions required by each interpretation;
• calculations that should be reproducible;
• evidence that rules out an approach;
• acceptable validation designs;
• decision criteria that must be stated; and
• conclusions the case cannot support.

The key can represent the admissible solution set as

Students need not reproduce the instructor's preferred model. They must remain inside the set of solutions supported by the evidence.

This protects case teaching from two opposite errors: one hidden “correct opinion” that rewards guessing the instructor's view, and unrestricted discussion in which technical contradictions have no consequence.

Assessment and Group Work

Group cases reflect professional practice but can hide individual competence.

A balanced design may use:

The group develops the main analysis. Each student writes a short individual memorandum, answers an oral question, or solves a changed condition independently.

This preserves collaboration while making ownership observable.

Ethical and Institutional Boundaries

Real cases can contain private data, commercial interests, or affected individuals.

The school should:

• anonymize or synthesize sensitive data;
• declare conflicts and permissions;
• avoid turning client material into advertising;
• separate educational evaluation from commercial success;
• state which outcomes are simulated; and
• teach students that some data should not be used.

Authenticity does not override responsibility.

The SIAI GSB Case Principle

At SIAI GSB, cases should demonstrate that technical learning is not confined to the classroom.

A case drawn from finance, marketing, operations, public policy, or scientific research should still require the same architecture: formulation, DGP, model, validation, decision, and revision. The application changes; the discipline remains.

This permits cases to connect MSc and MBA education without pretending that all students perform the same mathematics.

The strongest case materials are designed in layers. Every student receives the same decision context, raw evidence, and institutional constraint. A first layer requires a defensible baseline; a second introduces identification or estimation difficulty; a third asks how the result changes after deployment. This structure preserves a common discussion while allowing mathematical depth to increase. It also prevents complexity from becoming theatrical. Students cannot hide behind an elaborate model because the baseline remains visible, and they cannot treat a technically correct estimate as the end of the case because the decision and monitoring rule still have to be defended. A written technical note after the discussion should record the competing specifications, the evidence that separated them, and the conditions under which each recommendation would change. That note turns conversation into an auditable analytical product. It also gives individual students accountable work that can be assessed separately from the persuasive performance of the group. Technical depth survives because the case requires calculation to answer a consequential institutional choice.

A rigorous case joins three questions that current AI analysis often separates. The Economy’s education framework asks students to formulate and defend an approach; Value-Maxxing asks whether the resulting output improves the decision; and SIAI’s work on causal feedback asks whether deployment changes the process being measured. A case becomes technically serious when students must answer all three with data, a model, and an explicit account of uncertainty.

Conclusion

Case-based learning and technical depth reinforce one another when the case is built around a model-based decision.

The narrative supplies context. Mathematics supplies structure. Data supply evidence. Constraints give the result consequence. Perturbation reveals whether students can transfer what they learned.

The purpose is not to make technical education more entertaining. It is to make the meaning and limits of technical work impossible to ignore.

A serious AI case does not ask students merely what they think. It asks what they can defend.

References

Lee S. Shulman, “Signature Pedagogies in the Professions”, Daedalus 134, no. 3 (2005): 52-59.
Allan Collins, John Seely Brown, and Susan E. Newman, “Cognitive Apprenticeship: Teaching the Craft of Reading, Writing, and Mathematics”, 1987.
C. Roland Christensen, David A. Garvin, and Ann Sweet, eds., Education for Judgment: The Artistry of Discussion Leadership, Harvard Business School Press, 1991.
The Economy (2025) ‘Redesigning Education Beyond Procedure in the Age of AI’, The Economy Review, 17 September.
The Economy Editorial Board (2026) ‘Value-Maxxing: The AI Metric That Puts Judgment Back in Charge’, The Economy Review, 14 May.
Swiss Institute of Artificial Intelligence (2026) ‘From Feedback Loops to Causal Guardrails: Endogeneity in AI Systems’, SIAI AI Memo, 20 June.