Before and after are different jobs
There are two places to intervene: before the model writes, and after. Before is a scope screen — is this question even in remit — and it is cheap, because refusing early costs nothing. After is where the rules that must not be negotiable live, because after generation there is a finished text to examine rather than an intention to influence.
A rule applied after generation is a function of a string. It has no context window, no instruction hierarchy, and no better idea. Run it a thousand times on the same answer and it returns the same verdict a thousand times.
Every guard is a scar
None of these were designed up front. Each one exists because a prompt instruction was written, tested, and observed to fail — usually not immediately, and usually in a way that only showed up across many runs. A coaching agent told to avoid income claims will avoid them for a long stretch and then quote a growth figure it found in the library, because the library said it and nothing in the instruction covered the case where the source itself states one.
So the guard is written as a rule, and the rule is the thing that ships. The instruction usually stays too, because a model that has been asked nicely produces better raw text — but nothing depends on it any more.
Guards can be wrong, and that has a cost
A rule that fails correct answers is not erring on the safe side. It trains whoever reads the evaluation output to skim past that line, which is how a real problem eventually gets waved through. When a guard is narrowed, both directions have to be proven: that it stops flagging the case that was wrongly caught, and that it still catches the thing it was written for.
This is why every guard reports by name with a reason rather than silently rewriting. A reviewer can see which rule fired, on what, and disagree with it.