Entity Extraction with Source Attribution Prompt Template

This prompt is designed for audit, compliance, and legal review teams who need to extract named entities from unstructured text and anchor every extracted entity to its exact source span, sentence, or document section. Use this when downstream consumers require traceable provenance for every fact, when extraction results must survive external audit, or when you need to distinguish between explicitly stated entities and those merely implied by context. This prompt is not a general-purpose NER tool. It is purpose-built for evidentiary extraction where the source citation is as important as the entity itself.

The ideal workflow involves feeding this prompt a single, self-contained document or a clearly delimited section of text. The model is instructed to return a structured list of entities, each with a mandatory source_span (the exact text from which the entity was derived), a source_location (e.g., 'Paragraph 3, Sentence 2'), and an attribution_confidence (explicit vs. inferred). Do not use this prompt for high-throughput, real-time extraction where latency is critical and source tracing is unnecessary; a standard NER model will be faster and cheaper. Similarly, avoid this prompt for analyzing conversational chat logs where the 'document' boundary is ambiguous—prefer a dedicated transcript extraction playbook instead.

Before integrating this prompt into a production pipeline, you must define the evaluation criteria for attribution accuracy. A successful implementation requires a human-annotated golden dataset where every entity is paired with its correct source span. Run this prompt against that dataset and measure Exact Match (EM) on the source spans, not just entity type accuracy. If the model consistently paraphrases the source span instead of quoting it verbatim, you will need to tighten the constraints in the prompt or add a post-processing validation step that checks if the source_span is a substring of the original document. In high-risk domains like legal or financial compliance, always route extractions with attribution_confidence: inferred to a human review queue before they enter any downstream system of record.

This template is the core instruction set for an entity extraction task where every output must be attributable. It is designed to be copied directly into your AI harness, with square-bracket placeholders that you replace with your specific document content, target entity types, and output schema. The prompt enforces a strict contract: no entity should appear in the output without a corresponding source citation, and no source citation should be fabricated.

textCopy
You are an entity extraction system designed for audit and compliance workflows. Your primary directive is to anchor every extracted entity to its exact source span, sentence, or document section. You will be given [INPUT_TEXT] and a list of target entity types defined in [ENTITY_TYPES].

Your task:
1. Identify all mentions of the entity types specified in [ENTITY_TYPES] within [INPUT_TEXT].
2. For each identified entity, extract the exact text span from [INPUT_TEXT] that serves as the primary evidence for the entity.
3. Normalize the entity to its canonical form according to the rules in [NORMALIZATION_RULES]. If no canonical form can be determined, use the mention text.
4. Assign a confidence score between 0.0 and 1.0 for each extraction, following the [CONFIDENCE_RUBRIC].
5. Output the results strictly as a JSON array conforming to [OUTPUT_SCHEMA].

Critical constraints:
- Do not extract an entity if you cannot find an explicit source span in [INPUT_TEXT]. Do not infer entities from context alone.
- For each entity, the `source_span` field must contain a verbatim substring from [INPUT_TEXT]. You must be able to find this exact string in the text.
- If an entity is mentioned multiple times, include a separate entry for each distinct mention, or consolidate them into a single entry with an array of `source_spans` as specified in [OUTPUT_SCHEMA].
- If [INPUT_TEXT] contains no entities of a given type, return an empty array for that type. Do not fabricate entities to fill the schema.
- If the text is ambiguous, set the confidence score accordingly and include a brief `attribution_note` explaining the ambiguity.

[EXAMPLES]

[INPUT_TEXT]: {{document_content}}
[ENTITY_TYPES]: {{entity_types_list}}
[NORMALIZATION_RULES]: {{normalization_instructions}}
[CONFIDENCE_RUBRIC]: {{confidence_criteria}}
[OUTPUT_SCHEMA]: {{json_schema}}

To adapt this template for your own use, replace each placeholder with concrete instructions. The [ENTITY_TYPES] placeholder should contain a clear list like ["PERSON", "ORGANIZATION", "LOCATION", "DATE"]. The [NORMALIZATION_RULES] should specify how to handle variations—for example, "Resolve 'Inc.' and 'Incorporated' to the full legal name if known." The [CONFIDENCE_RUBRIC] is critical for downstream automation; a typical rubric might state: "1.0: Exact match with unambiguous source span. 0.8: Clear match but entity type is slightly ambiguous. 0.5: Multiple possible interpretations exist. Below 0.5: Do not extract." The [OUTPUT_SCHEMA] must be a valid JSON Schema that downstream systems can validate against. The [EXAMPLES] section is optional but strongly recommended for complex entity types or edge cases. After replacing the placeholders, test the prompt against a golden dataset of documents with known entities and source spans to verify that attribution is accurate and no hallucinations occur.

The Entity Extraction with Source Attribution prompt is designed to be a single step within a larger extraction pipeline, not a standalone chat interaction. In production, you will call this prompt for each document or text segment that requires entity extraction. The application layer is responsible for splitting long documents into manageable chunks that fit within the model's context window while preserving sentence boundaries for accurate source attribution. Each chunk should be processed independently, and the application must maintain a mapping of chunk IDs to their original document positions so that extracted spans can be resolved back to absolute offsets or section references in the source document. The prompt expects a [TEXT] input containing the raw text to analyze and an [ENTITY_TYPES] parameter listing the entity categories to extract (e.g., PERSON, ORGANIZATION, LOCATION, DATE). The output is a JSON array of entity objects, each containing the entity type, mention text, canonical form, confidence score, and a source attribution object with the exact text span, sentence index, and character offsets.

Validation must occur immediately after the model response is received and before any extracted entities are written to downstream systems. Implement a JSON schema validator that checks every entity object for required fields (entity_type, mention_text, source_attribution.span_text, source_attribution.offsets). The validator should also confirm that each source_attribution.span_text is a verbatim substring of the original [TEXT] input at the claimed character offsets. If the span text does not match the source text at those offsets, the entity should be flagged for review rather than silently accepted. Additionally, implement a deduplication check: if two extracted entities share the same mention text and entity type within overlapping source spans, merge them or flag the conflict. For high-stakes use cases such as legal contract review or financial filing extraction, route all entities with a confidence score below a configurable threshold (default 0.85) to a human review queue. The review interface should display the original source text with the extracted span highlighted, the model's proposed entity, and a simple accept/reject/edit form.

Retry logic should be applied selectively. If the model response fails JSON parsing entirely, retry once with the same prompt but append a brief repair instruction: The previous output was not valid JSON. Return ONLY a valid JSON array of entity objects. If the retry also fails, log the failure with the raw response and escalate to a human operator. Do not retry more than twice for the same input, as repeated failures often indicate an input quality problem (e.g., garbled text, encoding issues) rather than a transient model error. For partial failures where most entities validate but a few have attribution mismatches, accept the valid entities and route only the failed ones to review. Log every extraction run with the prompt version, model identifier, input hash, output entity count, validation pass/fail status, and any entities sent to review. This audit trail is essential for compliance teams who need to demonstrate that every extracted fact is traceable to its source.

Model choice matters for attribution accuracy. Models with strong instruction-following and JSON mode support (such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro) produce more reliable span offsets than smaller or older models. If you are using a model that does not support structured output or JSON mode natively, increase the retry budget and consider adding a post-processing step that uses fuzzy string matching to locate the claimed span in the source text when exact offset matching fails. For high-volume pipelines, implement batching where multiple text chunks are processed concurrently, but ensure each chunk's validation and review routing is independent so that one bad chunk does not block the entire batch. Finally, treat the prompt template as versioned code: store it in your repository alongside the validation schema, retry configuration, and review queue routing rules. When you update the prompt, run your eval suite against a golden dataset of annotated documents to confirm that attribution accuracy does not regress before deploying the change to production.