Anomaly Severity Classification Prompt Template

This prompt is designed for security operations, fraud operations, and incident response teams that need to apply a consistent, repeatable severity label to anomalies that have already been detected and enriched with context. The core job-to-be-done is standardizing the triage process so that a 'Critical' alert from one analyst or detection system carries the same weight and urgency as a 'Critical' alert from another. You should use this prompt when your team has pre-defined severity criteria and business impact definitions, but you are experiencing inconsistent labeling that leads to misrouted escalations, alert fatigue, or missed service level agreements (SLAs). The ideal user is a detection engineer, SOC analyst, or automation engineer who is building a triage pipeline and needs a classification step that is auditable, explainable, and calibration-ready.

This prompt is not a replacement for a risk scoring engine or an anomaly detection system. It does not compute raw risk scores, detect new anomalies, or ingest raw telemetry. It assumes that an upstream process has already identified an anomaly and enriched it with the necessary context, such as the affected asset, its criticality, the type of anomaly, and any relevant timestamps. The prompt's value is in its ability to apply your organization's specific business logic to that enriched context, producing a structured severity classification with an impact assessment, urgency justification, and a confidence indicator. For example, an input might be a JSON object describing a failed login spike on a production database server, and the output would classify it as 'High' severity with a justification citing the asset's criticality and the potential for a brute-force attack.

Avoid using this prompt for real-time blocking decisions where latency is measured in milliseconds; a model inference step adds unacceptable delay for inline transaction blocking. Similarly, do not use it when your severity definitions are vague or constantly changing—the prompt requires stable, documented criteria to produce reliable outputs. If you lack clear definitions, invest time in creating a severity matrix first. After classification, the structured output should be used to route the anomaly to the correct queue, trigger the appropriate SLA timer, and provide the human reviewer with an immediate understanding of why the alert matters. The next step is to wire this prompt into your SOAR or case management system and begin tracking inter-rater reliability to calibrate its performance against human analysts.

This prompt template provides a complete set of instructions for an LLM to act as a severity classification engine. It is designed for triage workflows that need consistent, explainable severity labels across different anomaly types. The template forces the model to apply defined criteria, assess business impact, and justify its urgency rating, making the output suitable for downstream automation or human review queues. Before using this prompt, ensure you have defined your severity levels, business impact categories, and the specific anomaly data schema your detection systems produce.

textCopy
You are an anomaly severity classifier for a security and fraud operations triage system. Your task is to analyze an anomaly record and assign a consistent severity classification based on defined criteria.

## INPUT
You will receive an anomaly record in the following JSON format:
[ANOMALY_RECORD]

## CLASSIFICATION CRITERIA
Apply the following severity definitions strictly:
- **CRITICAL**: Active compromise confirmed, financial loss in progress, or core service outage. Requires immediate human intervention.
- **HIGH**: Strong indicators of malicious activity, policy violation, or significant business impact expected within [HIGH_IMPACT_TIMEFRAME]. Requires human review within [HIGH_SLA_TIMEFRAME].
- **MEDIUM**: Anomalous behavior deviating from baseline but no immediate threat confirmed. Potential policy violation or operational inefficiency. Requires review within [MEDIUM_SLA_TIMEFRAME].
- **LOW**: Minor deviation, likely benign, or known false-positive pattern. Log for audit; no immediate action required.
- **INFO**: Informational event, no anomaly detected, or expected system behavior. No action required.

## BUSINESS IMPACT ASSESSMENT
Evaluate the potential business impact across these dimensions:
- **Financial**: Direct monetary loss, fraud exposure, or revenue impact.
- **Operational**: Service degradation, resource availability, or process interruption.
- **Reputational**: Customer trust, public perception, or partner confidence.
- **Compliance**: Regulatory violation, audit failure, or legal exposure.

## OUTPUT SCHEMA
Return a single JSON object with the following structure. Do not include any text outside the JSON object.
{
  "severity": "CRITICAL | HIGH | MEDIUM | LOW | INFO",
  "confidence_score": 0.0-1.0,
  "primary_impact_category": "Financial | Operational | Reputational | Compliance",
  "impact_summary": "A concise, evidence-based summary of the potential business impact.",
  "urgency_justification": "Specific reasons why this severity level was chosen, referencing the criteria above.",
  "recommended_action": "The immediate next step for a human reviewer or automated system.",
  "escalation_required": true/false,
  "inter_rater_calibration_notes": "Any edge cases or ambiguity that could cause another analyst to classify this differently."
}

## CONSTRAINTS
- Do not invent evidence not present in the anomaly record.
- If the anomaly record is incomplete or ambiguous, note this in `inter_rater_calibration_notes` and assign a confidence score below 0.7.
- If the anomaly matches a known false-positive pattern from [KNOWN_FALSE_POSITIVE_PATTERNS], classify as LOW and explain the match.
- Prioritize precision over recall; it is better to escalate a borderline case than to miss a critical event.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template for your environment, replace the square-bracket placeholders with your operational data. [ANOMALY_RECORD] should be populated with the JSON output from your detection system. [HIGH_IMPACT_TIMEFRAME] and the SLA placeholders must reflect your team's actual response commitments. [KNOWN_FALSE_POSITIVE_PATTERNS] is critical for reducing alert fatigue; provide a list of signatures or conditions that your team has previously determined to be benign. [FEW_SHOT_EXAMPLES] should include 3-5 representative anomaly records with their correct severity classifications, chosen to illustrate boundary cases between severity levels. Set [RISK_LEVEL] to 'high' if this prompt is used in a regulated industry, which will activate additional caution in the model's reasoning. Always use a structured output API or strict JSON mode when calling the model to prevent parsing failures in your triage pipeline.

The anomaly severity classification prompt is designed to sit inside a triage pipeline, not as a standalone chat interaction. In production, this prompt receives structured anomaly records from upstream detection systems—such as a log anomaly detector, a transaction monitoring engine, or a user behavior analytics platform—and returns a severity label with impact assessment and urgency justification. The application layer is responsible for assembling the prompt inputs, calling the model, validating the output against the expected schema, and routing the result to either an automated response workflow or a human review queue based on the classified severity.

Start by defining a strict output schema that the application can validate before the classification enters any decision path. The expected output should include at minimum: severity (an enum constrained to your defined levels, e.g., CRITICAL, HIGH, MEDIUM, LOW, INFORMATIONAL), impact_assessment (a short structured object with affected_assets, potential_blast_radius, and data_sensitivity), urgency_justification (a free-text field with explicit reasoning tied to business impact definitions), and confidence (a numeric score between 0.0 and 1.0). After the model responds, run a schema validator. If the output fails validation, retry once with the validation error message appended to the prompt as additional context. If the retry also fails, escalate the raw anomaly record and both failed responses to a human triage queue rather than guessing.

Logging is critical for calibration and inter-rater reliability. Capture the full prompt, the model response, the validation result, the final severity label, and any human override at decision time. Store these in a structured format that allows you to compare model classifications against human reviewer decisions over time. This log becomes your dataset for recalibrating severity definitions, tuning the prompt's few-shot examples, and measuring drift. For high-severity classifications (CRITICAL or HIGH), always route to a human review queue with the full classification payload, the source anomaly record, and a pre-built approval interface. For MEDIUM classifications, consider a staged approach: allow automated response within defined guardrails but require post-action review within a time window. LOW and INFORMATIONAL classifications can proceed automatically but should still be logged for periodic audit sampling.

Model choice matters for consistency. Use a model with strong instruction-following and structured output capabilities. If your latency budget allows, consider running the classification twice—once with a primary model and once with a smaller, faster model—and flagging disagreements for human review. This dual-model pattern catches edge cases where severity boundaries are ambiguous. For regulated environments, ensure that every CRITICAL classification includes a human approval step before any downstream action is taken, and that the approval decision is logged with the reviewer's identity, timestamp, and any override justification. Never allow automated execution on CRITICAL anomalies without a human-in-the-loop gate.