Policy Decision Trace Audit Trail Generation Prompt

This prompt is designed for governance, compliance, and trust and safety teams who need to convert a raw, machine-generated policy decision trace into a structured, human-readable audit trail. Use it when you must provide a clear, defensible record of why an AI system allowed or refused a specific request. The output is intended for internal review boards, external auditors, or regulatory filings where the chain of reasoning must be transparent and reproducible. This prompt assumes you already have a captured trace containing the user input, the policy rules evaluated, the evidence considered, and the final decision. It does not perform the policy evaluation itself; it documents the decision that was already made.

Do not use this prompt when you need to evaluate a policy decision in real time, classify a refusal reason at scale, or diagnose why a safety filter activated. Those tasks require different prompts from this pillar, such as the Safety Filter Activation Root-Cause Analysis Prompt or the Refusal Reason Extraction Prompt from Production Logs. This prompt is also unsuitable when the raw trace is incomplete or missing key fields like the policy rules evaluated or the evidence considered. In those cases, use the Policy Violation Trace Reconstruction Prompt first to assemble a complete trace before generating the audit trail. For batch processing of multiple traces into dashboard-ready summaries, prefer the Refusal Event Categorization Prompt for Production Logs.

The ideal user is a compliance officer, trust and safety lead, or governance analyst preparing evidence for an internal review board or external auditor. The required inputs are a complete policy decision trace in a structured format (JSON or similar), including the user input, the policy rules evaluated, the evidence considered, and the final decision with a timestamp. Before running this prompt, validate that the trace contains all required fields and that the decision is final. Wire this prompt into a human-review workflow: the generated audit trail should be reviewed and signed off before submission to auditors. For high-risk domains like healthcare or finance, always require human approval on the final output.

The prompt below is designed to be dropped into your audit workflow. It instructs the model to act as a forensic documentarian, not a policy judge. Its sole job is to translate the structured trace data—timestamps, policy rule evaluations, evidence snippets, and the final decision—into a linear narrative suitable for an internal governance board or an external auditor. The model must not re-evaluate the decision, fill gaps with assumptions, or offer opinions on the policy's correctness.

codeCopy
You are an AI audit documentation specialist. Your task is to generate a human-readable audit trail from the raw policy decision trace provided below. The audit trail must be a chronological, step-by-step record suitable for review by an internal governance board or an external auditor. Do not re-evaluate the decision. Your job is to document the reasoning that was already captured in the trace.

## Input Trace
[RAW_POLICY_DECISION_TRACE]

## Output Schema
Produce a markdown document with the following sections:
- **Audit Trail ID:** A unique identifier for this record.
- **Timestamp:** The date and time of the original decision.
- **Request Summary:** A neutral, one-sentence description of the user's request.
- **Chronological Decision Log:** A numbered list of steps. Each step must include:
    - The timestamp of the trace event.
    - The policy rule or condition evaluated.
    - The evidence considered (quote directly from the trace).
    - The outcome of that evaluation step.
- **Final Decision:** The final allow/refuse/flag decision and the exact output or refusal message provided to the user.
- **Reviewer Notes:** A placeholder section titled 'Human Review Notes' with the instruction: '[To be completed by a human reviewer]'.

## Constraints
- Do not add, remove, or reinterpret any evidence from the trace.
- If a timestamp or rule name is missing in the trace, write 'Not recorded in trace' instead of guessing.
- Maintain a neutral, factual tone. Do not use language that implies judgment of the policy or the user.
- If the trace is empty or unreadable, output only: 'Error: Invalid or empty trace provided.'

To adapt this template, replace [RAW_POLICY_DECISION_TRACE] with the actual JSON or structured log from your production system. If your traces use different field names (e.g., rule_id instead of policy_rule), update the 'Chronological Decision Log' instructions to map to your schema. For high-stakes compliance workflows, always route the generated audit trail to a human reviewer using the 'Human Review Notes' placeholder before finalizing the record. A validation step should check that the output contains all required sections and that the 'Final Decision' matches the original trace's outcome to prevent documentation drift.

This prompt is designed to be the final stage in a policy trace processing pipeline, not a standalone chat interface. The raw trace data—captured from model reasoning, tool calls, safety filter activations, and retrieval steps—must be pre-assembled into the [RAW_POLICY_TRACE] input variable before the prompt is called. The prompt's job is to transform that structured but verbose trace into a human-readable, timestamped audit trail suitable for internal review boards, external auditors, or compliance archiving. It does not make policy decisions; it documents the decision that was already made.

Wire this prompt into an application as a post-hoc documentation step triggered after a policy-sensitive decision completes. The application should: (1) extract the full trace from your observability store (e.g., LangSmith, Arize, custom logging); (2) populate the [RAW_POLICY_TRACE] variable with the serialized trace JSON; (3) populate [POLICY_RULES_EVALUATED] with the specific policy clauses and versions active during the request; (4) set [AUDIT_STANDARD] to the governing framework (e.g., 'SOC 2', 'ISO 42001', 'internal policy v2.3'); and (5) call the prompt. Validate the output against the [OUTPUT_SCHEMA] before storing it. The schema should require a decision_timeline array with ordered steps, each containing a timestamp, step_type (e.g., 'input_received', 'policy_check', 'evidence_retrieved', 'decision_made'), description, and evidence_reference. Reject any output missing the timeline or with out-of-order timestamps. Log the raw prompt, the trace input, and the validated audit trail to an append-only audit log with write-once-read-many (WORM) storage guarantees.

For high-risk domains (finance, healthcare, legal), this prompt must be part of a human-in-the-loop workflow. After the audit trail is generated, route it to a review queue where a compliance officer can inspect the gap_analysis and human_review_flags fields. The prompt is instructed to set human_review_required: true whenever the model's confidence in a policy boundary decision was below a threshold or when conflicting policy rules were evaluated. Your application should enforce this: if the flag is set, the audit trail must not be finalized until a human reviewer provides a digital sign-off. Implement retries with exponential backoff if the model call fails (HTTP 429, 5xx), but do not retry if validation fails—instead, log the malformed output and alert the on-call engineer. Model choice matters: use a model with strong instruction-following and long-context handling (e.g., GPT-4o, Claude 3.5 Sonnet) because the raw trace can be large. Set temperature=0 to maximize determinism and reproducibility for audit purposes.

Avoid using this prompt for real-time decision-making or as a replacement for policy enforcement. It documents decisions after they occur. Do not feed it live user PII unless the trace has been redacted; the prompt itself does not perform redaction. If the raw trace contains sensitive data, run a redaction step upstream before populating [RAW_POLICY_TRACE]. Finally, version this prompt alongside your policy rules. When policy clauses change, update the [POLICY_RULES_EVALUATED] input and test the prompt against a golden set of known decision traces to ensure the audit trail generation remains accurate and complete.