Conversation Decision Trace Prompt for Compliance Review

This prompt is designed for compliance officers and audit teams who need to review a single, high-stakes decision made by an AI assistant within a multi-turn conversation. The primary job-to-be-done is to transform a potentially complex and messy chat log into a structured, human-readable, step-by-step trace. This trace must explicitly link the user's request, the evidence retrieved, the internal policy rules that were triggered, and the assistant's final decision. The ideal user is not the AI engineer who built the system, but a compliance reviewer who needs to verify that a specific decision was made correctly, fairly, and in accordance with documented policies, without needing to understand the underlying model architecture.

You should use this prompt when a decision's auditability is non-negotiable, such as in regulated finance, healthcare, or insurance workflows. It is appropriate for post-hoc review of decisions involving claim eligibility, transaction flags, clinical trial matching, or access control. The prompt requires a complete context package: the full conversation history, the specific assistant turn containing the decision, the exact text of the relevant policy documents, and the evidence snippets that were available to the model at the time. Do not use this prompt for real-time decision-making, for debugging model behavior during development, or for decisions where the policy is ambiguous and requires human interpretation. It is a documentation tool, not a judgment replacement.

This prompt is not a substitute for a human-in-the-loop approval workflow. It assumes the decision has already been made and focuses on creating a defensible audit artifact. Before relying on its output, you must implement a validation harness that checks for hallucinated policy citations and missing evidence links. The next step after generating a trace is to have a human reviewer compare the trace's 'Evidence-to-Conclusion' chain against the source documents. Avoid using this prompt for low-risk, conversational decisions where the overhead of a full trace is not justified by the compliance requirement.

This template is the core instruction set for the model. It is designed to be dropped into your application's prompt assembly pipeline. The prompt forces the model to act as a compliance analyst, reconstructing a decision's lineage from raw conversation turns, retrieved evidence, and stated policies. It strictly separates facts from interpretation and requires explicit citations for every inferential step. The output is a structured markdown report suitable for direct human review or ingestion into a compliance audit system.

markdownCopy
You are a compliance review analyst. Your task is to produce a Decision Trace Report for a specific assistant action or conclusion within a conversation. You must reconstruct the logical path from user input to final decision, citing all evidence and policy rules used.

## Input Data
- **Conversation Log:** A sequence of turns between a user and an AI assistant.
  ```json
  [CONVERSATION_LOG]

• Assistant Decision Under Review: The specific statement, action, or tool call made by the assistant that requires a trace.

  jsonCopy
  [DECISION_UNDER_REVIEW]

• Retrieved Evidence Corpus: The set of documents or data chunks available to the assistant at the time of the decision.

  jsonCopy
  [EVIDENCE_CORPUS]

• Active Policy Set: The rules, guidelines, or constraints the assistant was instructed to follow.

  jsonCopy
  [POLICY_SET]

Output Schema

Generate a Decision Trace Report in markdown with the following sections. Be rigidly faithful to the input data. If a section cannot be completed due to missing information, explicitly state 'INSUFFICIENT DATA' and explain what is missing.

1. Decision Summary

• Decision: [Restate the decision under review]
• Turn: [Turn number where the decision occurred]
• Timestamp: [Timestamp of the decision turn]

2. Triggering Condition

• User Input: [The exact user message or event that immediately preceded the decision]
• Detected Intent/Need: [The inferred user goal that triggered the decision process]
• Confidence: [HIGH/MEDIUM/LOW] - [Brief justification]

3. Evidence Trail

For each piece of evidence used, provide:

• Source: [Document ID or chunk reference from the Evidence Corpus]
• Relevant Excerpt: [Quote the specific text used]
• Interpretation: [How this excerpt supports the decision. Clearly separate fact from inference.]
• Timeliness: [Timestamp of the evidence. Flag if it may be stale relative to the conversation.]

4. Policy Evaluation

For each policy rule that influenced the decision, provide:

• Policy Rule: [Exact text or ID of the rule from the Policy Set]
• Condition Check: [How the conversation state or evidence satisfied the rule's condition]
• Action Mandated: [The action the policy required or permitted]
• Compliance Status: [COMPLIANT / NON-COMPLIANT / NOT APPLICABLE] - [Justification]

5. Decision Logic Walkthrough

Provide a numbered, step-by-step narrative of the assistant's reasoning. Each step must reference the evidence (from Section 3) or policy (from Section 4) that justifies it. Do not add information not present in the inputs.

6. Missing Information & Ambiguities

List any gaps that prevented a complete trace:

• Missing Evidence: [What fact was needed but not found in the corpus]
• Ambiguous Policy: [Any policy rule that was open to interpretation]
• Unresolved Context: [Any prior user statement that was unclear or contradictory]

7. Overall Compliance Assessment

• Conclusion: [SUPPORTED / UNSUPPORTED / INCONCLUSIVE]
• Risk Level: [LOW/MEDIUM/HIGH/CRITICAL]
• Reviewer Notes: [Any flags for a human reviewer, such as potential hallucination, policy conflict, or evidence gap]

Constraints

• Do not invent facts, evidence, or policies not present in the input data.
• If the evidence is contradictory, note the contradiction in Section 6 and explain how it was resolved in Section 5.
• If the decision cannot be justified, state 'UNSUPPORTED' in the overall assessment.
• Maintain a neutral, factual tone. This is an audit document, not an argument for the defense.

To adapt this template, replace the four square-bracket placeholders with your application's data. The [CONVERSATION_LOG] should be a serialized JSON array of turn objects. The [DECISION_UNDER_REVIEW] can be a single string or a structured object identifying the specific assistant message or tool call. For high-risk domains, always pair this prompt's output with a programmatic validation harness that checks for the presence of all required sections and flags any 'INSUFFICIENT DATA' or 'UNSUPPORTED' conclusions for mandatory human review before the trace is archived.

The Conversation Decision Trace Prompt is designed to be called after a high-stakes assistant decision has been made, not during the real-time conversation flow. In a production compliance system, this prompt should be triggered by a decision-logging event—such as a tool call that modifies a customer record, a policy action that denies a claim, or an escalation that routes a case to a human reviewer. The application layer must capture the full conversation context, the retrieved evidence set, the applicable policy documents, and the final decision payload before invoking this prompt. Treat the trace generation as an asynchronous post-decision step that writes an immutable audit record to your compliance store.

Wire the prompt into a decision-audit pipeline with these components: Input assembly—collect the user's turn history, the evidence snippets returned by your RAG system (with source identifiers and retrieval timestamps), the policy rules that were active at decision time, and the structured decision output (action, confidence, reasoning). Model selection—use a model with strong instruction-following and long-context handling (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller models that may drop steps or hallucinate policy citations. Validation layer—after the trace is generated, run structured checks: (1) every cited policy rule must match a rule ID in the input policy set, (2) every evidence reference must resolve to a source ID in the input evidence set, (3) the trace must contain a step for each required phase (user intent, evidence retrieval, policy matching, decision, justification). Reject traces that fail validation and retry with a repair prompt that includes the specific validation errors.

For high-risk domains (finance, healthcare, legal), add a human review queue before the trace is finalized. The system should surface the generated trace alongside the original conversation and evidence for a compliance officer to approve, reject, or annotate. Log every review action with a timestamp and reviewer identity. Implement retry logic with a maximum of 2 repair attempts for validation failures; if the trace still fails after 2 retries, escalate to human review with the failure details attached. Store the final trace as an append-only record with a trace ID, decision ID, model version, prompt version, and generation timestamp. Never allow the trace to overwrite the original decision or conversation data—the trace is derivative evidence, not the source of truth. Avoid wiring this prompt into synchronous user-facing flows; the latency and review requirements make it unsuitable for real-time responses.