Multi-Language Abuse and Spam Detection Prompt

This prompt is designed for global platform trust engineers who need to detect abuse, spam, and policy violations in user-generated content that spans multiple languages, scripts, and code-switching patterns. The primary job-to-be-done is to act as a language-agnostic ingress filter: it takes a raw text input and returns a structured classification of whether the content violates a defined policy, along with a confidence score that is calibrated per language. The ideal user is an AI/ML engineer or trust and safety engineer integrating this prompt into a content moderation pipeline, an API gateway, or a model input sanitization layer. Required context includes the raw text to be classified, a defined policy violation taxonomy, and optionally, the user's declared or detected locale to aid calibration.

Do not use this prompt when you need to extract nuanced cultural context, adjudicate borderline satire, or make final enforcement decisions without human review. This prompt is a triage and detection tool, not a replacement for a full trust and safety investigation. It is also not suitable for detecting novel, zero-day abuse vectors that have no representation in the policy taxonomy or few-shot examples. For high-severity violation categories like child safety or self-harm, the output of this prompt must always be routed to a human review queue as a mandatory escalation step, not an automated action. The prompt's strength lies in its ability to handle code-switching (e.g., 'You are a scammer, bhai, send the money back now') and mixed-script inputs (e.g., 'fr33 m0n3y' or 'ср3дств0') by normalizing the text and focusing on semantic intent rather than relying on keyword blocklists.

Before deploying this prompt, you must build an evaluation harness that specifically covers low-resource languages and transliterated abuse. A common failure mode is high-confidence misclassification on languages underrepresented in the model's pre-training data. Your eval set should include examples of Hindi-English code-switching, Arabic transliterated into Latin script (Arabizi), and abuse terms that have been deliberately misspelled or separated by zero-width characters. After integrating the prompt, wire the output into a decision log that records the input, detected language, violation classification, confidence score, and the policy rule triggered. This audit trail is critical for tuning confidence thresholds and defending moderation decisions. The next step is to combine this prompt with a routing harness that sends high_confidence violations to an automated quarantine and low_confidence or high_severity flags to a human review queue.

This prompt template is designed to be the core instruction set for a language-agnostic abuse and spam detection classifier. It accepts raw user text, which may include code-switching, mixed scripts, or transliterated terms, and returns a structured violation analysis. The template is built to be wired directly into an API gateway, a message queue consumer, or a pre-model safety screen. Before copying it, you must define your specific policy taxonomy, risk thresholds, and output schema.

textCopy
You are a multilingual content safety classifier. Your task is to analyze the [INPUT_TEXT] for abuse, spam, and policy violations. The input may contain multiple languages, code-switching, mixed scripts (e.g., Latin and Cyrillic), and transliterated terms.

You must classify the input against the following policy taxonomy:
[POLICY_TAXONOMY]

For each violation category, provide a confidence score from 0.0 (no violation) to 1.0 (certain violation). Consider the following contextual factors:
- [CONTEXT_FACTORS]

Adhere to these constraints:
[CONSTRAINTS]

Before producing the final output, reason step-by-step about the linguistic features, any obfuscation attempts, and the specific policy rules that apply. Then, output your analysis strictly according to the following JSON schema without any additional text or markdown fences:
[OUTPUT_SCHEMA]

Here are some examples of correct input-output pairs to calibrate your judgment:
[EXAMPLES]

To adapt this template for production, start by replacing the placeholders. [POLICY_TAXONOMY] should be a structured list of your violation categories with clear definitions, such as 'Hate Speech (HS): Content that attacks or demeans a group based on protected attributes.' [CONTEXT_FACTORS] might include instructions like 'Consider the user's message history for patterns of harassment' or 'A URL alone is not spam unless combined with deceptive text.' [CONSTRAINTS] is critical for safety and consistency; use it to enforce rules like 'Do not classify discussions about moderation policies as abuse' or 'If confidence is below 0.7 for all categories, set the overall verdict to UNCLEAR.' [OUTPUT_SCHEMA] must be a strict JSON schema defining the structure you will parse downstream, including fields for overall_verdict, violations (an array of objects with category, confidence, and evidence_span), and language_notes. [EXAMPLES] should be a set of few-shot demonstrations covering edge cases, such as reclaimed slurs in one language that are benign in another, or a code-switched sentence where the violation is only in one language. After adaptation, validate the prompt's behavior against a golden dataset that includes low-resource languages and adversarial transliterations to ensure the model generalizes beyond the examples provided.

This prompt is designed to sit at the ingress layer of your application, before user-generated content reaches any model, tool, or database. It should be invoked synchronously in the request path for real-time moderation or asynchronously in a pre-processing queue for batch content review. The harness must handle the prompt's structured JSON output, validate it against the expected schema, and route the result to the appropriate action: block, quarantine, flag for review, or allow. Because this prompt operates across multiple languages, the harness must be language-agnostic and not rely on upstream language detection before invocation.

Wire the prompt into a dedicated moderation service with a strict contract. The service should accept the raw user input and an optional [CONTEXT] object containing user history, channel type, and locale hints. After receiving the model's JSON response, validate it against a schema that requires violation_category, confidence_score, detected_language, and evidence_spans. If validation fails, retry once with a repair prompt that includes the original input and the validation error. Log every invocation—including the raw input, model response, validation result, and routing decision—to an append-only audit store. For high-severity categories like child safety or self-harm, the harness must bypass any automated action and immediately escalate to a human review queue, regardless of confidence score. Use a model with strong multilingual performance, such as claude-3.5-sonnet or gpt-4o, and set temperature=0 to maximize output consistency for classification tasks.

The most common production failure mode is confidence miscalibration on low-resource languages and code-switched inputs. To mitigate this, implement a confidence threshold that triggers human review for any classification below 0.85 on high-severity categories. For languages underrepresented in your eval set, consider routing to a native-speaker review queue even when the model is confident. Avoid using this prompt as the sole defense for regulated content categories; it should be one layer in a defense-in-depth strategy that includes keyword filters, hash matching, and human moderation. The next step after implementing the harness is to build a regression test suite using your golden dataset of multilingual abuse examples, and to set up a periodic eval run that compares model performance across language families to detect drift.