How can a request pass a term-based input screen while the generator still answers the original ask?

## Two readers, one string A vendor sells a drafting assistant that lives inside somebody else's SaaS product. The end user never sees a chat window; they see a form field — "describe what you want" — and the vendor's service takes that value, screens it, and (if it passes) concatenates it into a prompt sent to a much larger generator the vendor licenses rather than owns. Two components read the same characters: | Component | What it is asked to do | What it was built from | | --- | --- | --- | | the input screening model | decide whether this string belongs to a flagged category | a small classifier trained on labelled examples, often sitting behind a flat list of denied terms | | the generator | produce the requested text | a frontier-scale model trained to comprehend language in general | The screen performs **recognition against a learned boundary**. The generator performs **comprehension**. Those are not the same difficulty, and the difference is the whole subject of this leaf. ## What a term-level screen actually keys on A denylist compares bytes: it fires when a listed string is present. A trained classifier is one step up — it fires when the input lands near a region it learned from labelled examples — but its notion of the request is still anchored to the surfaces it was shown. Neither component reasons about what the sentence would *mean* to a competent reader who also has the vendor's own prompt, the host product's context, and general world knowledge in front of it. So the construction is not a trick at the character level. It is a restatement: the same ask, carried in referents ("the second item described above"), in paraphrase, or in a professional register where the vocabulary is ordinary. Nothing is hidden and nothing is encoded. The words the screen knows are simply not present, while the meaning a fluent reader recovers is unchanged. ## Why the meaning survives Models do not store sentences; they resolve them. Anaphora, ellipsis, indirect reference and framing are exactly what a large language model is good at, because resolving them is what language modelling rewards. The screen was optimised for a narrow discrimination on a labelled dataset; the generator was optimised to understand text in general. When you ask a much stronger reader to reconstruct an ask from indirection, you are playing to its strength; when you ask a much weaker reader to recognise the same ask from an unfamiliar surface, you are playing to its limit. A useful way to hold it: **vocabulary is a property of the surface, meaning is a property of the reader.** Remove the vocabulary and you have changed what one reader can key on, not what the other reader recovers. ## What it costs the person doing it This is not free. Every term removed is information removed. Push the indirection far enough and the generator stops resolving the referent the way it was intended — the reply becomes generic, drifts to the wrong subject, or answers a harmless neighbouring question. The practical constraint is that the restatement has to remain **unambiguous to the generator while carrying none of the screen's vocabulary**, and those two pressures pull in opposite directions. That is an iteration cost, and it is why this class is a craft rather than a copy-paste. ## Two different failures, often confused Getting past the screen is not the same as getting an answer. A screening layer's block and the generator's own refusal are different events produced by different components: the first says a string scored above a threshold, the second says the model declined the answer on its own trained preferences. A restatement can clear the screen and still be declined — and it can equally be declined by the screen while the generator would have answered happily. Telling those two apart by their shape is its own skill, and it is the first measurement anyone probing a deployment makes. ## The direction of every claim here Be careful about what each observation proves: - A clean pass proves the text **scored below the screen's threshold**, not that it was harmless. - A block proves a **string was scored high**, not that a harmful action was prevented. - An answer coming back proves the generator **understood and complied**, not that the screen failed to notice something obvious. Getting these backwards is the misconception this material exists to correct. Somebody reading a dashboard of screen block counts is reading how often the screen matched its own training distribution — which is a fact about the screen, not a fact about the traffic. ## Where the class stops working It stops when the ask genuinely cannot be expressed without a term the *generator* also needs — some requests have no legible paraphrase. It stops when the generator itself refuses regardless of surface. And it stops being interesting when the restatement is so oblique that the output is useless, which is the honest ceiling on the technique.