Audit Trail Completeness Self-Assessment Prompt

This prompt is designed for compliance teams, audit engineers, and governance stakeholders who need to validate that an existing audit trail meets regulatory completeness standards. It takes a structured audit trail as input and produces a self-assessment report that identifies missing entries, compliance gaps, and false-completeness patterns where entries exist but lack required fields or evidence. Use this prompt when you have a generated audit trail and need a systematic completeness check before submitting it to regulators, internal reviewers, or certification bodies.

This is a post-generation validation step, not a real-time logging prompt. It assumes the audit trail already exists in a structured format and requires human review of its findings before final sign-off. The prompt works best with audit trails that follow a known schema, such as JSON arrays of event objects with timestamp, actor, action, and evidence fields. It is not suitable for unstructured narrative logs, real-time transaction monitoring, or systems where the audit trail schema is undefined. The prompt detects three categories of issues: missing entries (gaps in expected event sequences), incomplete entries (records that exist but lack required fields or evidence), and false-completeness patterns (entries that appear complete but contain placeholder values, circular references, or evidence that does not actually support the recorded action).

Before using this prompt, ensure your audit trail is in a structured format with a defined schema. The prompt requires you to specify the expected schema, required fields, and completeness rules as part of the input. Do not use this prompt as a substitute for real-time logging integrity checks or as the sole validation step before regulatory submission. Always route findings through a human reviewer who can verify flagged gaps, assess materiality, and approve remediation actions. For high-stakes compliance workflows, pair this prompt with the Evidence Chain Assembly Prompt and the Audit-Ready Evidence Package Prompt to create a complete validation and submission pipeline.

This prompt instructs the model to act as a compliance auditor and produce a structured self-assessment of an audit trail's completeness. It is designed for models with strong instruction-following and structured output capabilities. The template requires you to provide the audit trail data, the applicable regulatory standard, and the expected output schema. The prompt includes explicit instructions to detect 'false completeness'—cases where entries exist but lack sufficient detail, provenance, or evidence linkage to satisfy regulatory requirements.

textCopy
You are a senior compliance auditor reviewing an audit trail for regulatory completeness. Your task is to produce a self-assessment report in strict JSON format.

## INPUT
Audit Trail: [AUDIT_TRAIL_DATA]
Regulatory Standard: [REGULATORY_STANDARD]

## OUTPUT SCHEMA
Return a single JSON object with the following structure:
{
  "report_id": "string",
  "assessment_date": "YYYY-MM-DD",
  "standard_applied": "[REGULATORY_STANDARD]",
  "overall_completeness_score": 0-100,
  "findings": [
    {
      "entry_id": "string",
      "requirement": "string",
      "status": "complete | incomplete | false_complete",
      "gap_description": "string | null",
      "remediation": "string | null"
    }
  ],
  "false_completeness_entries": [
    {
      "entry_id": "string",
      "appears_complete": true,
      "missing_elements": ["string"],
      "risk_level": "high | medium | low"
    }
  ],
  "summary": "string"
}

## CONSTRAINTS
1. Classify an entry as "false_complete" if it exists but lacks required detail (e.g., missing actor identity, timestamp precision, evidence hash, or action justification).
2. For every "incomplete" or "false_complete" entry, provide a specific gap_description and actionable remediation.
3. The overall_completeness_score must reflect the proportion of entries that are genuinely complete, penalizing false_complete entries more heavily than missing entries.
4. If the audit trail contains fewer than [MINIMUM_EXPECTED_ENTRIES] entries, flag this as a systemic gap in the summary.
5. Do not invent entries or assume evidence not present in the input.

## EVALUATION CRITERIA
- Every entry in the input audit trail must appear in the findings array.
- False_complete_entries must be a subset of findings with status "false_complete".
- The summary must mention the total entries assessed, the count of each status, and the highest-risk gaps.

Adaptation guidance: Replace [AUDIT_TRAIL_DATA] with the full structured audit log, [REGULATORY_STANDARD] with the specific regulation (e.g., SOC 2, HIPAA, GDPR Article 30), and [MINIMUM_EXPECTED_ENTRIES] with a numeric threshold. If your audit trail uses a different schema, update the entry_id field mapping in the output schema. For high-stakes compliance workflows, route the generated report through a human reviewer before submission. Add a validation step in your application layer that checks the output JSON against the schema and confirms that every input entry appears in the findings array.

This prompt is designed to operate as a post-verification quality gate, not a real-time step. Run it after your primary verification pipeline has produced a batch of audit trail entries, decision logs, or evidence chains. The prompt takes the structured output of those upstream steps as its [AUDIT_TRAIL_ENTRIES] input, along with the [REGULATORY_STANDARD] that defines completeness requirements. It should never be the sole arbiter of compliance; treat its output as a structured self-assessment that flags gaps for human review before external submission.

Pipeline integration: Wire this prompt into a batch processing job that triggers after verification runs complete. The application layer should: (1) collect all audit trail entries from the verification database for the target time window or claim batch; (2) serialize them into the [AUDIT_TRAIL_ENTRIES] JSON array, ensuring each entry includes the fields the prompt expects (claim ID, verdict, evidence references, timestamp, reviewer identity); (3) inject the applicable [REGULATORY_STANDARD] as a structured object with required fields and completeness rules; (4) call the model with response_format set to JSON and the output schema enforced; (5) validate the returned JSON against the expected schema before accepting it. If validation fails, retry once with the validation errors appended to [CONSTRAINTS]. If the retry also fails, escalate to a human reviewer with the raw model output and validation error log attached.

Model choice and temperature: Use a model with strong JSON mode and instruction-following capability (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature to 0 or near-zero to maximize deterministic completeness checks. Avoid smaller or older models that may hallucinate missing-entry flags or fail to produce the completeness-metric and false-completeness detection fields reliably. If you must use a weaker model for cost reasons, add a second-pass validator prompt that independently checks the self-assessment output against the raw audit trail entries and flags discrepancies.

Human review and escalation: The false-completeness detection field is the most critical output for compliance teams. Any entry flagged as potentially falsely complete must route to a human reviewer with the full context packet: the original claim, the audit trail entry, the evidence chain, and the model's explanation of why completeness appears suspect. Build a review queue that prioritizes these flagged entries above routine completeness checks. The completeness-metric score can be used as a dashboard KPI, but never as an automated pass/fail gate without human sign-off when the metric falls below the threshold defined in [REGULATORY_STANDARD].

Logging and traceability: Log every invocation of this prompt with the full input payload, model response, validation result, and any retry attempts. Store these logs alongside the audit trail entries themselves so that an external auditor can trace how each completeness assessment was generated. Include the model version, timestamp, and any human review decisions in the log. This prompt is part of your compliance evidence chain—treat its execution history with the same immutability and retention requirements as the audit trail it assesses.