Evidence Cards Add Provenance to Retrieved Context

An agent can retrieve a sentence that looks authoritative and still have no evidence for the claim it wants to make.

That is the uncomfortable gap between context and evidence.

Context is material placed in the agent's working set: a search result, a database row, a prior note, a tool response, a colleague's handoff, or a compact summary. It can be useful, relevant, and entirely unsuitable as support for a consequential assertion. The agent may not know who produced it, when it was collected, whether it was transformed, whether it applies to the present task, or whether it was allowed to leave its original environment.

For this article, evidence is defined more narrowly. Evidence has a source, a supported claim, a scope, and enough lineage for a reviewer to understand why it was used.

Retrieved material becomes evidence only when its origin, meaning, limitations, and permitted use are available to the decision that relies on it.

This distinction is not pedantry. It affects quality, auditability, safety, and user trust. An agent that cites an old summary as though it were a primary source can be confidently wrong. An agent that combines facts from two incompatible sources can conceal the conflict. An agent that carries internal material into a different task boundary can create a privacy or authorization problem even if its factual answer is correct.

The answer is not to burden every model turn with raw logs. It is to make provenance compact, structured, and usable.

Why final accuracy is not enough

The June 2026 arXiv survey preprint *From Agent Traces to Trust* makes an important point: final-answer accuracy alone cannot explain how an agent arrived at an output, which evidence supported each claim, how memory influenced later work, or where an execution failure started. That is particularly true once an agent can search, call tools, retain memories, and delegate work.

Suppose an agent answers, “The service supports feature X.” A reviewer needs more than a fluent sentence:

• Was the source an official specification, a community comment, or an earlier model summary?
• Is it about the same version, environment, or product?
• Did the retrieved source state the claim directly, or did the agent infer it?
• Was the source current when it was retrieved?
• Did an intermediate summarization remove a qualification?
• Was the source appropriate to use in this user-facing answer?

Without those answers, a citation may be decorative rather than evidentiary.

The problem is not limited to web research. The Eywa preprint is one recent research example that separates source evidence, stored facts, retrieved context, and answer policy in a provenance-aware memory design. A stored summary may preserve a useful observation while losing the condition under which it was true. When it reappears later, an agent can mistakenly treat it as a current fact.

The Evidence Card

The W3C PROV Data Model provides a broader provenance vocabulary around entities, activities, and agents. This article's proposed seven-field Evidence Card is a smaller record attached to retrieved material that an agent may use as support. It is deliberately more compact than a full provenance graph and more informative than a bare URL or document title.

• Field: Source identity and authority — Question it answers: Who or what produced this material? — What it should preserve: Source reference, publisher or system category, and an authority classification suitable for the claim
• Field: Acquisition and snapshot — Question it answers: What exactly was observed, and when? — What it should preserve: Retrieval time, version or snapshot reference when available, and collection method category
• Field: Supported claim — Question it answers: What does this material directly establish? — What it should preserve: A concise claim statement, not an unbounded label such as “relevant”
• Field: Transformation lineage — Question it answers: What happened between source and current context? — What it should preserve: Extraction, summarization, translation, ranking, aggregation, or handoff steps
• Field: Scope and limitation — Question it answers: Where could this be misleading or incomplete? — What it should preserve: Version limits, coverage gaps, conflict state, uncertainty, and applicable context
• Field: Freshness and review trigger — Question it answers: When should the agent stop relying on it without checking again? — What it should preserve: Expiration, revalidation condition, or dependency on a changing environment
• Field: Permitted use and retention — Question it answers: In which task or audience boundary may it be used? — What it should preserve: Classification, access or sharing constraint, citation requirement, and retention posture

The card does not declare a source “true.” It explains why and how a piece of material may support a specific claim in a specific setting.

That framing matters. A vendor document might be authoritative for an interface it publishes but not for an independent security assessment. A preprint might support a description of what researchers evaluated but not a broad promise that the method will work everywhere. A user-provided note might be relevant to a task but not safe to repeat to another audience.

Separate claims from the context that inspired them

The key design move is to attach provenance to a claim, not merely to a blob of retrieved text.

One source may support several different claims, each with a different strength. Conversely, one answer may rest on several sources that need to agree. If the system only records “these documents were in context,” it cannot tell which sentence relies on which evidence.

An agent does not need a perfect formal proof for every low-stakes answer. It does need a proportionate process:

1. Name the claim. State the fact or inference the response intends to make.
2. Associate the supporting material. Link it to an Evidence Card rather than to an unexplained context block.
3. Check directness and scope. Decide whether the source states the claim, merely suggests it, or applies only under conditions.
4. Handle conflict deliberately. When sources disagree, preserve the disagreement or seek a more authoritative source instead of averaging them into certainty.
5. Respect freshness and permitted use. Revalidate changing material and do not move it into a broader audience or task without an appropriate policy basis.
6. Expose a reader-appropriate trace. A user may need a citation and limitation; an operator may need the fuller lineage record.

This is a claim-support workflow, not an instruction to reveal private context. The public trace should contain only what is appropriate for the intended audience. The full internal record should remain subject to access, retention, and privacy rules.

Summaries need lineage, too

Summaries are often indispensable. No agent can place an entire collection of source material into every decision. The risk begins when a summary is detached from what it compressed.

An Evidence Card should therefore distinguish:

• direct source material, which can support a claim within its stated scope;
• extracted material, which preserves a selected passage or field;
• summary material, which is a transformation that may omit qualifiers;
• derived analysis, which is the agent or analyst's inference; and
• memory material, which may need revalidation before it becomes active support again.

These categories do not make summaries untrustworthy. They make their limits visible. A good summary card records the source set, the transformation type, the intended scope, and the review trigger. It tells the next agent: “Use this to orient yourself; return to the primary source before making a strong claim.”

Make the card usable by the model and the operator

The model does not need every storage detail. It needs a concise operating view:

• Model-visible field: Claim and confidence posture — Why it helps: Helps the model distinguish direct support from inference or unknowns
• Model-visible field: Authority category — Why it helps: Helps it choose stronger sources when the task requires them
• Model-visible field: Scope and freshness marker — Why it helps: Prevents a stale or narrowly applicable fact from becoming a universal claim
• Model-visible field: Conflict flag — Why it helps: Encourages qualification, comparison, or further research
• Model-visible field: Permitted-use summary — Why it helps: Keeps the response within the allowed audience and task boundary

The operator or auditor may need additional lineage: the collection event, transformation record, version reference, and access decision. Keeping these views separate avoids two failures at once: overwhelming the model with raw trace data and stripping the platform of the evidence it needs to investigate a mistake.

Provenance is also a safety boundary

It is tempting to treat provenance as an observability feature. It is more than that.

Provenance helps an agent resist several common errors:

• treating untrusted retrieved text as an instruction or policy;
• turning a partial source into an absolute claim;
• carrying a fact into a different version, customer, workspace, or time period;
• converting a user-provided assertion into an independent verification; and
• repeating material to an audience that lacks a valid reason to receive it.

The last point is especially important. A fact can be accurate and still be inappropriate to distribute. The permitted-use field must sit alongside factual confidence. An agent should be able to say, in effect, “This may help solve the current task, but it is not approved for this answer or this audience.”

This is a general design principle, not a substitute for legal, privacy, or security review. The card makes the boundary inspectable; the platform's policies determine what the boundary permits.

Measure evidence quality, not just answer fluency

An agent team can begin with a few operational measures:

• Claim coverage: What share of material factual claims have an associated Evidence Card?
• Direct-support rate: How often does the cited material directly support the wording used, rather than merely being topically related?
• Freshness compliance: How often are expired or invalidated cards rechecked before they influence an answer or action?
• Conflict visibility: When material sources disagree, how often is that disagreement preserved rather than hidden?
• Lineage completeness: Can a reviewer identify the primary source and major transformations behind an important assertion?
• Use-boundary compliance: Does the system avoid putting sensitive or restricted context into an inappropriate task or audience?

None of these measures proves truth. They make an agent's evidentiary posture visible enough to improve.

A practical adoption path

1. Start with one high-value source type, such as official product documentation or a controlled internal knowledge base.
2. Define the seven Evidence Card fields in the language your team already uses.
3. Attach a card to each retrieved item that may support a material claim.
4. Require a current, permitted card before a result can be presented as a verified fact.
5. Make summaries link back to their source set and transformation type.
6. Add a visible conflict and freshness marker to the model's operating context.
7. Review a small sample of outputs for unsupported, stale, or over-broad claims.

The objective is not bureaucratic perfection. It is to replace an opaque leap—“the model saw it, so it must be true”—with a reviewable chain of support.

Common anti-patterns

Treating a URL as complete provenance

A link helps a reader navigate, but it does not say what claim it supports, whether it is current, or whether it was transformed before use.

Promoting memory to fact automatically

Memory should preserve useful experience without escaping its original scope. Revalidation may be necessary when time, environment, or task changes.

Giving the model raw trace logs

Raw logs can be noisy, sensitive, and difficult to interpret. Provide a compact operating summary while keeping the complete trace under appropriate controls.

Hiding conflict to make the answer smoother

Conflicting sources are information. A clear limitation is more valuable than false unanimity.

Forgetting permitted use

Factual support and authorization to disclose are separate questions. The evidence record needs both.

What we are learning building Virillio Code

Virillio Code is still in development. High-level work on context sources and durable agent workflows suggests a simple lesson: context should arrive with enough meaning to be used honestly. A fragment without origin, scope, or freshness is not yet evidence. It is an input that still needs judgment.

The durable question is not, “Was this in the context window?”

It is, “What claim can this support, for whom, under what limits?”

Sources and further reading

• From Agent Traces to Trust: A Survey of Evidence Tracing and Execution Provenance in LLM Agents — A recent survey explains why final-answer accuracy alone cannot explain evidence support, memory influence, tool use, or execution failures in agent workflows.
• Eywa: Provenance-Grounded Long-Term Memory for AI Agents — A recent preprint examines provenance-aware long-term memory and distinguishes source evidence, stored facts, retrieved context, and answer policy.
• PROV-DM: The PROV Data Model — A W3C Recommendation defines concepts for expressing provenance among entities, activities, and agents.

Editorial disclosure

This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.