A team that ships only a classifier guardrail discovers, during an incident review, that a $95,000 transfer went through because the classifier scored the request 0.58 against a 0.60 threshold — a near-miss that a one-line numeric rule would have blocked with total certainty. A team that ships only rules discovers, during a different incident review, that an attacker phrased a prompt injection in a way no rule author anticipated, and it sailed through untouched because rules only catch what they were explicitly told to look for. Neither team was using the wrong guardrail type; both teams were using only one, and single-layer defense fails predictably at exactly the boundary its one layer was never built to cover.
Layered defense is the discipline of combining input validation, rule-based checks, and classifier-based checks into an ordered pipeline where each layer catches what the layers around it structurally cannot, and where a compromise of any single layer does not compromise the whole system. This is not a hedge against uncertainty about which guardrail type is "best" — the previous two lessons established that rules and classifiers solve genuinely different problems, and layering is simply the architecture that lets a system have both without forcing a false choice between them.
This lesson builds the ordering discipline that makes layering actually work — cheap, deterministic checks first, expensive probabilistic checks later, output-side checks independent of input-side checks — and the failure-mode analysis that shows why a single point of failure anywhere in a guardrail pipeline defeats every layer behind it. The project lesson immediately following this one composes exactly this pipeline end to end, so the ordering decisions made here are the ones that project actually has to implement.