Audit Trail Narrative Generation Prompt

This prompt is for auditors, compliance officers, and governance teams who need a prose narrative explaining what was checked, how it was checked, and why each verdict was reached. It takes structured verification logs—claim-by-claim records with evidence, verdicts, and confidence scores—and produces a human-readable audit trail suitable for non-technical stakeholders, regulators, or board-level review. The core job-to-be-done is translating machine-actionable verification data into an explainable narrative that preserves factual accuracy, acknowledges uncertainty, and cites source evidence without introducing new claims or interpretations.

Use this prompt when you have completed upstream fact-checking and possess a structured log containing at minimum: a claim identifier, the claim text, the evidence consulted, the verdict (e.g., Supported, Contradicted, Unsupported), and a confidence score. The prompt is designed for workflows where the verification engine has already run and the remaining task is communication. It is not a fact-checking prompt itself—it does not retrieve evidence, compare claims to sources, or assign verdicts. Attempting to use it as a verification step will produce plausible-sounding but ungrounded narratives. The ideal input is a JSON array of verification records, each with fields like claim_id, claim_text, evidence_summary, source_citation, verdict, confidence, and verification_timestamp.

Do not use this prompt when the verification records are incomplete, when confidence scores are missing, or when evidence citations are absent. The narrative will faithfully reflect gaps in the input, which can mislead readers into thinking a claim was verified when the underlying data is insufficient. For high-risk domains such as financial compliance or healthcare, always pair this prompt with a completeness validator that checks every input record for required fields before generation. If the input log contains contradictory verdicts for the same claim, resolve those contradictions upstream—this prompt will not reconcile them. The next step after reading this section is to review the prompt template and implementation harness to understand how to wire this into a production verification pipeline with appropriate validation and human review gates.

This prompt template transforms structured verification data—claim records, evidence chains, verdicts, and confidence scores—into a prose narrative suitable for auditors, compliance officers, and business stakeholders who need to understand what was checked, how it was checked, and why each conclusion was reached. The template expects pre-processed verification logs as input and produces a narrative that traces the fact-checking journey from claim to evidence to verdict, with explicit handling of uncertainty and unsupported claims. Replace each square-bracket placeholder with actual data before sending to the model. The output should read like a professional audit memo, not a technical log dump.

textCopy
You are an audit documentation specialist. Your task is to convert a structured verification log into a clear, human-readable audit trail narrative. The narrative must explain what was checked, how it was checked, what evidence was used, and why each conclusion was reached. Write for an audience of auditors, compliance officers, and non-technical stakeholders who need to understand the verification process without reading raw logs.

## INPUT

### Claims Verified
[CLAIMS_DATA]

### Evidence Sources Consulted
[EVIDENCE_SOURCES]

### Verification Methodology
[METHODOLOGY_DESCRIPTION]

### Verdicts and Confidence Scores
[VERDICTS_AND_CONFIDENCE]

### Unsupported or Unresolved Claims
[UNSUPPORTED_CLAIMS]

### Contradictions and Conflicts Found
[CONTRADICTIONS]

### Reviewer Identity and Timestamp
[REVIEWER_INFO]

## OUTPUT REQUIREMENTS

Produce a narrative with these sections, in order:

1. **Executive Summary**: A 2-3 sentence overview of what was verified, the total number of claims checked, and the overall outcome distribution (supported, contradicted, unsupported).

2. **Methodology Overview**: A plain-language description of how claims were extracted, what evidence sources were consulted, how matching was performed, and how confidence was assigned. Do not use technical jargon.

3. **Claim-by-Claim Narrative**: For each claim, provide:
   - The claim as stated in the source material
   - What evidence was found (or not found)
   - How the evidence supports or contradicts the claim
   - The final verdict and confidence level
   - If unsupported, explain what evidence was sought and why it was insufficient

4. **Contradictions and Conflicts**: Describe any conflicting evidence found, compare source authority, and explain how conflicts were resolved or escalated.

5. **Unsupported Claims Summary**: List all claims that could not be verified, explain the evidence gap for each, and note whether additional sources or human review are recommended.

6. **Review and Sign-Off**: State who performed the verification, when it was completed, and what methodology was followed. Include a statement that this narrative was generated from structured verification logs and should be reviewed by a human before final submission.

## CONSTRAINTS

- Do not invent evidence, sources, or conclusions not present in the input data.
- When evidence is missing or insufficient, state that clearly rather than implying certainty.
- Use precise language: "the evidence supports the claim" not "the claim is true."
- Preserve all source citations and provenance information from the input.
- Flag any claims where the input data appears incomplete or contradictory.
- If [RISK_LEVEL] is "high," add a prominent notice that human review is required before this narrative is used for regulatory or legal purposes.

## OUTPUT FORMAT

Return the narrative as plain text with section headers in markdown (## Section Name). Use bullet points for claim-by-claim details where helpful for readability. Do not return JSON.

Adaptation guidance: Replace [CLAIMS_DATA] with a structured list of claims extracted from source content, each with a unique identifier and original context. [EVIDENCE_SOURCES] should contain the full set of evidence documents, passages, or records consulted, with source identifiers and retrieval metadata. [METHODOLOGY_DESCRIPTION] must describe the actual verification process used—claim extraction method, evidence retrieval approach, matching logic, and confidence scoring rules. [VERDICTS_AND_CONFIDENCE] requires the per-claim verdict (supported/contradicted/unsupported) and calibrated confidence score. [UNSUPPORTED_CLAIMS] and [CONTRADICTIONS] should be populated from upstream detection steps. [REVIEWER_INFO] captures the system, model version, or human operator responsible. [RISK_LEVEL] accepts "low," "medium," or "high" and controls whether a human-review notice is injected. Before sending to the model, validate that all placeholders contain actual data—empty inputs will produce a narrative that incorrectly reports zero findings. After generation, validate the output against the source logs: every claim mentioned must exist in the input, every verdict must match, and no evidence should be fabricated. For high-risk use cases, route the generated narrative to a human reviewer with the source logs attached for side-by-side verification.

The audit trail narrative prompt is designed to sit at the end of a structured verification pipeline, consuming a machine-readable verification log and producing a human-readable prose summary. This prompt is not a standalone tool; it requires a pre-existing structured input—typically a JSON array of claim verification records, each containing the claim text, evidence sources, verdict, confidence score, and reviewer identity. The implementation harness must enforce this input contract before the prompt is ever called, rejecting malformed or incomplete logs at the application layer rather than relying on the model to catch missing fields.

Wire the prompt into your application as a post-processing step within a verification workflow orchestrator. The typical flow is: (1) the upstream pipeline produces a structured verification log conforming to a strict schema; (2) a validation layer checks that every required field is present, that verdicts are from an allowed enum (SUPPORTED, CONTRADICTED, INSUFFICIENT_EVIDENCE, NOT_CHECKED), and that evidence entries include source identifiers and relevance notes; (3) the validated log is serialized into the [VERIFICATION_LOG] placeholder of the prompt template; (4) the model generates the narrative; (5) a post-generation validation step checks the output for factual consistency against the source log—specifically, that no claim is described with a verdict or evidence that differs from the structured input. If the output fails this consistency check, retry with a more explicit instruction or escalate for human review. For high-stakes audit contexts, always route the final narrative to a human reviewer before it reaches an external auditor or regulator.

Model choice matters here. Use a model with strong instruction-following and long-context handling, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Set the temperature low (0.0–0.2) to minimize creative drift from the source log. Implement retry logic with a maximum of two attempts: if the first output fails the factual-consistency validator, append the validation errors to a retry prompt that says 'The previous output contained factual errors compared to the source log. Regenerate the narrative and correct these specific discrepancies: [ERRORS].' If the second attempt also fails, log the failure, attach both outputs and the source log, and route to a human reviewer with a clear note about which claims were misrepresented. Do not loop indefinitely—two retries is the ceiling before escalation.

Logging and observability are non-negotiable for audit trail generation. Every invocation should produce a trace record containing: the prompt version, model identifier, input log hash, output narrative, validation results, retry count, and final disposition (passed, failed, escalated). Store these traces in an append-only log for downstream auditability. If your system uses a model gateway or observability platform, tag these traces with workflow=audit-trail-narrative and risk=high to ensure they surface in compliance reviews. Avoid caching narrative outputs across different input logs—each log is unique, and caching risks serving stale or incorrect narratives to auditors.

When integrating with human review queues, package the narrative alongside the structured verification log and a diff highlighting any claims where the narrative diverged from the source data. This makes the reviewer's job faster and reduces the chance they approve an inaccurate narrative. Finally, treat the prompt template itself as versioned configuration: store it in a prompt registry, tag releases, and run regression tests against a golden set of verification logs before deploying changes. A prompt that silently changes how it describes 'INSUFFICIENT_EVIDENCE' claims can create audit findings downstream.