Assistant Action Justification Audit Prompt

This prompt is designed for support operations and compliance teams who need a structured, machine-readable explanation of why an AI assistant took a specific action during a conversation. The core job-to-be-done is not to evaluate whether the action was correct, but to produce a reviewable artifact that cites the triggering condition, the relevant system policy, and the evidence from the conversation history. This is essential in regulated or high-stakes support environments where every assistant decision must be traceable to a documented rule and a specific user or system event. The ideal user is a compliance analyst, a support operations manager, or an audit system that consumes structured justification records for downstream review, storage, or reporting.

You should use this prompt when you already have three concrete inputs: the specific action taken by the assistant, the sequence of conversation turns leading up to that action, and a defined set of system policies or behavioral rules. The prompt assumes these inputs are available and does not attempt to retrieve them. It is not a decision-making prompt; it does not judge whether the action was the best choice or whether the policy itself is correct. Instead, it forces the model to articulate the causal chain from trigger to policy to action, making the assistant's stated reasoning explicit and auditable. This is particularly valuable when you need to demonstrate compliance with internal SOPs or external regulations that require explainability for automated decisions.

Do not use this prompt when you need real-time decision support, when the action itself is unknown, or when the system policies are ambiguous or missing. It is also unsuitable for evaluating the quality or correctness of the action—for that, you would need a separate evaluation prompt or human review step. The output of this prompt is a structured justification record, not a pass/fail verdict. Before deploying this into a production audit pipeline, you must pair it with validation checks that verify the cited policy actually exists in your policy set and that the cited evidence is present in the provided conversation history. Without these guardrails, the model may hallucinate plausible-sounding but fictitious policy citations, undermining the entire audit trail.

This template produces a structured audit record explaining why an assistant took a specific action. It requires the action under review, the conversation history leading up to it, and the system policies that should have governed the decision. The output is a JSON object that cites the triggering condition, the relevant policy, and the evidence from the conversation, making it suitable for compliance review queues and support operations workflows.

textCopy
You are an assistant action auditor. Your job is to explain why a specific action was taken by an AI assistant during a conversation, given the prior turns and the system policies in effect.

## INPUTS
- Action to audit: [ACTION_TO_AUDIT]
- Conversation history (prior turns): [CONVERSATION_HISTORY]
- System policies: [SYSTEM_POLICIES]
- Assistant role description: [ASSISTANT_ROLE]

## OUTPUT SCHEMA
Return a valid JSON object with this exact structure:
{
  "action_audited": "string (the action being reviewed)",
  "triggering_condition": "string (what in the conversation triggered this action, with turn reference)",
  "policy_citation": "string (the exact policy or rule that authorized or required this action)",
  "evidence_from_conversation": ["string (direct quote or paraphrase from a specific turn)"],
  "constraints_checked": ["string (each constraint that was verified before acting)"],
  "alternative_actions_considered": ["string (other actions that could have been taken and why they were not chosen)"],
  "confidence_assessment": "string (HIGH, MEDIUM, or LOW with brief explanation)",
  "missing_information": ["string (any information that would have improved the decision but was unavailable)"],
  "human_review_recommended": true or false
}

## CONSTRAINTS
- Every policy citation must be a direct quote or close paraphrase from [SYSTEM_POLICIES]. Do not invent policies.
- Every evidence item must reference a specific turn in [CONVERSATION_HISTORY].
- If no policy clearly applies, set policy_citation to "NO_APPLICABLE_POLICY_FOUND" and flag human_review_recommended as true.
- If the action appears to violate a policy, set confidence_assessment to "LOW" and explain the violation.
- Do not speculate about user intent beyond what is explicitly stated in the conversation.
- If the conversation history is insufficient to justify the action, state that explicitly.

## RISK LEVEL: [RISK_LEVEL]
- If RISK_LEVEL is HIGH, require human_review_recommended to be true regardless of confidence.
- If RISK_LEVEL is CRITICAL, add a "risk_justification" field explaining why the action was taken despite the risk.

Adapt this template by replacing the square-bracket placeholders with your data. The [ACTION_TO_AUDIT] should be a specific, identifiable action such as a tool call, a response claim, or a state change. The [CONVERSATION_HISTORY] should include turn markers so evidence citations are traceable. The [SYSTEM_POLICIES] should be the exact policy text the assistant was operating under, not a summary. For high-risk domains, always set [RISK_LEVEL] to HIGH or CRITICAL and route the output to a human review queue before any downstream action is taken. Validate the output against the schema before storing it in your audit system, and log any parse failures for prompt refinement.

The Assistant Action Justification Audit Prompt is designed to be called as a post-hoc review step, not a real-time interceptor. In a typical harness, a support operations dashboard or an automated audit pipeline submits a batch of conversation turns—each containing the assistant's action, the prior turns, and the applicable system policies—to an inference endpoint. The prompt returns a structured justification object that must be validated before it is stored as an audit record or surfaced to a human reviewer. Because the output is used for compliance and quality assurance, the harness must treat every field as potentially incomplete or hallucinated and must never silently accept a justification that fails validation.

Wire the prompt into an asynchronous job queue (e.g., a background worker pulling from a pending_audit table or a message queue). Each job payload should include: action (the assistant's decision or tool call), prior_turns (an ordered list of user and assistant messages with timestamps), policies (the relevant system instructions, policy documents, or rule sets active at the time of the action), and audit_id (a correlation ID for tracing). The prompt template's [ACTION], [PRIOR_TURNS], [POLICIES], and [CONSTRAINTS] placeholders map directly to these fields. After the model returns a JSON justification, run a strict schema validator that checks: (1) the triggering_condition field is non-empty and references a specific user turn or system state, (2) the policy_citation field contains an actual policy identifier or rule text that exists in the provided policies—not a hallucinated reference, (3) the evidence array contains at least one direct quote or turn reference, and (4) the confidence field is a number between 0 and 1. If validation fails, retry once with a repair prompt that includes the validation errors. If the retry also fails, flag the record for human review and log the failure with the audit_id.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet, or a fine-tuned variant if your policy surface is large). Set temperature to 0 or near-zero to maximize consistency across audit runs. For high-throughput operations, consider caching the policy embeddings and using a retrieval step to select only the relevant policy subset before calling the justification prompt—this reduces token cost and lowers the risk of the model citing an irrelevant or stale policy. Log every justification attempt, including the raw prompt, the raw response, the validation result, and the final accepted or escalated outcome. These logs become the evidence trail for your own audit of the audit system. Avoid wiring this prompt into a synchronous user-facing flow; the latency and validation overhead are better suited to offline review queues where a human can inspect flagged justifications before they become part of a compliance record.