Datasheets for Datasets

Description

A datasheet for a dataset is a short document that accompanies the dataset and answers a set of questions about it, in the way an electronic component comes with a datasheet. Gebru and colleagues group the questions into seven sections: why the dataset was made, what it contains, how it was collected, how it was cleaned and labelled, what it should and should not be used for, how it is distributed, and who maintains it. Creators read the questions before collecting data, answer them when the dataset is finished, and update the sheet when the dataset changes. People considering the dataset read it to judge whether it suits their task and what risks it carries. The questions are a prompt rather than a checklist, and a datasheet records what is known without testing it.

Example Use Cases

Transparency

A bank's model risk team asks a vendor for the datasheet of a transaction dataset before approving it for fraud-model training. The answers on how transactions were sampled, which merchants and periods are missing, and what the data should not be used for let the team judge whether the dataset fits its purpose.

A recruitment-technology team documents its CV dataset: the mix of applicants by job category and demographic group, how outcome labels were assigned, and which groups are thinly represented. Developers read this before training a screening model, so they know the limits of the data before they choose and test the model.

Safety

Documenting a safety-critical autonomous vehicle perception dataset with records of sensor calibration procedures, environmental conditions during collection, edge-case scenario coverage, and known distributional gaps, enabling safety engineers to assess whether training data adequately represents the operating conditions required for safe deployment and to support regulatory type-approval submissions.

General

A hospital trust's data governance group will not release a medical imaging dataset to model developers until its datasheet is complete. The sheet records consent, anonymisation, sensitive attributes and sharing limits, and the group files it with the release approval as the record of what was checked.

Limitations

Writing a thorough datasheet takes time and knowledge of how the dataset was built, and the work recurs with each version, which can delay release. Gebru et al. note that the overhead is real and that organisational workflows and incentives need to change to accommodate it.
A datasheet describes the dataset as it was when written. Cleaning, augmentation or new data make it wrong unless it is revised, and Gebru et al. say the format fits dynamic datasets poorly, so each updated version needs an updated datasheet.
There is no single mandated template. Gebru et al. give a set of questions and say it is not prescriptive. ECMA-424 (CycloneDX 1.7, December 2025) standardises a machine-readable record of a dataset's contents, sensitive data and owners, but not the account of motivation, collection and intended use. Without enforcement, depth and completeness vary.
Answers come from the dataset's creators and nothing checks them. Creators may leave out sensitive details about collection, consent or bias to avoid legal or commercial exposure, so a datasheet can look complete and still mislead.
A datasheet records what its authors know. It does not measure bias, check coverage or find errors, and Gebru et al. note that spotting societal bias often needs demographic labels that creators may not hold. A clean-looking datasheet is not evidence the data suits a particular use.

Resources

Research Papers

Datasheets for Datasets

Timnit Gebru et al.•Jan 1, 2021

The machine learning community currently has no standardized process for documenting datasets, which can lead to severe consequences in high-stakes domains. To address this gap, we propose datasheets for datasets. In the electronics industry, every component, no matter how simple or complex, is accompanied with a datasheet that describes its operating characteristics, test results, recommended uses, and other information. By analogy, we propose that every dataset be accompanied with a datasheet that documents its motivation, composition, collection process, recommended uses, and so on. Datasheets for datasets will facilitate better communication between dataset creators and dataset consumers, and encourage the machine learning community to prioritize transparency and accountability.

Tutorials

Create a dataset card — Hugging Face Datasets documentation

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

Documentations

Dataset Cards — Hugging Face Hub documentation

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

Related Techniques

Name	Description	Assurance Goals
Model Cards	A model card is a short structured document published with a trained model, stating what the model is for and what it should not be used for. It reports how the model performs on stated evaluation data, with results broken down by group (for example age or sex) and by operating condition (for example lighting or device) where these matter. It also records the training data, the metrics chosen and why, ethical considerations and known caveats. Readers use the card to judge whether the model suits their purpose before they deploy it. The original proposal gives suggested sections rather than a fixed format, and a card is only as reliable as the evaluation behind it.	Transparency Fairness Safety General
AI FactSheets	AI FactSheets is a documentation practice in which the developer or supplier of an AI model or service answers a structured set of questions about it, modelled on the supplier's declarations of conformity that industries such as telecommunications and transport use to give written assurance, with evidence, that a product meets stated requirements. The questions cover the service's purpose and its intended and unsuitable uses, the datasets it was trained and tested on, its test methods and results (reported for groups such as age bands or genders where relevant), checks for bias, explainability, behaviour on data unlike its training data and robustness to adversarial attack, how user data is secured, and its lineage, such as when and how its models were retrained; 'N/A' and 'Proprietary' are allowed answers. Facts are gathered from the people in each role across the lifecycle (business owner, data scientist, model validator and operations engineer), and any change to the service produces a new version of the FactSheet while earlier versions are kept. The originating group's seven-step method designs the template with its readers: interview the people who will read the facts and those who will produce them, draft and trial a template of questions, have the real producers complete it, evaluate the result with its readers for content and presentation, and build further templates for other audiences such as a review board or regulator. Unlike a model card, which reports one model's intended use and evaluation to the people choosing it, or a datasheet, which describes one dataset, a FactSheet may cover one model or a whole service built from several models and datasets (attaching their datasheets), gathers facts from each role in the lifecycle and has a different template for each audience; unlike a CycloneDX ML-BOM it is written for people to read rather than as a machine-readable parts list for software tools.	Transparency
Data Version Control	Data Version Control (DVC) is an open-source tool that records which version of a dataset or model was used at each point in a machine learning project. It works alongside Git, the standard system for tracking changes to code. DVC keeps large data and model files in separate storage, such as a cloud storage service, and puts a small pointer file into Git that holds a fingerprint (hash) of the file's contents. A team can also describe a pipeline, meaning the ordered steps from raw data through preprocessing to a trained model, and DVC then records fingerprints of each step's inputs, settings and outputs. Committed to Git, these files give a dated history of how data and models changed and let the team restore an earlier version, but only for what was added to DVC and committed.	General Transparency

Datasheets for Datasets

Description

Example Use Cases

Transparency

Safety

General

Limitations

Resources

Research Papers

Datasheets for Datasets

Tutorials

Create a dataset card — Hugging Face Datasets documentation

Documentations

Dataset Cards — Hugging Face Hub documentation

Tags

General Dimensions

Safety Dimensions

Transparency Dimensions

Other Categories