Tool Output Citation and Source Attribution Prompt Template

This prompt is for compliance engineers, governance teams, and AI platform builders who need every factual claim in a user-facing response to be traceable back to a specific field or record in a structured tool output. Use it when your system must produce auditable answers for regulated domains, internal policy enforcement, or customer-facing transparency where unsupported claims create liability. The prompt forces the model to act as a strict translator: it can only state facts that are explicitly present in the provided tool output and must cite the exact source path for each claim.

The ideal input is a structured JSON or tabular tool result where field-level attribution is possible—think database query results, API response objects, or typed configuration records. The user's question and the raw tool output are both required. Without both, the prompt cannot enforce its core contract. Do not use this prompt for creative generation, open-ended analysis, or when the tool output is already a natural language summary that the model should paraphrase. It is also a poor fit when the tool output is a single unstructured text blob with no clear field boundaries, because the model will struggle to produce precise $.path.to.field citations.

Before adopting this prompt, verify that your tool output schema is stable and well-documented. If field names change frequently or contain internal identifiers that users cannot interpret, the citations will confuse rather than assure. Pair this prompt with a validation harness that checks every claim for a corresponding source path and flags unattributed statements. In high-risk domains, route flagged outputs to human review before they reach the user. Start with a narrow set of trusted tools and expand only after you have measured the false-positive rate on unattributed-claim detection.

This template is designed for compliance and governance workflows where every factual claim in a user-facing response must be traceable to a specific field, record, or value in the tool output. It is not a general summarization prompt—it is a citation enforcement contract. Use it when your system must produce auditable answers for regulators, internal reviewers, or downstream systems that require source attribution. Do not use this prompt when the tool output is purely structural metadata, when latency requirements prohibit verbose citations, or when the user explicitly requests a conversational summary without inline references.

textCopy
You are an auditable AI assistant. Your task is to produce a user-facing response where every factual claim is explicitly linked to a specific field, record, or value in the provided tool output.

## INPUT
Tool Output:
```json
[TOOL_OUTPUT]

User Query: [USER_QUERY]

OUTPUT REQUIREMENTS

1. Produce a response in [OUTPUT_FORMAT] that directly answers the user query.
2. For every factual claim in your response, append a citation in the format [CITATION_FORMAT] that references the exact field path, record index, or value from the tool output.
3. If the tool output contains multiple records, cite the specific record index or identifier for each claim.
4. If a claim synthesizes information from multiple fields, cite every source field.
5. If the tool output does not contain information needed to answer the query, state that explicitly and do not invent or infer information.
6. Do not cite fields that do not exist in the tool output.
7. Do not paraphrase a citation source in a way that changes its meaning.

CONSTRAINTS

• Maximum response length: [MAX_LENGTH]
• Required citation coverage: Every sentence containing a factual claim must have at least one citation.
• Prohibited: Unattributed claims, inferred data, external knowledge, placeholder citations.
• If [REQUIRE_CONFIDENCE] is true, include a confidence indicator [CONFIDENCE_FORMAT] for each claim based on the clarity and completeness of the source field.

EXAMPLES

[FEW_SHOT_EXAMPLES]

OUTPUT

To adapt this template, replace each square-bracket placeholder with your specific values. [TOOL_OUTPUT] should be the raw JSON or structured output from your tool call, injected programmatically—never hardcoded. [CITATION_FORMAT] is the most critical design decision: choose a format that your downstream audit system can parse, such as [source: field.path, record: index] or a structured inline marker. [FEW_SHOT_EXAMPLES] should include at least one example where the tool output is partially relevant and the model correctly abstains from answering the uncovered portion, and one example where a claim requires multiple source fields. If you omit [FEW_SHOT_EXAMPLES], expect higher rates of misattribution and format drift. Before deploying, run eval checks for unattributed claims, citations pointing to nonexistent fields, and claims that paraphrase a source field into a materially different statement. For high-risk domains, route outputs with citation coverage below 100% to human review.

This prompt template is designed to be called after a tool has executed and returned a structured result. The application layer must first capture the raw tool output, the tool's name, and the original user query. These three pieces of data are injected into the prompt's [TOOL_OUTPUT], [TOOL_NAME], and [USER_QUERY] placeholders respectively. The model's response is a user-facing message where every factual claim is linked to a specific field or record path within the provided tool output. Do not use this prompt for open-ended generation or for summarizing outputs from tools that return unstructured free text; it is specifically designed for structured JSON or tabular tool results where field-level attribution is possible.

Validation and Retry Logic: The application must parse the model's output and validate it against a strict schema before showing it to the user. The expected output is a JSON object with a claims array, where each claim has a statement, source_field (the exact JSONPath or column name), and source_value. A post-processing validator should check that every source_field actually exists in the original [TOOL_OUTPUT] and that the source_value matches the value at that path. If validation fails, the application should retry the prompt once with the validation error appended to the [CONSTRAINTS] block, instructing the model to correct the misattribution. After a second failure, the system must escalate to a human review queue and log the raw tool output, the failed model response, and the validation error for diagnosis. Never surface an unattributed claim to the user.

Logging and Audit Trail: Every invocation of this prompt must produce an audit record. Log the [TOOL_NAME], a hash of the [TOOL_OUTPUT], the full model response, and the validation result. This audit trail is essential for compliance and governance teams who need to trace any user-facing statement back to the originating system of record. For high-risk domains, consider storing the audit record immutably and linking it to the user session. The model choice should favor models with strong instruction-following and structured output capabilities; GPT-4o and Claude 3.5 Sonnet are suitable defaults. Avoid smaller or older models that are prone to hallucinating field names or fabricating source paths under attribution pressure. If the tool output is large, pre-process it to extract only the fields relevant to the user query before passing it to the prompt, reducing the risk of the model citing unrelated data.