This artifact comes from AIML‑500 Workshop 2, where the assignment was to differentiate machine learning from deep learning by analyzing real‑world applications and arguing why each approach fits its problem and why the other does not. The assignment could be answered by reciting definitions. I treated it instead as the question engineering organizations actually face: given a problem, which class of tool earns its cost? The result is a report built around two deliberately mirror‑image cases and the decision framework that falls out of comparing them.
The report examines two production applications. The traditional machine learning case is customer churn prediction with a support vector machine, as used across subscription businesses: structured, tabular customer data, modest scale, and decisions that must be explainable to the people acting on them. The deep learning case is machine translation with Transformer models, the architecture behind Google Translate's neural systems: raw sequential text whose meaning depends on context no human could reduce to a feature checklist. For each case, the report argues both directions, why the chosen approach fits and why the opposite approach fails, and shows that the failures are structural rather than a matter of tuning. An SVM cannot generate a sentence; a deep network brings cost and opacity to a spreadsheet problem without adding accuracy. The full report, as submitted and written in APA 7 style, is available above as evidence.
The framework the two cases produce, four questions asked before any model is chosen:
The assignment objective was to differentiate machine learning from deep learning through real‑world case analysis. My personal objective was to add a third distinct skill to this portfolio. Artifact 01 shows I can design and ship an AI product; Artifact 02 shows I can synthesize research into a thesis and communicate it. This artifact demonstrates evaluative judgment: the ability to match an AI approach to a business problem under real constraints of data, cost, and accountability, and to argue the negative case, why the more sophisticated tool is sometimes the wrong one.
The report went through five stages:
The central challenge was resisting a false hierarchy in which deep learning is automatically treated as more advanced and therefore better. Building mirror-image cases forced me to separate capability from suitability. I learned that the most defensible recommendation begins with data shape, error cost, explanation needs, and operating constraints, then selects the simplest model class that can satisfy them.
The scarce skill in applied AI is not enthusiasm for the newest model; it is knowing when not to use it. This artifact argues the negative case in both directions, and it does so from production experience in financial services, where model decisions about real customers must survive questions from operations, compliance, and regulators.
Organizations routinely overspend by applying deep learning to tabular problems and underdeliver by applying simple models to perception and language problems. Engineers who can run this evaluation before a line of code is written save teams months. For senior backend and forward‑deployed roles, this judgment is the first thing exercised on every engagement.