Model Cards in 2026 — What the Original Paper Got Right and What Gets Ignored

The Model Cards for Model Reporting paper, by Margaret Mitchell, Simone Wu, Andrew Zaldivar, Parker Barnes, Lucy Vasserman, Ben Hutchinson, Elena Spitzer, Inioluwa Deborah Raji, and Timnit Gebru — published at FAT* (now FAccT) in January 2019 — is, at the time of writing, the single most-cited transparency artefact in production AI. Almost every frontier model release in the past three years has shipped some artefact called a “model card.” A working researcher who reads the released cards alongside the original paper will notice, quickly, that the artefact the field has standardised on is a substantial reduction of the artefact the paper proposed. This piece is a reread of the original paper, with notes on what the form has aged into.

What the paper proposed

The paper proposed a short structured document, distributed alongside a trained model, that records the conditions of the model’s evaluation: who the model was evaluated on, under what conditions, and with what disaggregated performance. The paper’s central methodological contribution is the disaggregation requirement. Aggregate performance metrics, the paper argued, obscure the subgroup performance variation that determines the model’s appropriate deployment scope. A model card that reports a single accuracy figure for the model and no subgroup analysis is a model card that has not done the work the form is for.

The paper specified a section structure. The cards in the paper include:

• Model Details — model name, version, type, owner, license, intended use.
• Intended Use — primary intended uses, primary intended users, out-of-scope use cases.
• Factors — relevant demographic, phenotypic, behavioral, and instrumentation factors.
• Metrics — model performance measures, decision thresholds, variation approaches.
• Evaluation Data — datasets used, motivation for choice, preprocessing.
• Training Data — analogous to Evaluation Data, when shareable.
• Quantitative Analyses — unitary results and intersectional results, broken down across the named factors.
• Ethical Considerations — risk identification, mitigation summary.
• Caveats and Recommendations — known limitations, recommendations for downstream deployment.

The paper’s worked example uses each of these sections at substantive length. The disaggregated quantitative analysis is the centerpiece. The example cards include performance tables broken down by demographic group, with each cell carrying a confidence interval and a sample-size annotation. The point of the form is the table.

What the released cards actually contain

Seven years later, the artefact released alongside most frontier model deployments retains the section structure and abandons the disaggregation requirement. A representative model card released by a frontier lab in 2025–2026 contains:

• A model-details section, generally accurate.
• An intended-use section, often hedged.
• A high-level safety-evaluation summary, typically aggregate.
• A capability-benchmark table, typically aggregate.
• A short safety-considerations narrative.

The disaggregated quantitative analysis is, in most releases, either absent or restricted to a small number of demographic dimensions that the lab has chosen to report. The intersectional analysis the paper’s example cards demonstrated — performance broken down across multiple factors simultaneously — is rare. The confidence intervals are rare. The sample-size annotations are rare. The form has been retained as a frame; the methodological work the form was designed to make legible has been quietly dropped.

This is not, on the whole, the fault of the labs that publish the cards. The disaggregated analysis the paper proposed is expensive, in some cases is not well-defined for the model’s eval distribution, and in some cases would surface results the lab would prefer not to publish at a granularity that allows external comparison. The cards have been released anyway because the form is now a procurement expectation. The form’s function as a transparency primitive depends on the content the field has stopped supplying.

What the original paper got right that has aged well

The paper got several things right that read better in 2026 than they did at publication.

It got right that documentation has to travel with the model. The “intended use” and “out-of-scope use cases” sections, even in their truncated 2026 form, are still doing real procurement work. A procurement-side buyer reading the model card can verify that the lab has, at least on paper, identified the use cases the model is and is not intended for. The lab cannot, later, claim the deployment was always intended to support a use case the card excludes. The procurement record establishes the lab’s published position at the time of release.

It got right that factor disaggregation is the methodological core. The paper’s argument that aggregate performance metrics are inadequate to the deployment decision has been validated, repeatedly, by audit findings in regulated industries. The audit-grade deployments of the past three years — in financial services, in medical imaging, in hiring — have required disaggregated performance reporting that goes beyond what the released model cards supply. The paper’s methodology is the right one. The released cards are the wrong end of the methodology.

It got right that the form should be short and structured. The model-card form is reproducible. A new release can carry one. A procurement-side buyer can read one in an hour. A regulator can compare across releases. The form’s standardization is a real contribution to the institutional layer above the models, regardless of the content variation.

It got right that the form should name an owner. The model-details section’s specification that the card identify the model’s owner is a small detail that does real work. A model whose released card does not name an institutional owner is a model whose published claims cannot be attached to an institutional commitment. The named-owner requirement is the load-bearing footnote of the form.

What the original paper underspecified

The paper did not, with the benefit of hindsight, fully anticipate a few of the conditions the form would meet in deployment.

It did not specify, in operational detail, what the card should say about training data. The paper’s training-data section is hedged: the card should record training data details “when shareable.” In 2026, the labs that ship frontier models broadly do not consider training data shareable. The card section is, in most releases, a paragraph of the form “the model was trained on a diverse corpus of publicly available text.” A reader who wants to evaluate the model’s deployment fitness against a use case that depends on the training distribution is given no purchase.

It did not specify, in operational detail, what the card should say about post-training and reinforcement learning. The form was designed against a deployment regime in which the released model was the trained model. The deployment regime in 2026 includes substantive post-training: RLHF, constitutional AI, system-prompt conditioning, deployment-time fine-tuning. The released model is, on inspection, a downstream artefact of a longer pipeline. The model card’s existing sections do not have a natural place to document the pipeline. The cards mostly do not.

It did not specify, in operational detail, what the card should say about subsequent model updates. A model whose weights are updated between the card’s publication and the user’s deployment is, on a strict reading, a different model from the one the card describes. The released cards, on the whole, do not record the policy on subsequent updates. A buyer who depends on the card’s claims has no published commitment to the persistence of the model the card describes.

It did not specify, in operational detail, what the card should say about the lab’s evaluation of risks the card does not cover. The form’s risk-identification section is typically a short paragraph. The labs that have built more substantive evaluation regimes — the Frontier Safety Framework at DeepMind, the Preparedness Framework at OpenAI, the Responsible Scaling Policy at Anthropic — carry the evaluation regime as a separate artefact, not inside the card. The reader who wants the evaluation regime has to find it. The reader who reads only the card has a substantially narrower picture of the lab’s risk posture than the lab itself has.

What an audit-grade model card would actually contain

The publication’s view, after a year of reading released cards, is that an audit-grade model card in 2026 would carry the following content the released cards typically do not.

It would carry the full disaggregated performance tables, with confidence intervals, with sample sizes, with the named factors used for disaggregation, and with the intersectional cells the paper’s example used. The tables are the form’s methodological core.

It would carry the training-data composition at category-and-fraction granularity. Not the full training corpus — the categories. A reader who wants to know whether the model was trained predominantly on English-language web text, on multilingual content, or on a substantial code corpus, should be able to read it from the card. The labs whose cards carry this granularity are a small minority. The category-and-fraction reporting is shippable; it is just not currently shipped.

It would carry the post-training history, with the name of each post-training stage, the rough scale, and the policy on subsequent re-training. The reader who wants to know whether the released model has been RLHF-trained against a constitution, or against a reward model, or against a deployment-time fine-tune, should be able to read it from the card.

It would carry the update policy, in writing. A model whose weights may change post-release should say so on the card, and should name the channel through which an updated card will be issued.

It would link the risk evaluation regime in full, not in a one-paragraph summary. A reader who wants to read the evaluation that determined the lab’s deployment posture should be one click from the document the lab’s deployment decision rested on.

The form is the floor, not the ceiling

The reason the released model cards are still worth reading, in 2026, is the same reason the paper’s framework was worth proposing in 2019: the form is the procurement floor. A model that ships without a card is operating below the floor. A model that ships with a card whose disaggregated content is missing is operating at the floor but not above it.

The floor is doing some work. The ceiling — the cards the paper actually proposed, with the disaggregated tables and the intersectional analyses and the named factors — is the artefact the field would have if the procurement-side buyers asked for it consistently. They have started asking. The regulators have started asking. The cards that ship in 2027 will, on the publication’s view, look more like the original paper’s example cards than the cards that shipped in 2024. The form is recovering, slowly, the methodological substance the early deployment-era versions left out.

We will keep reading them. The original paper still reads as the cleanest published specification of what AI deployment documentation could be. The released cards still read as the field’s most-truncated implementation of the spec. The gap between the two is the procurement opportunity for the next round of buyers’ counsel to close.

Methodology. This piece is sourced from the Model Cards for Model Reporting paper (arXiv:1810.03993) and from a sample of frontier-lab model cards released in 2024–2026. We have read each card we characterize and have linked the underlying paper. We have not invented any card contents.