Understand
Data Provenance & Lineage
Where does this data come from?
Shows where the data behind a decision came from, how current it is, and whether it fits the case at hand.
- Evidence: research-based (Gebru et al. 2018, Holland et al. 2018)
- Tested: concept only, mock data
Overview
Why it matters
A decision is only as good as the data under it.
Models trained on past decisions inherit their biases. Data from one population may not fit another. Stale data makes a system confidently wrong. People see the number, never the data underneath it.
This pattern covers two levels: the training data the model was built on, and the input data used in this specific decision. For what an assistant looks up at runtime, see Retrieved Source Attribution.
What does it look like?
Spotting stale data in a decision
Spotting stale data in a decision
- Applicant reviews a loan decision.
- The data panel shows a ⚠ badge on "Income: last verified 18 months ago."
- Applicant recognizes this is outdated (they changed jobs).
- System shows a link: "Provide updated income documentation to request re-evaluation."
- Applicant uploads current payslips and requests a new assessment.
Caseworker checking data quality before override
Caseworker checking data quality before override
- Caseworker reviews a borderline case flagged for human review.
- Data quality panel shows two ✗ Missing fields and one ? Inferred field.
- Caseworker requests the missing documentation before making a final decision.
- New data is added; system notes the data update in the audit trail.
Auditor tracing a decision
Auditor tracing a decision
- Auditor investigates a complaint about a declined application.
- Decision audit shows the data sources used at the time of decision, with timestamps.
- Auditor sees that the income figure used was from a third-party bureau, not from the applicant's submitted documents.
- Auditor flags a process inconsistency for review.
When does it fit?
Use it when
- Data quality directly affects how reliable the decision is
- People have a right to know which data was used about them
- Inputs may be stale, incomplete or inferred
Skip it when
- Disclosure would create commercial or security risk
- Full provenance can't actually be traced: don't show a partial chain as complete
Design
How do I apply it?
-
Keep training data and input data apart.
A biased training set is a systemic problem. A stale income figure is a fixable one.
-
Show data quality where the decision is made.
Not on a terms-of-service page.
-
Be honest about gaps.
A visible "missing" badge is more trustworthy than a blank field.
-
Link gaps to recourse.
If missing data drove the decision, offer a way to provide it.
-
Summarize here, document in full elsewhere.
Link to the Model Transparency Card for the training data.
How can I show it?
Data quality badges
Verified, stale or inferred, on each field.
Inline badges on specific data fields indicating their status: - ✓ Verified: confirmed against a document or external source - ⚠ Stale: last updated more than X months ago - ? Inferred: derived from other data, not directly collected - ✗ Missing: expected but not present
Data source list
Which sources were used, how recent, how reliable.
A structured list of the data categories or sources used in a specific decision: - Source name or type (self-reported, verified document, third-party bureau, inferred) - Recency (when the data was last updated) - Quality indicator (complete / incomplete / stale / flagged)
What data was used panel
The exact fields and values behind this decision.
For decisions where specific fields drove the outcome, a panel showing exactly which data fields were accessed, their source, and their value, not just that "financial data" was used, but that "income figure of €X from self-reported form, unverified" was used.
Data timeline
When each piece of data was collected.
A simple visual showing when key data points were collected relative to when the decision was made. Helps users see whether the data reflects their current situation.
Coverage warning
An alert when this case is unlike the training data.
A visible alert when the current case falls outside the distribution the model was trained on: "This system was primarily validated on applicants in urban employment contexts. Your case may be evaluated with lower accuracy."
Training data summary card
What the model was trained on, in short.
A compact card (linked to the full Model Transparency Cards) summarizing: - What kind of data the model was trained on - The time range of training data - Known limitations or gaps in training coverage
Dataset nutrition label
A standard summary of the training data's makeup.
A standardised summary of the training dataset's composition designed for non-technical audiences: analogous to a food nutrition label. Covers the key "ingredients": size, collection date range, source types, known demographic gaps, and any documented quality issues or biases. Where a training data summary card links to the full transparency documentation, the nutrition label is the readable quick-read version intended for practitioners who need to assess fitness-for-purpose without reading the full datasheet. Particularly useful in operator views where the dataset's profile, not just the model's, affects trust in the output.
Further left for the person affected, further right for auditors tracing the data chain.
What does it cost?
Transparency vs. complexity
Full lineage can span dozens of sources. Show what matters for this decision, link the rest.
Honesty vs. trust erosion
Prominent quality badges can unsettle people. Show what's good as well as what isn't.
Disclosure vs. business risk
Naming providers reveals relationships. Data types are often enough.
Connections
Which patterns work with it?
Retrieved Source Attribution
What sources did the system draw from?
Provenance covers training data and input data. Retrieved Source Attribution covers runtime retrieval in LLM systems. These are distinct but complementary.
Model Transparency Cards
How was this system built and tested?
Model cards are the canonical place for training data documentation. This pattern surfaces a summary of that documentation at the point of decision.
Actionable Recourse
What can I do to change this outcome?
Stale or missing data is one of the most actionable types of recourse. Provide updated data or request re-evaluation. Provenance and recourse should be linked.
Ethical & Fairness Signals
Is this system fair across groups?
Training data that underrepresents certain populations is a root cause of model bias. Provenance and fairness signals address the same underlying issue from different angles.
Audit Trail & Logging
What is the complete record of this decision?
Audit trails should capture the data state at the time of a decision, not just the decision itself. Provenance data is a key component of a complete audit record.
Sources (3)
Sources (3)
Gebru et al. (2018) — Datasheets for Datasets
proposes a standardized documentation format for datasets covering motivation, composition, collection process, and known biases. The direct foundation for training data provenance disclosure
Holland et al. (2018) — The Dataset Nutrition Label: A Framework To Drive Higher Data Quality Standards
proposes a "nutrition label" metaphor for dataset transparency, designed for non-technical audiences. Directly informs how provenance summaries should be designed for lay users
Mitchell et al. (2019) — Model Cards for Model Reporting
while focused on model-level documentation, model cards include dataset information as a core component. Establishes the connection between data provenance and model-level transparency
A decision was made on stale or wrong data, and nobody noticed.
Or an auditor asks which data was used, and where it came from. That's where this pattern starts. Let's look at your interface together.
Work with me