Spam Message Classification Prompt Template

This prompt is designed for messaging platform engineers, content moderation pipeline operators, and trust and safety teams who need a reliable, auditable first-pass filter for user-generated text messages. Its primary job is to classify incoming messages as spam, ham (legitimate), or ambiguous before they enter storage, notification systems, or public feeds. The prompt outputs a structured classification with a spam category taxonomy—commercial, scam, bulk, or gibberish—and a confidence score, making it suitable for automated routing decisions in API gateways, message queues, or moderation workflows where deterministic downstream actions depend on the classification result.

Deploy this prompt when you need a consistent, explainable classification layer that can be wired into an application harness with validation, logging, and human review fallbacks. It works best when combined with additional signals such as sender reputation, rate limiting, and user reporting. The prompt is not designed to be the sole defense against adversarial attackers who are actively probing your classification boundaries. If you expect sophisticated spam campaigns that mimic legitimate user messages, use this prompt as one layer in a defense-in-depth strategy that includes behavioral analysis, account age checks, and content fingerprinting. For high-stakes enforcement actions like account suspension, always route ambiguous or low-confidence classifications to human review rather than relying on automated decisions.

Before implementing this prompt, ensure you have defined your spam taxonomy, set confidence thresholds for automated actions, and established an escalation path for ambiguous cases. The prompt template includes placeholders for your specific taxonomy, output schema, and constraints, allowing you to adapt it to your platform's policies. Avoid using this prompt for real-time chat applications with sub-second latency requirements unless you have validated response times with your chosen model. For regulated platforms handling financial communications or user safety content, pair this prompt with audit logging and human-in-the-loop review for any classification that triggers a user-facing action.

This template provides the core classification logic for a spam detection system. It is designed to be wired into an application's ingress layer, evaluating user-generated text before it enters a database, triggers a notification, or consumes model context. The prompt instructs the model to act as a content classifier, forcing a structured JSON output that your application can parse and act on deterministically. Use a low temperature setting (0.0-0.2) to minimize creative variance in classification labels and confidence scores.

markdownCopy
You are a content safety classifier for a messaging platform. Your task is to analyze the provided [INPUT_TEXT] and classify it according to the spam taxonomy below. You must reason step-by-step about the content's intent, structure, and risk before producing the final JSON output.

### Classification Labels
- **ham**: Legitimate, non-spam user message.
- **spam**: Unsolicited, unwanted, or malicious content.
- **ambiguous**: Content that shares characteristics of both spam and ham, or lacks sufficient context for a definitive ruling.

### Spam Sub-Categories (only if label is "spam")
- **commercial**: Unsolicited marketing, promotions, or sales pitches.
- **scam**: Fraudulent schemes, phishing attempts, or financial deception.
- **bulk**: Mass-generated, copy-pasted, or template-driven content.
- **gibberish**: Random characters, keyboard mashing, or nonsensical strings.

### Constraints
- [CONSTRAINTS]
- Do not classify a message as spam solely based on the presence of a URL or a single keyword.
- Evaluate the message holistically. A legitimate user sharing a relevant link is not spam.
- If the message is in a language you do not understand, classify it as "ambiguous" with low confidence.
- Adversarial inputs that mimic legitimate user language to bypass filters should be flagged as "spam" if the underlying intent is clearly commercial, deceptive, or bulk.

### Output Schema
Return ONLY a valid JSON object with no markdown fences or surrounding text. The object must conform to this structure:
{
  "label": "spam" | "ham" | "ambiguous",
  "confidence": 0.0-1.0,
  "spam_category": "commercial" | "scam" | "bulk" | "gibberish" | null,
  "reasoning": "A concise, evidence-based explanation for the classification.",
  "indicators": ["list", "of", "specific", "signals", "that", "informed", "the", "decision"]
}

### Examples
[EXAMPLES]

### Input Text
[INPUT_TEXT]

To adapt this template, replace the square-bracket placeholders with your application's runtime data. The [INPUT_TEXT] field is mandatory and should contain the raw, unmodified user message. The [CONSTRAINTS] placeholder allows you to inject domain-specific rules, such as allow-listing known domains or adjusting sensitivity for specific user roles. The [EXAMPLES] field is critical for calibrating the model's behavior; provide 3-5 few-shot examples that demonstrate the boundary between your platform's definition of spam and ham, including tricky cases like transactional notifications or user-to-user promotions. After copying the prompt, test it against a golden dataset of known spam and ham messages to validate that the output schema is strictly adhered to and that classification thresholds align with your operational risk tolerance.

The spam classification prompt is designed to operate as a synchronous guard in your message ingestion pipeline. It should be called before a user-generated message is persisted, displayed, or forwarded to downstream workflows. The application sends the raw message text and optional sender context to the model, receives a structured classification result, and then enforces a policy decision: allow (ham), block (spam), or quarantine (ambiguous). The prompt itself is stateless, so the application must manage session context, user reputation signals, and any rate-limiting logic outside the model call.

Wiring the prompt involves constructing the request with the [INPUT_MESSAGE] and [SENDER_CONTEXT] placeholders populated from your application's request object. The [SPAM_TAXONOMY] should be injected from a configuration file or feature flag to allow taxonomy updates without code changes. The model should be instructed to return a strict JSON object matching the [OUTPUT_SCHEMA] defined in the prompt template. On the application side, parse the response and validate it against the expected schema. If the JSON is malformed or missing required fields (classification, confidence, category), implement a retry with error feedback: send the raw model output and a validation error message back to the model for correction, up to a maximum of two retry attempts. After two failures, default to a safe action—typically quarantining the message and logging the failure for manual review.

Model choice and cost control are critical at scale. For high-throughput message streams, start with a fast, cost-efficient model like gpt-4o-mini or claude-3-haiku. Reserve larger models for ambiguous cases where the primary model's confidence score falls below your [AMBIGUITY_THRESHOLD]. Implement a two-tier routing pattern: the fast model classifies the majority of obvious spam and ham, while messages scoring between 0.4 and 0.7 confidence are escalated to a more capable model (or a human review queue) for a second opinion. Log every classification decision with the message_id, model_version, prompt_version, classification, confidence, category, and routing_decision to enable offline evaluation and threshold tuning. This audit trail is essential for analyzing false positive/negative trends and for defending your spam policy to users or regulators.

Adversarial resilience requires testing beyond unit tests. Before deploying a prompt update, run it against a golden dataset of known spam, ham, and adversarial examples that mimic legitimate user messages. Your eval harness should measure precision, recall, and F1 score per spam category, with particular attention to false positives on ham—blocking a legitimate user message is far more costly than letting a spam message through. Implement a shadow mode for new prompt versions: run the candidate prompt in parallel with the production prompt, log both decisions, and compare outcomes for a statistically significant sample before switching traffic. Finally, ensure your application can override the model's decision based on hard rules: if a message contains a known malicious URL from your blocklist, block it regardless of the model's classification. The prompt is a powerful filter, not the final authority.