Statement Provenance Tracing Prompt

This prompt is designed for a single, high-stakes job: producing a machine-readable map that traces every factual statement in a generated answer back to its exact origin in a source document. The ideal user is a QA engineer, compliance officer, or AI platform architect who needs to prove that an answer is grounded in specific, retrievable evidence, not just that it sounds plausible. The required context is a fully synthesized answer and the complete set of source documents from which it was supposedly derived. The output is not a corrected answer or a simple pass/fail flag; it is a structured provenance map containing document IDs, character offsets, and the verbatim evidence spans that support each claim. This is a post-generation verification step, meaning it runs after an answer is created, and it serves as the auditable evidence foundation for downstream compliance checks, release gates, or regulatory filings.

You should use this prompt when your operational requirements demand full lineage. For example, in a regulated financial audit, a compliance officer might need to prove that a summary of a quarterly report is not just accurate but is mechanically traceable to specific paragraphs in the original filing. The prompt's output, a JSON object mapping each statement to a source_document_id and char_offset, can be stored as an audit artifact. This is distinct from a citation prompt, which might only add a reference number. Here, the goal is to build a verifiable chain of custody for information. The prompt is designed to be integrated into a validation harness where its output schema is strictly checked; if a statement cannot be traced, the system should flag it for human review rather than silently passing it.

Do not use this prompt as a replacement for answer generation or as a real-time citation formatter for a chat UI. It is too expensive and slow for per-token streaming. It is also not a fact-checking prompt; it assumes the source documents are the ground truth and only verifies if a statement is present in them, not if the source itself is correct. Avoid using it when the source documents are poorly chunked or lack stable identifiers, as the character offsets will be unreliable. The next step after understanding this use case is to examine the prompt template itself, where you will see how to structure the input and enforce the required output schema.

This prompt template is designed for audit and compliance workflows where full lineage is non-negotiable. It instructs the model to decompose a provided answer into discrete factual statements and then map each one to a precise location in the source documents, including document identifiers and character offsets. The output is a structured provenance map, not a revised answer. Use this when you need to prove exactly where every claim came from, such as in regulatory filings, legal briefs, or financial reports. Do not use this prompt for general fact-checking or when approximate source attribution is sufficient; it is intentionally exhaustive and will add latency and token cost.

textCopy
You are an audit-grade provenance tracer. Your task is to decompose a provided answer into individual factual statements and trace each one back to its exact source passage in the provided context documents. You must produce a structured provenance map that makes the answer's evidence foundation fully auditable.

## INPUT

**Answer to Trace:**
[ANSWER]

**Source Documents:**
[DOCUMENTS]

Each source document is provided with a unique DOCUMENT_ID and the full text. The text includes character offset markers at the start of each line for precision.

## OUTPUT SCHEMA

Return a JSON object with the following structure:
{
  "provenance_map": [
    {
      "statement_id": "S1",
      "statement_text": "The exact factual claim from the answer.",
      "source_document_id": "DOC-001",
      "source_passage": "The verbatim text from the source that supports this statement.",
      "character_offset_start": 145,
      "character_offset_end": 312,
      "relationship": "direct_support | partial_support | inference",
      "confidence": "high | medium | low",
      "notes": "Optional explanation of the mapping or any ambiguity."
    }
  ],
  "unmapped_statements": [
    {
      "statement_id": "S5",
      "statement_text": "A factual claim with no supporting source found.",
      "search_notes": "Description of where the model looked and why no match was found."
    }
  ]
}

## CONSTRAINTS

1. Decompose the answer into the smallest atomic factual claims. A single sentence may contain multiple statements.
2. For each statement, find the most specific source passage that supports it. Prefer the narrowest span that contains the evidence.
3. Character offsets must be exact and verifiable against the provided source text.
4. If a statement is a direct quote or close paraphrase, mark the relationship as "direct_support". If the source implies the statement but does not state it explicitly, use "inference". If the source supports part but not all of the statement, use "partial_support".
5. If no source passage supports a statement, place it in `unmapped_statements`. Do not guess or fabricate sources.
6. Do not alter the answer text. You are tracing, not editing.
7. If the source documents contain conflicting information for a statement, note the conflict in the `notes` field and include all relevant source passages as separate entries.

## EXAMPLES

**Example Statement:** "The company reported revenue of $4.2 billion in Q3 2024."
**Source Passage:** "Third-quarter revenue reached $4.2 billion, a 12% increase year-over-year."
**Output:**
{
  "statement_id": "S1",
  "statement_text": "The company reported revenue of $4.2 billion in Q3 2024.",
  "source_document_id": "EARNINGS-2024-Q3",
  "source_passage": "Third-quarter revenue reached $4.2 billion, a 12% increase year-over-year.",
  "character_offset_start": 245,
  "character_offset_end": 312,
  "relationship": "direct_support",
  "confidence": "high",
  "notes": "Exact match on the revenue figure and quarter."
}

## RISK LEVEL

**HIGH.** This prompt is used in audit and compliance contexts. Incorrect provenance mappings can lead to regulatory findings, legal liability, or financial misstatements. Always validate a sample of mappings manually before relying on this output for critical decisions.

To adapt this prompt, replace [ANSWER] with the generated text you need to audit and [DOCUMENTS] with your retrieved context, ensuring each document includes a unique ID and character offset markers. The output schema is designed to be machine-readable for downstream automation, such as populating an audit dashboard or triggering a review workflow when unmapped_statements is non-empty. If your source documents do not have character offsets, you can remove those fields from the schema and rely on document ID and passage text alone, but this reduces precision and auditability.

Before deploying this prompt in production, build a validation harness that checks the output JSON against the schema, verifies that character offsets are within bounds, and confirms that statement_text values are substrings of the original answer. For high-stakes use cases, implement a human review step for any statement marked with confidence: low or relationship: inference. The most common failure mode is the model hallucinating source passages or offsets that look plausible but do not exist in the provided documents; always run a programmatic verification of source_passage against the original document text before accepting the provenance map.

The Statement Provenance Tracing Prompt is not a casual chat instruction; it is a deterministic audit tool. It should be deployed as a post-generation verification step within a RAG pipeline, triggered only after a final answer has been synthesized and before it is delivered to the user or logged to an immutable audit store. The harness must treat the prompt as a strict contract: it expects a generated answer and the full set of retrieved source documents (with IDs and character offsets) as input, and it must produce a machine-readable provenance map. Because this workflow is designed for compliance use cases, the implementation must prioritize reproducibility and failure visibility over low latency. The model call should be synchronous in the critical path, with a strict timeout, and any failure to produce a valid provenance map should block the answer from being surfaced.

To wire this into an application, start by constructing the input payload. The [ANSWER] placeholder must receive the exact text that was generated in the previous step, with no truncation or normalization. The [SOURCES] placeholder requires a structured JSON array where each object includes a unique document_id, the full text of the retrieved chunk, and the char_offset range within the parent document. If your retrieval system does not track character offsets, you must add them before invoking this prompt; without precise offsets, the provenance map cannot be audited. The model should be instructed to return a strict JSON schema—an array of objects, each containing a statement string, a source_document_id, and a char_range array of [start, end]. Implement a JSON schema validator in your application layer immediately after the model response. If parsing fails, retry once with a stricter prompt variant that includes the raw model error message. If the retry also fails, log the full payload and escalate for human review rather than silently dropping the provenance check.

For high-risk audit and compliance deployments, you must go beyond schema validation. Implement a secondary verification step that checks whether the char_range offsets in the provenance map actually exist in the referenced source document and that the extracted substring matches the claimed statement. This prevents the model from hallucinating plausible but incorrect offsets. Additionally, compare the set of statements in the provenance map against the original answer using a text segmentation diff; any statement in the answer that is missing from the provenance map represents an untraced claim and must be flagged. Log every provenance map alongside the answer, the source documents, the model version, and the prompt template version in an append-only audit store. Do not rely on the model's internal confidence; the harness is the source of truth for whether tracing succeeded. Finally, expose a monitoring metric that tracks the percentage of answers with complete provenance coverage, and set an alert threshold below 100%—any gap is a potential compliance violation.