---
title: "Data provenance for AI agents"
description: "Data provenance records where a piece of data came from, who held it, and what transformed it. Why agent memory needs it for citation, audit, and deletion."
canonical: https://past.dev/guides/data-provenance
last-updated: 2026-09-02
---
# Data provenance for AI agents

Source: https://past.dev/guides/data-provenance

Data provenance is the record of where a piece of data originated, who has held it, and what transformations produced its current form. For an AI agent, provenance means every remembered fact points to the source record that supports it, with that source's date. This makes answers citable, wrong answers debuggable back to their source, and deletion precise: removing a source removes what only it supported.

## What data provenance covers

Data provenance is the recorded history of a piece of data: its origin, its chain of custody, and the transformations that produced its current form. Provenance tracking records that history at write time, because none of it can be reconstructed afterward.

- **Origin.** The system, person, or document the data came from, with a date. For an agent memory, the origin of a fact is a source record: an email, a transcript, a ticket.
- **Custody.** Which systems have held or transmitted the data since. Custody is what an audit asks about when data crosses team or vendor boundaries.
- **Transformation.** The processing that produced the current form: extraction from prose, normalization, deduplication, a [merge of duplicate profiles](/guides/merge-duplicate-profiles). Each step can introduce error, so each step belongs in the record.

> **Write time**
>
> Provenance is captured at ingestion or never. A store that discards source pointers while writing cannot reconstruct them later, whatever the retrieval layer does.

## Provenance vs lineage

The two terms overlap, and tooling uses them loosely. The useful distinction is granularity.

| Property | Data provenance | Data lineage |
| --- | --- | --- |
| Unit described | One record, fact, or value | A dataset, table, or column |
| Question answered | What supports this specific value? | Which upstream sets produced this set? |
| Typical consumer | An auditor, or an agent citing a source | A data platform team tracing pipelines |

Debugging one wrong agent answer is a provenance problem. Knowing which dashboards break when a table changes is a lineage problem. An agent memory needs the first and rarely supplies the second.

## W3C PROV, the shared vocabulary

W3C PROV is the standard vocabulary for provenance ([PROV overview](https://www.w3.org/TR/prov-overview/)). It models three node types: entities, activities, and agents, connected by relations such as `wasDerivedFrom`, `wasGeneratedBy`, and `wasAttributedTo`. The model maps directly onto agent memory.

- **Entity.** The stored fact, and the source record it was derived from.
- **Activity.** The ingestion or extraction run that generated the fact from the source.
- **Agent.** The connector, model, or person the activity is attributed to.

A memory system does not need to emit PROV serializations to benefit from the model. Recording which entity derived from which source, through which activity, is the part that matters when an answer is challenged.

## Why agent answers need provenance

An agent's answer is a claim derived from stored records. Four uses of provenance follow from that.

- **Citation.** An answer that names its source and the source's date can be verified in one step. An answer without provenance can only be re-derived from scratch.
- **Trust.** When sources disagree, provenance is what lets a reader weigh them. A price from the signed contract outweighs a price from a draft written two months earlier, and provenance is what distinguishes the two records. Disagreement handling is covered under [contradictory facts](/guides/contradictory-facts).
- **Audit.** Regulated workflows must show which record produced which answer, on what date. The [AI audit trail guide](/guides/ai-audit-trail) covers the record-keeping side.
- **Debugging.** A wrong answer traces to a wrong source, a wrong extraction, or a stale fact. Without provenance those three failures look identical and get fixed by guesswork.

## Provenance in agent memory

In an agent memory, provenance means every stored fact keeps a pointer to the record that supports it, along with that record's own date. The fact "Priya approved the vendor contract" points at the approval email of March 4, 2026. Recall then returns the claim, the source, and the date together.

```arecalledfactwithitsprovenance
{
  "claim": "Priya approved the vendor contract",
  "evidence": [
    {
      "source": "email, Priya to legal team",
      "source_date": "2026-03-04",
      "excerpt": "Approved. Send Meridian the countersigned copy today."
    }
  ]
}
```

The source date matters as much as the pointer. Facts should be dated by when the source said them rather than by when they were ingested, which is the [event time vs ingestion time](/guides/event-time-vs-ingestion-time) distinction. Dating by ingestion makes a record backfilled from 2024 read as a current statement.

## Provenance and deletion

Provenance makes deletion precise. When a source must be removed, under an erasure request or a retention rule, the system can compute which facts that source alone supported and remove them with it. Facts also supported by other sources remain, cited to the surviving sources. The mechanics are reference counting over sources: each fact lists its supporters, and a fact whose supporter count reaches zero is removed by the deletion.

Without provenance, deletion is either too broad (drop everything touching the person) or too narrow (drop the file, keep every derived fact). The [GDPR memory deletion](/guides/gdpr-memory-deletion) and [forgetting policy](/guides/forgetting-policy) guides cover the policy side.

## Testing provenance, and where past.dev fits

A memory system's provenance can be probed in four steps.

1. Ingest one record with a date, such as the March 4 approval email.
2. Ask a question only that record answers, and require the source and its date in the response.
3. Delete the record, then ask again. The answer must change to unsupported rather than persisting without a source.
4. Ingest two records supporting the same fact, delete one, and ask again. The fact should remain, cited to the surviving record.

Scoring for cited recall is described in the [benchmark methodology](/benchmarks/methodology). past.dev is built around this contract: every fact links the source that supports it with that source's date, recall returns evidence with dates and sources, and deleting a source through the API erases what only it supported. The [quickstart](/docs/memory-api/quickstart) shows the ingest, recall, and delete calls.

## Frequently asked questions

### What is data provenance in simple terms?

It is the recorded history of a piece of data: where it came from, who has held it, and what processing produced its current form. Provenance is what makes a value checkable after the fact.

### What is the difference between data provenance and data lineage?

Provenance describes one record or value, including its origin and custody. Lineage usually describes how whole datasets flow through pipelines. Auditing a single answer needs provenance, while impact analysis on a pipeline needs lineage.

### Why do AI agents need data provenance?

So every answer can cite a dated source, so disagreeing sources stay visible instead of being silently merged, and so a wrong answer can be traced to the record that caused it. Without provenance, none of those checks are possible.

### How do I test whether a memory system tracks provenance?

Ask a question and require the source with its date. Then delete that source and ask again. If the answer persists without support, or the citation cannot name a dated record, provenance is missing.

## Related

- [AI audit trail](https://past.dev/guides/ai-audit-trail)
- [GDPR memory deletion](https://past.dev/guides/gdpr-memory-deletion)
- [Forgetting policy](https://past.dev/guides/forgetting-policy)
- [Facts that change over time](https://past.dev/guides/facts-that-change-over-time)
- [Security at past.dev](https://past.dev/security)