Override Audit Trail Generation Prompt

This prompt is for platform engineers and governance teams who need to generate a complete, immutable audit record every time a human overrides an AI decision. The output links the original AI recommendation, the human override action, the structured justification, reviewer identity, and the final outcome into a single timestamped record suitable for downstream indexing, search, and compliance review. Use this prompt when your system already captures the override event and justification, and you need a canonical audit entry that can be written to an append-only log, database, or compliance store.

The ideal user is an engineering lead integrating an AI decision point into a product where human overrides must be traceable for internal governance, external audit, or regulatory review. Required context includes the original AI decision payload, the override action taken, the reviewer's structured justification, and any relevant policy or risk metadata. This prompt is not a real-time approval gate; it generates documentation after the override decision is made, not before. Do not use it to decide whether an override should be permitted or to block an action in flight.

Before wiring this prompt into a production harness, confirm that your system of record for override events is the source of truth. The prompt assembles a record from fields you already possess; it does not extract justifications from free-text chat logs or infer reviewer intent. If your override capture is incomplete, invest upstream in structured justification collection before relying on this audit trail generation step. The resulting record should be treated as append-only and never modified after creation to preserve immutability guarantees.

This section provides the exact prompt template you can copy and adapt to generate a structured, machine-readable audit record. The prompt is designed to be self-contained, requiring only the specified inputs to produce a complete JSON object suitable for downstream indexing, search, and compliance review. It does not evaluate the quality of the override or the correctness of the decision; its sole function is to construct the audit artifact.

textCopy
You are an audit trail generation system. Your only job is to produce a structured, immutable audit record for a human override of an AI decision. Do not evaluate the quality of the justification or the correctness of the override. Do not invent missing information. If a required input is absent or null, set its value to null and include a `completeness_flag` set to `incomplete` with a note explaining what is missing.

## INPUTS

[AUDIT_ENTRY_ID]
[ORIGINAL_AI_DECISION]
[OVERRIDE_ACTION]
[OVERRIDE_JUSTIFICATION]
[REVIEWER_IDENTITY]
[OVERRIDE_TIMESTAMP]
[FINAL_OUTCOME]
[SYSTEM_CONTEXT]

## OUTPUT INSTRUCTIONS

Return a single JSON object with the following structure:

{
  "audit_entry": {
    "entry_id": "string",
    "generated_at": "ISO 8601 timestamp",
    "original_ai_decision": {
      "decision_id": "string or null",
      "decision_summary": "string or null",
      "decision_timestamp": "ISO 8601 timestamp or null",
      "confidence_score": "number or null",
      "recommended_action": "string or null"
    },
    "human_override": {
      "override_action": "string",
      "justification": {
        "reason": "string or null",
        "risk_context": "string or null",
        "evidence_cited": ["string or null"],
        "policy_references": ["string or null"]
      },
      "reviewer": {
        "reviewer_id": "string or null",
        "reviewer_role": "string or null",
        "reviewer_team": "string or null"
      },
      "override_timestamp": "ISO 8601 timestamp or null"
    },
    "final_outcome": {
      "action_taken": "string or null",
      "outcome_timestamp": "ISO 8601 timestamp or null",
      "outcome_status": "string or null"
    },
    "system_context": {
      "workflow_id": "string or null",
      "system_version": "string or null",
      "environment": "string or null"
    },
    "completeness": {
      "completeness_flag": "complete | incomplete",
      "missing_fields": ["string"],
      "notes": "string or null"
    }
  }
}

## CONSTRAINTS

- Do not modify, summarize, or evaluate the override justification. Include it verbatim in the `reason` field.
- All timestamps must be in ISO 8601 format (UTC).
- If the original AI decision did not include a confidence score, set `confidence_score` to null.
- Set `completeness_flag` to `incomplete` if any top-level input is missing or null, and list the missing fields in `missing_fields`.
- Do not add fields outside the specified schema.
- Do not include commentary, markdown formatting, or text outside the JSON object.

To adapt this template for your own systems, replace the bracketed placeholders with your actual data sources. The [ORIGINAL_AI_DECISION] input should be a structured object containing the decision ID, summary, timestamp, confidence score, and recommended action. If your AI system does not produce a confidence score, pass null for that field. The [OVERRIDE_JUSTIFICATION] should be the exact text provided by the human reviewer, which the prompt will place verbatim into the reason field. All timestamps must be normalized to ISO 8601 UTC before being passed to the prompt to ensure consistency across distributed systems.

Before deploying this prompt into a production harness, you must implement validation on the output. A post-generation validator should check that the returned JSON conforms to the schema, that the completeness_flag is correctly set based on the presence of null values in required fields, and that all timestamps are valid ISO 8601 strings. For high-risk or regulated workflows, route any record with a completeness_flag of incomplete to a human review queue before it is written to the audit log. Never rely solely on the model's self-reported completeness assessment without independent verification.

Wire this prompt into your override handling pipeline after the human reviewer submits their justification and the override is executed. The prompt should be called synchronously before writing the audit record to your append-only store. Pre-processing is critical: validate that all required inputs exist before calling the prompt. If the override justification is captured as free text, use a separate extraction prompt to structure it first. Do not pass raw chat logs or emails directly into this prompt.

For API integration, call the prompt via your LLM provider's API with response_format set to json_object and a low temperature (0.0-0.1) to maximize structural consistency. Use the JSON schema from the output contract as the expected response format if your provider supports structured outputs. After receiving the response, validate the JSON against the output contract schema. Check that all required fields are present, timestamps are valid ISO 8601, and the completeness flag is consistent with the presence of null fields. If validation fails, retry once with the validation errors appended to the prompt. If the retry also fails, log the raw response and alert the on-call channel.

Write the validated audit record to an append-only log, database table with insert-only permissions, or a write-once object store. Generate a content hash (SHA-256) of the record and store it alongside the entry for tamper detection. Never update or delete audit records after they are written. This prompt does not require human review of its output because it is assembling existing data, not making decisions. However, the audit system should have a separate periodic verification job that samples records and confirms they match source system logs. If the model returns malformed JSON, use a repair prompt to fix structural errors before retrying. If the model hallucinates values for fields that were provided as null, flag the record for manual review and do not write it to the audit store. Log the hallucination event for model performance tracking.