Introduction Stakeholders use “AI”, “machine learning”, “deep learning”, “generative AI”, and “LLMs” interchangeably, and the result is that scoping conversations spend half their time negotiating what kind of system the team is actually building. The pairing of generative AI with supervised learning is one of the recurring confusions: they are different families with different inputs, different outputs, and different failure modes — but they compose well, and the production wins come from understanding where the composition is genuine and where it is being used as a marketing label over a single-family system. This article gives the working taxonomy and walks through the compositions that hold. See the generative AI practice for the broader scoping framework. The naive read is that “GenAI + supervised learning” is a single thing. The expert read is that the two families serve different problem classes and that the productive compositions are bounded: generative models help label, augment, or post-process; supervised models classify, score, or extract. Knowing which model carries which load is the scoping discipline. What this means in practice Generative AI produces content; supervised learning produces labels, scores, or classifications. The composition wins are bounded: synthetic-data generation, labelling assistance, retrieval re-ranking, post-processing. A “GenAI + supervised” system is not always genuinely both — sometimes it is one family doing the work with the other adding marketing surface. Pick the family by problem class first, then decide whether composition adds value. Why did symbolic AI fail in the way it did, and what does neuro-symbolic AI bring back? Symbolic AI in the 1980s and 1990s aimed to encode human knowledge as explicit rules and logical structures. It failed at two scales. Knowledge-acquisition: encoding every rule a domain expert uses exhausts the experts faster than the system reaches usefulness; the rule sets become unmaintainable. Brittleness: rule-based systems handle the cases the rules cover and fail abruptly on the cases just outside, with no graceful degradation. The 1990s “AI winter” partly reflected the limits of this approach for real-world domains. Neuro-symbolic AI brings back the strengths (explicit reasoning, verifiable steps, composable rules) by combining them with neural components (perception, fuzzy matching, generalisation). The pattern: a neural front-end extracts structured representations from messy inputs, a symbolic reasoner operates on the structured representations, and the result has both the generalisation of the neural part and the verifiability of the symbolic part. The hybrid is harder to build than either purely, but it solves problem classes (theorem proving, program synthesis, structured planning) that pure neural approaches still struggle with. How does a working taxonomy of ML, deep learning, LLMs, and GenAI map to real engineering decisions? ML (machine learning): models that learn from data. Includes everything below. Classical ML (logistic regression, gradient-boosted trees, SVMs): tabular data, structured features, problem sizes where deep learning is overkill or under-data. Still the right call for most enterprise tabular prediction. Deep learning: neural networks with many layers. Handles unstructured data (images, audio, text) where classical ML struggles. LLMs (large language models): a specific deep-learning architecture (transformers) trained on text at scale. Generative by default, also strong on text classification, extraction, and reasoning when prompted appropriately. GenAI (generative AI): models whose primary output is new content (text, image, audio, video). LLMs are one GenAI family; diffusion models for images are another. GenAI overlaps with deep learning but the framing is around the output type. The engineering decision: pick by the problem’s data, output, and scale. Tabular classification on 100k rows: classical ML. Image classification on 1M images with labels: deep learning (likely a fine-tuned ViT). Open-ended text generation: LLM. Image generation: GenAI (diffusion). The labels are operational, not academic. What is the key feature of generative AI that separates it from classical ML for a production team? Generative AI’s output is content; classical ML’s output is a label, a score, or a structured prediction. The operational consequence is that GenAI output is harder to evaluate (open-ended, no ground truth in most cases), harder to monitor (output distribution shifts mean something different when outputs are creative), and harder to constrain (the output space is not a fixed set of classes). Classical ML benefits from decades of MLOps infrastructure for evaluation, monitoring, and rollback. GenAI benefits less; the same patterns need to be re-engineered for open-ended outputs (LLM-as-judge evaluation, semantic-similarity drift detection, structured-output schemas to constrain the output space). A team adopting GenAI typically discovers that the production engineering it needs is recognisably different from the classical-ML engineering it has — different evaluation, different monitoring, different safety layer. Where do transformers sit in the taxonomy, and why do they keep dominating across modalities? Transformers are a deep-learning architecture characterised by self-attention. They started in text (the 2017 “Attention is All You Need” paper), spread to images (Vision Transformers, 2020), audio, video, time series, and structured data. The dominance across modalities comes from three properties: they handle variable-length input naturally, they scale predictably with model size and data, and they enable the cross-modal training (text+image, text+audio) that makes joint-embedding spaces practical. The practical consequence: a 2026 engineering team building a new model in almost any modality should default to a transformer architecture unless there is a specific reason not to (extreme latency constraints, very small data regimes where other architectures are more sample-efficient). The investment in transformer infrastructure (training stacks, inference optimisations, deployment patterns) carries across modalities, which compounds the architectural advantage. How does applied AI differ from general AI in terms of what an engineering team should build today? Applied AI: models trained for specific tasks (image classification for product inspection, text classification for support routing, language generation for a domain-specific assistant). The model is fit-for-purpose, the evaluation is bounded, the deployment is straightforward. This is what almost all production AI is. General AI (often “AGI”): the speculative idea of a single model that performs across the full range of human cognitive tasks. The 2026 reality is large foundation models (LLMs, multi-modal models) that approach general behaviour on text and increasingly across modalities — but they are still tools applied to bounded tasks in production deployments. The framing “is this AGI” is mostly a marketing discussion; the engineering question is whether the foundation model is a better starting point than a from-scratch task-specific model for the task at hand. Frequently yes; not always. Which technologies have actually advanced LLM operation in the last 24 months, and which are noise? Real advances: long-context models (1M+ token context windows that genuinely work for retrieval and reasoning), reasoning models (chain-of-thought built into the model, useful for problems that decompose), tool-use protocols (model-side function-calling that integrates with engineering systems), structured-output guarantees (schema-constrained generation), and inference optimisations (speculative decoding, caching, quantisation) that reduce production cost. Noise: “agentic” framings that re-label what was already prompt engineering, prompt-injection scares that were always known to security engineering, hype cycles around specific benchmark numbers that do not translate to production behaviour, and proliferation of frameworks that wrap underlying APIs without adding durable value. The signal-to-noise ratio is improving as the field matures but the engineering team’s discipline is the same: evaluate against the production workload, not the marketing surface. How TechnoLynx Can Help TechnoLynx works with leadership and engineering teams to disambiguate the AI/ML/LLM/GenAI taxonomy before the first vendor RFP, and then to scope production systems that compose the right families for the problem. If you are starting a GenAI initiative and need the taxonomy fixed before scope creep does it for you, contact us for a feasibility audit. Image credits: Freepik