Data Card

Explicitly states why the dataset was created and its intended use cases. This section answers the fundamental question of fitness-for-purpose.

• Intended Task: Classification, generation, or object detection.
• Creator Context: The organizational or research objective driving data collection.
• Out-of-Scope Uses: Explicitly warns against high-risk applications the data was not designed for, such as using synthetic retail data for medical diagnosis.

Details the granular makeup and origin of every data instance. This establishes lineage and allows for bias auditing.

• Instance Breakdown: Counts of images, text records, or tabular rows, segmented by class labels.
• Collection Method: Specifies if data was scraped via the Robots Exclusion Protocol, captured by physical sensors, or generated synthetically.
• Source Attribution: Links to raw archives or APIs, ensuring Data Provenance is verifiable and not anecdotal.

Documents the raw acquisition process and the cleaning logic applied. This transparency is critical for detecting Training-Serving Skew.

• Sensing Hardware: Specifies camera models or LIDAR frequencies used, as hardware variance directly impacts model robustness.
• Cleaning Scripts: Links to the exact code used for deduplication or outlier removal.
• Human Involvement: Discloses if crowd-workers performed labeling, including their demographic context and inter-annotator agreement rates.

Provides a binary guide for safe deployment, distinguishing between validated applications and prohibited contexts.

• Safety Benchmarks: Cites specific evaluation scores (e.g., F1 > 0.95) achieved on the dataset for a given task.
• Ethical Constraints: Prohibits use in surveillance or profiling systems where Algorithmic Impact Assessments have not been completed.
• Temporal Validity: Warns if the data is subject to Concept Drift and specifies the expiration date for its statistical relevance.

Establishes the living document status of the dataset through strict Data Versioning protocols.

• Semantic Versioning: Tracks major changes (e.g., new classes added) vs. minor patches (e.g., label corrections).
• Errata Log: A public changelog documenting known errors or removed instances, supporting the Right to Erasure.
• Deprecation Policy: Defines the process for sunsetting the dataset without breaking downstream pipelines that depend on the Feature Store.

Surfaces the intellectual property and privacy posture of the data to mitigate regulatory risk.

• Governing Law: Specifies jurisdiction, such as GDPR for EU Data Sovereignty or CCPA for California residents.
• Consent Mechanism: Clarifies if data was collected via an Opt-Out Mechanism or explicit opt-in consent.
• IP Status: Declares if the dataset is a Derivative Work or licensed under permissive terms like CC-BY-4.0, directly informing Fair Use Doctrine analysis.

The documented chain of custody that establishes the origin, lineage, and transformation history of a dataset. A data card relies on robust provenance to verify claims about collection methodology. Without provenance, the 'Collection Process' section of a data card is merely anecdotal.

• Tracks source systems and ETL transformations
• Uses cryptographic hashing for immutability
• Essential for copyright and IP compliance audits

A granular, technical map of how data flows and mutates through pipelines. While provenance answers where data came from, lineage answers how it was transformed. Data cards summarize lineage for non-technical auditors, but the underlying lineage graph is what makes the summary auditable.

• Captures column-level transformations
• Enables impact analysis and root-cause debugging
• Visualized in tools like Apache Atlas or Marquez

The automated validation ensuring ingested data conforms to a predefined structure, data types, and constraints. A data card's 'Composition' section is a human-readable reflection of the schema. Schema enforcement prevents corrupt or malformed records from silently degrading dataset quality.

• Validates data types, null constraints, and value ranges
• Rejects non-conforming records at ingestion
• Implemented via tools like Great Expectations or Deequ

An adversarial attack where malicious samples are injected into a training dataset to corrupt model behavior. A rigorous data card documents security and sanitization procedures used to mitigate this risk. The 'Preprocessing/Cleaning' section should explicitly address poisoning defenses.

• Backdoor attacks trigger misclassification on specific triggers
• Availability attacks degrade overall model accuracy
• Defenses include outlier detection and provenance verification

The computational process of identifying which specific training examples most influenced a model's output. Data cards provide the metadata framework for attribution by documenting dataset splits and instance identifiers. This is increasingly critical for copyright compliance and the right to erasure.

• Uses influence functions or Shapley values
• Enables targeted machine unlearning
• Supports legal 'right to explanation' requirements