What is data provenance? The context behind a number

A dashboard can preserve the final number while losing the context that makes the number inspectable. The source was downloaded by someone. A filter was changed in a notebook. A manager approved an exclusion. The report still says “qualified accounts,” but another analyst cannot tell which object was used or who changed it.

Data provenance is the record of the entities, activities, and agents involved in producing, influencing, or delivering a data object. It gives a result context. It does not certify that the source is accurate, the transformation is valid, or the conclusion is causal.

The data-lineage article owns the applied path from inputs through joins, filters, and transformations. This page owns the wider context around that path: which objects existed, which activity connected them, which agent was responsible, and which later use depended on the result.

What does data provenance mean?

The World Wide Web Consortium’s PROV-DM model describes provenance through entities, activities, and agents. It includes relations for usage, generation, derivation, association, and attribution (World Wide Web Consortium, 2013). These terms are useful because “the dashboard said so” is not an evidence path.

Keep the neighboring objects separate:

Provenance is therefore a context object. Lineage is a transformation path. Verification is an evidence judgment. Quality is a fitness judgment. Event capture is an observation record.

Which fields make provenance reviewable?

Start with the object a reader is being asked to trust. Then preserve the fields that let the reader reconstruct its context:

1. Entity: source file, record, table, report, model output, or decision object.
2. Identity and version: stable identifier, retrieval time, checksum or snapshot label.
3. Activity: extraction, normalization, join, aggregation, manual review, or publication.
4. Agent: person, team, system, vendor, or process responsible for the activity.
5. Relation: used, generated, derived, attributed, associated, superseded, or invalidated.
6. Clock: event time, retrieval time, processing time, and decision time where they differ.
7. Use: dashboard, model, claim, meeting, customer action, or policy that consumed the object.
8. Exception: missing source, changed rule, late data, failed validation, or unresolved owner.

The identity field matters. A file called customers.csv is not one permanent entity if its contents change every morning. A versioned snapshot or content hash makes the object distinguishable from its successor. The agent field matters too. “Automation” can hide whether a vendor, a scheduled job, or a person made the relevant change.

What does a provenance register look like?

The six rows below are synthetic. They contain no private source, participant, customer, or company data. They show how the same result can carry both a transformation path and a context record.

P-01 names the held entity. P-02 records an operation rather than silently treating the extract as original data. P-05 preserves attribution for the evidence sentence. P-06 makes the release decision part of the record. If P-01 cannot be identified or P-04 has no duplicate rule, the result can be held even if its final number looks plausible.

Where can provenance fail?

Provenance can be complete and still expose an invalid process. Common failures include:

• Unversioned substitution: a named file changes while its path stays constant.
• Relation loss: a derived table is kept but the operation that produced it disappears.
• Agent collapse: “the system” hides a manual edit, vendor change, or owner transition.
• Clock confusion: retrieval time is treated as event time or decision time.
• Unrecorded exclusion: a row is removed without a rule, reason, or reviewer.
• Citation overreach: a held source is used as if it supported a stronger proposition than it does.

The W3C model supports interoperable description and reasoning, but it does not certify that a source or transformation is correct. That boundary is the central reason to keep provenance beside quality, validity, and causal review rather than using it as a substitute.

How should a team review a provenance record?

Choose one result and replay it from the final use backward:

1. Name the entity, unit, version, and decision that need review.
2. Resolve the source object and retrieval or snapshot boundary.
3. List each activity in order, including manual or vendor steps.
4. Name the agent and time for each activity.
5. Check the relations: used, generated, derived, attributed, superseded, or invalidated.
6. Match every evidence sentence to the source object it actually uses.
7. Mark the result reproducible, held, reissued, or not reconstructable.

Provenance makes context visible. It does not make a weak source strong, a measure valid, or a descriptive result causal.

The reproducibility article takes the next question: whether another analyst can reconstruct the declared path.