Override Audit Report Generation Prompt

Use this prompt when a compliance officer, audit lead, or governance team member must produce a periodic (e.g., quarterly, annual) report summarizing human overrides of AI decisions. The prompt is designed to ingest a pre-aggregated, structured dataset of override events—not raw log streams—and synthesize it into a formal narrative report. The ideal user understands the override policy and the business context but needs the AI to handle the mechanical work of structuring statistics, surfacing notable cases, and drafting trend analysis and remediation language. This is a high-stakes workflow: the generated report is a draft artifact that must be reviewed, edited, and formally approved by a qualified human before it is distributed to internal stakeholders, auditors, or external regulators.

Do not use this prompt for real-time override decisions, for capturing individual override justifications (see sibling playbooks for structured logging), or for making policy judgments about whether an override was correct. The prompt does not evaluate the quality of override reasoning; it only synthesizes provided data. It also must not be used as the final step in an automated pipeline without human approval. The required input is a structured aggregation that includes override counts by category, time-series data, a pre-selected set of notable cases with sanitized descriptions, and any known remediation actions. If you lack this structured input, the prompt will hallucinate statistics and cases, producing a plausible but fabricated report. Always validate the input aggregation before invoking this prompt.

Before wiring this into a production harness, define the exact schema for the input aggregation and the output report sections. Implement a validation step that confirms required fields are present and that summary statistics are internally consistent. The harness should log every generated report draft, the reviewer who approved it, and the timestamp of approval. For regulated environments, retain the approved report and the draft as part of the audit trail. If the prompt is used to generate a report for an external regulator, legal review is mandatory before submission. The next section provides the copy-ready prompt template you can adapt to your specific report structure and data schema.

This prompt template is designed to be pasted into your orchestration layer after you have aggregated override event data from your audit log system. It expects pre-computed summary statistics, a batch of notable override cases, and any relevant policy or regulatory context. The model's job is to synthesize this material into a structured audit report suitable for internal governance review or external examination. The template uses square-bracket placeholders that your application must replace with real data before inference.

textCopy
You are an audit report generator for an AI governance system. Your task is to produce a structured override audit report from the provided data. You must not invent facts, omit required sections, or speculate beyond the evidence provided.

## INPUT DATA

### Audit Period
- Start Date: [AUDIT_PERIOD_START]
- End Date: [AUDIT_PERIOD_END]
- Report Generation Date: [REPORT_DATE]

### Summary Statistics
[SUMMARY_STATISTICS]

### Notable Override Cases
[NOTABLE_CASES]

### Policy and Regulatory Context
[POLICY_CONTEXT]

### Previous Audit Findings (if any)
[PREVIOUS_FINDINGS]

## OUTPUT SCHEMA

Produce a JSON object with the following structure:
{
  "report_metadata": {
    "report_id": "string",
    "audit_period_start": "date",
    "audit_period_end": "date",
    "generated_at": "datetime",
    "total_overrides_reviewed": "integer"
  },
  "executive_summary": {
    "overall_assessment": "string (2-3 sentences on override health)",
    "key_findings": ["string (one finding per item, max 5)"],
    "risk_level": "low | medium | high | critical"
  },
  "statistical_summary": {
    "total_overrides": "integer",
    "override_rate": "string (percentage of total decisions)",
    "by_category": [{"category": "string", "count": "integer", "percentage": "string"}],
    "by_reviewer_role": [{"role": "string", "count": "integer"}],
    "by_outcome": [{"outcome": "string", "count": "integer"}],
    "trend_direction": "increasing | decreasing | stable",
    "trend_detail": "string (brief explanation of trend)"
  },
  "notable_cases": [
    {
      "case_id": "string",
      "override_date": "date",
      "reviewer": "string (anonymized if required)",
      "category": "string",
      "original_ai_decision": "string (brief)",
      "override_decision": "string (brief)",
      "justification_summary": "string",
      "risk_rating": "low | medium | high | critical",
      "policy_reference": "string (specific policy section if applicable)",
      "audit_notes": "string (any concerns or observations)"
    }
  ],
  "trend_analysis": {
    "patterns_identified": ["string (one pattern per item)"],
    "anomalies_detected": ["string (one anomaly per item)"],
    "comparison_to_previous_period": "string (if previous data available, otherwise state 'No previous period data available')",
    "emerging_risks": ["string (one risk per item)"]
  },
  "compliance_assessment": {
    "policy_adherence_rate": "string (percentage or 'Unable to determine')",
    "gaps_identified": ["string (one gap per item)"],
    "regulatory_concerns": ["string (one concern per item)"],
    "overall_compliance_status": "compliant | partially_compliant | non_compliant | review_required"
  },
  "remediation_recommendations": [
    {
      "priority": "high | medium | low",
      "finding_reference": "string (link to specific finding or case)",
      "recommendation": "string",
      "owner_suggestion": "string (suggested team or role)",
      "timeline_suggestion": "string (immediate | short_term | long_term)"
    }
  ],
  "appendix_references": {
    "policy_documents_reviewed": ["string"],
    "data_sources": ["string"],
    "limitations": ["string (known limitations of this report)"]
  }
}

## CONSTRAINTS
- Do not fabricate case details. If a case has insufficient information, mark it as 'Incomplete record' in audit_notes.
- If trend comparison data is unavailable, explicitly state that rather than guessing.
- Anonymize reviewer names if the input data contains personally identifiable information.
- Flag any override that appears to violate policy with a risk_rating of 'high' or 'critical'.
- If the overall compliance status is unclear, use 'review_required' rather than guessing.
- Limit the executive summary to findings directly supported by the provided data.
- If fewer than 5 key findings exist, include only what is supported.

## RISK LEVEL: [RISK_LEVEL]
- If RISK_LEVEL is 'high' or 'critical', add a preamble to the executive_summary.overall_assessment stating: 'This report covers high-risk override activity and requires immediate governance review.'

To adapt this template, replace each square-bracket placeholder with data aggregated from your override logging system before sending the prompt to the model. The [SUMMARY_STATISTICS] placeholder should contain pre-computed counts, rates, and distributions—do not ask the model to compute these from raw records. The [NOTABLE_CASES] placeholder should contain a curated batch of override events that warrant individual audit attention, already formatted with case IDs, dates, categories, and reviewer context. The [POLICY_CONTEXT] placeholder should include relevant policy excerpts, regulatory requirements, or internal governance standards that the model must reference when assessing compliance. The [RISK_LEVEL] placeholder controls whether the report includes an escalation preamble. After the model returns the JSON output, validate it against the schema before distributing the report. Any report with a compliance_status of 'non_compliant' or risk_level of 'critical' must route to a human compliance officer for review and sign-off before distribution.

This prompt is not a standalone chat interaction. It is a final-stage report compiler that must be integrated into a broader audit data pipeline. The harness is responsible for aggregating override records from a structured data store, injecting them into the prompt template, executing the generation, validating the output, and routing the draft for human approval before distribution. The model's role is to synthesize pre-aggregated statistics and case details into a coherent narrative report; it should not be used to perform real-time data queries or to make policy judgments independently.

The implementation should begin with a data aggregation module that queries your override audit log—typically a database of structured OverrideEvent records containing fields like timestamp, reviewer_id, override_reason, risk_score, policy_references, and final_outcome. This module must pre-compute the summary statistics required by the prompt's [AGGREGATED_STATS] placeholder: total overrides, breakdowns by reason category, risk level distributions, reviewer activity, and time-series trends. The [NOTABLE_CASES] placeholder should be populated by a separate query that selects high-risk, anomalous, or precedent-setting overrides based on pre-defined criteria. The [REMEDIATION_RECOMMENDATIONS] placeholder can be seeded with draft findings from a pattern detection pipeline, but the prompt will refine and format them. All data injected into the prompt must be read-only and sourced from the audit log to maintain evidentiary integrity.

After the model generates the report draft, a strict validation layer must verify the output against the [OUTPUT_SCHEMA] defined in the prompt. This includes checking that all required sections are present, that summary statistics in the narrative match the input numbers, that every notable case includes a traceable override_id, and that remediation recommendations are linked to specific policy references or trend evidence. A retry loop with a maximum of three attempts should be used for schema validation failures, with each retry including the specific validation error message. If validation continues to fail, the task must escalate to a human operator with the partial output and error log. Do not silently accept a malformed report.

The final and most critical stage is the human approval gate. The validated report draft must be routed to a compliance officer or audit lead through a review interface that displays the full report, the source override records for each notable case, and a diff view if this is a periodic report with a prior version. The reviewer must explicitly approve, reject with comments, or request revisions before the report is finalized and distributed. This approval event should itself be logged as an audit record, creating a complete chain of custody from the original override events to the final distributed report. Model choice should default to a model with strong long-context reasoning and structured output reliability; avoid low-latency or small-context models that may truncate or hallucinate case details.