Override Decision Anomaly Detection Prompt

This prompt is designed for audit and governance teams who need to programmatically surface override events that deviate from established organizational patterns. The core job-to-be-done is retrospective batch analysis: you have a corpus of structured override records extracted from logs, databases, or audit trails, and you need to prioritize which events warrant human investigation. The prompt analyzes overrides against a defined baseline—looking at frequency spikes, unusual timing, atypical reviewer behavior, and justification content that diverges from norms—and returns a ranked list of anomalies with context and recommended investigation priority.

The ideal user is a compliance analyst, audit engineer, or governance lead who already has access to normalized override data. The prompt assumes you have completed the extraction and normalization step: each override record must include fields such as override_id, timestamp, reviewer_id, decision_type, justification_text, and any relevant risk_score or policy_reference. You must also define a baseline—either from historical data or policy thresholds—that establishes what 'normal' looks like. Without a well-formed baseline, the prompt will generate false positives or miss subtle anomalies. The prompt is not a real-time blocking mechanism; it is designed for periodic batch review cycles where a human auditor reviews the flagged output and decides which cases to escalate.

Do not use this prompt for real-time override interception, for making automated decisions about whether an override should be blocked, or for generating regulatory filings without human review. The prompt produces investigative leads, not definitive findings. Always route flagged anomalies to a human reviewer, and ensure your harness logs the prompt output alongside the original override records for auditability. If your override volume is low (fewer than 50 events per batch), statistical anomaly detection may be unreliable—consider using the Override Justification Quality Scoring Prompt instead for individual case review.

This prompt template is designed to be copied directly into your AI harness. It instructs the model to act as an audit anomaly detector, comparing a batch of override events against a provided baseline of normal behavior. The model will flag anomalies in frequency, timing, reviewer identity, or justification content, and assign an investigation priority. All placeholders are in square brackets and must be replaced with your specific data before sending the prompt to the model.

textCopy
You are an audit anomaly detection system. Your task is to analyze a batch of human override events and identify those that deviate from a defined baseline of normal patterns.

## BASELINE DEFINITION
[BASELINE_DEFINITION]

## OVERRIDE EVENTS TO ANALYZE
[OVERRIDE_EVENTS]

## OUTPUT SCHEMA
Return a valid JSON object with the following structure:
{
  "analysis_summary": {
    "total_events_analyzed": <integer>,
    "anomalies_found": <integer>,
    "baseline_period": "<string describing the baseline period>"
  },
  "anomalies": [
    {
      "event_id": "<string>",
      "anomaly_type": "frequency" | "timing" | "reviewer" | "justification_content" | "other",
      "severity": "low" | "medium" | "high" | "critical",
      "description": "<string explaining the deviation>",
      "baseline_comparison": "<string showing expected vs. observed>",
      "recommended_investigation_priority": 1-5,
      "context": "<string with relevant surrounding details>"
    }
  ],
  "false_positive_notes": "<string noting any anomalies that may be benign>"
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES OF NORMAL AND ANOMALOUS PATTERNS
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, start by defining your baseline in the [BASELINE_DEFINITION] placeholder. This should include expected override frequency per time period, typical reviewer roles, normal justification length and content patterns, and standard operating hours. The [OVERRIDE_EVENTS] placeholder should be populated with a structured list of events, each containing an ID, timestamp, reviewer, justification text, and any relevant metadata. Use the [CONSTRAINTS] section to specify tuning parameters like minimum deviation thresholds, ignore lists for known reviewers, or sensitivity levels. The [EXAMPLES] section is critical for few-shot learning—provide at least two examples of normal patterns and two examples of anomalies with their correct severity and priority labels. Set [RISK_LEVEL] to guide the model's caution; for high-stakes audits, instruct the model to flag borderline cases rather than dismiss them. After generating output, always validate the JSON structure and route any critical severity anomalies for immediate human review.

This prompt is designed to operate as a batch analysis step within an override audit pipeline, not as a real-time, user-facing chatbot. The harness should feed the prompt a structured batch of override records—each containing fields like override_id, timestamp, reviewer_id, decision_type, justification_text, and risk_score—alongside a defined baseline window for normal behavior. The model's job is to identify statistical and semantic outliers, not to make final decisions about policy violations. Therefore, the application layer must enforce strict input validation before the prompt runs: confirm that the batch size is within the model's context window, that timestamps are ISO 8601, and that required fields are non-null. A pre-processing step should also compute simple aggregate statistics (e.g., mean override frequency per reviewer, standard deviation of justification length) to include as [BASELINE_METRICS] in the prompt, giving the model a numerical anchor rather than asking it to derive baselines from raw data alone.

After the model returns its JSON output, a post-processing validator must parse the anomalies array and enforce the output schema. Each anomaly object must have a non-empty anomaly_id, a severity enum value of LOW, MEDIUM, or HIGH, and a recommended_action that maps to a downstream workflow (e.g., HUMAN_REVIEW, AUTO_ESCALATE, LOG_ONLY). If the JSON is malformed or missing required fields, the harness should retry once with a repair prompt that includes the raw output and the schema error. If the retry also fails, log the failure and route the entire batch to a human audit queue with a PARSING_ERROR flag. For HIGH severity anomalies, the harness should automatically create a ticket in the audit tracking system and attach the anomaly context, but it must not autonomously block reviewers or revoke permissions—human confirmation is required for any action that affects user access or policy enforcement.

Model choice matters here. Use a model with strong reasoning and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, and set temperature to 0 or a very low value (e.g., 0.1) to maximize consistency across batches. If your override volume is high, consider a two-stage architecture: a smaller, faster model performs initial frequency and timing anomaly detection using simple statistical rules, and this prompt is invoked only on the subset of batches that pass a preliminary flagging threshold. Log every invocation with the prompt version, batch ID, anomaly count, and any validation errors. This log becomes part of the audit trail itself, proving that anomaly detection was applied consistently. Finally, schedule a monthly human review of a random sample of LOW severity outputs to tune the false positive rate—anomaly detection prompts drift as override patterns change, and without periodic calibration, the system will either flood reviewers with noise or miss emerging risks.