Unsafe Request Audit Trail Generation Prompt

This prompt is for governance, compliance, and safety engineering teams that need structured, auditable records of every safety decision an AI system makes. It takes the output of an upstream safety classifier—a classification label, confidence score, and policy reference—and produces a complete audit trail entry suitable for regulatory review, internal investigations, or model improvement analysis. Use this prompt when your platform must demonstrate why a request was blocked, flagged, or allowed, and when that decision must be traceable to a specific policy version and reviewer. This is not a classification prompt. It assumes classification has already occurred and focuses entirely on evidence packaging and decision documentation.

The ideal user is a safety platform engineer or compliance architect integrating this prompt into a post-classification pipeline. The required context includes the raw user input, the classifier's output payload, the active policy document version, and any session or user metadata needed for traceability. Do not use this prompt for real-time enforcement gating—it is a documentation step, not a decision step. Do not use it to second-guess or override the classifier's decision; its job is to record the decision, not to re-litigate it. If the classifier's output is missing required fields or contains ambiguous labels, fix the classifier first. Feeding incomplete classification data into this prompt will produce incomplete audit records that fail regulatory scrutiny.

Before wiring this prompt into production, define the downstream consumer of the audit trail: a compliance database, a review queue, a monitoring dashboard, or a regulatory filing system. The output schema must match that consumer's requirements exactly. If your use case involves legally mandated reporting (e.g., CSAM, financial fraud, imminent harm), add a human-review step after audit generation and before any external submission. The prompt produces documentation, not legal filings. When in doubt, escalate to human review rather than relying on automated audit generation for high-severity incidents.

The following prompt template is designed to be integrated directly into your safety decision pipeline. It takes the output of upstream classification systems—harm category, confidence score, policy references, and input context—and produces a structured, timestamped audit record. The record is designed to satisfy governance reviewers who need to understand what was detected, why a decision was made, and who or what system was involved. Copy this template into your prompt management system and replace the square-bracket placeholders with your application's runtime values.

textCopy
SYSTEM: You are an audit trail generator for an AI safety platform. Your output must be a complete, structured record suitable for regulatory review. You must not omit any required fields. If any input value is missing or uncertain, you must flag it explicitly rather than inventing a value.

USER:
Generate a structured audit trail record from the following safety classification inputs.

INPUT:
- Request ID: [REQUEST_ID]
- Timestamp: [TIMESTAMP]
- User/Session Context: [USER_CONTEXT]
- Raw Input Excerpt: [RAW_INPUT_EXCERPT]
- Classification Result: [CLASSIFICATION_RESULT]
- Harm Categories Detected: [HARM_CATEGORIES]
- Confidence Score: [CONFIDENCE_SCORE]
- Severity Level: [SEVERITY_LEVEL]
- Policy References: [POLICY_REFERENCES]
- Decision: [DECISION]
- Decision Rationale: [DECISION_RATIONALE]
- Reviewer Context: [REVIEWER_CONTEXT]

OUTPUT_SCHEMA:
{
  "audit_record": {
    "record_id": "string, unique identifier for this audit entry",
    "generated_at": "string, ISO 8601 timestamp of audit record generation",
    "request": {
      "request_id": "string",
      "timestamp": "string, ISO 8601",
      "user_context": "string, anonymized session or user identifier",
      "raw_input_excerpt": "string, the portion of user input that triggered classification"
    },
    "classification": {
      "result": "string, the classification outcome",
      "harm_categories": ["string, array of detected harm categories"],
      "confidence_score": "number, between 0.0 and 1.0",
      "severity_level": "string, one of: LOW, MEDIUM, HIGH, CRITICAL"
    },
    "policy": {
      "references": ["string, array of policy IDs or section names"],
      "decision": "string, one of: BLOCK, FLAG, ALLOW, ESCALATE",
      "rationale": "string, explanation of why the decision was reached"
    },
    "review": {
      "reviewer_context": "string, additional context for human reviewers",
      "completeness_checks": {
        "all_required_fields_present": "boolean",
        "missing_fields": ["string, list of any missing required fields"],
        "uncertainty_flags": ["string, list of fields with uncertain or inferred values"]
      }
    }
  }
}

CONSTRAINTS:
- Every field in the output schema must be populated or explicitly marked as missing.
- Do not fabricate values for missing inputs. Use null and add an entry to missing_fields.
- If the confidence score is below [CONFIDENCE_THRESHOLD], add an uncertainty_flag indicating low-confidence classification.
- The rationale field must reference specific policy references, not generic statements.
- The raw_input_excerpt must be truncated to [MAX_EXCERPT_LENGTH] characters if longer.
- If the decision is ESCALATE, the reviewer_context must include the escalation reason and priority.

To adapt this template for your environment, start by mapping your upstream classifier's output fields to the INPUT placeholders. If your classifier produces additional metadata—such as model version, latency, or alternative classifications—add those as optional fields in the classification block rather than omitting them. The completeness_checks section is critical for regulatory readiness: it forces the model to self-audit whether all required information is present before the record is written. Configure [CONFIDENCE_THRESHOLD] based on your risk tolerance; a typical starting point is 0.85 for high-stakes domains. Set [MAX_EXCERPT_LENGTH] to comply with your data minimization policies, commonly 500 characters.

Before deploying, validate that the generated JSON strictly conforms to the OUTPUT_SCHEMA. A post-generation validation step should check for missing required fields, malformed timestamps, and enum violations in severity_level and decision. If the audit record fails validation, retry once with an explicit error message injected into the prompt. If the retry also fails, log the failure and escalate to a human reviewer rather than writing an incomplete record. For high-throughput systems, consider batching audit record generation and running periodic completeness spot-checks against a sample of records. Never allow an audit record with missing required fields to be persisted without a human-reviewed exception.

The audit trail generation prompt is not a standalone classifier—it is the final documentation step in a safety decision pipeline. Wire it after an upstream classification prompt has already produced a harm category, risk score, and policy reference. The audit prompt consumes that structured classification output plus the original user request and any session context, then produces a human-readable, evidence-anchored record suitable for compliance review. Do not use this prompt as the primary safety gate; it is too verbose and too slow for real-time blocking decisions. Its job is to create the paper trail that explains why a decision was made.

In a typical implementation, the audit prompt receives a JSON input payload containing [ORIGINAL_REQUEST], [CLASSIFICATION_RESULT], [POLICY_REFERENCES], [SESSION_ID], and [REVIEWER_CONTEXT]. Validate the upstream classification result before calling the audit prompt—if the classifier returned low confidence or an abstention, route to human review first and only generate the audit trail after a human decision is recorded. The audit prompt should be called with temperature=0 and a strict JSON output schema to enforce field completeness. Implement a retry loop with up to 3 attempts if the output fails schema validation, checking for missing required fields like decision_rationale, policy_citations, or evidence_excerpts. Log every audit record immutably with a timestamp, model version, and prompt version hash. For regulated domains, store the full prompt input and output as a signed record in a write-once data store.

Model choice matters for audit quality. Use a model with strong instruction-following and low hallucination rates on structured generation tasks—frontier models with JSON mode support are preferred. Avoid small or quantized models that may drop required fields or fabricate policy citations. The audit prompt includes a completeness self-check instruction; validate this self-check against your own schema validator rather than trusting it blindly. If the self-check claims completeness but your validator finds missing fields, escalate the record for human review and log the discrepancy as a prompt reliability incident. For high-volume systems, batch audit generation during off-peak hours rather than blocking the user-facing response path. Never expose raw audit trails to end users—these are internal governance artifacts and may contain sensitive policy reasoning that should not be disclosed.