Policy Enforcement Audit Report Prompt Template

This prompt is for compliance auditors, trust-and-safety analysts, and AI safety engineers who need to generate a structured audit report from raw policy enforcement logs. The job-to-be-done is converting a batch of enforcement decisions—each with a request, a policy evaluation, and an outcome—into a defensible report that summarizes violation rates, reviews exceptions, identifies compliance gaps, and documents the sampling methodology. The ideal user has access to enforcement log data and needs a report that can be shared with internal reviewers, external auditors, or product leadership to demonstrate policy adherence or surface enforcement drift.

Use this prompt when you have a defined set of enforcement events and a clear audit scope. The prompt requires several concrete inputs: a [POLICY_DOCUMENT] that defines the rules, an [ENFORCEMENT_LOG] containing the decisions under review, an [AUDIT_SCOPE] specifying the time range and policy categories to examine, and a [SAMPLING_METHODOLOGY] describing how the log subset was selected. Do not use this prompt for real-time enforcement decisions, for generating policy rules from scratch, or for single-event debugging. It is designed for batch retrospective analysis, not operational gating. If the enforcement log contains PII or sensitive user content, redact it before passing it into the prompt, and ensure your model deployment meets your organization's data-handling requirements.

The output is a structured audit report, not a conversational summary. You should expect sections for an executive summary, enforcement rate metrics, violation-type breakdowns, exception reviews with justifications, compliance gap findings, and an evidence traceability appendix. Because this workflow touches compliance evidence, always route the generated report through human review before it becomes an official record. Pair this prompt with a schema validator that checks for required sections, numeric consistency between reported counts and the input log, and citation of specific policy clauses for each finding. If the report will be used in a regulated context, log the prompt version, model version, and input hash alongside the final signed report.

This template is designed to be copied directly into your prompt management system, AI orchestration layer, or evaluation harness. It expects structured enforcement log data as input and produces a comprehensive audit report with violation summaries, enforcement rate metrics, exception reviews, and compliance gap findings. Every placeholder is enclosed in square brackets and must be populated by your application before the prompt is sent to the model.

textCopy
You are a compliance audit analyst generating a structured Policy Enforcement Audit Report from raw enforcement log data.

## INPUT DATA
[ENFORCEMENT_LOGS]

## AUDIT PARAMETERS
- Audit Period: [AUDIT_START_DATE] to [AUDIT_END_DATE]
- Policy Version: [POLICY_VERSION]
- Jurisdiction: [JURISDICTION]
- Sampling Methodology: [SAMPLING_METHOD]
- Sample Size: [SAMPLE_SIZE]
- Confidence Level: [CONFIDENCE_LEVEL]

## OUTPUT SCHEMA
Generate a JSON object conforming to this structure:
{
  "audit_metadata": {
    "audit_id": "string",
    "generated_at": "ISO8601 timestamp",
    "audit_period": { "start": "date", "end": "date" },
    "policy_version": "string",
    "jurisdiction": "string",
    "sampling_method": "string",
    "sample_size": "integer",
    "confidence_level": "string"
  },
  "executive_summary": {
    "total_requests_audited": "integer",
    "total_violations_detected": "integer",
    "overall_enforcement_rate": "percentage string",
    "critical_findings_count": "integer",
    "compliance_status": "compliant | partially_compliant | non_compliant"
  },
  "violation_summary": [
    {
      "violation_type": "string",
      "policy_reference": "string",
      "occurrence_count": "integer",
      "severity": "critical | high | medium | low",
      "trend_direction": "increasing | decreasing | stable",
      "representative_example_ids": ["string"]
    }
  ],
  "enforcement_rate_metrics": {
    "overall_rate": "percentage string",
    "by_violation_type": [
      {
        "violation_type": "string",
        "detection_rate": "percentage string",
        "action_rate": "percentage string",
        "false_positive_rate": "percentage string"
      }
    ],
    "by_severity": [
      {
        "severity": "string",
        "detection_rate": "percentage string",
        "action_rate": "percentage string"
      }
    ]
  },
  "exception_review": [
    {
      "exception_id": "string",
      "request_id": "string",
      "violation_type": "string",
      "override_reason": "string",
      "approver": "string",
      "approved_at": "ISO8601 timestamp",
      "expiration": "ISO8601 timestamp or null",
      "audit_finding": "justified | questionable | unjustified",
      "finding_rationale": "string"
    }
  ],
  "compliance_gap_findings": [
    {
      "gap_id": "string",
      "gap_description": "string",
      "affected_policy_sections": ["string"],
      "risk_level": "critical | high | medium | low",
      "evidence_summary": "string",
      "recommended_action": "string"
    }
  ],
  "evidence_traceability": {
    "log_source": "string",
    "log_integrity_hash": "string or null",
    "sampling_seed": "string or null",
    "reproducibility_notes": "string"
  },
  "methodology_notes": {
    "sampling_rationale": "string",
    "limitations": ["string"],
    "excluded_categories": ["string"]
  }
}

## CONSTRAINTS
[RISK_LEVEL: HIGH]
- Every violation must cite a specific policy reference from [POLICY_DOCUMENT_REFERENCE].
- Exception reviews must include the original override reason and an independent audit assessment.
- Compliance gap findings require evidence from the log data, not speculation.
- If enforcement rate metrics cannot be calculated due to insufficient data, mark them as "insufficient_data" and explain why in methodology_notes.
- All timestamps must be in ISO8601 format.
- Do not fabricate violation types, exception records, or gap findings not present in the input logs.
- Mark any field where data is genuinely unavailable as null with a corresponding entry in methodology_notes.limitations.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## INSTRUCTIONS
1. Parse the enforcement logs and extract all violation events, enforcement actions, and exception records within the audit period.
2. Calculate enforcement rates per violation type and severity level.
3. Review each exception for justification quality against policy criteria.
4. Identify patterns that indicate compliance gaps where policy coverage or enforcement consistency is insufficient.
5. Generate the output strictly conforming to the schema above.
6. If the input data is insufficient to complete any section, document the limitation rather than inventing data.

To adapt this template for your environment, replace each square-bracket placeholder with your application's data. The [ENFORCEMENT_LOGS] placeholder should receive structured log records, ideally as JSON with fields for request_id, timestamp, violation_type, policy_reference, enforcement_action, and exception_details. The [FEW_SHOT_EXAMPLES] placeholder is optional but strongly recommended for production use—include 2-3 example input-output pairs that demonstrate correct handling of edge cases such as multi-violation requests, expired exceptions, and borderline severity classifications. The [RISK_LEVEL: HIGH] tag signals to your orchestration layer that this prompt requires human review of outputs before they are distributed or acted upon.

Before deploying this prompt, validate that your enforcement log schema matches the fields the prompt expects. Common failures occur when log field names differ from what the prompt references, when timestamps are in inconsistent formats, or when exception records lack approver identity. Build a pre-processing step that normalizes log fields to the expected names and formats before populating [ENFORCEMENT_LOGS]. For audit workflows, also ensure that the [POLICY_DOCUMENT_REFERENCE] is a stable, versioned pointer so that audit reports remain traceable to the exact policy version in effect during the audit period.

This prompt is designed to be called as part of a scheduled or on-demand audit workflow, not as a real-time user-facing endpoint. The application layer is responsible for assembling the enforcement log data, sampling methodology parameters, and policy reference documents before invoking the model. Because audit reports carry compliance weight, the harness must enforce strict output validation, log every invocation with a trace ID, and route reports that fail validation to a human review queue rather than silently accepting malformed outputs.

The recommended implementation pattern is a three-stage pipeline. Stage 1: Data Assembly — aggregate enforcement logs from your policy engine, apply the sampling methodology (e.g., stratified random sampling by policy category and risk tier), and package the sample into the [ENFORCEMENT_LOG_SAMPLE] placeholder along with the [SAMPLING_METHODOLOGY] description and [POLICY_DOCUMENTS] reference set. Stage 2: Model Invocation — send the assembled prompt to a capable model (GPT-4o, Claude 3.5 Sonnet, or equivalent) with response_format set to json_schema using the expected audit report schema. Set temperature=0 or very low to maximize consistency across audit runs. Stage 3: Output Validation — validate the returned JSON against the audit report schema, checking that all required sections are present, violation counts match the evidence, enforcement rate calculations are arithmetically correct, and every finding includes a traceable evidence reference back to the log sample. Reject and retry once on validation failure; if the second attempt also fails, route to a human auditor with the raw log sample and both failed outputs attached.

For production deployment, instrument the pipeline with structured logging that captures the audit_run_id, sample_size, model_version, prompt_version, validation pass/fail status, and any human review outcomes. Store completed audit reports in an append-only audit database with the full prompt input, model output, and validation result for downstream governance review. If your enforcement logs contain PII or sensitive content, run redaction in the data assembly stage before the data reaches the model. Never send raw enforcement logs directly to a third-party model endpoint without scrubbing. For high-stakes audits, consider running the same sample through two independent model calls and flagging discrepancies for human review before finalizing the report.