Review Item Decision Audit Trail Prompt for Compliance Records

This prompt is designed for governance teams and compliance engineers who need to produce structured, auditable decision records from human review queue items. Use it when a reviewer has made a decision on a flagged item and the system must capture a complete audit trail that includes the rationale, evidence considered, alternatives rejected, and reviewer identity. The primary job-to-be-done is transforming a reviewer's action and notes into a machine-readable, human-auditable artifact that can be stored in a system of record and retrieved during internal audits or regulatory examinations. It is appropriate for regulated industries, internal policy enforcement, and any workflow where downstream auditors or regulators may need to reconstruct why a specific action was taken.

The ideal user is a compliance engineer integrating this prompt into a review queue application. Required context includes the original flagged item, the reviewer's decision and notes, any evidence or policy documents referenced, and the reviewer's authenticated identity. This prompt is not a replacement for a legal review process or a system of record; it is the formatting layer that turns a reviewer's action into a compliance artifact. Do not use this prompt to make the decision itself—it assumes a human has already adjudicated the item. It is also not suitable for generating real-time alerts or for cases where the decision logic must be kept secret from the model provider.

Before using this prompt, ensure you have a reliable method for capturing the reviewer's identity from your authentication layer and injecting it into the [REVIEWER_IDENTITY] placeholder. The output should be validated against a defined schema before being committed to your audit log. If the review item involves multiple reviewers or a multi-step approval chain, use this prompt for each individual decision point rather than attempting to summarize the entire workflow in one record. For high-stakes domains, always pair this prompt with a human-in-the-loop confirmation step before the audit record is finalized.

This prompt template is designed to be the single source of truth for generating a compliance-grade audit trail. It ingests the raw details of a review item and the human reviewer's final action, then produces a structured record that captures not just the decision, but the rationale, evidence considered, and alternatives rejected. The primary goal is to make the decision explainable to an auditor months later, without requiring the original reviewer to recall the context.

codeCopy
You are an audit record generator for a compliance system. Your task is to produce a structured decision record from a human reviewer's action on a queued item. The record must be self-contained, evidence-based, and suitable for external audit.

## INPUTS
- [REVIEW_ITEM]: The full, unredacted content of the item that was reviewed.
- [REVIEWER_ACTION]: The action taken by the human reviewer (e.g., APPROVED, REJECTED, ESCALATED, REQUESTED_CHANGES).
- [REVIEWER_NOTES]: Any unstructured notes, comments, or annotations provided by the reviewer during the decision.
- [REVIEWER_IDENTITY]: A unique identifier for the reviewer (e.g., email, employee ID).
- [POLICY_CONTEXT]: The specific policy, regulation, or internal standard against which the item was reviewed.

## OUTPUT_SCHEMA
Generate a JSON object conforming to this exact schema:
{
  "audit_record": {
    "record_id": "string, a unique ID for this decision record",
    "timestamp": "string, ISO 8601 timestamp of the decision",
    "reviewer": {
      "identity": "string, from [REVIEWER_IDENTITY]",
      "action": "string, from [REVIEWER_ACTION]"
    },
    "item_summary": "string, a one-sentence summary of the [REVIEW_ITEM]",
    "decision_rationale": {
      "primary_reason": "string, the single most important reason for the decision, synthesized from [REVIEWER_NOTES] and [POLICY_CONTEXT]",
      "evidence_considered": [
        {
          "source": "string, a reference to a specific part of the [REVIEW_ITEM]",
          "finding": "string, what the evidence showed and how it influenced the decision"
        }
      ],
      "policy_alignment": "string, an explanation of how the decision aligns with or deviates from the [POLICY_CONTEXT]"
    },
    "alternatives_rejected": [
      {
        "alternative_action": "string, another possible action that was not taken",
        "rejection_reason": "string, why this alternative was rejected, based on evidence and policy"
      }
    ],
    "completeness_check": {
      "all_required_evidence_reviewed": "boolean, true if the rationale covers all critical parts of the [REVIEW_ITEM]",
      "missing_context_note": "string or null, a note if any standard context was missing from the review packet"
    }
  }
}

## CONSTRAINTS
- Do not fabricate evidence. If the [REVIEWER_NOTES] or [REVIEW_ITEM] do not support a finding, do not invent one.
- If the reviewer's rationale is unclear from the notes, set the `primary_reason` to "RATIONALE_NOT_DOCUMENTED" and flag the record for human review.
- The `alternatives_rejected` array must contain at least one alternative, even if it is a generic "DO_NOTHING" option.
- The output must be valid JSON. Do not include any text outside the JSON object.

To adapt this template, start by mapping your system's existing data fields to the placeholders. The [REVIEW_ITEM] should be a serialized object containing all context the reviewer saw, not just a database ID. The [POLICY_CONTEXT] is critical for audit defensibility; it should be a stable reference to a specific policy version. Before deploying, run this prompt against a set of historical decisions where you know the expected rationale. Use an LLM-as-judge eval to check if the generated primary_reason and policy_alignment fields are faithful to the reviewer's notes and the cited policy. A common failure mode is the model hallucinating a plausible-sounding but incorrect policy alignment, so a strict evaluation against your policy documents is essential.

The Review Item Decision Audit Trail Prompt is designed to sit at the final stage of a human review workflow, after a reviewer has made a decision on a queued item. The prompt takes the review item, the decision, the reviewer's rationale, and any supporting evidence and produces a structured, auditable record. This record becomes the compliance artifact that governance teams, auditors, and internal reviewers can search, replay, and verify. The prompt is not a decision-maker; it is a record-formatter that enforces completeness and traceability.

Wire this prompt into your application as a synchronous post-decision step. When a reviewer submits their decision, the application should assemble the [REVIEW_ITEM], [DECISION], [REVIEWER_ID], [RATIONALE], and [EVIDENCE_SOURCES] inputs and call the model. The output must be validated against the [OUTPUT_SCHEMA] before being written to the audit log. Implement a strict JSON schema validator that checks for required fields: decision_id, timestamp, reviewer, decision, rationale_summary, evidence_considered, alternatives_rejected, and compliance_flags. If validation fails, retry once with the validation errors appended to the prompt as [PREVIOUS_ERRORS]. If the second attempt also fails, log the raw output, flag the record for manual audit review, and alert the compliance engineering channel. Do not silently accept malformed audit records.

For model choice, prefer a model with strong instruction-following and structured output capabilities. If your compliance requirements prohibit sending review data to external APIs, use a local or private deployment. The prompt's [RISK_LEVEL] parameter should be set based on the review item's regulatory sensitivity. For high-risk items, consider adding a second-pass verification: run the generated audit record through a separate fact-checking prompt that verifies the evidence_considered fields are actually present in the source [REVIEW_ITEM] and that the rationale_summary does not introduce claims absent from the reviewer's [RATIONALE]. This two-stage harness catches hallucinated evidence references before they enter the permanent audit log.

Log every step: the input assembly, the model request, the raw response, the validation result, any retries, and the final stored record. Include the prompt version and model identifier in the log. This traceability is essential for demonstrating to auditors that the audit trail generation process itself is controlled and reproducible. Avoid wiring this prompt into asynchronous fire-and-forget pipelines where a failure might go unnoticed. The audit record is the compliance artifact; treat its generation with the same reliability engineering you would apply to a financial transaction log.