Inline Citation Span Selection Prompt

This prompt is for RAG application engineers who need to render inline citations. Given a generated answer and the source documents that were used to produce it, the prompt instructs the model to select the minimal evidence spans that ground each sentence. The output is a sentence-to-span mapping that can be consumed by a citation rendering component. Use this prompt when your product requires users to see exactly which source text supports each claim, such as in legal research, medical literature review, financial analysis, or any application where auditability matters.

The ideal workflow feeds this prompt after answer generation, not during it. You already have a complete answer and a set of retrieved documents. The prompt's job is to trace each sentence back to the smallest supporting text span, not to rewrite the answer or re-rank the documents. This separation keeps answer generation and citation selection as distinct, testable steps. The prompt expects a specific input shape: a full answer text and a list of source documents with identifiers. If your system cannot provide both, this prompt will fail. Do not use this prompt when the answer is a creative synthesis, when source documents are not available, or when the model is expected to generate citations without access to the original retrieved context.

Before adopting this prompt, verify that your application actually needs sentence-level span mappings. If your users only need document-level references or a simple source list, a lighter-weight citation prompt will be cheaper and less error-prone. This prompt adds latency and token cost proportional to answer length and document count. It also introduces a new failure mode: hallucinated span boundaries that point to text that does not actually support the sentence. You must pair this prompt with a validation harness that checks span existence, boundary accuracy, and support faithfulness before citations reach users. In regulated domains, add human review for any citation confidence below your threshold. If your latency budget cannot absorb the extra model call, consider pre-computing citation mappings or using a smaller, fine-tuned span selection model instead.

This template is the core instruction set for the Inline Citation Span Selection workflow. It takes a pre-generated answer and a set of source documents, then returns a structured mapping of each answer sentence to the minimal text spans that support it. Copy this prompt into your prompt layer, replace each square-bracket placeholder with application data, and wire it into your RAG pipeline after answer generation but before rendering the response to the user.

textCopy
You are an evidence grounding specialist. Your task is to select the minimal evidence spans from the provided source documents that directly support each sentence in the given answer.

## INPUT

**Answer:**
[ANSWER_TEXT]

**Source Documents:**
[DOCUMENTS]

## INSTRUCTIONS

1. For each sentence in the answer, identify the minimal contiguous text span(s) from the source documents that provide direct support.
2. A supporting span must contain the factual basis for the claim made in the sentence. Do not select spans that are merely topically related.
3. Prefer the shortest span that fully supports the claim. Avoid including extraneous surrounding text.
4. If multiple spans from different documents support the same sentence, include all of them.
5. If no span in any source document supports a sentence, mark that sentence as ungrounded.
6. Do not fabricate spans. Only use exact text present in the provided source documents.
7. Preserve the original text of each span exactly, including any formatting artifacts from the source.

## OUTPUT SCHEMA

Return a JSON object with this structure:
{
  "sentence_spans": [
    {
      "sentence_index": 0,
      "sentence_text": "<exact text of the answer sentence>",
      "spans": [
        {
          "document_id": "<source document identifier>",
          "span_text": "<exact supporting text from source>",
          "span_start": <character offset start>,
          "span_end": <character offset end>,
          "relevance": "<direct_support | partial_support | tangential>"
        }
      ],
      "grounding_status": "<grounded | partially_grounded | ungrounded>"
    }
  ],
  "ungrounded_sentence_count": <integer>,
  "total_sentence_count": <integer>
}

## CONSTRAINTS

[CONSTRAINTS]

## EXAMPLES

[EXAMPLES]

## RISK LEVEL

[RISK_LEVEL]

Adaptation guidance: Replace [ANSWER_TEXT] with the full generated answer string. Replace [DOCUMENTS] with a serialized list of source documents, each including a unique document_id and the full document text. Use [CONSTRAINTS] to add domain-specific rules such as minimum span length, required metadata fields, or handling of conflicting sources. Use [EXAMPLES] to provide few-shot demonstrations of correct span selection, especially for edge cases like partial support or conflicting evidence. Set [RISK_LEVEL] to high if the output drives user-facing citations without human review, which triggers additional validation requirements in the harness. After copying this template, test it against a golden dataset of answer-sentence-to-span mappings before deploying to production.

The Inline Citation Span Selection Prompt is designed to sit between answer generation and citation rendering in a RAG pipeline. Its job is narrow: given a generated answer and the source documents that were provided to the answer-generation step, it maps each sentence in the answer to the minimal evidence spans that ground it. This means the prompt should receive the exact same source documents that the answer model saw, not a re-retrieved set. Any mismatch between the answer's context window and the citation prompt's input will produce hallucinated citations or missed grounding. Wire this prompt as a post-processing step that runs before citations are rendered to the user, and treat its output as the single source of truth for which spans appear as inline references.

The implementation harness needs four components: input assembly, model invocation, output validation, and a retry-or-escalate decision. For input assembly, construct the prompt with the full answer text in [ANSWER], the source documents in [SOURCE_DOCUMENTS] with stable identifiers (chunk IDs, paragraph numbers, or URL anchors), and a clear [OUTPUT_SCHEMA] specifying the expected JSON structure with sentence index, source document ID, and character-level span boundaries. Validate the output against this schema immediately: check that every span reference resolves to a real document ID, that character offsets fall within the referenced document's text, and that no sentence is left ungrounded unless the model explicitly marks it as unsupported. If validation fails, retry once with the validation errors injected into [CONSTRAINTS] as explicit correction instructions. If the retry also fails, escalate to a human review queue rather than silently rendering broken citations.

Model choice matters for span boundary accuracy. Use a model with strong instruction-following and precise text extraction capabilities. Lower-latency models may truncate spans or hallucinate offsets, especially with long source documents. If you observe boundary drift in production, add a post-processing step that fuzzy-matches the extracted span text against the source document to correct minor offset errors. Log every citation selection event with the answer text, source document IDs, extracted spans, and validation results. This audit trail is essential for debugging hallucinated citations and for defending the system's outputs in regulated or high-stakes domains. For cost control, consider batching multiple answers against the same source set when the document context is shared across a user session.

The most common production failure mode is the model inventing plausible-looking but non-existent spans when the answer contains claims not supported by the provided documents. Your validation harness must detect this by verifying that the extracted span text exactly matches a substring in the referenced source document. A second failure mode is over-citation, where the model maps a sentence to an entire paragraph instead of the minimal grounding span. Mitigate this by including explicit span-length constraints in [CONSTRAINTS] and by running a post-processing check that flags spans exceeding a character or sentence threshold for human review. A third failure mode is citation omission, where the model silently skips sentences it cannot ground. Your output schema should require an explicit grounding_status field per sentence with values like grounded, unsupported, or partial to make omissions visible and auditable.

Before shipping, build a regression test suite with at least 50 answer-document pairs that include known grounded claims, known unsupported claims, and edge cases like answers that summarize multiple documents in a single sentence. Measure span boundary accuracy (character-level F1 against human-annotated spans), hallucinated citation rate (percentage of spans that don't match source text), and omission recall (percentage of unsupported claims the model correctly flagged). Run these evals on every prompt or model version change. If your application serves user-facing citations in a regulated domain, require human review of citation outputs for at least the first month of production and maintain a feedback loop where corrected citations are added to your few-shot examples in [EXAMPLES].

When the prompt is working reliably, the harness should still monitor for drift. Track the distribution of span lengths, the rate of unsupported markings, and the frequency of validation failures over time. A sudden increase in unsupported markings may indicate retrieval degradation upstream. A rise in validation failures may signal a model version change or prompt drift. Wire these metrics into your production monitoring dashboard alongside answer quality metrics so that citation grounding quality is visible and actionable, not an afterthought.