Content Filtering › Rule-Based Filtering

Before machine learning was applied to content moderation, rule-based filtering was the dominant approach, and it remains valuable today for specific use cases where precision is critical and the patterns are well-defined.

The simplest rule-based filter is a blocklist: a list of words, phrases, or patterns that trigger an immediate block. If any item in the list appears in the text, the text is blocked. No machine learning required.

Blocklists have real advantages. They are interpretable (you can audit exactly what triggers a block), they are fast (string matching is extremely cheap compared to model inference), and they are deterministic (you know exactly when they will fire). For categories where the harmful content is reliably expressed through specific terms, such as illegal product names, known scam phrases, or regulatory keywords, blocklists can achieve near-perfect precision on their specific patterns.

The limitations are equally well-known. Blocklists are brittle: they block the exact strings they list, but miss paraphrases, misspellings, and synonyms. A blocklist for the word "kill" will also block "skill", "killer whale", "kill switch in the factory process". This over-blocking problem is called the Scunthorpe problem, after the English town whose name triggered early internet profanity filters. Conversely, a user motivated to bypass a blocklist can do so trivially through character substitution, spacing, or language switching.

For this reason, blocklists are almost never used as a standalone filter in modern systems. They function as a fast first-pass layer or as a precision tool for high-severity known patterns, supplemented by classifier-based detection.

The maintenance burden of blocklists is also often underestimated. A blocklist that covers the known threats as of launch day will be incomplete three months later. New slang terms emerge, adversaries discover gaps, and user populations shift. Keeping a blocklist current requires ongoing human monitoring of production traffic, which is expensive and easy to deprioritize. Organizations that invest in automated ML-based detection can often afford to let blocklists age more gracefully, because the classifier provides a backstop for patterns the blocklist misses.

Regular expressions (covered in detail in Part I: Text as Data of this book, particularly the Regular Expressions chapter) give you more expressive rule patterns than simple string matching. You can write patterns that match structural properties of harmful content rather than just specific words.

Common use cases for regex-based filters include:

• Personal identifiable information (PII) detection: Patterns for credit card numbers, Social Security numbers, email addresses, and phone numbers.
• URL pattern filtering: Blocking known malicious domains or filtering all external links in certain contexts.
• Structured content detection: Detecting code patterns associated with SQL injection or command injection.
• Format violations: Ensuring outputs conform to required formats (no raw HTML in a plaintext response, for example).

The advantage of regex filters over ML classifiers for these cases is precision. A regex for a 16-digit credit card number will match credit card numbers reliably without false positives on other numeric strings. A classifier trained to detect PII might flag "he is 45 years old" as sensitive, because it has learned to associate numbers with PII.

The limitation is that regex is brittle to slight variations and cannot generalize to new patterns it was not written to match. A credit card regex written for 16-digit Visa and Mastercard numbers will miss 15-digit American Express numbers unless you remember to add that pattern. A phone number regex that handles US formats will miss international formats unless each country's format is explicitly encoded. Maintaining broad coverage requires dedicated engineering attention and regular updates.

Despite these limitations, regex-based filters are often the right choice for PII detection and format enforcement, because the cost of a false negative (leaking a user's credit card number or Social Security number) is high, the patterns are relatively stable, and the precision requirements are strict. ML classifiers trained on noisy internet data tend to have higher false positive rates on structured PII patterns than a well-written regex.

Beyond keywords and regexes, some systems use structured rule engines that combine multiple conditions. A rule might say: "Block if the message mentions substance X AND the user's account is less than 30 days old AND the application is not in the approved-use list." This kind of multi-factor rule captures business logic that is difficult to encode in a classifier: the harm is not a property of the text alone but of the text in combination with context signals.

Rule systems are common in fraud detection and content policy enforcement at scale, where the policy logic is complex but interpretable and needs to be auditable. The downside is maintenance burden: rule systems require ongoing engineering work to update as threats evolve.

The advantage of structured rule systems over purely ML-based approaches is their auditability and controllability. When a regulator or legal team asks why a particular request was blocked, a rule system produces a clear, human-readable audit trail. A neural classifier produces a probability score that cannot easily be traced to specific text features. For organizations subject to regulatory requirements around automated decision-making (such as GDPR's right to explanation), this auditability can be a significant operational advantage.

Some organizations combine rule systems with ML classifiers in a cascade: the rule system handles the clear-cut, high-severity cases where policy is explicit and unambiguous, and the ML classifier handles the ambiguous middle ground. This gives you the best of both worlds: fast, interpretable, high-precision blocks for known patterns, and flexible, context-sensitive judgment for the cases where rules alone are insufficient.

---