Safety Score Audit Trail Generation Prompt

This prompt is designed for governance, compliance, and trust-and-safety teams who need an explainable, machine-readable record of every safety decision made by an AI system. The core job is to take a user input, its associated risk scores, the configured refusal thresholds, and the final routing decision, and produce a structured audit trail that can be ingested by downstream compliance reporting tools, reviewed by auditors, or used to defend a decision during an incident review. The ideal user is an ML engineer or safety platform builder integrating this prompt into a production safety pipeline where every refusal, escalation, or high-risk allowance must be traceable to a specific policy, score, and evidence source.

Use this prompt when your system already produces calibrated risk scores and threshold-based routing decisions, and you need to close the audit loop. It is appropriate for regulated domains, internal policy enforcement, and any production surface where stakeholders will later ask 'why did the system do that?' The prompt expects structured inputs: the original user request, the risk scores (per-category or aggregated), the active threshold configuration, the final decision, and any evidence or policy citations that informed the scoring. If your system does not yet produce these inputs, start with the sibling prompts for Safety Classification Confidence Scoring or Risk Threshold Gating before wiring in this audit trail generator.

Do not use this prompt as a real-time decision-maker. It is a documentation step that runs after a safety decision has been made. It does not classify, score, or route; it records. Avoid using it for low-risk, non-audited workflows where the overhead of structured audit records adds latency without value. For high-risk domains such as healthcare, legal, or finance, always ensure a human reviewer can access and challenge the audit record, and never treat the generated trail as a substitute for independent compliance review. The next step after reading this section is to examine the prompt template, adapt the output schema to your compliance system's ingestion format, and wire it into your post-decision logging pipeline with validation checks.

This prompt template is designed to be the core instruction set for an LLM tasked with producing a machine-readable audit trail. It takes the raw inputs of a safety decision—the original user request, the calculated risk scores, the applicable policy, and the final routing action—and synthesizes them into a structured JSON record. The primary goal is explainability for governance, compliance, and engineering review, not to re-evaluate the safety decision itself.

textCopy
You are an AI Safety Audit Trail Generator. Your task is to produce a structured, evidence-backed audit record explaining a safety decision. You do not make the safety decision; you document it based on the provided inputs.

# INPUTS
- USER_REQUEST: "[USER_REQUEST]"
- RISK_SCORES: [RISK_SCORES]
- APPLICABLE_POLICY: "[APPLICABLE_POLICY]"
- THRESHOLD_CONFIG: [THRESHOLD_CONFIG]
- FINAL_DECISION: "[FINAL_DECISION]"
- DECISION_RATIONALE: "[DECISION_RATIONALE]"

# OUTPUT_SCHEMA
Generate a single JSON object conforming to this structure:
{
  "audit_record_id": "string, a unique ID for this record",
  "timestamp": "string, ISO 8601 timestamp of generation",
  "input_summary": {
    "user_request_preview": "string, first 100 chars of the user request",
    "risk_score_summary": {
      "highest_risk_category": "string",
      "highest_risk_score": "number"
    }
  },
  "decision_trace": {
    "triggered_policy_clause": "string, the exact policy text that was violated or triggered",
    "threshold_comparison": {
      "relevant_score": "number",
      "threshold_value": "number",
      "operator": "string, e.g., 'gte', 'lte'",
      "result": "boolean"
    },
    "final_action": "string, one of: ALLOW, WARN, REDIRECT, REVIEW, BLOCK",
    "rationale": "string, the provided decision rationale"
  },
  "evidence_sources": [
    {
      "source_type": "string, e.g., 'user_request_excerpt', 'policy_document', 'risk_model_output'",
      "content_excerpt": "string, the relevant snippet of evidence",
      "relevance": "string, explanation of why this evidence supports the decision"
    }
  ],
  "escalation_path": "string or null, the next step if the decision was REVIEW or BLOCK"
}

# CONSTRAINTS
- Do not invent new risk scores or policies. Use only the provided inputs.
- If the FINAL_DECISION is ALLOW, the `escalation_path` must be null.
- Ensure all excerpts in `evidence_sources` are verbatim from the inputs.
- The `audit_record_id` should be a UUIDv4 string.

To adapt this template, replace the square-bracket placeholders with data from your safety pipeline. The RISK_SCORES and THRESHOLD_CONFIG fields should be passed as pre-serialized JSON strings or native objects if your model API supports structured data injection. For high-stakes governance workflows, the generated audit trail should be treated as a draft and programmatically validated against the JSON schema before being committed to an append-only log. A human reviewer should sign off on a batch of these records daily to ensure the rationale quality remains high and the evidence excerpts are not hallucinated.

The audit trail prompt is not a standalone artifact—it is a post-decision recorder that fires after a safety classifier, risk threshold gate, or human reviewer has already made a refusal or escalation decision. Wire it as a synchronous or async step in your safety pipeline, triggered only when the final decision is refuse, escalate, or flag_for_review. Do not call this prompt for allowed requests unless your compliance framework requires universal logging. The prompt consumes the original user input, the upstream classifier's risk scores, the active threshold configuration, the final decision, and any evidence or policy citations that informed that decision. It produces a structured JSON audit record suitable for insertion into an append-only audit store, a compliance reporting database, or a review queue ticket.

Integration pattern: Place this prompt after your decision node. If your safety architecture uses a classifier → threshold gate → action pipeline, insert the audit trail generation step immediately after the gate produces a non-allow decision. Use a retry wrapper with up to 2 retries on schema validation failure, since malformed JSON or missing required fields will break downstream compliance ingestion. Validate the output against a strict JSON schema that enforces: audit_id (UUID generated by your system, not the model), timestamp, decision, risk_scores (per-category objects with score and threshold), evidence_citations (array of policy clause references or input excerpts), rationale_summary (1-3 sentence human-readable explanation), and review_priority (enum: low, medium, high, critical). If validation fails after retries, log the raw model output and the validation errors, then fall back to a template-based audit record that captures at minimum the decision, scores, and a flag indicating automated audit generation failed. Never silently drop audit records—missing audit trails are a compliance finding in themselves.

Model choice and latency: Use a fast, instruction-following model for this task (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model). The prompt is structured data generation, not complex reasoning, so paying for a frontier model here is usually unnecessary. If your pipeline is latency-sensitive, run audit generation asynchronously after returning the refusal response to the user—the user sees the refusal immediately, and the audit record populates within seconds. For synchronous compliance regimes where the audit record must exist before the response is delivered, budget an additional 200-500ms for this step and monitor P95 latency closely. Logging and observability: Emit structured logs at each stage: prompt submission, response receipt, schema validation pass/fail, retry attempts, and final audit record insertion. Tag each log with a trace_id that links the audit record back to the originating request, classifier run, and decision gate. This traceability is essential for debugging discrepancies between what the classifier scored and what the audit trail recorded.

Human review integration: When the decision is escalate or flag_for_review, the audit record becomes the ticket payload for your review queue. Include the audit_id in the review ticket so reviewers can pull the full context. For high-severity harm categories (CSAM, self-harm, violence), configure the harness to require human acknowledgment of the audit record before the refusal response is sent—this is a synchronous blocking step that prevents automated refusals on the most sensitive categories without human verification. For lower-severity categories, the audit record can be generated and stored without blocking the user response. What to avoid: Do not ask the model to generate the audit_id or timestamp—these must come from your application layer to guarantee uniqueness and clock accuracy. Do not pass raw user input through the audit prompt without first redacting PII if your audit store has different data retention policies than your inference pipeline. Do not use this prompt as a substitute for a real safety classifier—it records decisions, it does not make them.