Override Audit Trail Completeness Verification Prompt

This prompt is designed for audit engineers and compliance platform teams who need to programmatically verify that every human override of an AI decision has a complete, unbroken audit trail. It is not a one-off manual check but a component you wire into an automated audit pipeline. The prompt ingests a batch of override event records and their associated audit log entries, then produces a structured completeness report that flags missing records, broken chains, orphaned decisions, and timestamp anomalies. Use this when you are building a system that must prove to internal auditors or external regulators that no override event escapes documentation.

The ideal deployment context is a post-hoc verification step that runs after override events have been logged. You should feed this prompt a structured batch containing override event IDs, timestamps, reviewer identities, and the corresponding audit log entries that should link each override to its originating AI decision, justification record, and final outcome. The prompt does not generate audit trails or capture overrides in real time; it verifies completeness after the fact. Do not use this prompt for real-time override capture, for generating the audit trail itself, or as a substitute for a proper immutable logging system. It is a verification gate, not a logging mechanism.

Before wiring this prompt into production, define your completeness criteria explicitly: what constitutes a complete chain (e.g., AI decision → override event → justification → outcome), which timestamp ordering rules apply, and what tolerance you allow for clock skew. The prompt's output schema should map directly to your downstream alerting or dashboarding system. For high-stakes compliance workflows, always route flagged incompletes to a human auditor for confirmation before taking automated remediation actions such as blocking a system or invalidating a decision. The next step after reading this section is to review the prompt template and adapt the placeholders to your specific audit log schema and completeness rules.

This prompt template is designed to be dropped directly into your audit verification pipeline. It accepts a batch of override event records and a completeness schema, then produces a structured report identifying missing audit trail links, broken chains, orphaned decisions, and records that fail to meet your defined completeness criteria. The template uses square-bracket placeholders for all variable inputs—replace each with your actual data, schema definitions, and operational constraints before execution.

textCopy
You are an audit trail completeness verifier. Your task is to examine a batch of override event records and determine whether each event has a complete, linked audit trail according to the provided schema.

## INPUT DATA
[OVERRIDE_EVENT_RECORDS]

## COMPLETENESS SCHEMA
[COMPLETENESS_SCHEMA]

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
You must return a valid JSON object with the following structure:
{
  "summary": {
    "total_events": <integer>,
    "complete_events": <integer>,
    "incomplete_events": <integer>,
    "completeness_rate": <float between 0 and 1>
  },
  "incomplete_events": [
    {
      "event_id": "<string>",
      "missing_records": ["<field name or record type>"],
      "broken_chains": [
        {
          "expected_link": "<description of expected connection>",
          "actual_state": "<description of what was found or missing>"
        }
      ],
      "orphaned_decisions": ["<decision_id or description>"],
      "severity": "critical|high|medium|low",
      "recommended_action": "<string>"
    }
  ],
  "warnings": ["<string describing systemic issues or patterns>"],
  "verification_timestamp": "<ISO 8601 timestamp>"
}

## INSTRUCTIONS
1. For each override event in [OVERRIDE_EVENT_RECORDS], check that all required fields and linked records defined in [COMPLETENESS_SCHEMA] are present and non-null.
2. Identify any broken chains where a referenced record ID does not resolve to an existing record in the provided data.
3. Flag orphaned decisions that lack a connection to an originating AI decision or a final outcome.
4. Assign a severity level based on [CONSTRAINTS] and the audit criticality of the missing information.
5. If no completeness schema is provided, flag this as a warning and report only structural integrity issues (broken references, orphans).
6. Do not fabricate missing data. If a record is absent, report it as missing rather than guessing its contents.
7. If [CONSTRAINTS] specifies a minimum completeness threshold, include a pass/fail assessment in the summary.

To adapt this template, replace [OVERRIDE_EVENT_RECORDS] with your serialized event batch—typically a JSON array of override objects containing fields like event_id, original_decision_id, override_justification_id, reviewer_id, timestamp, and final_outcome_id. Replace [COMPLETENESS_SCHEMA] with your organization's definition of a complete audit trail, specifying required fields per event type, mandatory cross-references, and acceptable nullability rules. Replace [CONSTRAINTS] with operational parameters such as minimum completeness thresholds, severity classification rules, and any regulatory requirements that affect how missing records should be flagged.

Before deploying this prompt into a production harness, validate that the output JSON strictly conforms to the declared schema. Add a post-processing validation step that checks field types, required keys, and value ranges. For high-stakes audit workflows, route all critical and high severity findings to a human reviewer before the completeness report is finalized. Log every verification run with the input batch hash, the model version, and the raw output for downstream traceability.

This prompt is designed to operate as a batch verification job within an audit pipeline, not as a real-time synchronous call. The harness should pull a set of override events from the audit log system, package each event with its linked records (original AI decision, human justification, policy check result, and final outcome), and submit them to the model for completeness verification. Because the output is a structured completeness report with pass/fail assessments and specific gap descriptions, the harness must validate the response schema before writing results back to the audit database or review queue. Treat this as a high-integrity workflow: false negatives (marking an incomplete trail as complete) carry more risk than false positives, so bias your validation toward flagging borderline cases for human review.

Integration points include: (1) a query layer that fetches override events and their linked records from your audit store, (2) a prompt assembly step that populates [OVERRIDE_EVENT], [LINKED_RECORDS], and [REQUIRED_TRAIL_ELEMENTS] from your system's schema, (3) a model call with a low-temperature setting (0.0–0.2) to maximize consistency on structured pass/fail decisions, and (4) a post-processing validator that checks the output against the expected [OUTPUT_SCHEMA]. Retry logic should be minimal: if the model returns malformed JSON, retry once with a repair prompt that includes the raw output and the schema. If the second attempt fails, log the failure and route the event to a human audit queue with the raw model output attached. Do not silently drop verification failures.

Validation rules to implement in the harness: confirm that every override event in the input batch appears in the output report with a matching event_id; verify that each trail_element_status entry references a valid element from the REQUIRED_TRAIL_ELEMENTS list; check that overall_completeness is either complete or incomplete and is consistent with the individual element statuses (if any element is missing or partial, overall must be incomplete); and flag any gap_description that is empty when the corresponding status is missing. For evaluation, maintain a golden set of override events with known trail completeness states and run this prompt against them weekly to detect drift in model behavior. Track false positive rate (incomplete trails marked complete) as your primary metric—target near zero. Human review is required for any event where the model flags overall_completeness: incomplete and the gap involves regulatory or financial decision types. Route those to the compliance review queue with the full completeness report and linked records attached.

Model choice matters less than schema discipline here. The prompt works with any model that supports structured JSON output, but prefer models with strong instruction-following on classification tasks. If using a model without native JSON mode, append a strict format reminder and validate the output with a JSON schema validator before accepting results. Logging should capture: the prompt version, model identifier, input event IDs, raw output, validation result, and any human review routing decision. This creates its own audit trail for the verification process itself—essential when this pipeline is used for regulatory evidence packaging. Finally, avoid running this prompt on streaming or real-time override events without batching; the verification logic benefits from consistent context and batch processing reduces per-event cost while making pattern detection across events easier for downstream analysis.