You have learned to map a phase into steps, classify each as AI-ready or human-owned, and place gates at the consequential handoffs. This lesson adds the rigor that tells you how hard to verify at each gate and where the workflow is most likely to fail: failure-mode mapping, which asks of every AI step not just whether it can fail but how it fails, what the failure costs, and how likely the failure is to slip through undetected. Engineers know this discipline as FMEA, failure mode and effects analysis, and applied to AI steps it transforms verification from a uniform habit into a targeted strategy, concentrating effort where a failure would be severe, likely, and hard to catch, and economizing where a failure would be minor, rare, and obvious. Without failure-mode mapping, verification is either uniform, wasting effort on low-risk steps while under-protecting high-risk ones, or ad hoc, depending on whether someone happened to worry about the right step. With it, the verification design is principled, matched to where the AI's characteristic failures meet the workflow's consequential points. This lesson teaches you to map the failure modes of every AI step so your verification goes exactly where it is needed.

Why Map Failure Modes at All

Classifying steps and placing gates tells you where verification must happen; failure-mode mapping tells you what each verification must catch and how rigorous it must be, which is the difference between knowing a gate exists and knowing how to staff it. A gate without a failure-mode analysis is a checkpoint with no specification: the verifier knows they must check the AI output but not what they are checking for, so they review generically, which catches obvious errors but misses the specific failures the AI step is prone to. A gate informed by failure-mode mapping is a checkpoint with a specification: the verifier knows the particular ways this step fails, so they look for exactly those, which is far more likely to catch the real errors.

The deeper reason to map failure modes is that verification effort is finite and should be allocated by risk, not spread uniformly. Some AI steps fail in ways that are severe (a large consequence), likely (the AI is prone to that error), and hard to detect (the failure does not announce itself), and these deserve intensive verification; others fail in ways that are minor, rare, and obvious, and these deserve light verification. Without a failure-mode map, the workflow cannot tell these apart, so it either over-verifies everything, which is slow and wasteful, or under-verifies the dangerous steps, which is unsafe. The failure-mode map is what lets the verification be proportionate, concentrating on the steps where a failure would be costly, likely, and concealed, which is both more efficient and safer than uniform verification. So failure-mode mapping is the analysis that turns gate placement into a verification strategy, specifying what each gate catches and how much effort it warrants, which is the rigor the workflow design needs to be both safe and efficient.

The Three Questions: How, How Bad, How Hidden

Failure-mode mapping asks three questions of every AI step, and they correspond to the three dimensions of risk. The first is how does it fail: what are the specific ways this AI step can produce a wrong output, which depends on the engine and the task, a generative step can fabricate or misstate, a vision step can misread, a predictive step can extrapolate wrongly, a generative-design step can optimize the wrong objective. The second is how bad is the failure: what is the consequence if this failure reaches the consequential action, which ranges from minor and recoverable to severe and irreversible, the severity dimension. The third is how hidden is the failure: how likely is it to slip through undetected, which depends on whether the failure announces itself or is concealed behind plausible, well-formed output, the detectability dimension.

These three questions together determine how much verification a step warrants, because risk is the combination of how the step fails, how bad the failure is, and how hard it is to catch, so a step that fails in a severe, hard-to-detect way needs the most verification regardless of how rarely it fails, while a step that fails only in minor, obvious ways needs little even if it fails often. The mapping produces, for each AI step, an answer to all three, which is the step's risk profile, and the verification is then designed to match the profile: intensive where the failure is severe and hidden, lighter where it is minor and obvious, and specifically targeted at the particular failure modes the first question identified. The three questions are the discipline that converts a vague sense that AI output should be checked into a precise specification of what to check, how hard, and why, which is what makes the verification reliable rather than a generic glance. Mapping the failure modes is asking these three questions of every AI step and designing the verification from the answers.

Failure-mode mapping asks three questions of every AI step: how does it fail (the specific failure modes, which depend on the engine), how bad is the failure (severity), and how hidden is it (detectability). Together these give the step's risk profile, and the verification is designed to match it: intensive where the failure is severe and hidden, lighter where it is minor and obvious, and targeted at the specific failure modes identified.

Each Engine Has Characteristic Failure Modes

The first question, how does the step fail, is answered largely by which engine the step uses, because each of the four engines has characteristic failure modes that the level has taught. A generative-AI step, drafting or extracting, fails by fabrication and misstatement: it produces fluent, confident output that may contain invented facts, wrong citations, or plausible falsehoods, and the failure is hidden behind the fluency. A computer-vision step, reading images or point clouds, fails by misperception: it is right about ninety percent and misreads the unusual, occluded, or ambiguous conditions, and the failure is hidden because the misread looks like a confident correct read. A predictive-ML step, forecasting, fails by extrapolating from patterns that may not hold, especially on conditions unlike its training data, and the failure is hidden because the prediction is presented with unwarranted confidence. A generative-design step, optimizing, fails by optimizing the stated objective while violating the unstated constraints, and the failure is hidden because the output is optimal on the metrics and unbuildable on the omitted ones.

Knowing the engine therefore tells you the step's characteristic failure modes, which is what the first question needs, and it also tells you something about detectability, because all four engines share the property that their failures are hidden behind confident, well-formed output, the fluency-is-not-accuracy theme, so AI failures generally have low detectability, which is precisely why they need verification. The engine-specific failure modes let the failure-mode map be specific rather than generic: instead of this AI step might be wrong, the map says this generative step might fabricate a citation, this vision step might misread the occluded tie-in, this generative-design step might route through a sequence constraint, which tells the verifier exactly what to look for. So the engine classification from the workflow map feeds directly into the failure-mode map, because the engine determines the characteristic failures, and the failure-mode map turns that into a specific verification target. The four engines are not just a way to classify AI-ready steps but a catalog of characteristic failure modes that makes the failure-mode mapping concrete and the verification targeted.

Severity and Detectability Drive Verification Intensity

The second and third questions, severity and detectability, together drive how much verification a step warrants, and they interact in a way worth understanding. Severity is the consequence if the failure reaches the consequential action: a fabricated citation in a draft RFI that a human reads before sending is low-severity because it is caught and recoverable, while a misread dimension that drives a prefabricated assembly is high-severity because it produces an expensive physical misfit, and a wrong value in a safety document is highest-severity because it endangers a person. Detectability is how likely the failure is to be caught: a failure that produces obviously broken output is highly detectable and low-risk even if severe, while a failure that produces plausible, well-formed wrong output is poorly detectable and high-risk because nothing signals the error.

The interaction is that the most dangerous steps are those that are both high-severity and low-detectability, where a costly failure hides behind plausible output, because those combine a large consequence with a high chance of slipping through, and these deserve the most intensive verification. A high-severity but highly-detectable failure is less dangerous because it will be caught, and a low-severity failure is less dangerous regardless of detectability because the consequence is small. So the verification intensity should be driven by the product of severity and undetectability, concentrating on the steps where a severe failure is also hard to catch, which are the steps where unverified output would most likely cause a large, undetected problem. This is why failure-mode mapping is more than listing failures: it ranks the steps by the combination of how bad and how hidden their failures are, which tells the workflow designer where to put the most verification, and the insight that AI failures are characteristically low-detectability (hidden behind fluent output) means that severity often becomes the dominant factor, so the high-severity steps, the ones touching stamps, schedules, payments, and safety, get the most verification because their failures are both costly and concealed. Severity and detectability together turn the failure-mode map into a verification-intensity ranking.

The Failure-Mode Map Drives the Verification Design

The output of failure-mode mapping is a map that drives the verification design of the entire workflow, specifying for each AI step its failure modes, severity, detectability, and the resulting verification, which converts the gate placement from lesson one into a fully specified verification strategy. Where the map shows a severe, hidden failure mode, the verification is intensive and specifically targeted at that failure: the gate at that handoff is staffed to look for exactly the engine-characteristic failure that would be costly and concealed. Where the map shows a minor or obvious failure mode, the verification is light, conserving effort. The map thus tells the workflow designer not just where the gates are but how to staff each one, what it checks for, and how rigorous it must be, which is the specification a gate needs to actually catch the failures it exists to catch.

This is also what makes the verification design defensible and improvable. Because the map states each step's failure modes and the verification matched to them, the design can be reviewed: someone can ask whether a high-severity hidden failure is adequately verified, whether a step's failure modes were correctly identified, whether the verification actually catches the stated failure, which makes the design auditable rather than a matter of whoever happened to verify what. And the map improves over time: when a failure slips through, it is added to the map for its step, and the verification is strengthened, so the failure-mode map is a living record of how the workflow's AI steps fail and how the verification catches them, getting more accurate as experience accumulates. The discipline is that every AI step gets a failure-mode analysis, the verification is designed from it, and the map is maintained as failures are discovered, which keeps the verification matched to the actual failure modes rather than to a one-time guess. The failure-mode map is the engineering of the verification, making it targeted, proportionate, defensible, and improvable, which is what turns the workflow design from a sketch into a rigorous specification.

The Applied Problem: Map the Failure Modes

Here is the exercise. Take an AI-integrated workflow you have mapped, or map one, and for every AI step perform a failure-mode analysis: identify the step's characteristic failure modes (from its engine), the severity of each failure if it reached the consequential action, and the detectability of each failure, then design the verification for each step from its risk profile, intensive and targeted where the failure is severe and hidden, light where it is minor and obvious. Produce the failure-mode map that specifies the verification strategy for the whole workflow.

Produce two things. First, the failure-mode map: for each AI step, its failure modes, severity, detectability, and the verification designed to match, in the form that specifies how each gate is staffed and how rigorous it must be. Second, the verification-priority ranking: the AI steps ranked by the combination of severity and undetectability, identifying the steps that most need intensive verification because their failures are both costly and concealed, with the reasoning. Pay particular attention to the steps that are high-severity and low-detectability, because those are where an unverified failure would most likely cause a large, undetected problem, and they are where the failure-mode map most changes the verification design from a uniform habit to a targeted strategy.

The deliverable is the failure-mode map and the verification-priority ranking, and the lasting product is the ability to design verification that is proportionate to risk, concentrated where AI failures are severe and hidden and economized where they are minor and obvious, which makes the AI-integrated workflow both safe and efficient. This completes the workflow-design chapter: lesson one mapped the phase and placed the gates, lesson two designed the highest-stakes handoff, and this lesson specifies how rigorously each gate must verify and what it must catch, by mapping the failure modes of every AI step. The professional who masters this designs workflows whose verification is engineered rather than habitual, matched precisely to where the AI's characteristic failures meet the workflow's consequential points, which is the difference between verification that reliably catches the dangerous failures and verification that hopes to, achieved by mapping how every AI step fails, how bad and how hidden each failure is, and designing the verification from the answers.

Key Takeaways

• Classifying steps and placing gates tells you where verification must happen; failure-mode mapping (FMEA applied to AI steps) tells you what each verification must catch and how rigorous it must be, turning verification from a uniform habit into a targeted strategy.
• Verification effort is finite and should be allocated by risk, not spread uniformly: some AI steps fail in severe, likely, hard-to-detect ways deserving intensive verification, others in minor, rare, obvious ways deserving light verification, and the map is what tells them apart.
• The mapping asks three questions of every AI step: how does it fail (the specific failure modes), how bad is the failure (severity, the consequence if it reaches the consequential action), and how hidden is it (detectability, how likely to slip through undetected).
• The first question is answered largely by the engine: generative steps fabricate and misstate, vision steps misread (right ninety percent), predictive steps extrapolate wrongly, generative-design steps optimize the wrong objective. All four hide their failures behind confident, well-formed output, so AI failures are characteristically low-detectability.
• Severity and detectability drive verification intensity, and they interact: the most dangerous steps are high-severity and low-detectability, where a costly failure hides behind plausible output, combining a large consequence with a high chance of slipping through, so they deserve the most intensive verification.
• Because AI failures are characteristically low-detectability (hidden behind fluency), severity often dominates, so the high-severity steps (touching stamps, schedules, payments, safety) get the most verification because their failures are both costly and concealed.
• The failure-mode map drives the verification design: it specifies how each gate is staffed, what it checks for (the engine-characteristic failure), and how rigorous it must be, and it makes the design auditable (others can review whether high-risk failures are adequately verified) and improvable (failures that slip through are added and the verification strengthened).
• The artifact: for every AI step, map the failure modes, severity, and detectability, design the matched verification, and rank the steps by severity times undetectability, identifying the high-severity, low-detectability steps where the map most changes verification from a uniform habit to a targeted strategy.