Log Level and Severity Enum Control Prompt Template

This playbook is for SRE, observability, and platform engineering teams who need AI-generated log entries to feed directly into logging pipelines, SIEM systems, or structured log aggregators. The prompt produces JSON log records where the severity field is locked to a controlled enum (DEBUG, INFO, WARN, ERROR, FATAL) and the assigned level is consistent with the content urgency described in the input. Use this when downstream systems reject or misroute log entries with non-standard severity strings, or when human operators write free-text severity that drifts from organizational logging standards.

This prompt belongs in incident summarization pipelines, automated runbook logging, alert-to-log translation, and any workflow where structured observability data must survive automated validation before ingestion. It is not a general-purpose text generator. Do not use it when you need free-form narrative, when severity is unknown or intentionally omitted, or when the input content is too ambiguous to support a reliable severity mapping. The prompt assumes you have enough context—an alert payload, an incident note, a runbook step outcome—to justify a severity decision. If the input is a vague chat message, the model will guess, and guessing breaks downstream routing.

Before wiring this into a production pipeline, confirm that your log aggregator or SIEM expects the exact enum set defined in the prompt. If your organization uses custom levels like CRITICAL instead of FATAL, or TRACE instead of DEBUG, adapt the enum in the template before deployment. Also confirm that your validation layer rejects outputs where the severity field does not match the enum—never rely on the prompt alone. The next section provides the copy-ready template with placeholders for your input, context, and output schema.

This template instructs the model to produce a structured log record where the severity field is locked to a standard SRE enum: DEBUG, INFO, WARN, ERROR, or FATAL. It forces the model to map the urgency and impact described in the input text to the correct severity level, preventing vague or invented severity values that break downstream log aggregation and alerting pipelines. Use this template when you need every log entry to be immediately ingestible by tools like Splunk, Datadog, or the ELK stack without a normalization layer.

textCopy
You are a structured log generation system. Your output must be a single JSON object representing a log entry.

[CONTEXT]

[EXAMPLES]

[CONSTRAINTS]
- The 'severity' field MUST be exactly one of the following strings: 'DEBUG', 'INFO', 'WARN', 'ERROR', 'FATAL'. No other values, abbreviations, or synonyms are permitted.
- Map the input's urgency and impact to the correct severity level using these rules:
  - DEBUG: Verbose diagnostic information useful only for developers during active debugging.
  - INFO: Routine operational events that confirm the system is working as expected.
  - WARN: Unexpected events or potential problems that do not yet cause a service failure but require attention.
  - ERROR: A failure in a specific operation or component that requires immediate investigation but does not stop the entire system.
  - FATAL: A catastrophic failure that causes the entire application or a critical subsystem to shut down or become unavailable.
- If the input does not contain enough information to confidently determine a severity level, default to 'INFO' and set the 'message' field to explicitly note the ambiguity.
- The 'timestamp' field must be in ISO 8601 format with a UTC offset (e.g., '2023-10-26T14:30:00Z').
- The 'message' field must be a concise, factual summary of the event, not a question or a command.
- The 'source' field must be a string identifying the originating component or service.

[OUTPUT_SCHEMA]
{
  "timestamp": "<ISO 8601 string>",
  "severity": "<DEBUG|INFO|WARN|ERROR|FATAL>",
  "message": "<string>",
  "source": "<string>",
  "traceId": "<string or null>"
}

[INPUT]

To adapt this template, replace the [INPUT] placeholder with the raw event description, log line, or error text. Populate [CONTEXT] with any system-wide rules, such as a service name to use in the source field or a specific trace ID format. Use [EXAMPLES] to provide few-shot demonstrations of ambiguous inputs mapped to the correct severity, which is the most effective way to calibrate the model's judgment. Before deploying, run the prompt through a validation harness that checks the output against the JSON Schema and confirms the severity field is a member of the allowed enum. For high-risk observability pipelines where a wrong severity level could suppress a critical alert, add a human review step for all ERROR and FATAL outputs before they are written to the production log stream.

This prompt is designed to be called from an SRE or observability pipeline that already has the raw log content or incident context. The application layer should inject the [LOG_CONTENT] and [CONTEXT] placeholders before sending the request. The model is expected to return a JSON object with a severity field restricted to the standard enum: DEBUG, INFO, WARN, ERROR, FATAL. The application should never trust the raw model output directly. Instead, it must validate the severity field against the allowed enum set and reject or repair any output that does not conform. This is a classification and normalization task, not a generative one, so the harness should treat it as a structured extraction with a tight contract.

Wire the prompt into your application with a post-processing validator that checks three things: (1) the severity field is present and exactly matches one of the five allowed values, (2) the confidence field is a float between 0.0 and 1.0, and (3) the rationale string is non-empty and does not exceed a reasonable character limit (e.g., 500 characters). If validation fails, implement a retry loop with a maximum of two additional attempts. On each retry, append the validation error message to the prompt as additional [CONSTRAINTS] context so the model can self-correct. If all retries are exhausted, apply a safe fallback: default the severity to WARN and log the failure for human review. This prevents a single malformed output from blocking your log ingestion pipeline.

For observability, instrument every call with the model ID, prompt version, latency, token usage, and validation outcome. Emit a structured log event from the harness itself—ironically, using the same severity enum you are asking the model to produce. Tag validation failures as ERROR and successful retries as WARN. This creates a feedback loop where your own system's health is visible in the same schema you are enforcing. Avoid wiring this prompt directly into a synchronous user-facing flow; it belongs in an asynchronous processing step where a 2-second retry delay is acceptable. If you need sub-100ms responses, consider a smaller model or a cached classification layer instead of a general-purpose LLM.