Everything the previous four lessons established — the trust boundary, the two shapes of injection, the leaky instruction hierarchy — points to the same practical conclusion: something has to check text before it reaches the model, and that something cannot be the model itself. Input validation is the guardrail layer that does this checking, and content filtering is its close cousin, screening not for injection specifically but for content the system should never process at all — harassment, self-harm content, requests for genuinely dangerous instructions unrelated to the application's purpose.
Building this layer well is harder than it looks, because the naive version, a keyword blocklist, is both too weak (defeated by paraphrase, as Lesson 3 showed) and too strong (blocking legitimate requests that happen to contain a flagged word, like a customer support message that legitimately says 'ignore the shipping delay and just refund me'). A production input validator has to layer techniques the way this course has layered everything else, and calibrate each layer's sensitivity against the real cost of a false positive, not just the cost of a false negative.
This lesson builds that layered validator concretely: what it checks, in what order, and how to reason about the trade-off between catching more attacks and blocking fewer legitimate users, a trade-off Lesson 29 returns to in full under the name of the safety-speed trade-off.
Analogy🏏Cricket
🏏 Think of it like cricket: A stadium's bag-check policy at the gate is not one blanket rule, 'no bags allowed'; it is a layered set of checks calibrated to actual risk — a clear rule against anything that looks like a weapon or a flare, a size limit on bags that triggers a manual search rather than an outright ban, and a more relaxed pass for small, obviously harmless items like a rolled-up team flag. A gate that banned every bag outright would stop the actual threats but also turn away thousands of ordinary fans carrying nothing more dangerous than a water bottle and a scorecard, which is its own kind of failure for a stadium that exists to host fans. A gate that let everything through unchecked would obviously fail the other way. Just as the bag-check policy layers a strict rule for genuinely dangerous items with a lighter check for ambiguous ones, an input validator layers a strict rule for clear attack patterns with a lighter, more calibrated check for ambiguous text. Just as an overly strict gate policy turns away the fans a stadium exists to serve, an overly strict input filter blocks the legitimate users a product exists to serve. The insight is that the goal of a checkpoint is never maximum restriction — it is calibrated restriction that catches real threats while letting the actual audience through.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.