Model Cards for Model Reporting

🎯 Pitch

Commercial face recognition systems fail disproportionately on darker-skinned women—but we only discover this after users suffer the consequences. The authors propose "model cards," a standardized disclosure that surfaces such biases before deployment by reporting performance broken down across demographic and intersectional groups.

1. Executive Summary

This paper proposes model cards — short documents accompanying trained machine learning models that report benchmarked evaluation disaggregated across cultural, demographic, and phenotypic groups (e.g., race, geographic location, sex, Fitzpatrick skin type) as well as intersectional groups (e.g., age and race combined) — to standardize transparent model reporting for human-centric machine learning. The framework is demonstrated on two supervised models: a smiling detection classifier trained on the CelebA dataset, and a toxicity scoring classifier from Perspective API evaluated on a synthetically-constructed Identity Phrase Templates test set. Model cards include intended use, evaluation metrics (e.g., false positive rate, false negative rate, false discovery rate, false omission rate for classification; pinned AUC for score-based systems), training and evaluation data provenance, ethical considerations, and quantitative analyses broken down by unitary and intersectional groups, establishing that such documentation enables stakeholders — from ML practitioners and policymakers to impacted individuals — to assess model suitability, compare candidate models, and surface disproportionate errors only when models are accompanied by disaggregated performance reporting.

2. Context and Motivation

At the time of this paper's writing in 2019, trained machine learning models were being released and deployed into high-stakes domains — law enforcement, healthcare, education, and employment — with no standardized documentation of their performance characteristics. There was no established convention for what information should accompany a model when it leaves the lab and enters the world. This meant that anyone considering using a trained model — a product manager at a company, a policy analyst evaluating an algorithmic decision system, or a software developer integrating a cloud API into an application — had no systematic way to answer basic questions like: under what conditions does this model work? For whom does it fail? What were the assumptions baked into its training?

The paper frames this as a transparency gap with direct human consequences. The authors point to a now-famous sequence of discoveries (Section 1):

"Researchers have discovered systematic biases in commercial machine learning models used for face detection and tracking, attribute detection, criminal justice, toxic comment detection, and other applications. However, these systematic errors were only exposed after models were put into use, and negatively affected users reported their experiences."

The critical word here is "after." When Joy Buolamwini found that commercial face recognition systems failed to detect her face entirely, this was not something disclosed in any documentation accompanying those systems — it was discovered through her own independent testing, which then led to the "Gender Shades" study (Buolamwini & Gebru, 2018) showing disproportionate errors on darker-skinned women. The pattern was reactive: harm occurs, a user or researcher notices, they publish a study, the problem becomes public. There was no proactive mechanism for surfacing these performance disparities before deployment.

Why Documentation, Specifically, Is the Gap

The paper's diagnosis is that this isn't just a fairness problem or a model quality problem — it's fundamentally a documentation problem. The authors are not claiming that models lack biases (they do), or that evaluation doesn't happen (it does, internally). The claim is that when a model is released, whatever internal evaluation was conducted is not communicated to downstream users in any standardized, useful form. The stakes are enumerated directly:

"Despite the potentially serious repercussions of these errors, those looking to use trained machine learning models in a particular context have no way of understanding the systematic impacts of these models before deploying them."

This matters for multiple stakeholders (Section 3):

ML practitioners and software developers cannot compare models or understand failure modes before integration.
Policymakers and organizations cannot assess whether a model is appropriate for a given regulatory or operational context.
Impacted individuals — the people subject to model predictions — cannot understand how a system works or pursue remedies when it fails.

The authors argue that this documentation gap is distinct from gaps in model architecture, training methodology, or fairness mitigation. You can have an excellent model with rigorous internal testing and still create downstream harm if no one outside the development team knows the model's edge cases, failure modes, or intended use boundaries.

The Analogy: Mature Industries Have Standardized Reporting

The paper draws an explicit comparison to fields where standardized documentation is long-established (Section 2):

"Many mature industries have developed standardized methods of benchmarking various systems under different conditions. For example, as noted in [21], the electronic hardware industry provides datasheets with detailed characterizations of components' performances under different test conditions."

An electronic component datasheet tells you exactly what voltage range, temperature range, and humidity conditions the component is rated for, what its typical failure rates are, and what testing was performed. If you use an op-amp rated for 0–70°C in a 100°C environment, the failure is your responsibility, not the manufacturer's — but you can only make that informed decision because the datasheet told you the spec.

No such convention existed for machine learning models. A model card is the proposed analog: a datasheet for a trained model that tells you what it can and cannot do, under what conditions its performance degrades, and for what populations its error rates may be unacceptably high.

The paper also draws a parallel to medicine (Section 2), citing the TRIPOD statement (Transparent Reporting of a multivariable prediction model for Individual Prognosis Or Diagnosis; Collins et al., 2015) and the FDA's 1998 mandate that clinical trial results be disaggregated by age, race, and gender. The medical precedent is instructive because it emerged from the same reactive pattern: drugs developed and tested only on male participants were found to cause overdosing in women (a phenomenon noted in Section 2), and disaggregation requirements were instituted to prevent recurrence. The model card proposal applies this same logic to machine learning: if you only report aggregate accuracy, you cannot know whether the model is equally accurate across subgroups, and the failures will only be discovered after deployment.

Prior Approaches and Their Shortcomings

The paper positions itself in relationship to several contemporaneous proposals, all of which address pieces of the transparency problem but leave the model side unaddressed:

Datasheets for Datasets (Gebru et al., 2018). This is explicitly cited as the primary intellectual precursor. Datasheets document the motivation, composition, collection process, and recommended uses of a dataset. The model card is the complementary document for the trained model itself:

"Model cards (for model reporting) are complements to 'Datasheets for Datasets' and similar recently proposed documentation paradigms that report details of the datasets used to train and test machine learning models."

The distinction matters: a dataset can be well-documented but used to train a poorly-understood model; conversely, a well-documented model might be trained on poorly-characterized data. Both types of documentation are needed, and the paper envisions them as paired: each model card could reference its corresponding datasheets.

Data Statements for NLP (Bender & Friedman, 2018). This is another dataset-focused documentation effort, specifically tailored for natural language processing. Data Statements report speaker demographics, language varieties, and annotation practices. Again, the coverage is on the data side, not on trained model characteristics.

The Dataset Nutrition Label (Holland et al., 2018). This framework adapts the visual language of food nutrition labels to report dataset properties — a user-facing, glanceable format. It shares the goal of making data documentation accessible to non-experts, but does not address model-level reporting.

Factsheets / Supplier's Declarations of Conformity (Hind et al., 2018). This is the closest prior work to a model-level reporting framework. Factsheets propose that AI service suppliers provide standardized declarations about their models, including intended use, performance metrics, and safety considerations. The paper acknowledges this but does not position model cards as superseding or competing with Factsheets — rather, model cards are a specific instantiation of similar principles, with an explicit focus on disaggregated, intersectional evaluation by demographic and phenotypic groups, which is not a central organizing principle of the Factsheets proposal.

What's Missing: Intersectional, Disaggregated Model Evaluation. The paper's key point is that none of these prior frameworks, even those addressing models (like Factsheets), put disaggregated evaluation by unitary and intersectional groups at the center. The authors argue — and this is the paper's primary normative claim — that reporting aggregate accuracy is insufficient for human-centric models:

"We advocate for measures of model performance that contain quantitative evaluation results to be broken down by individual cultural, demographic, or phenotypic groups, domain-relevant conditions, and intersectional analysis combining two (or more) groups and conditions."

This is not a small addition to existing documentation practices; it's a fundamental reorientation. Standard ML evaluation reports accuracy on a holdout test set. A model card would report false positive rate and false negative rate separately for, say, younger men, older men, younger women, and older women (as shown in Figure 2). This surfaces performance disparities that aggregate metrics conceal.

The Intersectionality Argument

The paper grounds its call for intersectional analysis in Kimberlé Crenshaw's foundational work on intersectionality (Crenshaw, 1989), specifically citing the case of Emma DeGraffenreid (Section 2). The 1976 lawsuit against General Motors claimed discrimination against Black women, but the court dismissed it on the grounds that GM hired women (for secretarial roles, but those were only White women) and Black people (for factory roles, but those were only Black men). The dis-aggregation — reporting hiring rates separately by gender and by race — failed to capture the interaction: Black women were hired for neither.

The direct analog in model evaluation is clear: if you report accuracy by gender (finding that the model works well for men and for women in aggregate) and by age (finding that it works well for young people and old people in aggregate), you might still miss that older women have systematically higher error rates. The unitary breakdowns create a false impression of fairness because they mask the interaction effect. The paper insists that model cards must report metrics for intersectional subgroups — e.g., "older women," not just "women" and "older people" separately — to avoid the DeGraffenreid error.

Why a Standardized Framework Rather Than an Ad-Hoc Best Practice?

The paper is explicit that the goal is standardization, not merely encouragement:

"The proposal of 'Model Cards' specifically aims to standardize ethical practice and reporting — allowing stakeholders to compare candidate models for deployment across not only traditional evaluation metrics but also along the axes of ethical, inclusive, and fair considerations."

Standardization serves multiple purposes. First, it creates comparability: if every model is accompanied by a document with the same structure (model details, intended use, factors, metrics, evaluation data, quantitative analyses, ethical considerations, caveats), then potential users can make apples-to-apples comparisons between competing models. Second, it creates accountability: if the format is standardized, you can tell when required information is missing. Third, it creates a forcing function: the requirement to report disaggregated metrics incentivizes teams to collect the data necessary to compute those metrics — evaluation datasets with demographic and phenotypic annotations — which, the paper notes, are "not yet common."

This last point reveals a strategic dimension: model cards are not purely descriptive. By establishing the expectation that models will be evaluated on intersectional subgroups, the framework aims to create demand for better evaluation datasets and to shift development practice before models are released, not merely after.

How the Paper Positions Itself

The paper positions model cards as:

Complementary, not competitive, with Datasheets for Datasets, Data Statements, Nutrition Labels, and Factsheets. It's filling a specific gap (model-level reporting) that those frameworks leave open.
A transparency tool among many, not a standalone solution. The authors are careful to note in Section 6:

"The usefulness and accuracy of a model card relies on the integrity of the creator(s) of the card itself. It seems unlikely, at least in the near term, that model cards could be standardized or formalized to a degree needed to prevent misleading representations of model results."

This is a meaningful self-limiting claim. Model cards are proposed as one layer in a broader ecosystem that should also include third-party algorithmic auditing, adversarial testing, and inclusive user feedback mechanisms. The paper doesn't claim that documentation alone solves fairness — only that its absence makes fairness evaluation and accountability structurally impossible.
A framework, not a checklist. The suggested sections (Figure 1) are explicitly "not intended to be complete or exhaustive, and may be tailored depending on the model, context, and stakeholders" (Section 4). The paper provides structure (what to report) and rationale (why to report it), but acknowledges that a text toxicity model, a face detection model, and a clinical risk prediction model will have different relevant factors, metrics, and ethical considerations. The framework is designed to be flexible while still establishing minimum expectations — disaggregated evaluation, intended use disclosure, and transparent reporting of training and evaluation data.
Aimed at a broad audience, not just technical experts. The model card format (one to two pages, visual presentation of results, plain-language sections) is designed to be legible to policymakers, journalists, impacted communities, and organization decision-makers — not merely ML researchers. This is a deliberate design choice that reflects the paper's theory of change: transparency only works if the transparency artifacts are actually accessible to the people who need them.

3. Technical Approach

3.1 Reader Orientation

The "system" in this paper is not a piece of software — it is a standardized documentation framework called a model card that accompanies any trained machine learning model when it is released to users, developers, or the public. The problem it solves is that trained ML models are currently deployed without any structured disclosure of their performance characteristics, failure modes, or intended use boundaries, which means stakeholders (from software engineers to policymakers to impacted communities) have no systematic way to assess whether a model is appropriate for their context or to anticipate who will experience disproportionate errors. The shape of the solution is a short, structured document — one to two pages — organized into nine sections that together answer: what is this model, who is it for, what are its relevant evaluation factors (demographic groups, environmental conditions, instrumentation), how was it tested, and where does it fail?

3.2 Big-Picture Architecture (Diagram in Words)

The model card framework has nine major sections, each addressing a distinct question about the model. Information flows through these sections in a deliberate order — from basic identity (what is this?) through intended use (who is it for?) to risk factors (what could go wrong?) and finally to quantitative evidence (how do we know?). The components are:

Model Details — basic metadata: who built it, when, what type of model, where to find more information. This is the "identity card" section.
Intended Use — what the model was designed to do, who it's for, and explicitly what it should NOT be used for. This frames everything that follows.
Factors — the groups, environmental conditions, and instrumentation characteristics for which model performance may vary. This section defines the axes along which evaluation will be disaggregated.
Metrics — what quantitative measures are being reported and why they were chosen. This depends on whether the model is a classifier (confusion matrix metrics) or a score-based system (distribution comparison measures).
Evaluation Data — what datasets were used to evaluate the model, why they were chosen, and how they were preprocessed.
Training Data — ideally mirrors evaluation data; when full disclosure isn't possible, minimal information about distributions over groups should be provided.
Quantitative Analyses — the actual numbers: disaggregated results broken down by unitary factors and intersectional combinations, with confidence intervals where possible. This is the empirical core of the card.
Ethical Considerations — risks, mitigations, sensitive data usage, and fraught use cases.
Caveats and Recommendations — what's missing, what further testing is needed, and what an ideal evaluation dataset would look like.

These components are not independent — they form a chain of reasoning. Intended Use tells you what "good performance" means. Factors tell you which subgroups to worry about. Metrics operationalize performance in context-appropriate ways. Evaluation Data tells you how the evidence was gathered. Quantitative Analyses provide the evidence. Ethical Considerations contextualize the evidence in terms of potential harms. Caveats and Recommendations flag what the evidence cannot tell you.

3.3 Roadmap for the Deep Dive

I will explain the model card framework in the following order, because each section's design decisions depend on the conceptual commitments established in earlier sections:

First, the overall rationale and scope — what kind of paper this is (a framework proposal, not an empirical study) and what the core commitments are (disaggregated evaluation, intersectional analysis, transparency as a complement to other accountability mechanisms).
Second, Model Details and Intended Use — these establish the model's identity and purpose, which constrain everything else. I'll explain why "out-of-scope use cases" are structurally necessary, not optional.
Third, Factors — this is the most conceptually innovative section. I'll walk through what "groups," "instrumentation," and "environment" mean, why intersectional analysis is mandatory (not optional), and the deliberate tension between relevance and privacy when defining groups.
Fourth, Metrics — how the choice of metric depends on model type (classifier vs. score-based), and why the paper recommends reporting all four confusion-matrix-derived error types (FPR, FNR, FDR, FOR) rather than picking one. I'll explain the connection to formal fairness definitions and the importance of confidence intervals when sample sizes become small in disaggregated subgroups.
Fifth, Evaluation Data and Quantitative Analyses — these are paired because the analyses are only as meaningful as the data they're computed on. I'll explain the paper's unconventional recommendation to evaluate on both representative AND challenging datasets (including synthetic data when necessary), and why intersectional analysis requires deliberate evaluation dataset construction, not just post-hoc slicing.
Sixth, Training Data, Ethical Considerations, and Caveats — these sections acknowledge what the quantitative analysis cannot capture: biases encoded in training data distributions that basic evaluation metrics don't measure, ethical risks that aren't reducible to numbers, and gaps in the evaluation that users need to know about.
Seventh, the two worked examples (Smiling Classifier and Toxicity Classifier) — these are the paper's proof-of-concept, showing how the abstract framework translates to concrete model cards in two different modalities and model types, demonstrating both the flexibility and the common structure.
Eighth, design choices and tradeoffs — a synthesis of why specific decisions were made and what alternatives were considered or remain open.

3.4 Detailed, Sentence-Based Technical Breakdown

This is primarily a framework design paper whose core idea is that trained machine learning models, when released, should be accompanied by standardized, structured documentation that includes disaggregated performance evaluation by unitary and intersectional groups, enabling stakeholders to assess suitability, surface disproportionate errors, and compare models before deployment.

The Core Commitments: Disaggregation, Intersectionality, and Transparency as a Complement

Before diving into the individual sections, it's essential to understand the three normative commitments that structure every design decision in the model card framework:

Commitment 1: Aggregate metrics conceal disparities; disaggregation is mandatory. The paper rejects the standard practice of reporting a single accuracy or F1 score on a holdout test set, arguing (Section 4.7) that such aggregate reporting is actively misleading for human-centric models because it renders invisible the systematic performance differences across subpopulations. A smiling classifier with 90% overall accuracy might have 95% accuracy on younger women and 60% accuracy on older men — the aggregate number tells the product manager nothing about this disparity, and the disparity only matters if the model is deployed on a diverse population. The model card therefore requires that quantitative results be "broken down" by the chosen factors — unitary groups individually and intersectional groups in combination.

Commitment 2: Unitary breakdowns are insufficient; intersectional analysis is required. The paper explicitly invokes Crenshaw (1989) and the DeGraffenreid case to argue that evaluating by gender alone and by age alone can fail to detect errors concentrated at the intersection of these categories — older women, for instance. A model card that reports false negative rates for "men" and "women" and separately for "young" and "old" would miss that older women specifically have a high false negative rate. The framework therefore insists that quantitative analyses include intersectional results at whatever granularity the evaluation data and privacy constraints allow (Section 4.7).

Commitment 3: Documentation is a complement to, not a replacement for, other accountability mechanisms. The paper is explicit in Section 6 that model cards are "one transparency tool among many" and that their usefulness "relies on the integrity of the creator(s) of the card itself." They will not prevent bad actors from making misleading claims, and they cannot substitute for third-party auditing, adversarial testing, or inclusive user feedback. This self-limiting commitment shapes the design: the card is structured to make verifiable claims (quantitative results on named datasets) that can be independently checked, rather than relying on developer self-attestation alone.

Model Details: The Identity Card

This section answers "what is this thing, and who made it?" The prompts (Section 4.1) are intentionally straightforward because they serve an identification and provenance function — they allow a user to determine whether they're looking at the right model, the right version, and whether the source is credible.

The specific prompts are:

Person or organization developing model: This enables stakeholders to "infer details pertaining to model development and potential conflicts of interest." A toxicity classifier developed by a social media platform for internal moderation has different incentives than one developed by an academic research group.
Model date: This contextualizes what "techniques and data sources were likely to be available during model development." A model from 2017 trained with a convolutional neural network reflects different capabilities than a model from 2023 trained with a transformer.
Model version: This enables tracking of "whether the model is the latest version, associate known bugs to the correct model versions, and aid in model comparisons." The distinction matters concretely in the toxicity example (Figure 3): TOXICITY v. 1 and TOXICITY v. 5 show drastically different performance characteristics, and a user needs to know which one they're evaluating.
Model type: Basic architecture information (e.g., "Convolutional Neural Network" as shown in Figures 2 and 3). This "highlights what kinds of assumptions are encoded in the system" for knowledgeable practitioners — e.g., a CNN embeds translation invariance assumptions, which matter for certain types of image inputs.
Paper or other resource: A pointer for deeper technical information.
Citation details: How to cite the model.
License: Usage terms.
Feedback on the model: A contact address for questions.

A critical design choice here is what the paper does not require. The authors explicitly note (Section 4.1) that "there are cases where some of this information may be sensitive" and that "this section should not be seen as a requirement to compromise private information or reveal proprietary training techniques." The boundary is: disclose enough for identification, provenance, and basic technical understanding, but the model card is not a technical paper. A corporate developer might disclose "transformer-based language model" without revealing the exact architecture, training schedule, or proprietary optimization techniques. This is a deliberate pragmatism — the framework must be adoptable by industry, not only by academic researchers who can share everything.

Intended Use: Bounding the Model's Legitimate Scope

This section is not merely descriptive — it is normative and constraining. It serves to establish what the model was designed for and, equally importantly, what it was not designed for. The paper draws an analogy to "warning labels on food and toys, and similar disclaimers presented in electronic datasheets" (Section 4.2). This analogy is instructive: a warning label on a toy ("choking hazard: not for children under 3") doesn't just inform, it establishes a boundary of manufacturer responsibility and user expectation.

The section has three sub-components:

Primary intended uses: This can be "as broadly or narrowly defined as the developers intend." In the smiling classifier example (Figure 2), intended uses include "fun applications, such as creating cartoon smiles on real images; augmentative applications, such as providing details for people who are blind; or assisting applications such as automatically finding smiling photos." The key observation is that these are all applications where the consequence of error is low — a cartoon smile applied to the wrong face, or a missed smiling photo, is not a high-stakes error.

Primary intended users: This captures the expected audience and sophistication level. The smiling classifier is "particularly intended for younger audiences" — a signal that it has not been stress-tested on elderly faces and may perform poorly there (which is, in fact, what the quantitative analysis shows for older men).

Out-of-scope uses: This is the most structurally important sub-component because it creates an affirmative disclosure of limitations that the developer is aware of. The smiling classifier card states: "Not suitable for emotion detection or determining affect; smiles were annotated based on physical appearance, and not underlying emotions." This is critical: without this disclosure, a user might reasonably assume that a "smile detector" detects happiness and deploy it in a mental health monitoring application, with potentially harmful consequences. The disclosure draws a bright line: this model detects a facial muscle configuration, not an emotional state.

The out-of-scope section also serves as a negative specification mechanism — it tells users what the model might easily be confused with and "may provide an opportunity to recommend a related or similar model that was designed to better meet that particular need, where possible." Examples given include "not for use on text examples shorter than 100 tokens" or "for use on black-and-white images only; please consider our research group's full-color-image classifier for color images."

The design rationale is twofold: (1) it protects users from category errors (using a smile detector as an emotion detector, using a toxicity classifier as a content moderation decision-maker), and (2) it protects developers by establishing documented boundaries of intended use that can be referenced if a model is misapplied.

Factors: Defining the Axes of Disaggregation

This is the conceptually richest section of the model card. It defines what systematic variation in performance the developer expects or suspects, and therefore what axes the evaluation should be disaggregated along. The section introduces three categories of factors, but the critical insight is that not all relevant factors may be evaluable given available data — and the card must be honest about that gap.

Groups (Section 4.3.1)

"Groups" are "distinct categories with similar characteristics that are present in the evaluation data instances." For human-centric models, groups are people who share one or multiple cultural, demographic, or phenotypic characteristics. The paper is careful about what group categories it recommends and why:

For computer vision models: "the visual presentation of age, gender, and Fitzpatrick skin type may be relevant." Fitzpatrick skin type (Fitzpatrick, 1988) is a six-point scale originally developed for dermatology to classify skin's response to UV light, adapted in ML fairness work (particularly following Buolamwini & Gebru, 2018) as a proxy for how computer vision systems perform across skin tones.
For NLP models: the toxicity example (Figure 3) uses "identity terms referencing frequently attacked groups, focusing on sexual orientation, gender identity, and race" as the relevant groups.

The crucial design choice is that groups should be defined based on what is relevant to the model's domain and intended use, not based on a universal checklist. A facial recognition model deployed in a dermatology clinic might need Fitzpatrick skin type and age; a speech recognition model might need dialect, accent, and age; a résumé screening model might need gender, race, and educational background. The framework provides principles for selection (relevance, foreseeable harm) but not a fixed set of groups.

The paper also addresses the practical and ethical complexities of group labeling (Section 2):

"How 'ground truth' race or gender categories should be labeled in a dataset, and whether or not datasets should be labeled with these categories at all, is not always clear. This issue is further confounded by the complex relationship between gender and sex."

The recommendation is to use either (1) datasets with self-identified labels, or (2) datasets with labels clearly designated as perceived rather than self-identified. When neither is possible, "datasets of public figures with known public identity labels may be useful." These are not presented as ideal solutions but as practical accommodations in a world where existing evaluation datasets (like CelebA) already have third-party annotations of perceived gender and age based on visual appearance. The paper explicitly flags this as an open problem: "Further research is necessary to expand how groups may be defined, for example, by automatically discovering groups with similarities in the evaluation datasets."

Instrumentation (Section 4.3.2)

Performance can vary not just by who is being classified but by what equipment captured the input. For a face detection model, relevant instrumentation factors include "camera's hardware and software, including lens, image stabilization, high dynamic range techniques, and background blurring for portrait mode" as well as "real or simulated traditional camera settings such as aperture, shutter speed and ISO." For an audio model, the microphone type, sampling rate, and background noise profile would be relevant.

This category is important because it captures a class of systematic errors that are not demographic — a model might fail equally on all groups under low-light conditions, or it might fail disproportionately on darker skin tones specifically under low-light conditions. The interaction between instrumentation and group factors can be critical: a model that performs well on darker skin tones under studio lighting might degrade sharply under the poor lighting conditions typical of surveillance cameras or doorbell cameras, producing intersectional failures (dark skin + low light) that neither factor alone would reveal.

Environment (Section 4.3.3)

Similarly, environmental conditions like "lighting and moisture conditions" (cited for face detection) systematically affect performance. A model trained on clear, well-lit images may degrade under fog, rain, or extreme sunlight. Again, these effects may interact with group factors — e.g., a model's accuracy on darker skin tones might be more sensitive to lighting conditions than its accuracy on lighter skin tones.

The Relevant Factors vs. Evaluation Factors Distinction

The paper introduces a critical distinction between two prompts (Section 4.3.4):

Relevant factors: "What are foreseeable salient factors for which model performance may vary, and how were these determined?" This captures what the developer should evaluate — the complete set of factors that domain knowledge and prior literature suggest could matter.
Evaluation factors: "Which factors are being reported, and why were these chosen?"

The gap between these two is explicitly acknowledged as potentially large. The smiling classifier card (Figure 2) states:

"Based on known problems with computer vision face technology, potential relevant factors include groups for gender, age, race, and Fitzpatrick skin type; hardware factors of camera type and lens type; and environmental factors of lighting and humidity."

But the evaluation factors actually reported are only "gender and age group, as annotated in the publicly available dataset CelebA." The card then adds:

"Further possible factors not currently available in a public smiling dataset."

This is not a flaw in the smiling classifier card — it is a feature of the framework. By requiring developers to contrast what should be evaluated with what was evaluated, the model card surfaces the limitations of available evaluation data. A user reading this card knows that race and skin type were not evaluated, not because they're irrelevant (they are relevant, as the Gender Shades study showed), but because the available evaluation dataset didn't include those annotations. This creates demand for better evaluation datasets and prevents the card from creating a false sense of completeness.

The paper's suggested resolution for this gap is deliberately forward-looking:

"An ideal evaluation dataset would additionally include annotations for Fitzpatrick skin type, camera details, and environment (lighting/humidity) details."

This is stated in the Caveats and Recommendations section of the smiling classifier card (Figure 2), and represents the framework's mechanism for pushing the field toward better evaluation infrastructure.

Metrics: Choosing What to Measure

The appropriate metrics depend on the type of model. The paper distinguishes two broad categories, each with distinct reporting requirements.

Classification Systems (Section 4.4.1)

For binary classification systems (like the smiling detector), the paper recommends reporting all four metrics derivable from a confusion matrix, not just accuracy:

False Positive Rate (FPR): The fraction of actual negatives that are incorrectly predicted as positive. In the smiling detector: what fraction of non-smiling faces are classified as smiling?
False Negative Rate (FNR): The fraction of actual positives that are incorrectly predicted as negative. In the smiling detector: what fraction of smiling faces are classified as not smiling?
False Discovery Rate (FDR): The fraction of predicted positives that are actually negative. In the smiling detector: of all the faces the model says are smiling, what fraction are actually not smiling?
False Omission Rate (FOR): The fraction of predicted negatives that are actually positive. In the smiling detector: of all the faces the model says are not smiling, what fraction are actually smiling?

The reason to report all four rather than selecting one is that the relative importance of each metric is "system, product and context dependent" (Section 4.4.1). The paper provides a concrete example:

"In a surveillance scenario, surveillors may value a low false negative rate (or the rate at which the surveillance system fails to detect a person or an object when it should have). On the other hand, those being surveilled may value a low false positive rate (or the rate at which the surveillance system detects a person or an object when it should not have)."

This is a critical insight for model cards: the stakeholder who chooses to deploy a model may have different error tradeoff preferences than the stakeholders affected by the model's errors. By reporting all four metrics (not just the one the developer optimized), the card enables different stakeholders to evaluate the model against their criteria. The paper recommends "listing all values and providing context about which were prioritized during development and why."

Connection to formal fairness definitions. The paper notes that parity on certain confusion-matrix metrics across groups corresponds to specific formal fairness criteria (Section 4.4.1):

Equal false negative rates across groups is equivalent to Equality of Opportunity (Hardt et al., 2016) — the model is equally good at correctly identifying positives across groups.
Equal false positive rates AND equal false negative rates across groups is equivalent to Equality of Odds (Hardt et al., 2016) — the model makes the same types of errors at the same rates across groups.

This connection matters because it ties the model card's descriptive reporting to the normative language of fairness: a model card that reports FPR and FNR by subgroup doesn't just describe performance — it provides the raw materials for a fairness audit. The card itself doesn't assert whether the observed disparities are "fair" or "unfair" (that's a contextual judgment), but it provides the evidence needed to make that judgment.

Decision thresholds. For models whose output is a score that is thresholded to produce a binary decision, the model card should report the threshold used and, ideally, provide a mechanism to explore performance across different thresholds: "When the model card is presented in a digital format, a threshold slider should ideally be available to view performance parameters across various decision thresholds." This acknowledges that the developer's chosen threshold may not be appropriate for all use contexts, and that threshold selection itself is a fairness-relevant decision (a higher threshold reduces false positives but increases false negatives, which may shift burdens across groups differently).

Score-Based Systems (Section 4.4.2)

For systems where the primary output is a score rather than a class label — pricing models, risk assessment algorithms, or any system where comparing raw outputs across instances is the natural analysis — the paper recommends reporting differences in the distribution of scores across groups, not just point estimates. Specific recommendations include:

Measures of central tendency: mode, median, mean
Measures of dispersion: range, quartiles, absolute deviation, variance, standard deviation
Distribution comparison measures: cross entropy, perplexity, KL divergence, and "pinned AUC" (pinned area under the curve, as used in the toxicity example)

The paper also observes that many systems that don't initially appear score-based can be usefully analyzed as score-based for disaggregated evaluation:

"Although the primary outputs of these systems are not scores, looking at the score differences between populations may yield meaningful insights since comparing raw inputs quickly grows too complex."

For a translation system, you could compare BLEU score distributions across demographic groups of speakers. For a speech recognition system, you could compare word error rate distributions. The principle is: find a scalar metric of quality, then analyze its distribution across groups rather than reporting only the aggregate mean.

Confidence Intervals (Section 4.4.3)

Disaggregating evaluation by subgroups inevitably shrinks sample sizes — an evaluation dataset of 10,000 examples might have only 200 older women, or only 50 examples of a particular intersectional group. Small sample sizes make point estimates unreliable. The paper explicitly calls for confidence interval reporting:

"Performance metrics that are disaggregated by various combinations of instrumentation, environments and groups makes it especially important to understand the confidence intervals for the reported metrics."

The recommended method for classification metrics is to treat confusion matrices as "probabilistic models of system performance" (citing Goutte & Gaussier, 2005) and calculate confidence intervals accordingly. The smiling classifier card (Figure 2) reports "95% confidence intervals calculated with bootstrap resampling." This is a critical practical detail — without confidence intervals, a user might overinterpret a 5% FPR difference between two subgroups that is statistically insignificant given the sample size. The framework requires quantifying uncertainty alongside point estimates.

The decision threshold choice. For the smiling classifier, the card notes: "All metrics reported at the .5 decision threshold, where all error types (FPR, FNR, FDR, FOR) are within the same range (0.04 - 0.14)." This reveals an intentional design decision: the threshold was chosen to balance error rates rather than to optimize a single metric. The disclosure of this choice allows users to assess whether that balance is appropriate for their context.

Evaluation Data: What the Model Was Tested On

The Evaluation Data section addresses a fundamental tension in model evaluation: the ideal evaluation dataset would be both representative of intended users and representative of challenging edge cases. These goals are often in tension. The paper recommends evaluating on both types:

"The evaluation datasets should not only be representative of the model's typical use cases but also anticipated test scenarios and challenging cases."

For example, if a model is intended for a "workplace that is phenotypically and demographically homogeneous," the card should include (1) an evaluation dataset that matches that workplace population (to measure expected performance in the target context), and (2) a separate evaluation dataset with "individuals that might be more challenging for the model (such as children, the elderly, and people from outside the typical workplace population)." The first dataset measures whether the model works for its intended users; the second measures whether it fails catastrophically on anyone else — for instance, if a visitor, contractor, or client from outside the homogeneous workplace population triggers the model and receives erroneous outputs.

Synthetic evaluation data. The paper makes an unconventional recommendation: when real datasets don't represent populations that need to be evaluated, synthetically generated data is acceptable:

"It is often difficult to find datasets that represent populations outside of the initial domain used in training. In some of these situations, synthetically generated datasets may provide representation for use cases that would otherwise go unevaluated."

The toxicity model card (Figure 3) uses exactly this approach. The evaluation data is described as:

"A synthetic test set generated using a template-based approach, as suggested in [11], where identity terms are swapped into a variety of template sentences."

The justification is specific and important:

"Synthetic data is valuable here because [11] shows that real data often has disproportionate amounts of toxicity directed at specific groups. Synthetic data ensures that we evaluate on data that represents both toxic and non-toxic statements referencing a variety of groups."

This is a subtle but critical point. In a naturally occurring dataset (e.g., online comments), the phrase "I am a lesbian" and the phrase "I am a straight man" may appear with very different frequencies, and comments containing the former may have systematically different toxicity labels than comments containing the latter — not because the classifier is biased, but because the real-world toxicity directed at those groups differs. Synthetic data breaks this confounding by ensuring equal representation of toxic and non-toxic content for each identity term, allowing the evaluator to isolate model bias from base-rate differences in the data distribution.

The paper explicitly acknowledges the limitation: "Synthetic test data covers only a small set of very specific comments. While these are designed to be representative of common use cases and concerns, it is not comprehensive." This is flagged in the Caveats and Recommendations section (Figure 3), maintaining the framework's pattern of pairing positive claims with explicit limitations.

Preprocessing disclosure. The card should detail how evaluation data was prepared: "tokenization of sentences, cropping of images, any filtering such as dropping images without faces." This matters because preprocessing decisions (e.g., resizing images to a fixed resolution, lowercasing text) can differentially affect subgroups. If a face detection model's evaluation pipeline drops all images where the face detector fails to find a face, the evaluation systematically excludes the exact cases where the model performs worst — a form of survivorship bias that inflates reported accuracy.

Training Data: What the Model Learned From

The model card framework acknowledges a practical tension here. In an ideal world, the training data section would mirror the evaluation data section in detail level — disclosing the dataset composition, collection process, and distribution over groups. However:

"There might be cases where it is not feasible to provide this level of detailed information about the training data. For example, the data may be proprietary, or require a non-disclosure agreement."

The minimum standard is therefore lower: "basic details about the distributions over groups in the data, as well as any other details that could inform stakeholders on the kinds of biases the model may have encoded" (Section 4.6). Even if you can't release the training data or fully describe it, you can report that the training data was, for instance, 70% lighter-skinned individuals, or that it contained comments primarily from US-based English speakers, or that it was collected from a specific time period. This minimal disclosure serves as a bias prior — it tells users what kinds of systematic errors to expect, even if the exact mechanism can't be audited.

The toxicity card (Figure 3) provides an example of partial training data disclosure:

"Proprietary from Perspective API. Following details in [11] and [32], this includes comments from online forums such as Wikipedia and New York Times, with crowdsourced labels of whether the comment is 'toxic'."

And crucially, the definition of "toxic" used in labeling is disclosed: "a rude, disrespectful, or unreasonable comment that is likely to make you leave a discussion." This definition, provided by the annotators, makes explicit a value judgment that might otherwise be implicit and unexamined. Someone reading this can immediately see that "toxic" doesn't mean "factually false," "hateful," or "harassing" — it means "likely to make you leave a discussion," which is a specific, contestable operationalization.

Quantitative Analyses: The Evidence Section

This is the empirical core of the model card. It has two structural requirements:

Unitary results: "How did the model perform with respect to each factor?" For the smiling classifier (Figure 2), this means reporting FPR, FNR, FDR, and FOR separately for each gender and each age group, and plotting them with confidence intervals. The card must present actual numbers, not qualitative statements.

Intersectional results: "How did the model perform with respect to the intersection of evaluated factors?" For the smiling classifier, this means reporting the same metrics for the four intersectional subgroups: younger women, older women, younger men, older men. The card must demonstrate that unitary breakdowns are insufficient.

The visualization in Figure 2 uses horizontal bar charts with confidence intervals, grouped by metric type and colored by subgroup. This design choice prioritizes comparability: you can immediately see, for each error type, which subgroup has the highest rate and whether the confidence intervals overlap.

For the toxicity classifier (Figure 3), the metric is pinned AUC (pinned area under the curve), as introduced in Dixon et al. (2018). This metric requires some explanation:

$\text{Pinned AUC}(g) = \text{AUC}(\text{examples with identity term } g, \text{all other examples})$

where $g$ is a specific identity term (e.g., "lesbian," "gay," "homosexual," "Black," "Muslim"). The pinned AUC measures how well the classifier separates toxic from non-toxic comments within the context of a background distribution of other groups. Specifically, it computes the AUC for the binary task of distinguishing toxic and non-toxic examples containing the identity term $g$ from all other examples (both toxic and non-toxic, containing any identity term or none).

What it computes: For each identity term $g$ , the metric constructs a pooled set consisting of (1) all comments containing $g$ (both toxic and non-toxic) and (2) all comments not containing $g$ . The pinned AUC then measures how well the classifier's toxicity score separates the toxic from non-toxic comments within this pooled set. A low pinned AUC for a group means the classifier has difficulty distinguishing toxic from non-toxic comments for that group — it's essentially scoring both toxic and non-toxic comments similarly. A value around 0.5 indicates random performance; a value near 1.0 indicates perfect separation.

Why this form: The standard AUC on a dataset containing disproportionate toxicity by group would be misleading because groups that receive more actual toxicity would naturally have higher toxicity scores, which could be misinterpreted as classifier bias when it's actually reflecting the data distribution. The pinned AUC controls for this by comparing each group's examples against a shared background distribution, isolating the classifier's discriminatory power from base-rate differences. The "pinned" aspect — fixing the background to all other examples — ensures that the comparison is consistent across groups and not driven by differences in the non-toxic distribution for different identity terms.

The toxicity card reports pinned AUC for multiple identity terms across two model versions (v. 1 and v. 5), showing that v. 1 had low pinned AUC for terms like "lesbian," "gay," and "homosexual" (meaning the classifier couldn't distinguish toxic from non-toxic uses of these terms), and that v. 5 substantially improved these values through bias mitigation techniques.

Ethical Considerations: Beyond the Numbers

This section addresses dimensions of model impact that are not captured by quantitative metrics. The prompts (Section 4.8) are intentionally open-ended, guiding reflection rather than prescribing specific content:

Data: "Does the model use any sensitive data (e.g., protected classes)?"
Human life: "Is the model intended to inform decisions about matters central to human life or flourishing – e.g., health or safety? Or could it be used in such a way?"
Mitigations: "What risk mitigation strategies were used during model development?"
Risks and harms: "What risks may be present in model usage? Try to identify the potential recipients, likelihood, and magnitude of harms. If these cannot be determined, note that they were considered but remain unknown."
Use cases: "Are there any known model use cases that are especially fraught?"

The design philosophy here is distinct from the quantitative sections. Those sections report what was measured; this section reports what was considered and what might go wrong, including scenarios that cannot be measured from available data. For the toxicity classifier (Figure 3), the ethical considerations include referencing the Perspective API's "set of values to guide their work" — Community, Transparency, Inclusivity, Privacy, and Topic-neutrality — and noting that "because of privacy considerations, the model does not take into account user history when making judgments about toxicity." This disclosure matters because a toxicity classifier that did incorporate user history would raise different privacy concerns and would require different ethical analysis.

The importance of acknowledging unknown risks. The paper explicitly instructs developers to note when risks "cannot be determined" but "were considered." This prevents the ethical considerations section from implying comprehensiveness when the developer lacks information. It also creates a record: if a harm materializes that the developer genuinely didn't anticipate, the card makes visible that it was at least considered as a category of concern.

Caveats and Recommendations: What's Missing

This final section serves as a limitations disclosure and a call to action. It should address:

Gaps in the evaluation: "Did the results suggest any further testing? Were there any relevant groups that were not represented in the evaluation dataset?"
Recommendations for use: What additional constraints should users apply?
Ideal future evaluation: "What are the ideal characteristics of an evaluation dataset for this model?"

The smiling classifier card (Figure 2) demonstrates this:

"Does not capture race or skin type, which has been reported as a source of disproportionate errors [5]."

"Given gender classes are binary (male/not male), which we include as male/female. Further work needed to evaluate across a spectrum of genders."

"An ideal evaluation dataset would additionally include annotations for Fitzpatrick skin type, camera details, and environment (lighting/humidity) details."

Each caveat is paired with a specific citation or rationale, making the limitation verifiable rather than generic.

The toxicity classifier card (Figure 3) adds a domain-specific caveat:

"Synthetic test data covers only a small set of very specific comments. While these are designed to be representative of common use cases and concerns, it is not comprehensive."

This is structurally important: the card uses synthetic data to enable intersectional evaluation that wouldn't otherwise be possible, and then immediately discloses the limitation of that approach. The reader is not left with a false sense of thoroughness.

The Two Worked Examples as Proof-of-Concept

The paper provides two complete model cards (Figures 2 and 3) that demonstrate the framework's application to qualitatively different model types:

Smiling classifier (image classification): Evaluated on CelebA, with factors of gender and age (binary male/female, binary young/old, as annotated by third-party annotators based on visual presentation). Metrics are the four confusion-matrix error types (FPR, FNR, FDR, FOR) at a 0.5 decision threshold. Quantitative analyses include unitary results (error rates by gender alone, by age alone) and intersectional results (error rates for the four gender × age subgroups). Key finding demonstrated: the false discovery rate on older men is substantially higher than for other groups, visible only in the intersectional breakdown.

Toxicity classifier (text scoring): Evaluated on the synthetically-constructed Identity Phrase Templates test set, with identity terms referencing sexual orientation, gender identity, and race as the relevant factors. Metric is pinned AUC — chosen because standard accuracy or F1 would be confounded by base-rate differences in toxicity across groups. Quantitative analyses compare two model versions (v. 1 and v. 5) side-by-side, demonstrating that pinned AUC for terms like "lesbian," "gay," and "homosexual" improved substantially from v. 1 to v. 5 through bias mitigation techniques.

The two examples together demonstrate the framework's claimed flexibility: different modalities (vision vs. text), different model types (classifier vs. score-based), different metrics (confusion-matrix error types vs. pinned AUC), different factor types (visual presentation of demographics vs. identity terms in text), and different evaluation data types (real face dataset vs. synthetic template dataset). Yet both follow the same nine-section structure, demonstrating that the framework is a genuine abstraction rather than a template specific to one domain.

Design Choices and Their Justifications

Why one to two pages? The paper explicitly says "short (one to two page) records" (Section 1). This is a deliberate constraint: the model card must be concise enough to actually be read by non-experts (policymakers, journalists, product managers), not just by ML researchers who might read a 20-page technical report. The constraint forces prioritization: what are the most critical things a stakeholder needs to know? The nine sections represent the authors' answer.

Why not require all relevant factors to be evaluated? The paper acknowledges the gap between what should be evaluated and what can be evaluated given currently available datasets. Rather than making the framework impossible to adopt (by requiring annotations that don't exist for most evaluation datasets), the framework requires developers to be transparent about the gap. This is a pragmatism that enables adoption while simultaneously creating pressure to close the gap — if every model card says "ideally we would have evaluated on Fitzpatrick skin type, but no public dataset with those annotations exists," that creates a clear agenda for dataset creators.

Why intersectional analysis is mandatory, not optional? The paper grounds this in Crenshaw's legal and theoretical work, but the practical justification is clear from the DeGraffenreid example: unitary breakdowns can systematically miss the most vulnerable subgroups. A model card that reports accuracy by gender and by race but not by gender × race is making an implicit claim that the intersection doesn't matter — a claim the paper rejects on both empirical (Buolamwini & Gebru, 2018) and normative (intersectionality theory) grounds.

Why report all four confusion-matrix metrics rather than just accuracy? Because different stakeholders have different error cost functions. The developer who optimized for overall F1 doesn't get to decide that false positives and false negatives are equally important for every use case. Reporting all four metrics allows downstream stakeholders to make their own tradeoff assessments. This also surfaces a fairness-relevant dynamic: a model might have equal accuracy across groups but very different FPR/FNR profiles — high FPR on one group, high FNR on another — which aggregate accuracy conceals.

Why the emphasis on confidence intervals? Because disaggregated evaluation necessarily operates on smaller subgroups, and small sample sizes produce noisy estimates. Without confidence intervals, a user might make deployment decisions based on apparent disparities that are statistically indistinguishable from noise. The framework's insistence on quantifying uncertainty is a guardrail against overinterpretation.

Why synthetic evaluation data is acceptable? Because the alternative — not evaluating on underrepresented groups at all — is worse. A synthetic evaluation dataset with known limitations is better than no evaluation dataset for groups absent from existing real-world datasets. The framework mitigates the risk of synthetic data by requiring explicit caveats about its limitations.

Why the "intended use" and "out-of-scope use" sections matter structurally? They create an affirmative disclosure that can be referenced later. If a model card says "not suitable for emotion detection" and someone deploys it for emotion detection, the developer has documented that this was an out-of-scope use. This is not a legal shield (the paper makes no legal claims), but it is an accountability mechanism — it shifts some burden of due diligence to the deployer.

Why separate "ethical considerations" from "quantitative analyses"? Because many ethically relevant factors cannot be reduced to numbers. The fact that a model uses sensitive data, or could be repurposed for surveillance, or makes assumptions about gender as binary, or was trained on data from a specific time period — these are not numerical quantities, but they are essential for responsible deployment decisions. The separation prevents the quantitative analysis from being mistaken for a complete ethical evaluation.

4. Key Insights and Innovations

Innovation 1: Disaggregated Evaluation Is Not a Fairness Metric — It's an Epistemological Requirement for Knowing What Your Model Does

The most fundamental intellectual move in this paper is not the proposal of a documentation format (that's the mechanism), but the claim that aggregate accuracy is an active concealment device, not a neutral summary. Before this paper, the dominant practice in ML evaluation was to report performance on a holdout test set as a single scalar — overall accuracy, F1, BLEU — and treat that number as the answer to "how well does this model work?" The Gender Shades study (Buolamwini & Gebru, 2018) had demonstrated that this aggregate conceals massive subgroup disparities, but that finding was still framed primarily as a fairness problem — a normative concern about equitable treatment.

This paper reframes the issue as something more fundamental: if you report only aggregate accuracy, you literally do not know what your model does. You don't know whether the 90% accurate smiling detector is 95% accurate on younger women and 60% on older men, or vice versa, or anything in between. The aggregate number is consistent with infinitely many subgroup performance profiles, and without disaggregation, you are simply ignorant of which profile is true. The smiling classifier results in Figure 2 make this concrete: the false discovery rate on older men is substantially higher than on other groups, and this would be invisible in any aggregate accuracy report. The model's behavior is qualitatively different for different people, and aggregate metrics render that qualitative difference invisible.

This is a more radical claim than "we should care about fairness." It's an epistemological claim: standard evaluation practice produces ignorance. A developer who reports only overall accuracy has not merely failed to check for fairness — they have failed to characterize their model's behavior in any meaningful way. The model card's central requirement — disaggregated evaluation by unitary and intersectional groups — is not an optional fairness add-on; it is the minimum necessary condition for claiming to understand what a human-centric model does.

The comparison to drug trials in Section 2 reinforces this: when drugs were tested only on men, the problem wasn't just "unfairness to women" — the problem was that the medical community literally did not know the correct dosage for women, leading to overdosing. The knowledge was absent, not merely inequitably distributed. The model card proposal applies the same logic: if you don't evaluate on darker-skinned women, you don't know whether your face detection model works on darker-skinned women — you have no knowledge one way or the other, and any deployment that encounters darker-skinned women is an uncontrolled experiment.

This constitutes a fundamental conceptual shift, not just an incremental addition to evaluation practice, because it changes what counts as "knowing your model's performance." The pre-2019 default — "we got 92% on the test set, we know the model works" — is reframed as "you know one summary statistic that is consistent with arbitrarily large failures on arbitrarily large subgroups, and you are choosing not to look."

Innovation 2: Intersectional Analysis Is Structural, Not Optional — The Unitary Breakdown Trap

The paper's insistence on intersectional analysis — reporting metrics for combinations of factors (e.g., older women), not just factors individually (e.g., women, older people) — is not merely an application of Crenshaw's intersectionality framework to ML evaluation. It is a diagnosis of a specific, reproducible failure mode in disaggregated reporting: the unitary breakdown trap.

The trap works as follows. A well-intentioned developer disaggregates evaluation by gender and finds equal false negative rates. They disaggregate by age and find equal false negative rates. They conclude the model is fair across both dimensions. But this conclusion is logically invalid — the unitary equalities are consistent with a model that has a 5% FNR on younger men, a 5% FNR on younger women, a 5% FNR on older men, and a 30% FNR on older women. The equality on each unitary slice is maintained by averaging the high-performing and low-performing intersectional subgroups within each slice. The developer, having checked the unitary breakdowns, has a false sense of confidence.

The DeGraffenreid example (Section 2) operationalizes this perfectly: GM hired women (White women for secretarial roles) and hired Black people (Black men for factory roles), so unitary analyses showed no discrimination by gender and none by race. The intersectional analysis — Black women — revealed that both unitary claims were artifacts of averaging over hiring categories that were themselves segregated. The direct analog in ML: reporting equal FNR "for women" can be an artifact of equalizing high performance on younger women and abysmal performance on older women with the reverse pattern for men, producing unitary equality that masks stark intersectional disparities.

What makes this a genuine innovation rather than an obvious corollary of intersectionality theory is that the paper identifies it as a systematic failure mode of the evaluation structure itself, not just a social justice concern. The unitary breakdown trap is not about developers being careless or biased — it's about the mathematical fact that equality on marginals does not imply equality on joints. A documentation framework that requires only unitary breakdowns is structurally incapable of surfacing certain classes of disparities, and the paper provides a concrete remedy (mandatory intersectional results in Section 4.7) whose absence is not a political choice but a logical gap in the evaluation procedure.

This is a fundamental reframing: intersectional analysis moves from "progressive best practice" to "basic logical hygiene for any evaluation that claims to characterize subgroup performance." It is not an incremental improvement over standard disaggregated reporting — it's the difference between a reporting framework that can detect the DeGraffenreid pattern and one that is structurally blind to it.

Innovation 3: Out-of-Scope Use as an Affirmative Disclosure — Moving from "Caveat Emptor" to "Documented Boundaries"

The intended use and out-of-scope use sections (4.2) represent a conceptual innovation in how the ML community thinks about developer responsibility for downstream misuse. The pre-2019 default was essentially caveat emptor: a developer releases a model (or an API), users apply it however they want, and if a user applies a smiling detector to emotion recognition and gets nonsense results, that's the user's problem — they should have known better. The model's limitations were the user's responsibility to discover.

The model card framework inverts this relationship. By requiring developers to affirmatively state what the model should not be used for — "Not suitable for emotion detection or determining affect; smiles were annotated based on physical appearance, and not underlying emotions" (Figure 2) — the framework creates a documented boundary that the developer has already considered and flagged. This is not a legal mechanism (the paper makes no legal claims), but an accountability mechanism: it shifts the informational burden. A user who deploys the smiling detector for emotion recognition despite the card's explicit warning is not merely making a mistake — they are acting against documented developer guidance.

What makes this innovative is the reversal of the default assumption about what developers know and what users should infer. The pre-2019 assumption was that users should figure out limitations from the model's architecture, training data, and published results. The model card assumption is that developers know their model's limitations better than anyone (they chose the training data, the task formulation, the loss function), and that failing to disclose those limitations is a form of withholding safety-critical information. The analogy to electronic component datasheets (Section 2) is instructive: an op-amp datasheet doesn't say "good luck figuring out the voltage range" — it specifies the range, and operating outside it voids the manufacturer's responsibility. The model card proposes the same convention for ML models: the developer specifies the operating envelope, and use outside that envelope is a documented deviation.

This is a fundamental shift in the norms of model release, not an incremental addition. It changes the baseline expectation from "use at your own risk" to "here are the risks we already know about." The fact that the paper frames out-of-scope use as a section that "may provide an opportunity to recommend a related or similar model that was designed to better meet that particular need" (Section 4.2) reveals the underlying theory of change: documentation isn't just about warning — it's about routing users to appropriate tools, creating an ecosystem where model boundaries are respected rather than ignored.

Innovation 4: The "Relevant Factors vs. Evaluation Factors" Gap as a Productive, Not Embarrassing, Disclosure

One of the subtlest but most consequential design choices in the model card framework is the distinction between relevant factors (what should be evaluated) and evaluation factors (what was actually evaluated), and the explicit requirement that the gap between them be disclosed (Section 4.3.4). This seems like a minor formatting choice, but it constitutes a strategic innovation in how documentation frameworks create pressure for better evaluation infrastructure.

The standard approach to a documentation gap is to either (a) ignore it (don't mention factors you can't evaluate) or (b) treat it as an embarrassment to be minimized (acknowledge limitations briefly in a "future work" section). Both approaches leave the gap invisible to downstream users and create no incentive for anyone to close it. The model card framework takes the opposite approach: make the gap a first-class, named section of the document. By requiring developers to enumerate what factors should be evaluated (based on domain knowledge and prior literature) and then contrast that with what they could evaluate (given available datasets), the framework transforms the gap from a private developer concern into a public, named absence.

The smiling classifier card (Figure 2) demonstrates this: "Based on known problems with computer vision face technology, potential relevant factors include groups for gender, age, race, and Fitzpatrick skin type; hardware factors of camera type and lens type; and environmental factors of lighting and humidity." But the evaluation factors are only "gender and age group, as annotated in the publicly available dataset CelebA." The card then states: "An ideal evaluation dataset would additionally include annotations for Fitzpatrick skin type, camera details, and environment (lighting/humidity) details."

This three-step pattern — (1) here's what matters, (2) here's what we could test, (3) here's what's missing — serves multiple functions simultaneously:

For users: It provides an honest accounting of what the reported numbers can and cannot tell you. You know that race and skin type disparities are unmeasured, not absent.
For developers: It creates a reputational incentive to close the gap. A model card with a long list of unevaluated relevant factors signals less thoroughness than one with a short list. This is not a regulatory requirement — it's a market signal.
For the field: If every model card in computer vision says "we couldn't evaluate on Fitzpatrick skin type because no public annotated dataset exists," that becomes a clear, repeated demand signal for dataset creators. The gap moves from "something individual researchers occasionally lament" to "a documented, systematic absence visible to anyone reading model cards."

What makes this a genuine innovation rather than a trivial "be honest about limitations" is that it structures the limitation disclosure as a mechanism for field-level change, not just individual transparency. The gap isn't merely confessed — it's operationalized as a specification of what evaluation infrastructure is missing, in a format that is standardized, comparable across models, and visible to the entire stakeholder ecosystem. This is an incremental mechanism with fundamental implications: a small formatting choice (two prompts instead of one) that, if widely adopted, creates systematic pressure to build the evaluation datasets that the framework's own vision requires.

Innovation 5: Model Cards as an Ecosystem Intervention, Not Just a Documentation Standard

The paper's final innovation is not in any individual section of the model card but in the theory of change embedded in the proposal. The model card is not designed to solve fairness, accountability, or transparency on its own — the paper is explicit that "it seems unlikely, at least in the near term, that model cards could be standardized or formalized to a degree needed to prevent misleading representations of model results" (Section 6). Instead, the model card is designed as one node in a broader ecosystem of accountability mechanisms, and its specific contribution is to create interoperability between those mechanisms.

To see this, trace the paper's explicit connections:

Model cards + Datasheets for Datasets: A model card references its training and evaluation datasheets, so a stakeholder can trace from model performance disparities (the card) to training data composition (the datasheet) to annotation practices (the data statement). No single document tells the whole story, but the structured cross-referencing enables traceability that ad-hoc documentation cannot.
Model cards + third-party auditing: The quantitative analyses in a model card specify exactly which datasets, metrics, and subgroups were evaluated. An auditor can replicate those analyses, verify the numbers, or extend them to unevaluated factors. The model card provides the specification that makes auditing possible without inside access to the developer's infrastructure.
Model cards + adversarial testing: The caveats section identifies gaps. Adversarial testers (whether academic researchers, journalists, or community groups) can target exactly those gaps — testing on unmeasured groups, under unevaluated environmental conditions — and publish findings that either confirm the card's limitations or reveal failures the developer missed. The model card doesn't prevent adversarial findings; it provides the baseline against which they can be assessed.
Model cards + user feedback: Impacted individuals who experience model failures can reference the model card to determine whether their experience falls within documented limitations (in which case the card acknowledged the risk) or represents an undocumented failure mode (in which case the card is incomplete).

What's innovative here is that the paper doesn't just propose a documentation format — it proposes a documentation format designed to interface with other accountability mechanisms. The card's structure is chosen not just for what it communicates directly but for what it enables other actors to do: compare models, target audits, replicate analyses, identify gaps. This is a fundamentally different design philosophy than "write a report describing your model." It's a specification designed for an accountability ecosystem that the paper acknowledges does not yet fully exist, but that the card format itself helps to instantiate by creating consistent interfaces.

This is a fundamental conceptual framing — model cards as infrastructure for an accountability ecosystem — that distinguishes the paper from contemporaneous proposals. Factsheets (Hind et al., 2018) proposed supplier declarations; Datasheets proposed dataset documentation; the Nutrition Label proposed a visual format. Model cards synthesize elements of all of these but add the key insight that the format should be designed to be referenced, verified, extended, and challenged by actors outside the development team, not merely to convey what the developer already knows. This is a theory of change, not a template, and it represents the paper's most distinctive intellectual contribution: the claim that standardization plus disaggregation plus explicit gap disclosure creates the conditions for accountability even when individual cards are imperfect.

5. Experimental Analysis

Evaluation Methodology

Dataset. The paper provides worked examples using two evaluation datasets rather than conducting a unified experimental study. The smiling classifier is evaluated on the CelebA dataset (Liu et al., 2015) — specifically, the test data split — which contains celebrity face images annotated with binary gender (male/female) and binary age (young/old) labels determined by third-party annotators based on visual presentation. The toxicity classifier is evaluated on a synthetically-constructed dataset: the Identity Phrase Templates test set from Dixon et al. (2018), generated by swapping identity terms referencing sexual orientation, gender identity, and race into template sentences to ensure equal representation of toxic and non-toxic content across groups. Neither evaluation dataset was created by the paper's authors; the paper uses them to demonstrate how existing resources can be repurposed for disaggregated model card reporting.

Base models. Two models are carded as proof-of-concept: (1) a convolutional neural network pretrained for face recognition then fine-tuned with cross-entropy loss for binary smiling classification, developed by researchers at Google and the University of Toronto (2018, v1), and (2) the Perspective API TOXICITY classifier (Jigsaw, 2017), also a convolutional neural network, evaluated in two versions — v. 1 (initial release) and v. 5 (post-bias-mitigation). Both are supervised models in human-centric application domains (computer vision and NLP, respectively), representing the paper's stated focus. The models were chosen to demonstrate the framework across modalities, not because they represent optimal or state-of-the-art performance — their purpose is to illustrate how the card format surfaces performance variation that would otherwise remain hidden.

Metrics. For the smiling classifier (binary image classification), the paper reports all four confusion-matrix-derived error types: false positive rate (FPR), false negative rate (FNR), false discovery rate (FDR), and false omission rate (FOR). These are computed at a fixed decision threshold of 0.5, with 95% confidence intervals calculated via bootstrap resampling. For the toxicity classifier (score-based text system), the metric is pinned AUC as introduced in Dixon et al. (2018). Pinned AUC for an identity term $g$ measures the area under the ROC curve for separating toxic from non-toxic comments containing $g$ , using all other examples (from any group) as the background distribution. A value of 0.5 indicates random performance; values near 1.0 indicate perfect separation. The metric is threshold-agnostic and controls for base-rate differences in toxicity across groups, which would otherwise confound standard accuracy comparisons (since some groups receive disproportionately more actual toxicity in naturally occurring data).

Baselines. This paper does not use baselines in the traditional ML sense — it is not comparing methods but rather proposing a reporting framework. The closest analog to a baseline is the implicit pre-2019 status quo: aggregate accuracy reporting on a holdout test set without subgroup disaggregation. The paper's claim is not that model card reporting improves a metric relative to some baseline practice, but that it surfaces information that aggregate reporting conceals. For the toxicity classifier, the comparison between v. 1 and v. 5 serves as a within-model temporal baseline, showing how pinned AUC values changed after bias mitigation.

Generation budget / compute accounting. Not applicable. This paper does not involve training models, running experiments, or allocating inference-time compute. The two worked examples use pre-existing, already-trained models evaluated on pre-existing, publicly available datasets. The "cost" of generating a model card is the human effort of evaluation design, metric computation, and documentation — not computational resource allocation.

Cross-validation / statistical protocol. The smiling classifier reports 95% confidence intervals calculated with bootstrap resampling on the confusion matrix metrics. No further cross-validation or statistical testing protocol is described, as the goal is descriptive reporting (what are the error rates across subgroups?) rather than hypothesis testing (does model A outperform model B?). For the toxicity classifier, pinned AUC is reported as a point estimate without stated confidence intervals — a limitation the paper does not explicitly address.

Main Quantitative Results

Since this paper does not conduct a controlled experiment with systematic comparisons, the "results" are the specific quantitative findings disclosed by each worked example model card. These serve as existence proofs: they demonstrate that disaggregated model cards can surface performance disparities that aggregate reporting would conceal, and that the framework is applicable across modalities and model types.

Smiling Classifier: Disaggregated Error Analysis by Gender and Age

The smiling classifier model card (Figure 2) reports false positive rate, false negative rate, false discovery rate, and false omission rate for both unitary groups (gender alone, age alone) and intersectional groups (gender × age). The key quantitative findings, extracted from the horizontal bar charts in Figure 2:

Unitary breakdowns show modest variation. By gender alone, false positive rates are approximately in the 0.08–0.12 range for both male and female subgroups (with overlapping confidence intervals), and false negative rates are approximately 0.04–0.08. By age alone, false positive rates are approximately 0.06–0.10 (young vs. old), and false negative rates are approximately 0.04–0.10. A developer reporting only these unitary breakdowns might reasonably conclude that the model performs similarly across demographic groups.

Intersectional breakdown reveals concentrated disparities. When the same metrics are computed for the four intersectional subgroups (younger women, older women, younger men, older men), a different pattern emerges. The false discovery rate on older men is substantially higher than for other intersectional groups — the horizontal bar extends noticeably further right than the bars for younger women, older women, and younger men. Specifically, the FDR for older men appears to be approximately 0.14–0.18 (based on visual inspection of the bar chart), compared to roughly 0.04–0.08 for younger women. This means that when the model predicts an older man is smiling, it is incorrect roughly 14–18% of the time — nearly 3–4 times the error rate for younger women.

The gender-only and age-only breakdowns masked this disparity. Older men appear in the "male" unitary group (diluted by younger men, who performed well) and the "older" unitary group (diluted by older women, who performed better). Neither unitary slice isolated the problematic subgroup. This is the DeGraffenreid pattern made concrete: equality on marginals with pronounced inequality on joints.

Men have higher false negative rates in aggregate, but the intersectional breakdown qualifies this. The card notes that "men (in aggregate) have a higher false negative rate," but the intersectional results show that this aggregate effect is likely driven by one intersectional subgroup (older men) rather than being uniform across all men. A mitigation strategy based on the unitary finding (e.g., "collect more training data of men") would be inefficient compared to one based on the intersectional finding ("collect more training data of older men specifically").

The card also reports that "all error types (FPR, FNR, FDR, FOR) are within the same range (0.04 - 0.14)" at the chosen 0.5 decision threshold, and that this threshold was selected because it balanced error rates. This disclosure is important because a different threshold would produce different subgroup error profiles — the reported parity across error types is partly an artifact of the threshold choice, not an inherent property of the model.

Toxicity Classifier: Pinned AUC Across Identity Terms, Before and After Mitigation

The toxicity classifier model card (Figure 3) reports pinned AUC for multiple identity terms, comparing TOXICITY v. 1 (the initial release) and TOXICITY v. 5 (after bias mitigation). The specific numerical results are presented visually in the bar chart within Figure 3.

TOXICITY v. 1 shows low pinned AUC for sexual orientation terms. For identity terms "lesbian," "gay," and "homosexual," the pinned AUC values are visibly lower than for other terms — based on inspection of the Figure 3 bar chart, these values appear to be in the range of approximately 0.6–0.7, compared to values near 0.8–0.9 for terms like "Black" and "Muslim." A pinned AUC around 0.6–0.7 means the classifier has substantially reduced ability to distinguish toxic from non-toxic comments when those comments reference lesbian, gay, or homosexual identity — it is more likely to either over-flag non-toxic mentions as toxic (false positive) or under-flag genuinely toxic content (false negative), or both.

TOXICITY v. 5 shows substantially improved pinned AUC for the same terms. In the comparison bar chart (Figure 3), the bars for v. 5 are visibly longer than those for v. 1 on "lesbian," "gay," and "homosexual." The exact numerical improvement is not stated in text, but the visual difference is pronounced — v. 5 appears to bring pinned AUC for these terms into the 0.8–0.9 range, roughly matching the performance on other identity terms like "Black" and "Muslim." This demonstrates that the bias mitigation techniques applied between v. 1 and v. 5 (referenced generally in the card as informed by Vasserman et al., 2018) produced measurable improvements in the model's ability to handle toxicity detection for frequently targeted groups without degrading performance on other groups.

The improvement is term-specific, not uniform. The card's bar chart shows that some identity terms (e.g., "Black," "Muslim") had high pinned AUC in both versions, suggesting that the initial bias was concentrated on specific categories of identity terms (those related to sexual orientation) rather than being a general degradation across all identity terms. This granularity — knowing which terms improved and which were already performing well — is precisely the type of information that aggregate metrics would obscure. An aggregate "average pinned AUC across all identity terms" would have shown a modest improvement from v. 1 to v. 5 while concealing that the improvement was concentrated on terms where the model was previously worst, which is the most important pattern to surface.

The synthetic evaluation data construction is crucial for interpreting these results. Because the test set uses templates where identity terms are swapped into structurally identical toxic and non-toxic sentences, the pinned AUC differences across terms cannot be attributed to differences in the linguistic complexity or toxicity ambiguity of the sentences themselves — the sentences are identical except for the identity term. Any difference in pinned AUC across terms is therefore attributable to the model's differential treatment of those identity terms, not to confounding by the data distribution. This is a stronger causal claim than would be possible with naturally occurring evaluation data.

Ablation Studies and Robustness Checks

This paper does not contain ablations in the traditional ML sense — there is no model component being removed, no hyperparameter being varied, no architecture being compared. However, the two worked examples collectively serve as a form of framework stress test: they demonstrate that the model card format functions across qualitatively different settings, which constitutes a robustness check on the framework's claimed generality.

Modality stress test (vision vs. text): The smiling classifier operates on images; the toxicity classifier operates on text. The factors are visual (perceived gender, perceived age) vs. linguistic (identity terms in text). The metrics are confusion-matrix-derived (FPR, FNR, FDR, FOR) vs. distribution-comparison (pinned AUC). The evaluation data is real (CelebA) vs. synthetic (Identity Phrase Templates). Despite these differences, both examples fit within the same nine-section structure and surface the same type of insight: subgroup-level variation that aggregate metrics conceal. This supports the paper's claim that the framework is "general enough to be applicable across different institutions, contexts, and stakeholders" (Section 6), though two examples across two modalities is suggestive rather than conclusive.

Model version comparison as a temporal robustness check: The toxicity card (Figure 3) reports pinned AUC for two versions of the same model (v. 1 and v. 5) side by side. This demonstrates that the model card format can track model evolution over time — a stakeholder reading the card can see not only how the model performs now, but whether and how it has improved. The paper explicitly notes this in Section 5.2: "This model card highlights the drastic ways that models can change over time, and the importance of having a model card that is updated with each new model release." The temporal comparison also serves as a weak form of causal evidence: since v. 5 shows improved pinned AUC specifically on the terms that v. 1 handled poorly, and since the card attributes this to bias mitigation techniques, the card format enables users to assess the effectiveness of those techniques without access to internal development logs.

Metric type stress test (classification vs. scoring): The smiling classifier uses threshold-dependent metrics (FPR, FNR, etc.) at a specific decision threshold. The toxicity classifier uses pinned AUC, a threshold-agnostic metric. Both fit within the Metrics section of the framework, and both produce interpretable subgroup-level results. This demonstrates that the framework does not implicitly assume a classification setting — it accommodates score-based systems through distribution-comparison metrics as discussed in Section 4.4.2. However, only two metric types are demonstrated (confusion matrix metrics and pinned AUC), and the paper's broader recommendations (KL divergence, cross-entropy, BLEU score distributions for translation systems) remain undemonstrated.

Synthetic vs. real evaluation data stress test: The smiling classifier is evaluated on real face images (CelebA). The toxicity classifier is evaluated on synthetic template-generated sentences. Both produce interpretable, subgroup-level results. The synthetic data approach is specifically justified for the toxicity case (Section 5.2 and the card itself): "Synthetic data is valuable here because [11] shows that real data often has disproportionate amounts of toxicity directed at specific groups. Synthetic data ensures that we evaluate on data that represents both toxic and non-toxic statements referencing a variety of groups." This is not presented as an ablation (synthetic vs. real data on the same model), but the two examples together demonstrate that the framework can accommodate both real and synthetic evaluation data, and that the choice depends on domain-specific properties (confounding between group membership and outcome in naturally occurring data).

Decision threshold disclosure: The smiling classifier card explicitly states that "all metrics reported at the .5 decision threshold, where all error types (FPR, FNR, FDR, FOR) are within the same range (0.04 - 0.14)." This disclosure reveals that the threshold was chosen to balance error types, and a user reading the card knows that the reported subgroup error profiles are conditional on this specific threshold. The card does not show results at alternative thresholds (e.g., 0.3, 0.7), which would reveal how subgroup disparities shift as the threshold changes — a potentially important omission, since threshold selection can differentially affect subgroups. The paper does not treat this as an ablation; rather, it recommends (Section 4.4.1) that digital model cards ideally include a threshold slider "to view performance parameters across various decision thresholds," but this feature is not implemented in the static Figure 2 prototype.

Critical Assessment

The experiments in this paper are fundamentally demonstrations, not validations. The paper does not set out to prove that model cards improve fairness outcomes, increase transparency, change developer behavior, or lead to better model selection by downstream users. It sets out to demonstrate that a specific documentation format can exist, that it can surface information previously invisible in standard evaluation practice, and that it can be applied across different model types and modalities. The two worked examples succeed at this narrow goal: they show that applying the model card framework to existing models and existing datasets produces a structured document containing subgroup-level performance information that would not be visible in aggregate accuracy reports. But this is a proof-of-concept, not an empirical evaluation, and several categories of evidence that would be needed to validate the framework's practical impact are entirely absent.

What the Demonstrations Actually Show (and Do Not Show)

The smiling classifier card demonstrates that intersectional disaggregation can reveal concentrated disparities invisible to unitary breakdowns. The FDR on older men is visibly higher than on other intersectional subgroups (Figure 2), and this disparity is not apparent from the gender-only or age-only breakdowns. This is a concrete instantiation of the DeGraffenreid pattern — a genuine empirical finding that supports the paper's conceptual argument for intersectional analysis. However, it is worth noting that this finding required no novel data collection, no new annotation, and no new model training. The CelebA dataset already had gender and age annotations; the "innovation" was simply computing confusion matrix metrics on the intersectional subgroups rather than only on the unitary groups. This suggests that the primary barrier to intersectional evaluation is not technical difficulty but rather the absence of a norm requiring it — which is precisely the norm the model card framework aims to establish.

The toxicity classifier card demonstrates that model cards can track improvement over time and attribute it to specific mitigation techniques. The pinned AUC for terms like "lesbian," "gay," and "homosexual" improves visibly from v. 1 to v. 5 (Figure 3). A user comparing the two versions can see both that improvement occurred and where it occurred — on the specific terms where v. 1 performed worst. This is more informative than an aggregate "average pinned AUC improved from 0.75 to 0.85" statement, which would conceal the distribution of improvement across groups. However, the card provides no detail on how the bias mitigation was performed (the text references Vasserman et al., 2018 generally), which limits a user's ability to assess whether the improvement is robust or fragile. A model card that says "we applied bias mitigation and it worked" provides less actionable information than one that specifies the mitigation approach (e.g., data augmentation, adversarial training, threshold adjustment) — a user considering deploying the model cannot know whether the mitigation will transfer to their domain without understanding its mechanism.

Neither card demonstrates the full set of recommended sections working together in a real deployment context. The smiling classifier card includes model details, intended use, factors, metrics, training data, evaluation data, quantitative analyses, ethical considerations, and caveats — all nine sections. But the training data section (Section 5.2) simply says "CelebA, training data split," which provides minimal information about training data composition or distribution over groups. The ethical considerations section is correspondingly thin — "Faces and annotations based on public figures (celebrities). No new information is inferred or annotated." A more substantive ethical analysis would discuss, for example, whether training on celebrity faces produces systematic errors on non-celebrity faces (due to differences in image quality, makeup, lighting, or expression range), or whether the binary gender annotation scheme (male/female) encodes a normative assumption that may produce errors on non-binary or gender-nonconforming individuals — an issue the card itself acknowledges in the Caveats section but does not analyze quantitatively.

The paper provides no evidence that model cards actually change stakeholder behavior. This is the most significant gap between the paper's claims and its evidence. The paper's motivation (Section 3) lists six stakeholder groups — ML practitioners, model developers, software developers, policymakers, organizations, ML-knowledgeable individuals, and impacted individuals — and describes how each would benefit from model cards. But none of these claims are tested. We do not know whether ML practitioners who read a model card make better model selection decisions than those who see only aggregate accuracy. We do not know whether policymakers can interpret the quantitative analyses correctly. We do not know whether impacted individuals find the information in a model card useful for pursuing remedies. These are empirical questions that the paper does not address, and the two worked examples cannot answer them because they are studies of the cards themselves, not of the cards' effects on readers.

The paper acknowledges but does not resolve the tension between disclosure and misuse prevention. Section 6 states that "it seems unlikely, at least in the near term, that model cards could be standardized or formalized to a degree needed to prevent misleading representations of model results (whether intended or unintended)." This is a significant self-limiting admission. A developer who wants to present their model favorably could selectively choose evaluation datasets, metrics, or subgroups that make performance look better than it is — for example, evaluating only on the CelebA test split (which may have demographic distributions that favor the model) and not on a more challenging external dataset, or choosing a decision threshold that equalizes error rates across groups (as the smiling classifier card explicitly did) without disclosing that different thresholds produce different subgroup profiles. The paper proposes no mechanism — technical, institutional, or legal — for detecting or preventing such selective reporting. The model card's usefulness rests on "the integrity of the creator(s) of the card itself," which is a fragile foundation for a transparency mechanism intended to operate at scale across the ML industry.

What Experiments Would Strengthen the Paper but Were Not Run

A user study with downstream stakeholders. The most important missing evidence is whether model cards actually improve decision-making. A study could present participants (ML practitioners, product managers, policy analysts) with model descriptions — some with model cards, some with only aggregate accuracy, some with only a brief text description — and measure their ability to identify which models are appropriate for a given deployment context, which models have unacceptable subgroup disparities, and which models require additional evaluation before deployment. Without such evidence, the claim that model cards enable stakeholders to "compare candidate models for deployment across not only traditional evaluation metrics but also along the axes of ethical, inclusive, and fair considerations" (Section 3) is an aspiration, not a demonstrated outcome.

A card for a model with known, documented failures. The smiling classifier has no known history of causing real-world harm (it was built as a demonstration). The toxicity classifier has a known history — users reported that v. 1 exhibited bias, and the Perspective API team acknowledged this (Vasserman et al., 2018) — but the paper's card describes v. 1 and v. 5 side by side, after both existed, so the card did not prevent the v. 1 deployment or surface the bias before users experienced it. A stronger demonstration would be to produce a model card for a model before its release, then follow up to determine whether the card's disclosures led to changes in deployment decisions, mitigation efforts, or user awareness compared to a model released without a card. The paper provides no such prospective evidence.

A card with environmental or instrumentation factors. The Factors section (4.3) proposes three categories — groups, instrumentation, and environment — but both worked examples only evaluate group factors. The smiling classifier card explicitly acknowledges that "hardware factors of camera type and lens type; and environmental factors of lighting and humidity" are relevant but unevaluated. A worked example that actually evaluated on these non-demographic factors — e.g., showing how false negative rate varies across lighting conditions or camera types — would demonstrate the full scope of the framework and surface a different type of performance variation (one that may interact with but is not reducible to demographic group membership).

A card for a model where training data disclosure is genuinely constrained. The paper acknowledges that "there might be cases where it is not feasible to provide this level of detailed information about the training data" (Section 4.6) and advocates for minimal allowable information in such cases. Both worked examples provide some training data information (CelebA, which is public, and the Perspective API's training sources, which are partially described in prior publications). A worked example where the training data is entirely proprietary — e.g., a model trained on internal corporate data that cannot be described beyond "proprietary dataset of customer interactions" — would test whether the minimal disclosure standard (basic distributional information) is achievable in practice or whether it collapses to "cannot disclose" in the most constrained real-world settings.

A card with continuous subgroup definitions rather than binary ones. The smiling classifier uses binary gender (male/female) and binary age (young/old) as defined by the CelebA annotations. The card acknowledges in its Caveats: "Given gender classes are binary (male/not male), which we include as male/female. Further work needed to evaluate across a spectrum of genders." But the card does not demonstrate what evaluation across a spectrum of genders would look like, whether existing datasets could support it, or whether the framework's sections are adequate for non-binary, continuous, or self-identified group definitions. This is a significant open question, especially for applications where the relevant groups are not visually categorizable (e.g., socioeconomic status, disability status, language variety).

Conditional Claims and Boundary Conditions

The paper's central claims are conditional on adoption, not on inherent properties of the framework. The claims hold only if:

Developers actually complete model cards honestly and thoroughly. The framework provides no enforcement mechanism. If model cards become a checkbox exercise — filled out with minimal detail, omitting unfavorable results, or using metrics chosen to obscure rather than reveal disparities — they will not achieve their intended transparency goals.
Evaluation datasets with appropriate subgroup annotations exist or are created. The smiling classifier card could only evaluate on gender and age because those were the annotations available in CelebA. Race, skin type, camera type, and lighting conditions — all flagged as relevant — could not be evaluated. If the adoption of model cards does not also drive the creation of richly annotated evaluation datasets (as the paper hopes it will, but does not guarantee), the cards will systematically report narrower evaluations than what is relevant, and the gap between relevant factors and evaluation factors will become normalized rather than serving as a productive pressure mechanism.
Stakeholders can interpret the quantitative analyses correctly. The smiling classifier card reports four metrics (FPR, FNR, FDR, FOR) with confidence intervals for four intersectional subgroups — that is 16 numbers with uncertainty bounds, presented as a bar chart. A product manager without statistical training may not understand the difference between false discovery rate and false positive rate, or may misinterpret overlapping confidence intervals as "no difference" when they actually indicate insufficient sample size to detect a difference. The paper does not address the interpretability burden its framework places on non-technical stakeholders.
The card format scales to models with many more relevant factors. The smiling classifier has two binary factors (gender × age), producing four intersectional subgroups. A facial recognition model with six relevant factors (gender, age, skin type, lighting condition, camera type, head pose), each with multiple levels, would produce dozens or hundreds of intersectional subgroups. The quantitative analysis section would become unwieldy, and confidence intervals on sparsely populated subgroups would be too wide to be informative. The paper's recommendation to report intersectional results does not address how to handle combinatorial explosion of subgroups when factors are numerous.
The model card remains up to date as models are updated. The toxicity card (Figure 3) compares v. 1 and v. 5 — but this required the Perspective API team to produce and release a card for both versions. In practice, models may be updated frequently (fine-tuned on new data, deployed with new thresholds, integrated into larger systems), and the card may lag behind the actual model in production. The paper provides no guidance on versioning cadence, stale card detection, or how users should verify that the card they are reading corresponds to the model they are using.

In summary, the experimental analysis demonstrates that the model card framework is coherent, applicable across modalities, and capable of surfacing subgroup performance variation that aggregate metrics conceal. But it does not demonstrate that the framework changes behavior, that the surfaced information is interpretable by non-experts, that the framework prevents selective or misleading disclosure, or that it scales to models with many relevant factors or to deployment contexts with proprietary training data and frequent model updates. These are not flaws in the worked examples — they are boundaries of what two proof-of-concept demonstrations can establish, and they correspond to the paper's own acknowledgment (Section 6) that model cards are "one transparency tool among many" whose ultimate impact depends on adoption, integrity, and integration with complementary accountability mechanisms like third-party auditing and adversarial testing. The paper should be read as a proposal with existence proofs, not as a validation study with performance benchmarks.

6. Limitations and Trade-offs

6.1 The Framework Provides No Enforcement or Verification Mechanism — It Assumes Developer Integrity

The model card framework is a voluntary disclosure standard with no technical, institutional, or legal mechanism to ensure that the information provided is complete, accurate, or honest. The paper is strikingly candid about this in Section 6:

"The usefulness and accuracy of a model card relies on the integrity of the creator(s) of the card itself. It seems unlikely, at least in the near term, that model cards could be standardized or formalized to a degree needed to prevent misleading representations of model results (whether intended or unintended)."

Consequence. A developer who wants to present their model favorably has multiple avenues for selective disclosure that the framework cannot detect. They can choose evaluation datasets on which the model performs well and omit those on which it performs poorly. They can select a decision threshold that equalizes error rates across groups (as the smiling classifier card explicitly does, noting the 0.5 threshold was chosen where "all error types are within the same range") without disclosing that different thresholds would reveal different subgroup disparities. They can define "relevant factors" narrowly to exclude categories where they suspect problems. They can compute intersectional results, discover unfavorable disparities, and simply not report those specific intersections. The card format asks for information but cannot verify its completeness. This means a model card can create the appearance of thorough evaluation without the substance — it can function as a legitimizing device for models that have not been rigorously stress-tested, providing what the paper itself might call a false sense of transparency.

Evidence in the paper. None. The paper does not study or measure the prevalence of selective disclosure, does not propose verification mechanisms, and does not audit the two example cards for completeness. The worked examples (Figures 2 and 3) are produced by the paper's authors themselves, so they cannot demonstrate adversarial or negligent misuse of the framework. The smiling classifier card acknowledges relevant factors it cannot evaluate (race, skin type, camera type, lighting) — which is the intended use of the gap disclosure — but a less scrupulous developer could simply omit those factors from the "relevant factors" section entirely, and the framework provides no way to detect that omission.

Mitigation status. The paper partially addresses this by positioning model cards as "one transparency tool among many" (Section 6) that should be complemented by "algorithmic auditing by third-parties (both quantitative and qualitative), 'adversarial testing' by technical and non-technical analysts, and more inclusive user feedback mechanisms." This is an acknowledgment of the limitation, not a solution to it. The paper's theory is that model cards are one node in an accountability ecosystem where other actors (auditors, adversarial testers, users) can verify or challenge card claims. But this only works if those other actors exist and are resourced — a condition the paper does not establish. In the near term, a model card released without accompanying third-party audit is effectively a self-attestation with no verification, and the framework provides no guidance on what a stakeholder should do when external verification is unavailable.

6.2 Disaggregated Evaluation Requires Subgroup Annotations That Are Notoriously Difficult, Contested, and Often Unavailable

The model card framework makes disaggregated evaluation by unitary and intersectional groups its central requirement — this is not an optional add-on but the framework's primary differentiator from prior documentation proposals. The entire quantitative analyses section (Section 4.7) is structured around it. Yet the paper acknowledges, both explicitly and through the gaps in its own worked examples, that the evaluation datasets with the necessary subgroup annotations often do not exist. The smiling classifier card (Figure 2) states this directly in two locations. In the Factors section:

"Evaluation factors are gender and age group, as annotated in the publicly available dataset CelebA. Further possible factors not currently available in a public smiling dataset."

And in the Caveats section:

"Does not capture race or skin type, which has been reported as a source of disproportionate errors. An ideal evaluation dataset would additionally include annotations for Fitzpatrick skin type, camera details, and environment (lighting/humidity) details."

Consequence. The framework imposes an evaluation standard that cannot currently be met for most models and most relevant factors. A developer who wants to comply with the model card's requirements can only evaluate on the factors for which annotated datasets happen to exist — which, as the paper notes, are "not yet common" (Section 4.5). This creates a structural tension: the framework insists that certain factors should be evaluated (race, skin type, camera type, lighting for face models; dialect, language variety, socioeconomic markers for NLP models), but the evaluation infrastructure to do so is missing. The gap between relevant factors and evaluation factors — which the paper frames as a productive disclosure (see Section 4's analysis of Innovation 4) — can easily become normalized. If every face model card says "we couldn't evaluate on Fitzpatrick skin type because no annotated dataset exists," then the statement loses its force as a demand signal and becomes boilerplate that readers learn to ignore. Worse, a developer who genuinely wants to evaluate on skin type may be unable to do so, and is then faced with an uncomfortable choice: either release a card that fails to meet the framework's own standards (evaluating only what datasets allow), or not release a model card at all. The framework provides no guidance for this dilemma.

Beyond availability, the paper acknowledges deeper problems with subgroup annotations themselves (Section 2):

"How 'ground truth' race or gender categories should be labeled in a dataset, and whether or not datasets should be labeled with these categories at all, is not always clear. This issue is further confounded by the complex relationship between gender and sex."

The CelebA annotations used in the smiling classifier card illustrate this: gender is binary (male/female) and assigned by third-party annotators based on visual presentation, not self-identification. The card itself acknowledges this in its Caveats: "Given gender classes are binary (male/not male), which we include as male/female. Further work needed to evaluate across a spectrum of genders." This means that a model card's intersectional analysis inherits whatever conceptual and ethical problems exist in the underlying annotations — problems that the paper recognizes but does not resolve. A model that appears to perform equally across "male" and "female" as visually perceived by annotators may still fail systematically on non-binary, gender-nonconforming, or transgender individuals, and the card would not reveal this because the evaluation ontology itself is inadequate.

Evidence in the paper. The gap between relevant and evaluation factors is explicitly present in Figure 2 (smiling classifier) and is not present in Figure 3 (toxicity classifier) because the toxicity card evaluates on synthetic data constructed specifically for the identity terms of interest. The smiling classifier card demonstrates the gap directly: of the six factor categories listed as relevant (gender, age, race, skin type, camera/lighting, environment), only two (gender and age) are actually evaluated. The remaining four are named as absent. The paper provides no example of a card that successfully evaluates on all or even most relevant factors.

Mitigation status. The paper suggests using synthetic data where real annotated datasets are unavailable (Section 4.5), as demonstrated with the Identity Phrase Templates dataset for toxicity. This is a partial mitigation for text domains where template-based generation is feasible — you can construct sentences with specific identity terms and label them. For vision, where generating photorealistic synthetic faces with controlled demographic and environmental variation is substantially harder, this mitigation is less applicable. The paper also suggests "further research is necessary to expand how groups may be defined, for example, by automatically discovering groups with similarities in the evaluation datasets" (Section 2) — an acknowledgment that the current approach (predefined categories with manual annotation) does not scale, but no such automatic discovery method is developed or evaluated.

6.3 The Framework Provides No Guidance on the Combinatorial Explosion of Intersectional Subgroups

The paper's central methodological requirement is that quantitative analyses include "intersectional results: how did the model perform with respect to the intersection of evaluated factors?" (Section 4.7). The DeGraffenreid argument (Section 2) establishes that unitary breakdowns are insufficient. But the paper does not address what happens when the number of factors — and therefore the number of intersectional subgroups — grows beyond what can be meaningfully reported in a one-to-two-page document, or beyond what the evaluation dataset's sample size can support with reasonable confidence intervals.

Consequence. The smiling classifier has two binary factors (gender × age), producing four intersectional subgroups. This is tractable: four subgroups, each with sufficient samples in CelebA to compute confidence intervals. But consider a more realistic model: a face detection system with six relevant factors — perceived gender (male/female/non-binary), perceived age (young/middle/old), Fitzpatrick skin type (I–VI), lighting condition (bright/dim/dark), camera type (smartphone/DSLR/security camera), and head pose (frontal/profile/overhead). Even if each factor is coarsely discretized, the full intersectional space contains 3 × 3 × 6 × 3 × 3 × 3 = 1,458 subgroups. An evaluation dataset of 100,000 images — already large by academic standards — would average fewer than 70 images per intersectional subgroup. Many subgroups would have near-zero representation. Confidence intervals, which the paper correctly insists are necessary (Section 4.4.3), would be so wide as to be uninformative for all but the most common subgroups.

The framework provides no guidance on how to handle this. Should the developer report only pairwise intersections? Which ones? How should they decide which intersectional combinations are most important? Should they aggregate rare subgroups — and if so, on what basis? The paper's normative argument (intersectional analysis is mandatory because unitary breakdowns conceal the DeGraffenreid pattern) does not translate into an operational procedure when the number of factors exceeds two or three.

Evidence in the paper. Both worked examples keep the factor space artificially small. The smiling classifier uses two binary factors (four subgroups). The toxicity classifier reports pinned AUC for individual identity terms (unitary in the paper's terminology) and does not report intersectional results combining identity terms (e.g., how does the classifier perform on text containing both a sexual orientation term and a race term?). The paper does not acknowledge the combinatorial scaling problem, does not provide an example of a card with more than four intersectional subgroups, and does not discuss how the framework should handle models where the domain-relevant factors are numerous or continuous.

Mitigation status. None. The paper neither identifies this scaling challenge nor proposes strategies for addressing it. The recommendation to report intersectional results is unconditional — "how did the model perform with respect to the intersection of evaluated factors?" — with no qualification about what to do when the intersectional space is combinatorially large. This is a significant gap because it means the framework's central requirement is undefined for exactly the kind of complex, multi-factor evaluation that real-world human-centric models would need. The paper's silence on this issue means that a developer who takes the framework seriously and tries to apply it to a model with five or six relevant factors has no principled way to determine which intersections to report.

6.4 The Paper Provides No Evidence That Model Cards Change Stakeholder Behavior or Improve Outcomes

The paper's motivation (Section 3) enumerates six stakeholder groups — ML and AI practitioners, model developers, software developers, policymakers, organizations, ML-knowledgeable individuals, and impacted individuals — and describes specific ways each group would benefit from model cards. For example, policymakers "can understand how a machine learning system may fail or succeed in ways that impact people," and organizations "can inform decisions about adopting technology that incorporates machine learning." These are empirical claims about human behavior: they assert that providing structured documentation will change how people evaluate, select, deploy, and contest models. The paper provides no evidence for any of these claims.

Consequence. A documentation framework can be elegantly designed, grounded in relevant ethical and legal theory, and still fail to improve outcomes if the intended audience does not read it, cannot understand it, or does not act on the information it provides. The model card format presents four metrics with confidence intervals across four intersectional subgroups (smiling classifier) or pinned AUC for a dozen identity terms across two model versions (toxicity classifier). Interpreting these results requires understanding what false discovery rate means, what a confidence interval represents, what pinned AUC measures, and why intersectional analysis matters — statistical literacy that cannot be assumed for policymakers, journalists, impacted community members, or even all product managers. The framework's theory of change assumes that providing this information will lead to better decisions, but that link is unexamined. A product manager might misinterpret overlapping confidence intervals as "no difference between groups" (when they actually indicate insufficient sample size), or might focus on the one metric that makes the model look acceptable while ignoring the three that reveal problems. A policymaker might see the nine-section structure and conclude that a model has been thoroughly vetted, without the expertise to notice that crucial factors were omitted from the evaluation.

Evidence in the paper. None. The paper contains no user study, no behavioral experiment, and no qualitative interview data about how stakeholders interact with model cards. The two worked examples demonstrate that the cards can be created, not that they change decisions when read. This is consistent with the paper's self-characterization as a "framework proposal" (Section 1), but it means that the paper's central practical claim — that model cards will improve transparency and accountability in ML deployment — is untested. The gap between "this information would be useful to have" and "having this information leads to better outcomes" is not small, and the paper does not bridge it.

Mitigation status. The paper acknowledges in its Future Work (Section 6) that researchers should study this: "Future work will aim to refine the methodology of creating model cards by studying how model information is interpreted and used by different stakeholders." This is presented as a direction for subsequent research, not as something the current paper addresses. The acknowledgment is appropriately humble but does not mitigate the limitation for a practitioner reading the paper today: you can adopt model cards because they seem like good practice, but you cannot know from this paper whether they actually work.

6.5 The Framework's "One to Two Page" Constraint Trades Comprehensiveness for Accessibility in Ways That May Undermine Both

The paper specifies that model cards should be "short (one to two page) records" (Section 1). This constraint is justified by the goal of accessibility: a policymaker, journalist, or impacted community member is unlikely to read a 20-page technical report, and a one-page document forces prioritization of the most critical information. But the constraint also creates a fundamental tension: the framework demands a substantial amount of information (nine sections including quantitative analyses with confidence intervals by intersectional subgroup, a full listing of relevant vs. evaluation factors, ethical considerations, and caveats), and fitting this into one to two pages forces either extreme concision (which risks being uninterpretable to non-experts) or selective omission (which undermines completeness).

Consequence. The two worked examples illustrate different resolutions of this tension, and both are incomplete in ways that matter. The smiling classifier card (Figure 2) fits into a single page but achieves this by drastically compressing almost every section to a sentence or two. The training data section is a single line: "CelebA, training data split." The ethical considerations section is two sentences — no discussion of the privacy implications of face analysis, the potential for misuse in surveillance, or the fact that the model's "smile" detection is based on physical appearance and was trained on celebrity faces (which may not generalize). The caveats section flags the missing race/skin type evaluation and the binary gender limitation, but cannot elaborate on why these matter or what the practical consequences of these gaps might be for a deployer.

The toxicity classifier card (Figure 3) similarly compresses: the "Factors" section says "Identity terms referencing frequently attacked groups, focusing on sexual orientation, gender identity, and race" without specifying which specific terms, how many, or why the particular set shown in the chart was chosen. The ethical considerations section references the Perspective API's values (Community, Transparency, Inclusivity, Privacy, Topic-neutrality) but does not explain what these values mean in practice, how they were operationalized, or what tradeoffs they required.

A reader who is not already familiar with CelebA, the Identity Phrase Templates dataset, or the Perspective API's development history would struggle to extract actionable understanding from these compressed cards. The one-to-two-page format may achieve glanceability at the cost of comprehensibility. The paper does not test whether the compressed format is actually interpretable by its target audience — it asserts accessibility as a design goal but does not validate it.

Evidence in the paper. The card prototypes (Figures 2 and 3) are the evidence, and they are best understood as demonstrating the feasibility of fitting the framework into a small space, not the adequacy of the information density for stakeholder decision-making. Several sections in both cards are reduced to sentence fragments that would require substantial background knowledge to interpret. The quantitative analysis bar charts (Figures 2 and 3) are dense with information but lack explanatory annotation — a reader unfamiliar with FDR vs. FPR, or with pinned AUC, has no guidance within the card itself about what the numbers mean or how to weigh them.

Mitigation status. The paper partially addresses this by noting (Section 4) that the sections "are not intended to be complete or exhaustive, and may be tailored depending on the model, context, and stakeholders" — but this flexibility cuts both ways. It acknowledges that the framework is a starting point, but it also means there is no minimum standard of completeness that separates an adequate model card from a superficial one. A developer could produce a one-page card with minimal detail in each section (as the worked examples essentially do) and claim compliance with the framework, while providing little actionable information to any stakeholder who needs more than a superficial overview. The paper does not propose a mechanism for determining whether a given card achieves the right balance of concision and substance for its intended audience.

6.6 The Framework Does Not Address Dynamic Models, Frequent Updates, or Model Drift

The model card is designed as a static document accompanying a released model — "model cards are short documents accompanying trained machine learning models" (Section 1). The section prompts include "Model date" and "Model version" (Section 4.1), which assume that models have discrete versions and identifiable release dates. But in modern ML deployment, models are often updated continuously — fine-tuned on new data, retrained with expanded datasets, deployed with modified thresholds, integrated into larger pipelines where their behavior depends on upstream components. A model served through an API (like the Perspective API TOXICITY classifier) may be updated without the user's knowledge, and the model card corresponding to the version the user read may no longer describe the model they are actually interacting with.

Consequence. Model cards can become stale, and stale documentation is potentially worse than no documentation — it creates a false sense of security. If the TOXICITY classifier is updated from v. 5 to v. 6 with a new training procedure that inadvertently reintroduces bias against certain identity terms, a user reading the v. 5 card (which shows substantially improved pinned AUC for those terms) would be misled about the model's current behavior. The paper acknowledges the importance of version tracking implicitly — the toxicity card compares v. 1 and v. 5 side by side — but provides no guidance on versioning cadence, on how users should verify that the card they are reading corresponds to the model they are accessing, or on what happens when a model is updated without a corresponding card update.

More fundamentally, the framework implicitly models ML deployment as a discrete release cycle: a model is trained, evaluated, documented, and released. This does not match the reality of continuously-trained models, online learning systems, or models whose behavior changes because their training data distribution shifts (not because the model itself was retrained, but because the world changed — e.g., a toxicity classifier encountering new slang, new forms of coded harassment, or new identity terms that did not exist when the training data was collected). The model card has no mechanism for capturing distributional drift between the evaluation data and the deployment context, even though such drift can cause the card's reported performance characteristics to become inaccurate without any change to the model itself.

Evidence in the paper. The toxicity card (Figure 3) demonstrates a model that has changed over time (v. 1 to v. 5), and the paper explicitly notes that "this model card highlights the drastic ways that models can change over time, and the importance of having a model card that is updated with each new model release" (Section 5.2). But the paper does not discuss how a user would know whether the model they are querying through the Perspective API is v. 5, v. 6, or some continuously-deployed variant. The API itself may not expose version information in a way that maps to the model card's version field.

Mitigation status. The paper suggests updating model cards with each release — "the importance of having a model card that is updated with each new model release" — but this is an aspiration, not a mechanism. There is no discussion of versioning infrastructure, of how to verify that a served model matches its documented evaluation, or of how frequently "each new model release" occurs. For models trained continuously or updated weekly, producing a new model card with each update may be practically infeasible (the evaluation itself takes time and compute), creating a structural lag between model changes and documentation updates. The paper's theory of documentation as a transparency mechanism does not account for this temporal dimension, and a user has no way to detect staleness from the card itself.

7. Implications and Future Directions

How This Work Changes the Landscape

This paper does not introduce a new algorithm, a new architecture, or a new evaluation metric. Its contribution is a normative intervention in the practice of model release, and its impact — if adoption follows — is to change what counts as adequate disclosure when a trained model leaves the development environment. Before model cards, the field had no shared expectation about what information should accompany a released model. After model cards, the question "where is your model card?" becomes askable — and the absence of a card becomes a conspicuous gap, not a neutral default.

The magnitude of this shift is best understood as reframing model evaluation from a purely technical activity to a sociotechnical one. Standard ML evaluation (accuracy on a holdout test set) treats performance as a property of the model-in-isolation. A model card insists that performance is a property of the model-in-context: it depends on who is being classified, under what conditions, with what instrumentation, and for what purpose. The smiling classifier's FDR on older men (Figure 2) is not a fact about the model — it's a fact about the model's interaction with a specific subgroup under specific evaluation conditions, and without disaggregation, that fact is simply unknown. The model card framework makes this ignorance structurally visible by requiring that evaluation be sliced along named axes and that the gap between what was evaluated and what should have been evaluated be disclosed explicitly (the "relevant factors vs. evaluation factors" distinction in Section 4.3.4).

The paper also resolves a latent contradiction in contemporaneous documentation proposals. Datasheets for Datasets (Gebru et al., 2018), Data Statements (Bender & Friedman, 2018), and the Dataset Nutrition Label (Holland et al., 2018) all addressed the data side of the transparency problem — they argued that datasets carry implicit assumptions, biases, and contextual limitations that must be disclosed to enable responsible use. But they left open the question: what about the trained model itself? A well-documented dataset can still produce a poorly-understood model. The model card closes this loop by proposing the complementary document — the model-side analog of the datasheet — with a specific focus on disaggregated, intersectional evaluation that had not been a central organizing principle in prior proposals. The paper does not compete with datasheets; it completes the documentation stack, enabling traceability from training data (datasheet) to trained model (model card) to deployment decisions (stakeholder assessment).

This reframing makes certain research directions more attractive. Evaluation dataset construction — specifically, the creation of richly annotated evaluation datasets that include demographic, phenotypic, environmental, and instrumentation metadata alongside traditional ground-truth labels — becomes a first-class research contribution rather than mere infrastructure work. The paper's repeated observation that "evaluation datasets suitable for disaggregated evaluation are not yet common" (Section 4.5) is effectively a research agenda: every model card that says "we could not evaluate on Fitzpatrick skin type because no public annotated dataset exists" is a demand signal. The smiling classifier card (Figure 2) makes this explicit: "An ideal evaluation dataset would additionally include annotations for Fitzpatrick skin type, camera details, and environment (lighting/humidity) details." If model card adoption spreads, the scarcity of such datasets transitions from an inconvenience to a bottleneck, and dataset creation efforts that were previously framed as "data work for fairness" become reframed as "infrastructure required for basic model evaluation."

Conversely, the framework makes pure aggregate benchmarking — reporting a single accuracy number on a holdout set with no subgroup analysis — look increasingly inadequate. The paper's core epistemological claim (that aggregate accuracy conceals rather than reveals model behavior for human-centric applications) is not rebuttable with better aggregation methods; the only adequate response is disaggregation. This means that benchmark leaderboards that report only overall accuracy (or F1, or BLEU) without subgroup breakdowns are, under the model card framework's logic, producing incomplete information of a kind that can be actively misleading. The implication for the field is that evaluation infrastructure — test sets, benchmarks, competition leaderboards — must be redesigned to support disaggregated reporting as a baseline requirement, not a specialized fairness add-on.

The paper also shifts the burden of proof for model suitability. Before model cards, the implicit default was that a model could be used for any purpose unless the developer explicitly warned against it, and the user bore the responsibility for discovering limitations. Under the model card framework, the intended use and out-of-scope sections (Section 4.2) create an affirmative disclosure obligation: the developer must state what the model is for and what it is not for, and using the model outside those documented boundaries is a deviation from developer guidance. This does not have legal force (the paper makes no legal claims), but it establishes a norm. If a model card says "not suitable for emotion detection" and a user deploys it for emotion detection, the user is not merely making a mistake — they are acting against documented, publicly available guidance, which changes the character of accountability discussions even if it does not change formal liability.

The paper's most far-reaching conceptual contribution may be its implicit theory of change for transparency, articulated in Section 6: model cards are not a standalone solution but "one transparency tool among many" that must be integrated with third-party auditing, adversarial testing, and inclusive user feedback. This is a different theory than "if we just disclose more information, things will improve." It's an ecosystem theory: the model card's primary function is to create standardized, referenceable claims that other actors can verify, challenge, or extend. An auditor can replicate the reported evaluation; an adversarial tester can target the acknowledged gaps; an impacted community can point to the card's own numbers when contesting a deployment. The card is not the accountability mechanism — it's the substrate on which accountability mechanisms operate. To the extent this theory is correct, the model card's impact depends less on the thoroughness of individual cards and more on the existence and resourcing of the external actors (auditors, testers, civil society organizations, regulators) who can use cards as leverage. This makes adoption partly an institutional question, not merely a technical one — and the paper's primary legacy may be in giving those external actors a standard format to demand and reference.

Follow-Up Research This Work Enables

Auditing model cards for completeness and honesty at scale. The paper acknowledges that model cards rely on developer integrity and proposes no verification mechanism (Section 6). A natural follow-up is a systematic audit study: collect a corpus of publicly released model cards (if and when adoption occurs), then independently evaluate the models described in those cards on factors the cards claim were evaluated, and on factors the cards omit. The research question is: do model cards accurately report subgroup performance, or do they systematically underreport disparities? Specifically, one could take 50–100 model cards, replicate the reported quantitative analyses on the named evaluation datasets, and measure (a) whether the reported numbers match the replication, (b) whether metrics on unevaluated relevant factors (e.g., skin type for a face model whose card only reports gender and age) reveal disparities the card did not disclose, and (c) whether cards from different types of organizations (academic, corporate, startup) differ in completeness or accuracy. If model cards are generally accurate, that strengthens the case for voluntary adoption. If they systematically omit unfavorable results, that demonstrates the enforcement gap the paper identifies and motivates institutional or regulatory mechanisms. The paper makes this study tractable by providing a specific, standardized format whose claims are structured to be verifiable — the card specifies the datasets, metrics, and subgroups, so a third party can replicate them. Without the standardization model cards provide, such audit studies would require extensive per-model reverse engineering.

Measuring whether model cards change model selection decisions by downstream stakeholders. The paper enumerates six stakeholder groups and claims model cards will help each make better decisions (Section 3), but provides no evidence. A controlled experiment could present participants — ML practitioners, product managers, or policy analysts — with pairs of hypothetical models described either (a) with a model card containing disaggregated performance (including a known disparity, e.g., higher FDR on a specific subgroup), or (b) with only aggregate accuracy and a brief text description. Measure whether participants in the model card condition are more likely to identify the problematic model, more likely to choose the more equitable alternative when one exists, and more confident in their deployment decisions. A variant could vary whether the card includes intersectional results versus only unitary breakdowns, directly testing the paper's claim that unitary breakdowns are insufficient. The paper's two worked examples (Figures 2 and 3) provide templates for constructing realistic model cards for hypothetical models; a researcher could adapt these to create stimuli that vary specific features (presence/absence of intersectional analysis, presence/absence of confidence intervals, narrow vs. broad out-of-scope disclosures) while holding model identity constant. The results would directly test the paper's theory of change — that structured documentation changes behavior, not just provides information.

Developing and validating methods for cheap, continuous difficulty estimation (in the model card context: subgroup performance estimation without exhaustively annotated evaluation datasets). The model card framework's central requirement — disaggregated intersectional evaluation — demands richly annotated evaluation datasets that do not exist for most domains and factors. A research direction the paper gestures toward is "automatically discovering groups with similarities in the evaluation datasets" (Section 2). Concretely: can we predict subgroup performance disparities from a small number of labeled examples combined with model embeddings, without requiring a fully annotated evaluation dataset for every intersectional subgroup? For example, given a face model and an unannotated evaluation set, could we cluster images by embedding similarity, identify clusters that correspond to coherent demographic or phenotypic groups (without knowing the group labels), and estimate per-cluster error rates from model confidence scores and a small number of human-verified labels? A strong result would be a method that can flag which clusters are likely experiencing disproportionate errors with, say, 50–100 human annotations per cluster rather than the thousands needed to compute statistically reliable confusion matrix metrics. This would directly address the evaluation dataset scarcity problem that the paper identifies as the primary bottleneck for model card adoption (visible in the gap between relevant and evaluation factors in Figure 2). The paper's finding that intersectional disparities can be large and concentrated (older men's FDR in the smiling classifier) suggests that even coarse-grained cluster-level analysis might surface the most egregious failures without exhaustively annotating every subgroup.

Extending model cards to generative models and open-ended outputs. The paper's two worked examples are both discriminative models with well-defined output spaces (binary classification for smiling, score-based detection for toxicity). The metrics recommended — confusion matrix error types, pinned AUC — assume that correctness is definable and that the output is either a class label or a scalar score. Many of the most impactful ML systems deployed since the paper's publication are generative: large language models that produce open-ended text, text-to-image models, code generation models. How would a model card work for a language model? What are the relevant "factors" — prompt phrasing, language variety, topic domain, user demographic? What are the appropriate metrics — toxicity rates in generated text disaggregated by the demographic terms appearing in the prompt, factuality rates by topic, code correctness by programming language? What does "intersectional analysis" mean for a system whose output is evaluated holistically rather than classified as correct/incorrect? This extension is non-trivial because the model card framework's structure assumes (a) a well-defined task, (b) ground-truth labels for correctness, (c) discrete, pre-identified subgroups, and (d) metrics derived from confusion matrices or score distributions. Generative models violate all four assumptions. A research contribution would be to propose and validate a model card format adapted for generative models, specifying what replaces the confusion-matrix metrics, how subgroups are defined when the task is open-ended, and how synthetic evaluation data (already demonstrated for the toxicity classifier) can be systematically generated for generative evaluation. The paper's synthetic data approach (Figure 3) — template-based generation with controlled identity term insertion — provides a starting point: for a language model, one could construct templated prompts that vary demographic terms, languages, or dialects and measure toxicity, factuality, or refusal rates across those templates, producing a generative analog of the toxicity card's pinned AUC analysis.

Longitudinal study of model card adoption and its effects on the ML ecosystem. The paper was published in 2019. As of 2025, model cards have been adopted by several major organizations (Google, Hugging Face, Meta) and integrated into model-sharing platforms (Hugging Face Hub). A retrospective study could examine: (a) what fraction of models on major hubs have model cards, (b) whether cards from different organizations differ systematically in completeness (e.g., do corporate cards disclose fewer relevant factors than academic cards? do they more frequently omit intersectional analyses?), (c) whether the presence of a model card correlates with improved subgroup performance in independent audits (i.e., do models with cards actually perform more equitably, or do cards simply document existing disparities?), and (d) whether model card adoption has driven the creation of new evaluation datasets (as the paper hypothesized it would — Section 4.5). This study would test the paper's ecosystem-level theory of change: that standardized documentation formats create demand for evaluation infrastructure and pressure for improved model development practices, not merely better post-hoc reporting. A negative result — finding that model cards are widely adopted but shallow, that they do not correlate with improved subgroup performance, and that they have not stimulated evaluation dataset creation — would suggest that the transparency-via-documentation theory is insufficient without stronger enforcement or regulatory mechanisms. A positive result would validate the paper's bet that standardization plus stakeholder pressure can shift industry practice.

Testing whether the "relevant factors vs. evaluation factors" gap disclosure actually functions as a demand signal. One of the paper's most distinctive design choices is the requirement to contrast what should be evaluated with what was evaluated (Section 4.3.4), with the hypothesis that this gap will create pressure for better evaluation datasets. A controlled experiment could test this: present dataset creators (e.g., researchers who build and release evaluation benchmarks) with a corpus of model cards from a specific domain (e.g., face detection), some of which contain explicit gap disclosures ("we could not evaluate on Fitzpatrick skin type because no annotated dataset exists") and some of which do not. Measure whether dataset creators exposed to the gap disclosures are more likely to express intent to create an evaluation dataset addressing the named gap, and whether they actually do so (in a longitudinal follow-up). The paper's hypothesis is that repeated, standardized gap disclosures aggregate into a visible demand signal; this experiment would test whether the signal is actually received and acted upon by the actors (dataset creators) who can close the gap. The study could also examine whether the specificity of the gap disclosure matters — does "no dataset exists with Fitzpatrick skin type annotations" produce a stronger response than "further evaluation needed on diverse skin types"? If so, the model card's structured format (which forces developers to name specific missing factors and specific missing datasets) is doing work that informal limitation statements do not.

Practical Applications and Downstream Use Cases

Model-sharing platforms integrating model cards as first-class metadata. The most direct operationalization of this paper is the integration of model cards into model hubs and API documentation. Hugging Face Hub, for instance, now supports model cards as a standard metadata format — when a user uploads a model, the platform provides a model card template and renders it alongside the model's weights, license, and usage statistics. This means that a practitioner comparing two fine-tuned BERT models for toxicity classification can, in principle, compare their model cards side by side: see which identity terms each was evaluated on, whether intersectional results are reported, what the intended use and out-of-scope disclosures say, and whether the evaluation datasets are publicly accessible or proprietary. The specific benefit is comparability: without a standard format, every model's documentation is idiosyncratic (one developer reports F1 on a custom test set, another reports accuracy on GLUE, another reports nothing at all), and the practitioner cannot make an informed choice. With model cards, the practitioner can quickly identify that Model A was evaluated on a synthetic dataset with balanced identity term representation and achieved pinned AUC above 0.85 for sexual orientation terms, while Model B has no disaggregated evaluation at all — a clear decision criterion that aggregate accuracy would not provide.

Regulatory and procurement contexts requiring documented model evaluation. As governments and organizations develop AI procurement guidelines and algorithmic accountability requirements, the model card format provides a ready-made template for what "documented evaluation" should include. New York City's law requiring audits of automated employment decision tools (Local Law 144, effective 2023), for example, mandates that employers using AI for hiring or promotion conduct bias audits and publish results. The model card's structure — disaggregated evaluation by relevant demographic groups, intersectional analysis where sample sizes permit, disclosure of evaluation datasets, intended use boundaries, and ethical considerations — directly addresses what such an audit would need to contain. An organization facing a regulatory requirement to document their model's performance across demographic groups does not need to invent a format: they can produce a model card structured as specified in this paper, and the card's standardized sections make it differentially easy for regulators to verify completeness (a card missing the quantitative analyses section, or reporting only aggregate accuracy, is visibly incomplete). The specific benefit is regulatory interoperability: when both model developers and regulators converge on a shared documentation format, compliance costs drop and enforcement becomes more systematic.

Internal model governance within organizations deploying ML at scale. Large organizations that deploy dozens or hundreds of ML models across different products and teams face an internal coordination problem: how does the legal team know whether a model being integrated into a consumer-facing product has been evaluated for demographic disparities? How does a product manager considering reusing an existing model for a new application know whether it's suitable? A model card repository — where every model released internally is accompanied by a card following the paper's format — creates an auditable inventory. The nine sections of the card correspond to the questions different internal stakeholders need answered: the legal team checks intended use and out-of-scope disclosures against regulatory requirements; the product team checks the factors section to see whether the new application's user demographics match the evaluated subgroups; the engineering team checks the metrics and evaluation data sections to understand what "good performance" means for this model. The specific benefit is organizational memory: without model cards, institutional knowledge about a model's limitations and evaluation history walks out the door when the original developers leave. With model cards, the documentation is attached to the model artifact itself, creating a persistent record that can be referenced and updated across personnel changes.

Community-driven model auditing and accountability campaigns. The paper envisions model cards as a tool for impacted individuals and civil society organizations: "Impacted individuals who may experience effects from a model can better understand how it works or use information in the card to pursue remedies" (Section 3). Organizations like the Algorithmic Justice League (founded by Joy Buolamwini, whose experience with face detection failures is cited in the paper's introduction) or the ACLU could systematically request model cards from companies deploying high-stakes ML systems, compare the cards' reported performance against independent audits, and publicize discrepancies. The model card format makes this feasible at scale by standardizing what "disclosure" means: an advocacy organization can issue a request for the model card of a specific deployed system (e.g., a facial recognition system used by law enforcement) and immediately know whether the response is complete or evasive — a card that lacks quantitative analyses, or that omits a relevant factor (like race or skin type in a face recognition context), is visibly non-compliant with the framework's structure. The specific benefit is accountability leverage: the model card transforms "the company didn't tell us anything" into "the company's model card says X but our independent testing found Y," which is a far more actionable claim in public discourse, legal proceedings, or regulatory complaints. The paper's insistence on named datasets, specific metrics, and explicit thresholds (Section 4.4.1) means that the card's claims are falsifiable — an auditor can replicate the evaluation on the named dataset and check the numbers.

🎯 Pitch

1. Executive Summary

2. Context and Motivation

The Core Problem: ML Models Are Deployed Blind

Why Documentation, Specifically, Is the Gap

The Analogy: Mature Industries Have Standardized Reporting

Prior Approaches and Their Shortcomings

The Intersectionality Argument

Why a Standardized Framework Rather Than an Ad-Hoc Best Practice?

How the Paper Positions Itself

3. Technical Approach

3.1 Reader Orientation

3.2 Big-Picture Architecture (Diagram in Words)

3.3 Roadmap for the Deep Dive

3.4 Detailed, Sentence-Based Technical Breakdown

The Core Commitments: Disaggregation, Intersectionality, and Transparency as a Complement

Model Details: The Identity Card

Intended Use: Bounding the Model's Legitimate Scope

Factors: Defining the Axes of Disaggregation

Groups (Section 4.3.1)

Instrumentation (Section 4.3.2)

Environment (Section 4.3.3)

The Relevant Factors vs. Evaluation Factors Distinction

Metrics: Choosing What to Measure

Classification Systems (Section 4.4.1)

Score-Based Systems (Section 4.4.2)

Confidence Intervals (Section 4.4.3)

Evaluation Data: What the Model Was Tested On

Training Data: What the Model Learned From

Quantitative Analyses: The Evidence Section

Ethical Considerations: Beyond the Numbers

Caveats and Recommendations: What's Missing

The Two Worked Examples as Proof-of-Concept

Design Choices and Their Justifications

4. Key Insights and Innovations

Innovation 1: Disaggregated Evaluation Is Not a Fairness Metric — It's an Epistemological Requirement for Knowing What Your Model Does

Innovation 2: Intersectional Analysis Is Structural, Not Optional — The Unitary Breakdown Trap

Innovation 3: Out-of-Scope Use as an Affirmative Disclosure — Moving from "Caveat Emptor" to "Documented Boundaries"

Innovation 4: The "Relevant Factors vs. Evaluation Factors" Gap as a Productive, Not Embarrassing, Disclosure

Innovation 5: Model Cards as an Ecosystem Intervention, Not Just a Documentation Standard

5. Experimental Analysis

Evaluation Methodology

Main Quantitative Results

Smiling Classifier: Disaggregated Error Analysis by Gender and Age

Toxicity Classifier: Pinned AUC Across Identity Terms, Before and After Mitigation

Ablation Studies and Robustness Checks

Critical Assessment

What the Demonstrations Actually Show (and Do Not Show)

What Experiments Would Strengthen the Paper but Were Not Run

Conditional Claims and Boundary Conditions

6. Limitations and Trade-offs

6.1 The Framework Provides No Enforcement or Verification Mechanism — It Assumes Developer Integrity

6.2 Disaggregated Evaluation Requires Subgroup Annotations That Are Notoriously Difficult, Contested, and Often Unavailable

6.3 The Framework Provides No Guidance on the Combinatorial Explosion of Intersectional Subgroups

6.4 The Paper Provides No Evidence That Model Cards Change Stakeholder Behavior or Improve Outcomes

6.5 The Framework's "One to Two Page" Constraint Trades Comprehensiveness for Accessibility in Ways That May Undermine Both

6.6 The Framework Does Not Address Dynamic Models, Frequent Updates, or Model Drift

7. Implications and Future Directions

How This Work Changes the Landscape

Follow-Up Research This Work Enables

Practical Applications and Downstream Use Cases

Adjacent in domain

Qwen-Scope: Turning Sparse Features into Development Tools for Large Language Models