Evidence Conflict Audit Trail Prompt Template

This prompt is for compliance engineers and audit workflow builders who need a machine-readable, step-by-step record of how an AI system detected, analyzed, and resolved conflicting evidence. The primary job-to-be-done is producing a traceable decision record that can be stored in an audit log, reviewed by a human, or submitted as part of a regulatory filing. It is not designed for generating user-facing answers, summaries, or conversational responses. The ideal user is someone integrating AI into a governed workflow where every evidence-handling decision must be explainable to an internal or external reviewer.

Use this prompt when you have already identified a set of conflicting source passages—through retrieval, upstream detection, or human escalation—and need to produce a structured audit trail. The prompt assumes the inputs include the original query or claim, the conflicting passages with source metadata, and any applicable resolution policies or risk classifications. It is appropriate for regulated domains such as financial compliance, clinical documentation review, legal evidence management, and safety-critical decision support. The output is a structured record containing conflict identification, analysis steps, resolution rationale, and traceable links back to source passages.

Do not use this prompt when you need a real-time answer for an end user, when the conflict is trivial or already resolved by a simple rule, or when the system lacks access to the original source passages. This prompt is also inappropriate for generating speculative explanations about why sources disagree—it must ground every statement in the provided evidence. If your workflow requires a balanced summary of conflicting positions for a decision memo, use the Conflicting Evidence Summary Prompt instead. If you need to classify the type of disagreement before producing an audit trail, run the Source Disagreement Classification Prompt first and feed its output into this template. The next section provides the copy-ready prompt template you can adapt for your evidence conflict audit workflow.

This prompt template produces a structured audit record when your system detects conflicting evidence across multiple sources. It forces the model to document each conflict, the resolution decision, the reasoning behind that decision, and explicit links back to source passages. The output is designed to be machine-readable for downstream compliance systems and human-readable for review queues. Use this template when you need a verifiable record of how your AI system handled contradictory information—not just what it decided, but why.

textCopy
You are an evidence audit trail generator. Your task is to produce a structured, traceable record of how conflicting evidence was detected, analyzed, and resolved. Every claim in your output must be grounded in the provided source passages.

## INPUTS

### Source Passages
[SOURCE_PASSAGES]
<!-- Array of source objects, each with: source_id, source_label, passage_text, authority_score, recency_date -->

### Detected Conflicts
[DETECTED_CONFLICTS]
<!-- Array of conflict objects, each with: conflict_id, claim_in_dispute, source_ids_supporting, source_ids_opposing, conflict_type, severity_score -->

### Resolution Policy
[RESOLUTION_POLICY]
<!-- String describing the resolution rules: e.g., "prefer most recent source," "defer to highest authority score," "present both sides with uncertainty," "escalate if severity >= 0.7" -->

### Output Schema
[OUTPUT_SCHEMA]
<!-- JSON schema or field specification for the audit record -->

### Constraints
[CONSTRAINTS]
<!-- Additional constraints: e.g., "max 3 sentences per resolution rationale," "include exact quote spans," "flag unresolved conflicts for human review" -->

## INSTRUCTIONS

For each conflict in [DETECTED_CONFLICTS], produce an audit entry that includes:

1. **Conflict Summary**: Restate the claim in dispute and identify which sources support versus oppose it. Use exact source_ids from [SOURCE_PASSAGES].

2. **Evidence Extraction**: For each source involved, extract the specific passage text that supports or opposes the claim. Quote the relevant span verbatim and include the source_id and passage offset if available.

3. **Resolution Decision**: Apply [RESOLUTION_POLICY] to determine how this conflict should be resolved. State the decision clearly: which position is adopted, whether both are presented, or whether the conflict is escalated.

4. **Resolution Rationale**: Explain why this resolution was chosen, referencing the policy rule applied, the authority scores, recency dates, or other factors from [SOURCE_PASSAGES]. If the policy requires escalation, explain which threshold was exceeded.

5. **Unresolved Flag**: Set to true if the conflict could not be resolved under the policy and requires human review. Set to false if a resolution was reached.

6. **Traceability Links**: For every claim in your audit entry, provide a back-reference to the specific source_id and passage span that supports it. If you cannot ground a statement in the provided passages, do not include it.

## OUTPUT FORMAT

Return a JSON object matching [OUTPUT_SCHEMA]. Every field must be populated. If a field cannot be populated from the provided evidence, use null and include a note in the "gaps" array explaining what was missing.

## CRITICAL RULES

- Do not invent evidence. If a source does not contain information needed for a field, mark it as null.
- Do not resolve conflicts by ignoring opposing evidence. Every conflicting source must be accounted for in the audit entry.
- If [RESOLUTION_POLICY] is ambiguous for a given conflict, escalate rather than guess.
- Preserve exact quotes. Do not paraphrase when extracting evidence spans.

Adaptation guidance: Replace each square-bracket placeholder with live data from your conflict detection pipeline before sending to the model. [SOURCE_PASSAGES] should be populated from your retrieval or evidence store, including authority scores and recency metadata if your resolution policy depends on them. [DETECTED_CONFLICTS] should come from an upstream conflict detection prompt or classifier—do not ask this prompt to both detect and audit conflicts, as combining those tasks degrades audit quality. [RESOLUTION_POLICY] must be a concrete, executable rule set, not a vague guideline; ambiguous policies produce inconsistent audit trails. [OUTPUT_SCHEMA] should be a strict JSON schema that your downstream compliance system can validate. If you are operating in a regulated domain, add a human review step after audit generation and before the audit record is finalized.

What to do next: After pasting this template into your application, build a validation layer that checks every traceability link against the original source passages. The most common failure mode is the model generating plausible-sounding rationales that reference source details not actually present in the provided text. Run this prompt against a golden set of known conflicts with expected resolutions, and measure whether the audit trail correctly identifies which sources support which positions and whether resolution decisions follow your policy. If your resolution policy involves numerical thresholds, test boundary cases where scores are close to the threshold to ensure consistent escalation behavior.

The Evidence Conflict Audit Trail prompt is designed to be the final, record-producing step in a multi-stage evidence pipeline. It should not be called in isolation. Before invoking this prompt, your application must already have: (1) a set of retrieved passages from your knowledge base or document corpus, (2) a specific claim or question being evaluated, and (3) the output of a conflict detection step that has identified which passages disagree and on what points. The audit trail prompt consumes these structured inputs and produces a machine-readable audit record. This record is the compliance artifact—it must be stored immutably, linked to the originating request, and never regenerated without explicit versioning.

Integration pattern: Wire this prompt as a post-processing step after your conflict detection model returns structured contradictions. The typical call sequence is: retrieve → detect_conflicts → generate_audit_trail → validate_audit → store. The prompt expects a JSON input object containing [CLAIM], [CONFLICTING_PASSAGES] (an array of objects with passage_id, source_document, excerpt, and position), [CONFLICT_TYPE] (the classification from your detection step), and [RESOLUTION_POLICY] (the rule your system applied, e.g., 'prefer_higher_authority', 'present_both', 'escalate'). The output schema should be enforced with structured output mode or a strict JSON schema validator. Model choice: Use a model with strong instruction-following and JSON mode support (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller models for this task—audit completeness requires precise extraction and no hallucinated passage IDs.

Validation and retries: After generation, run a validation step that checks: (a) every passage_id in the audit output exists in the input, (b) no fabricated quotes appear (compare excerpt strings against source passages), (c) the resolution_decision field is non-empty and matches one of your allowed resolution types, and (d) the traceability_chain array contains at least one entry per conflict. If validation fails, retry once with the validation errors appended as [CONSTRAINTS]. If the second attempt fails, log the failure, flag the record for human review, and do not store an invalid audit trail. Logging: Log the full prompt, response, validation result, and any retries to your observability platform. Include a trace_id that links the audit record back to the originating user request and evidence retrieval query.

Human review gates: For high-severity conflicts (where conflict_severity is 'high' or the resolution policy is 'escalate'), route the generated audit trail to a review queue before finalizing. The reviewer should confirm that the resolution reasoning is sound and that no evidence was misrepresented. Once approved, the audit record should be signed with the reviewer's identity and timestamp. Storage: Store audit records in an append-only database or log. Never overwrite an existing audit trail—if a conflict is re-evaluated later (e.g., because new evidence arrives), generate a new audit record with a new audit_id and a reference to the prior record. This preserves the chain of decisions for compliance review. What to avoid: Do not use this prompt to make the resolution decision itself—that should happen in a prior step with its own validation. Do not skip the excerpt-matching validation step; fabricated quotes in an audit trail are a compliance failure. Do not regenerate audit trails on the same inputs without explicit version tracking.