Data Cards: Purposeful and Transparent Dataset Documentation for Responsible AI

• Diverse stakeholder goals, workflows, and backgrounds have limited the success of standardized, practical, and sustainable ML transparency mechanisms.Prior transparency efforts have included exposing source code and contribution trails, data analysis methods, and diverse oversight.Source: §1 · p. 2
• Data Cards add explanations, rationales, and instructions about dataset provenance, representation, usage, and fairness-informed evaluation beyond metadata.They summarize observable and unobservable aspects needed for organizational and practice-oriented decisions, including context that cannot be inferred from the dataset itself.Source: §1 · p. 2
• Data Cards are accessible boundary objects that support informed data decisions and complement Model Cards [22], Data Statements, and Datasheets for Datasets [14].The accompanying frameworks adapt them to different datasets and organizational contexts and help establish common ground for stakeholder input.Source: §1 · p. 2
• The paper documents a large-technology-company development methodology, maps dataset-lifecycle stakeholders to objectives and principles, and describes Data Cards’ content, design, and evaluation.These contributions aim to reduce knowledge asymmetries across stakeholders.Source: §1 · p. 3
• The authors propose three construction frameworks for organizing information, framing questions, and evaluating answers, including the repeatable knowledge-acquisition framework OFTEn.Case studies cover computer vision and language datasets; creators also identified opportunities such as investigating unknown values and aligning team labeling lexicons.Source: §1 · pp. 2–3

2 DEVELOPMENT METHODOLOGY

• With 12 teams, researchers co-created 22 Data Cards covering image, language, tabular, video, audio, and relational datasets in production settings; their workflows and stakeholder feedback informed continuing usability and utility improvements.A follow-up MaxDiff survey (n=191) assessed the relative importance of 31 themes and variation by modality and job function; an internal study of 30 experts highlighted assessing documentation without conflating it with the dataset.Source: §2 · pp. 3–4

2.1 Framing Transparency in the Context of Data Cards

• Transparency is audience-specific and contextual, and Data Cards aim to make it understandable through plain-language explanations and ongoing questions.Participants found technical, dense, presumptive documentation opaque, potentially impairing decisions and reinforcing power asymmetries; they described transparency as a shared understanding built over time.Source: §2.1 · pp. 4–5

2.2 A Typology of Stakeholders

• The stakeholder typology distinguishes producers, agents, and users, while recognizing that few readers meet producers’ assumed expertise and that users need different artifacts.Agents read transparency reports and may use or determine uses of datasets or AI systems; Data Cards are intended for agents with access to technical expertise, while product-grounded artifacts are encouraged for users. Stakeholders can span groups and vary in expertise, fluency, roles, and goals; scaled adoption should preserve comparability across datasets.Source: §2.2 · pp. 5–6, §2.2.1 · p. 6

2.2.1 O1. Consistent:

• Data Cards should be created alongside datasets, with fields distributed to the people best positioned to complete them.Consistent documentation also requires standardized methods that extend to reports produced throughout the dataset lifecycle.Source: §2.2.2 · p. 6

2.2.2 O2. Comprehensive:

• Data Cards should serve readers with the least proficiency while enabling more proficient readers to find detail without overwhelming deliberation or cooperation.Differences in proficiency can make the person with the strongest dataset mental model the de-facto decision maker, potentially excluding perspectives from downstream and lateral stakeholders.Source: §2.2.3 · p. 6

2.2.3 O3. Intelligible and Concise:

• Known unknowns matter in decision-making, so Data Cards should communicate uncertainty alongside known dataset facets.Participants considered communicating uncertainty a feature rather than a bug.Source: §2.2.4 · p. 6

2.2.4 O4. Explainability, Uncertainty:

• Clear explanations and justifications for uncertainty can prompt risk-mitigating measures and support fairer models and greater trust.They help readers distinguish irrelevant analyses from insignificant results, and withheld proprietary information from unknown information [9].Source: §2.2.4 · p. 7

3 DATA CARDS

• Data Cards capture critical dataset information across its life cycle, with tailored frameworks intended to preserve their utility and intent.The authors describe Data Cards as summaries of essential facts and note that no single template captures the nuance of every dataset.Source: §3 · p. 7

3.1 Principles

• Data Cards’ design principles are flexibility, modularity, extensibility, accessibility, and support for diverse content types.The authors present this generative design as a framework for readable transparency reporting that can scale in production contexts, rather than a prescriptive, domain-specific approach.Source: §3.1 · p. 7

3.2 Design and Structure

• Data Cards use blocks with prompts and structured answer inputs, arranged thematically and hierarchically to support navigation at varying levels of detail.The authors propose adapting templates by decomposing themes or questions into telescopes, periscopes, and microscopes rather than adding ad-hoc blocks that could compromise usability and integrity.Source: §3.2 · p. 7, §3.2.1 · p. 8

3.2.1 Socratic Question-Asking Framework: Scopes.

• Telescopes give broad, low-utility overviews; periscopes support quick suitability decisions; microscopes are hardest but help assess risk, plan mitigations, and identify dataset-creation opportunities.Telescopes support indexing, context, and conditional logic; periscopes provide technical or operational details that can often be reproduced or automated; microscopes elicit explanations of implicit decisions and policies.Source: §3.2.1 · pp. 8–9

3.3 Content and Schema

• The template identifies 31 generalizable dataset themes, whose importance varies by task, and OFTEn offers a repeatable way to identify and add lifecycle-spanning themes.Topics such as consent can have different implications at different life-cycle stages; OFTEn supports inductive and deductive transparency investigations.Source: §3.3 · p. 9, §3.3.1 · p. 9

3.3.1 OFTEn Framework.

• OFTEn tracks dataset topics across Origins, Factuals, Transformations, Experience, and an n=1 example, accommodating non-linear development and downstream feedback.It can help formulate questions, assess whether a Data Card represents a dataset, and expand or update documentation over time; the framework also exposes caveats and limitations relevant to tracking AI-system performance.Source: §3.3.1 · pp. 9–10

3.4 Evaluation of Data Cards

• Producers’ template-forking practices caused inaccurate repeated answers, fragmented cards, and labor-intensive updates, motivating low-barrier quality mechanisms across the dataset life cycle.The study worked with over 18 producers; when uncertain, producers sometimes answered “N/A.”Source: §3.4 · pp. 10–11

3.4.1 Dimensions.

• Reviewers found five evaluation dimensions made feedback more structured and actionable, while expert feedback also revealed opportunities to improve datasets.The dimensions cover accountability, utility or use, quality, impact or consequences of use, and risk and recommendations; reviewers with varied domain and data fluency rated cards and supplied evidence and improvement steps.Source: §3.4.1 · p. 12

4.1 A Computer Vision Dataset for Fairness Research

• The computer-vision fairness dataset used 100,000 manually annotated bounding boxes from 30,000 Open Images images, with perceived gender and age-range labels.The team sought to explain the dataset’s characteristics, limitations, and acceptable uses to internal ethics reviewers and external audiences; the Data Card was created after dataset preparation.Source: §4.1 · p. 12
• Reviewers questioned why nearly 40% of perceived age-range labels were unknown; the team linked this to small boxes and added documentation and visualizations.Thirty percent of boxes were less than 1% of the image, and unknown labels were relatively typical in this problem space; the process also prompted new fields for future computer-vision Data Cards.Source: §4.1 · pp. 12–13
• After launch, downstream agents found the Data Card useful and sought templates, despite producers lacking access to dataset consumers.Human-centered design feedback focused on information needed to draw acceptable conclusions about accountability, risk, recommendations, uses, consequences, and dataset quality.Source: §4.1 · p. 13

4.2 A Geographically Diverse Dataset for Language Translation

• To address models relying on names to infer gender, the team created a geographically diverse biography dataset and Data Card to explain its goals and gender definitions.The team used a limited set of publicly curated Wikipedia data and recognized that diversity also involved race, age, gender, background, and profession.Source: §4.2 · p. 13
• The approximately 20-hour Data Card process prompted reflection on selection, assumptions, and limitations, extending the timeline but yielding a more intentional dataset.Experts and a human-centered designer developed the card iteratively after dataset creation.Source: §4.2 · p. 13
• Stakeholder discussions defined perceived gender labels and helped justify exclusions; the final card documented selection and sampling criteria, field sources, and continental country distributions.The team used “masculine”, “feminine”, and “neutral” for biographies describing collections of individuals, and justified not including non-binary individuals and excluding collected data while describing dataset limitations.Source: §4.2 · p. 13

5 DISCUSSION

• Creating Data Cards as datasets are developed can reduce final-step burden while bringing multiple perspectives together, consolidating lifecycle documentation, and enabling early responsible-AI feedback.Teams creating multiple cards also developed a more nuanced vocabulary for expressing uncertainty.Source: §5.0.1 · p. 14

5.0.1 Experiences and outcomes from Case Studies.

• Data Cards support reviews, audits, dataset selection, comparison, reproduction, and adoption tracking while enabling stakeholders to make decisions using their own community’s concepts and vocabulary.They can facilitate collaboration without requiring consensus.Source: §5.0.2 · p. 14

5.0.2 Data Cards as Boundary Objects.

• Data Cards act as boundary objects connecting dataset documentation with model and AI-system transparency artifacts, supporting fairness and accountability inquiries and broader knowledge transfer, reuse, governance, and oversight.Source: §5.0.2 · p. 14
• After Data Card release, public and private organizations sought to adopt similar constructs (,,); quality and comprehensiveness depend on producer rigor, nuanced uncertainty expression, and dataset knowledge.Source: §5.0.3 · p. 14

5.0.3 Path to Adoption.

• Organizations should tailor Data Cards to their datasets, models, and technology stacks, connecting knowledge-management infrastructure to data and model pipelines so new knowledge keeps cards current.Source: §5.0.4 · pp. 14–15

5.0.4 Infrastructure and Automation.

• Blocks supports implementation across interactive and static formats, while repositories can help stakeholders find suitable datasets and collaborate on cards, linked artifacts, and partially automated analyses.Readers opposed automating some fields containing assumptions or rationales; automation should protect accuracy, while human-written context explains methods, assumptions, decisions, and baselines.Source: §5.0.4 · p. 15

6 CONCLUSION

• Data Cards and their frameworks support customized, consistent dataset documentation that explains implications, surfaces unknowns, and informs ethical, production, and research decisions.The paper presents qualitative and anecdotal evidence from two case studies and argues that the approach can help co-create practical industry standards.Source: §6 · p. 15
• Google Docs enabled stakeholder collaboration and preserved development history, but text, tables, and images constrained responses, while field-level iteration fragmented templates and impeded automation.The first case study observed template fragmentation and loss of original intent; producers also requested a streamlined collection experience and automation.Source: §6 · p. 15
• Future work should develop principled ways to extend and adapt templates without sacrificing comparability, and engage diverse, non-traditional stakeholders early through co-creation across the dataset lifecycle.The paper proposes deliberate automation in documentation as a potential outcome of this co-creative approach.Source: §6 · p. 15
• Assessing Data Cards’ value quantitatively requires adoption at industry breadth and depth, plus investigation of how different stakeholder groups perceive and use their content.Source: §6 · p. 15

• Fig. 3 classifies typical dataset-life-cycle stakeholders by type, identifiers, tasks, and example roles, and notes that early inclusion of non-technical and indirect stakeholders supports successful Data Card adoption.Including these stakeholders during initial decisions about content and structure builds foresight for adoption.Source: Figure 3 · p. 18

B OFTEN FRAMEWORK AS A GENERATIVE TOOL

• OFTEn generated data-consent questions across a dataset’s life cycle and, during template creation (E), helped anticipate standardization requirements and investigate documentation over time.Source: Table 4 · p. 19

C DATA CARD FOR COMPUTER VISION DATASET

• The computer vision dataset Data Card spans five pages.The figures label the card’s pages 1 through 5.Source: Figure 4 · p. 20, Figure 5 · p. 21, Figure 6 · p. 22
• The supplied figures identify pages 1–4 of the Data Card.They provide page labels only, not the card’s substantive content.Source: Figure 4 · p. 20, Figure 5 · p. 21, Figure 6 · p. 22
• The final supplied figure identifies page 5 of the Data Card.Its caption provides no further content about that page.Source: Figure 8 · p. 24

• The Language Translation Dataset Data Card spans three pages.Source: Figure 9 · p. 25, Figure 10 · p. 26, Figure 11 · p. 27

Summary, Authorship, and Dataset Overview

• The opening sections identify the dataset and its authors, then provide a top-level overview suitable for other transparency artifacts, with links to the full Card and fields on sensitivity and version maintenance.Authorship fields distinguish publishers from dataset owners and record funding sources.Source: Figure 12 · p. 28, Figure 13 · p. 29, Figure 14 · p. 30

Example of Datapoints and Transformations

• The production sections help readers inspect datapoints without downloading the dataset and document raw-data transformations, including those that may introduce residual or system-level risks requiring oversight.Transformation documentation begins with an aggregate, followed by a detailed breakdown.Source: Figure 16 · p. 32, Figure 28 · p. 44, Figure 29 · p. 45

Motivations & Use

• Motivations and Use records why the dataset was created and asks producers to describe intended, suitable, and unsuitable use cases.The template recognizes that producers cannot enumerate every possible use case.Source: Figure 17 · p. 33

Access, Retention and Wipeout

• Access, Retention and Wipeout documents storage locations, access prerequisites and policies, retention periods and exceptions, and appropriate deletion procedures after retention expires.The template notes access policies are particularly important in regulated industries.Source: Figure 18 · p. 34, Figure 19 · p. 35

Dataset Provenance

• Dataset Provenance documents collection methods and upstream sources, selection and exclusion criteria, source relationships, and recent or planned updates, including cases with multiple sources or collection methods.The template notes that creating Cards for new datasets or versions is often easier than documenting older versions after knowledge has been lost.Source: Figure 20 · p. 36, Figure 21 · p. 37, Figure 22 · p. 38

Human and Other Sensitive Attributes

• Human and Other Sensitive Attributes documents rationales for capturing human attributes alongside disaggregated statistics, correlations, risks, and trade-offs for fairness analysis.The template describes this information as particularly important for human-centered machine learning applications.Source: Figure 23 · p. 39, Figure 24 · p. 40

Extended Use

• Extended Use provides guidance for joining, forking, or sampling datasets and records known or benchmark performance and descriptive statistics for training and testing splits.The template encourages automating split-statistics fields to improve accuracy and rigor.Source: Figure 25 · p. 41, Figure 26 · p. 42, Figure 27 · p. 43

Annotations, Validation, Sampling, and Additional Documentation

• Annotations records quantitative and qualitative characteristics, distributions, and task instructions, while Validation Methods and conditional Sampling Methods capture relevant processes and attributes.Known Applications & Benchmarks records models, evaluation processes, expected performance, and caveats; Terms of Art and Reflections provide definitions and space for additional information.Source: Figure 30 · p. 46, Figure 31 · p. 47, Figure 32 · p. 48