Log Level Standardization Prompt

This prompt is designed for observability platform engineers and SREs who need to ingest machine-generated logs from AI systems into a centralized logging pipeline. The core job-to-be-done is normalizing inconsistent, model-generated severity strings into a strict, enumerated set of standard log levels (DEBUG, INFO, WARN, ERROR, FATAL) that downstream tools like Splunk, Datadog, or Elasticsearch can index and alert on without manual cleanup. The ideal user is an integration developer building a connector between an LLM's output and a logging API, where the model might produce 'warning', 'WARNING', 'warn', 'critical', or even a numeric syslog code like 3 instead of the required canonical string.

You should use this prompt when you have a high-volume stream of model outputs where the semantic intent of the severity is correct but the string representation is unreliable. It is particularly valuable when your logging backend enforces a controlled vocabulary and rejects or miscategorizes non-conforming values. The prompt handles three classes of input: variant strings ('warn', 'critical', 'information'), numeric syslog severity codes (0-7 per RFC 5424), and mixed-case or whitespace-damaged tokens. It maps each to a canonical level and provides a structured output that includes the original value, the normalized level, and a confidence score, enabling automated routing for high-confidence mappings and a review queue for ambiguous cases.

Do not use this prompt as a general text classifier or for deriving severity from unstructured log messages. It is not designed to read a full log line like 'user authentication failed after 3 attempts' and infer that it should be WARN. That is a semantic classification task requiring a different prompt architecture. This prompt assumes the severity signal already exists in the input; its sole function is type coercion and value normalization. If you need to infer severity from message content, pair this normalization prompt with a separate classification step. For high-risk environments where a miscategorized FATAL log could delay incident response, always route low-confidence normalizations to a human review queue and log the original model output alongside the normalized value for auditability.

This prompt template is designed to be dropped into an observability pipeline where a model or an upstream system has generated log entries with non-standard or inconsistent severity labels. It takes a raw severity string and a set of constraints, then maps the input to one of the canonical syslog severity levels: DEBUG, INFO, WARN, ERROR, or FATAL. The template is structured to handle both string variants (e.g., 'warning', 'critical') and numeric codes (e.g., 4, 0) while enforcing strict output validation.

textCopy
You are a log normalization engine. Your task is to map an input log severity string or numeric code to a standard syslog severity level.

[CONSTRAINTS]
- Map the input to exactly one of: DEBUG, INFO, WARN, ERROR, FATAL.
- If the input is a numeric code, use the standard syslog RFC 5424 mapping: 0=FATAL, 1=ERROR, 2=WARN, 3=INFO, 4=DEBUG.
- Resolve common synonyms: 'warning' -> WARN, 'critical' -> FATAL, 'information' -> INFO, 'trace' -> DEBUG, 'panic' -> FATAL.
- If the input is ambiguous or unrecognized, default to [DEFAULT_LEVEL] and set the confidence to 'low'.
- Do not invent new severity levels.

[INPUT]
Severity String: "[RAW_SEVERITY_STRING]"

[OUTPUT_SCHEMA]
Return a single valid JSON object with no additional text:
{
  "standard_level": "<DEBUG|INFO|WARN|ERROR|FATAL>",
  "original_input": "[RAW_SEVERITY_STRING]",
  "confidence": "<high|medium|low>",
  "mapping_rule": "<exact_match|numeric_code|synonym_resolution|default_fallback>"
}

To adapt this template, replace [RAW_SEVERITY_STRING] with the actual log level text from your pipeline. Set [DEFAULT_LEVEL] to the fallback severity that makes sense for your system's alerting posture—typically WARN or ERROR. If your environment uses custom severity levels beyond the syslog standard, extend the synonym list in the constraints section. Before deploying, run this prompt against a golden dataset of known severity variants and verify that the confidence field correctly flags ambiguous cases for human review or quarantine.

This prompt is designed to sit inside a post-processing repair loop within a log ingestion pipeline. After an AI model generates a log entry or a human writes a free-text severity description, the raw string is passed to this prompt for normalization. The harness should call the prompt only when the initial severity field fails validation against a known enum (DEBUG, INFO, WARN, ERROR, FATAL) or when the numeric value falls outside the syslog RFC 5424 range (0-7). Do not route every log through this prompt; use it as a targeted repair step to control cost and latency.

Wrap the prompt call in a function with a strict contract: accept a raw severity string and an optional source context (e.g., the application name or log parser that produced it), and return a structured object with standard_level, numeric_code, confidence, and repair_method. Implement a retry policy with a maximum of two attempts. If the first call returns confidence below 0.85 or an unrecognized repair method, re-prompt with the original input and an explicit instruction to flag the result for review. After the second failure, default to WARN (numeric 4) and log the incident with the raw input, timestamp, and model response for offline analysis. Use a lightweight model (e.g., GPT-4o-mini, Claude Haiku) for this task; it requires classification and mapping, not deep reasoning.

Validation must happen in the application layer, not just in the prompt. After receiving the model's output, confirm that standard_level is one of the five canonical strings, numeric_code is an integer between 0 and 7, and the mapping between them is correct per RFC 5424 (e.g., ERROR is 3, not 4). Reject and retry any response that fails this structural check. Log every normalization event—including the raw input, normalized output, model used, latency, and retry count—to an audit table. This audit trail is critical for tuning the prompt over time and for demonstrating to compliance teams that automated severity assignment is traceable and overridable. Never silently drop the raw input; always preserve it alongside the normalized value.