Information Provenance
PatternsDefinition
The tracking of which source each piece of information in an agent's output came from. Critical for multi-source agents where conflicting data must be attributed. Preserved via claim-source mappings that travel with data through the pipeline.
Example Usage
Tag each extracted claim with its source document ID so downstream agents can resolve contradictions by referencing original sources.
In Depth
The Core Problem: Multi-Source Pipelines Lose the Trail
When an agent synthesizes information from multiple tools, documents, or subagents, the final output is a blend of claims from different sources — some reliable, some outdated, some potentially contradictory. Without provenance tracking, that blend is opaque: a human reviewer sees a claim in the output but cannot determine whether it came from the authoritative database, the user's uploaded document, or a web search result from three years ago.
Information provenance solves this by requiring every claim to carry a machine-readable source tag that travels with the data through the entire pipeline. The tag does not disappear when data is transformed, summarized, or forwarded between agents.
The Claim-Source Mapping Pattern
The canonical provenance implementation attaches a source_id to every extracted claim at the point of extraction, before any transformation:
{
"claim": "Contract expires on 2026-03-31",
"source_id": "doc_7f3a",
"source_type": "uploaded_pdf",
"page": 4,
"extraction_confidence": 4
}This structure must survive all downstream transformations. When the analysis agent summarizes ten claims into a paragraph, the paragraph must link back to the source IDs it drew from. When the coordinator merges outputs from parallel subagents, it must preserve each claim's origin, not flatten them into a merged object.
Conflict Resolution: Provenance as Arbiter
The most important use of provenance is conflict resolution. When two sources disagree on a fact, provenance data tells the system which source is more authoritative without requiring a human to re-locate the original documents. Design a source-priority hierarchy into your pipeline:
| Priority | Source Type | Rationale |
|---|---|---|
| 1 | Internal authoritative database (real-time) | Single source of truth |
| 2 | User-uploaded signed document | Contractually binding |
| 3 | Internal knowledge base (indexed) | Recent but not real-time |
| 4 | Web search results | May be outdated |
When the extraction agent detects that source_id: doc_7f3a and source_id: db_account_42 disagree, it can apply this hierarchy automatically and flag the conflict with both values preserved — rather than silently picking one.
What Provenance Is Not
Provenance is not citation formatting for user-facing output. That is a presentation concern. Provenance is a *pipeline engineering* concern: the internal bookkeeping that makes conflict resolution, audit trails, and downstream trust decisions possible. User-facing citations may be derived from provenance data, but the provenance system must operate even when no user-facing citation is needed.
For how conflicting sources should be handled when provenance-based resolution fails, see the concept guide Information Provenance & Claim-Source Mappings and Handling Conflicting Data Sources. The orchestrator-pattern is the architectural context in which multi-source provenance tracking most commonly appears.
How It's Tested & Common Confusions
Question Angles
Design identification: A multi-source pipeline is described. You are asked which design correctly implements provenance tracking. The correct answer attaches source_id at extraction and preserves it through transformation; distractors attach it only at the final output stage (too late to support conflict resolution) or omit it from forwarded claims.
Conflict scenario: Two subagents return contradictory values for the same field. You are asked how a provenance-aware system handles this. Correct: preserves both values with their source IDs, applies source-priority hierarchy, and flags the conflict. Incorrect: picks one arbitrarily, discards the other, or merges them.
Audit trail question: An exam question asks what data structure enables a human reviewer to trace a claim in the final output back to the original document page. The answer involves the claim-source mapping with source_id, source_type, and position data.
Common Confusions
- Provenance vs. logging: Logging records *events* (when a tool was called, what the API returned). Provenance records the *lineage of claims* (where each piece of information in the output came from). Both are needed; neither substitutes for the other.
- Adding provenance at the end: A common mistake is to add source attribution at the output formatting stage. By this point, conflicting claims may already have been silently resolved or dropped. Provenance must be attached at extraction time.
- Provenance requires citing every claim: In practice, provenance operates on structured fields and key claims, not free-form prose. Design your subagent contracts to return structured claim-source pairs, and let the presentation layer produce readable citations from those pairs.
Frequently Asked Questions
Does provenance tracking significantly increase token usage?
It adds per-claim metadata (typically 20–50 tokens per claim for source_id, source_type, and position fields), which is meaningful in large extraction tasks. The mitigation is to carry provenance in structured side-channels (a separate `provenance_map` object keyed by claim ID) rather than inlining it in every claim object. This keeps the primary data clean while preserving the full audit trail.
How should a subagent communicate provenance when it processes a document chunk it did not retrieve itself?
The orchestrator should pass the source_id along with the chunk when tasking the subagent. The subagent's contract should require it to echo the source_id back in every claim it extracts. This is a documentation-of-contract problem: if source IDs are not part of the subagent's input schema and output schema, they will be lost at that boundary regardless of how the orchestrator is designed.
What happens to provenance when a summarization step combines multiple claims?
The summarization step should output a `sources_used` array listing all source IDs that contributed to the summary, even though individual claim-to-source mappings are collapsed. This trades fine-grained traceability for paragraph-level attribution. For high-stakes pipelines where claim-level audit trails are required, avoid summarization steps that collapse provenance — keep claims structured throughout and only render prose at the final presentation layer.