Compliance Rule Violation Root-Cause Prompt

This prompt is designed for compliance reviewers and AI reliability engineers who need to produce an audit-ready root-cause report after an automated compliance evaluation flags a production response. The job-to-be-done is forensic: you have a structured trace log that records every step of a request's lifecycle (retrieval, tool calls, context assembly, generation), the text of the specific regulatory or policy rule that was violated, and the final model output that triggered the eval failure. Your goal is not to fix the prompt or block the response in real time, but to trace the violation back to its origin—whether that is a retrieval step that pulled in a prohibited document, a tool call that returned non-compliant data, a context assembly step that dropped a required disclaimer, or the generation step itself that produced a violative claim. The prompt performs a rule-by-rule trace analysis, mapping each segment of the trace against the rule's requirements and identifying the first point of failure with preserved evidence for audit review.

To use this prompt effectively, you must have three inputs ready: [TRACE_LOG] containing step-level events with timestamps, inputs, outputs, and metadata; [VIOLATED_RULE] with the exact rule text, its regulatory or policy source, and any interpretive guidance; and [FLAGGED_OUTPUT] which is the final model response that failed the compliance eval. The prompt assumes the trace log is structured and complete—it will not fill gaps or infer missing steps. It also assumes you are operating in a post-hoc investigation context, not a real-time blocking pipeline. Do not use this prompt for initial policy design, for deciding whether to block a request in production, or when you lack a structured trace log. For high-risk regulated domains (finance, healthcare, legal), the output of this prompt should be treated as an investigative aid, not a final determination. Always require human review of the root-cause report before it becomes part of an audit record or regulatory submission.

The prompt's output is a structured root-cause report that identifies the violation point (the specific trace step where the rule was first breached), the evidence chain (the inputs and outputs at that step that demonstrate the violation), a severity classification (critical, major, minor), and a recommended remediation (e.g., add a retrieval filter, adjust a tool contract, insert a generation guardrail). The report is designed to be audit-ready: it preserves the exact trace evidence, rule text, and output that triggered the investigation, so a human reviewer can independently verify the finding. After receiving the report, your next step should be to validate the identified violation point against the raw trace data, then determine whether the remediation requires a prompt change, a pipeline change, or a policy update. Avoid using this prompt when the trace log is incomplete or when the rule text is ambiguous without interpretive guidance—in those cases, escalate to a human compliance expert before running the analysis.

This template is designed to be the single executable prompt you use to investigate a compliance rule violation. It forces a structured, rule-by-rule analysis of the entire production trace, ensuring that no step in the pipeline is overlooked. The output is designed to be preservation-ready for audit review, linking every finding to a specific trace event and source document. Before using this prompt, ensure you have exported the full trace from your observability platform, including system prompts, retrieved context, tool calls, and the final output. This prompt is not a substitute for a human compliance reviewer; it is a diagnostic tool to accelerate their investigation and standardize evidence collection.

textCopy
You are a senior compliance review analyst. Your task is to perform a root-cause analysis of a single production trace that violated one or more compliance rules.

## INPUT DATA
- **Trace ID:** [TRACE_ID]
- **Violated Rules:** [LIST_OF_VIOLATED_RULE_IDS_AND_DESCRIPTIONS]
- **Full Trace Log:** [FULL_TRACE_JSON]
- **Applicable Policy Documents:** [POLICY_DOCUMENT_TEXT_OR_REFERENCE]

## ANALYSIS INSTRUCTIONS
For each violated rule in [LIST_OF_VIOLATED_RULE_IDS_AND_DESCRIPTIONS], perform the following steps. Document your findings in the `rule_analyses` array of the output JSON.

1.  **Rule Definition:** Restate the specific compliance rule that was violated, quoting the relevant text from [POLICY_DOCUMENT_TEXT_OR_REFERENCE].
2.  **Violation Manifestation:** Quote the exact segment of the final model output or action that constitutes the violation.
3.  **Trace Event Attribution:** Identify the single most likely trace event (e.g., a specific tool call, a retrieved document chunk, a turn in the conversation) that introduced the violation. Provide the event's timestamp and a brief description.
4.  **Causal Chain:** Construct a step-by-step causal chain from the attributed trace event to the violation manifestation. Explain *how* the event led to the violation.
5.  **Evidence Preservation:** List all trace event IDs, document chunk IDs, and timestamps that serve as evidence for this causal chain. This is critical for audit review.
6.  **Severity Assessment:** Classify the violation's severity as `CRITICAL`, `HIGH`, `MEDIUM`, or `LOW` based on the policy's definitions and the potential impact.

## CONSTRAINTS
- **Evidence Grounding:** Every claim in your analysis MUST be directly supported by a specific event in [FULL_TRACE_JSON]. Do not speculate about model intent or external factors not present in the trace.
- **No New Violations:** Your analysis must not introduce or discuss potential violations beyond those provided in [LIST_OF_VIOLATED_RULE_IDS_AND_DESCRIPTIONS].
- **Audit-Ready Language:** Use precise, objective language. Avoid marketing jargon, anthropomorphism, and vague terms like "the model hallucinated" without linking it to a specific trace event.
- **Structured Output Only:** Your entire response must be a single, valid JSON object conforming to the schema below. Do not include any text outside the JSON.

## OUTPUT_SCHEMA
{
  "trace_id": "string",
  "analysis_timestamp": "string (ISO 8601)",
  "rule_analyses": [
    {
      "rule_id": "string",
      "rule_definition": "string",
      "violation_manifestation": "string (exact quote from output)",
      "attributed_trace_event": {
        "event_id": "string",
        "timestamp": "string",
        "description": "string"
      },
      "causal_chain": "string (step-by-step explanation)",
      "evidence_event_ids": ["string"],
      "severity_assessment": "CRITICAL | HIGH | MEDIUM | LOW"
    }
  ],
  "overall_summary": "string (a brief, factual summary of the root cause(s) across all violations)"
}

To adapt this template, start by integrating it with your observability platform's API. The [FULL_TRACE_JSON] placeholder should be populated programmatically with a structured trace object, not a raw log dump. Ensure your trace export includes all necessary spans: system prompt rendering, retrieval calls with scores, LLM calls with token usage, and any tool or API requests. The [POLICY_DOCUMENT_TEXT_OR_REFERENCE] should contain the exact text of the rules that were violated, not just a link. This grounds the model's analysis in the specific policy language. For high-risk compliance environments, the output of this prompt should always be routed to a human review queue. The JSON output is designed to be parsed and displayed in a review tool, allowing a human to quickly validate the causal chain and evidence before accepting the analysis. Never automatically close a compliance incident based solely on this prompt's output.

This prompt is designed to be invoked programmatically as part of an automated compliance review pipeline, not as a one-off chat interaction. The typical integration point is a post-eval hook: when a compliance eval flags a response as a violation, the system retrieves the full trace for that request and calls this prompt with the trace, the violated rule, and the eval output. The prompt's structured output—a rule-by-rule trace analysis—is then written to an audit log and surfaced in a compliance review queue. Do not use this prompt for real-time blocking decisions; it is a diagnostic and evidence-preservation tool, not a gate.

Input assembly requires three data sources wired together before the prompt is called: (1) the full production trace including system prompt, retrieved context, tool calls, intermediate reasoning steps, and final output; (2) the specific compliance rule definition that was violated, including its policy text and eval criteria; and (3) the eval result that triggered the investigation, including the score, the violating excerpt, and any judge rationale. These should be assembled into the [TRACE_DATA], [COMPLIANCE_RULE], and [EVAL_RESULT] placeholders respectively. For high-risk regulated domains, also include [EVIDENCE_SOURCES] with links to the original documents or knowledge base entries that the model was supposed to follow.

Validation and retry logic must be applied to the prompt's output before it enters the audit record. Parse the JSON output and validate that every identified violation step includes a trace_event_id that matches an actual event in the input trace. If the output references trace events that don't exist, or if the evidence_preserved field is empty for a confirmed violation, reject the output and retry with a stronger instruction to ground every claim in trace event IDs. Set a maximum of two retries; if the prompt still produces ungrounded output, escalate to a human reviewer with the raw trace and eval result attached. Log every retry and escalation for observability into the compliance pipeline itself.

Model choice matters for this workflow. Use a model with strong instruction-following and long-context reasoning capabilities—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate. The trace data can be long, so ensure the model's context window can accommodate the full trace plus the prompt. If traces exceed the context window, preprocess by extracting only the steps relevant to the violated rule's domain (e.g., for a data-handling violation, include retrieval steps, output generation, and any tool calls that touched user data; exclude unrelated planning steps). Do not summarise the trace before passing it—the prompt needs step-level detail to isolate root causes.

Audit trail integration is the final step. After validation passes, store the prompt's output alongside the original trace, eval result, and any human review decisions in an immutable audit log. The output's evidence_preserved field should contain direct quotes from the trace that a compliance auditor can verify without re-running the prompt. If the prompt identifies a root cause that requires remediation—such as a system prompt that contradicts a compliance rule—create a ticket in the prompt versioning system and link it to the audit record. Never auto-apply prompt changes based on this analysis; always require human approval for any change that affects compliance posture.