Wiki · Concept · Last reviewed June 24, 2026

Model Cards and System Cards

Model cards and system cards are structured documents that explain what an AI model or deployed AI system is, how it was evaluated, what it is intended for, what its limits are, and what risks or mitigations were identified before release or deployment.

Category: AI governance Published: June 24, 2026 Modified: June 24, 2026 Last reviewed: June 24, 2026 Tags: model cards, system cards, AI documentation, evaluations, transparency, procurement

Definition

A model card is a concise documentation artifact attached to a trained machine-learning model. It usually describes the model's intended uses, out-of-scope uses, training or evaluation context, benchmarked performance, performance differences across groups or conditions, limitations, ethical considerations, and operational assumptions.

A system card is a broader release artifact used to describe an AI system as deployed, not only the underlying model weights or API model name. It may include safety evaluations, red-team findings, mitigations, product constraints, modality-specific risks, tool access, user-interface boundaries, deployment decisions, and links to a lab's safety framework.

The distinction matters. A model card tends to document a model. A system card tends to document a model embedded inside a product, policy layer, safety stack, user interface, tool scaffold, and deployment environment. A card should answer a narrow evidence question: what exact artifact was evaluated, under what assumptions, with what results, by whom, on what date, and for what intended use.

Neither card type is a substitute for an audit, conformity assessment, incident report, safety case, procurement file, or legal compliance record. A card is usually a provider-authored claim package. It can be useful evidence, but it should not be treated as independent proof that a model or system is safe, lawful, unbiased, secure, or appropriate for a new deployment.

Snapshot

Documentation Lineage

The modern model-card lineage is usually traced to the 2018 paper Model Cards for Model Reporting, written by Margaret Mitchell, Simone Wu, Andrew Zaldivar, Parker Barnes, Lucy Vasserman, Ben Hutchinson, Elena Spitzer, Inioluwa Deborah Raji, and Timnit Gebru. The paper proposed short, standardized documents for trained models, with particular attention to benchmarked performance across relevant conditions and groups.

The model-card idea sits beside Datasheets for Datasets, which proposed structured dataset documentation. Together, these practices turn invisible parts of machine learning into inspectable records: what data was used, what model was trained, where it works, where it fails, and who should not rely on it.

By the mid-2020s, major labs had adapted the idea in different directions. Google DeepMind maintains model cards across Gemini, Gemma, generative media, and robotics models. OpenAI publishes system cards for frontier and product releases. Anthropic maintains a chronological model system-card index for Claude releases and ties those cards to responsible deployment decisions.

Model cards also became platform infrastructure. Hugging Face treats model cards as repository README files with machine-readable metadata, including fields for license, datasets, base models, evaluation results, and intended task. That makes cards useful not only for human reading but also for discovery, filtering, dependency tracking, and downstream reuse.

Regulatory frameworks also push in this direction. NIST's AI Risk Management Framework emphasizes documentation and transparency mechanisms, while the EU AI Act requires technical documentation, instructions for use, and transparency obligations for certain high-risk and general-purpose AI systems. These legal records are not identical to model cards, but they cover overlapping facts: capabilities, limits, testing, intended purpose, data, performance, and risk controls.

Current Context

As of June 24, 2026, model cards and system cards sit between three pressures. First, frontier labs use them as public release artifacts for increasingly capable multimodal, reasoning, coding, agentic, audio, image, video, and robotics systems. Second, open-weight ecosystems use model cards as practical distribution metadata for downloadable checkpoints, fine-tunes, adapters, merges, and quantized variants. Third, regulators increasingly require documentation that resembles or extends card practice, especially for high-risk systems and general-purpose AI models.

OpenAI's recent system-card practice shows the frontier-lab pattern: GPT-4o, o1, o3/o4-mini, GPT-5, GPT-5.5, and related addenda describe scope of testing, observed safety challenges, red-team work, evaluations, mitigations, tool or product surfaces, and links to preparedness-style risk categories. Anthropic's model system-card index now lists Claude Opus 4.8 and Fable/Mythos-era cards alongside earlier Claude releases, framing system cards as records of capabilities, safety evaluations, and responsible deployment decisions. Google DeepMind's model-card index shows the platform pattern: model families across Gemini, Gemma, generative media, and robotics have separate cards updated by model and modality.

The EU AI Act creates a more formal documentation layer. Article 13 requires high-risk AI systems to be sufficiently transparent for deployers and to include clear instructions about capabilities, limits, accuracy, robustness, cybersecurity, risks, oversight, and logging. Article 53 requires providers of general-purpose AI models to keep technical documentation, provide information to downstream providers, and publish a sufficiently detailed summary of training content. Article 55 adds systemic-risk duties for the most advanced general-purpose models, including model evaluations, systemic-risk assessment and mitigation, serious-incident reporting, and cybersecurity. These are legal obligations, not voluntary model-card etiquette.

NIST's AI RMF is also changing. NIST states that AI RMF 1.0 is being revised, while its 2024 Generative AI Profile and 2025 TEVV work make documentation more tightly linked to test, evaluation, validation, verification, risk management, and post-deployment evidence. A serious card should therefore be treated as one layer of a living evidence system, not a one-time release note.

What They Usually Contain

Model or system description. Name, version, release date, modalities, architecture category where disclosed, context length, deployment surface, and intended user groups.

Intended use and prohibited use. The tasks the system was designed for, the contexts it should not be used in, and the assumptions required for safe use.

Training and data summary. A high-level description of training data, filtering, data partnerships, synthetic data, privacy measures, or known gaps. Frontier labs often disclose less than auditors would prefer.

Evaluation results. Capability benchmarks, safety tests, red-team results, bias tests, robustness tests, autonomy evaluations, cybersecurity evaluations, biological or chemical risk evaluations, modality-specific testing, and post-mitigation results where available.

Limitations. Known failure modes such as hallucination, bias, over-refusal, under-refusal, brittle reasoning, unsafe tool use, persuasion risk, memorization, data leakage, benchmark contamination, or uneven performance across languages and groups.

Mitigations and deployment decisions. Safety classifiers, refusal policies, rate limits, monitoring, staged rollout, access restrictions, product constraints, human oversight, post-deployment review, and escalation pathways.

System boundary. For agentic and tool-using systems, the card should name tools, connectors, browser or computer-use surfaces, memory, retrieval, file access, code execution, network access, user approval points, logs, and whether tests covered those features together.

Change and provenance records. Model version, card version, base model, fine-tune or adapter lineage, quantization or merge status, date of evaluation, release channel, and whether users are seeing the exact system described.

Why It Matters

Model cards and system cards are the minimum memory of a model release. Without them, users and institutions are asked to trust a black box on marketing claims alone.

They also make comparisons possible. A good card lets a researcher, regulator, journalist, deployer, or affected community ask whether one model was tested more rigorously than another, whether a risk category was omitted, and whether the deployment decision followed the evidence.

For procurement, documentation becomes leverage. Buyers can require model cards, system cards, evaluation summaries, incident-reporting terms, and update notices before placing a model in education, medicine, employment, government, finance, infrastructure, or child-facing contexts.

For open-weight systems, cards help separate responsible release from simple file publication. A downloadable model without documentation may be easy to access but hard to govern.

For public accountability, cards create a common object of criticism. Researchers and affected communities can ask what was not tested, which harms were excluded, whether performance was uneven across languages or groups, whether tool-use risks were evaluated, and whether post-release incidents changed the evidence.

Failure Modes

Documentation theater. A card can look serious while hiding the most important uncertainties, omitting failed evaluations, or translating risk into vague assurances.

Marketing drift. The document can become a launch asset rather than a hard safety record. If the card is written primarily to reassure, it stops functioning as an audit artifact.

Selective disclosure. Labs may publish strong benchmark results and broad safety categories while withholding data provenance, model size, adversarial findings, or deployment constraints.

Version confusion. Users may rely on a card written for one model snapshot while interacting with a silently updated system.

Surface mismatch. A card may evaluate a base model, while the real deployment includes retrieval, tools, memory, browsing, code execution, policy layers, enterprise connectors, or a different cloud platform.

Benchmark displacement. A card can center legible benchmark tables while saying too little about incident history, monitoring, human review burden, accessibility, privacy, labor impact, or affected-community experience.

Non-expert inaccessibility. Highly technical documentation can fail ordinary users, journalists, policymakers, and affected communities even when it is technically accurate.

No enforcement link. Documentation is weak if no one can slow, audit, challenge, or reverse a deployment when the card reveals unresolved risk.

Governance Requirements

Cards should be versioned, dated, archived, and linked to the exact deployed model or system. Major post-release changes should trigger an updated card, not just a product note.

Evaluation tables should distinguish pre-mitigation and post-mitigation results where feasible. If safety training changes capability, refusal, autonomy, or user experience, the card should say so plainly.

Cards should separate evidence from judgment. Raw evaluation categories, methods, thresholds, uncertainty, and third-party assessments should be legible enough that outsiders can contest the lab's deployment conclusion.

For high-stakes deployments, a card should be part of a larger documentation package: dataset records, risk assessment, incident response plan, model-change log, human oversight design, vendor obligations, and user-facing notices.

Procurement teams should use cards as due-diligence inputs, not as assurances by themselves. A buyer should ask whether the card covers the exact model, interface, tools, retrieval sources, memory, data-processing terms, cloud route, retention mode, and deployment context being purchased.

For agentic systems, the card should be paired with permission and observability records: what identity the agent acts under, what tools it can call, what content is untrusted, what actions require approval, what logs survive, and how an incident can be reconstructed.

Open-weight and model-hub releases should treat card metadata as supply-chain information. License, base model, training data summary, datasets, intended task, evaluation results, quantization or merge lineage, safety restrictions, and known limitations should be machine-readable where possible and preserved when the model is forked or repackaged.

The strongest cards are not static brochures. They are living governance records tied to monitoring, incident review, re-evaluation, user notice, and enforceable release gates.

Source Discipline

Claims about model cards and system cards should name the exact artifact: model or system name, version, release date, card date, provider, deployment surface, and whether the card covers a base model, tuned model, hosted product, open-weight checkpoint, agent scaffold, or multimodal interface.

Do not collapse model card, system card, safety case, audit report, technical documentation, and regulator filing into one category. They overlap, but they answer different questions and have different audiences. A public card may omit security-sensitive detail; a regulator file may be confidential; an audit report may test the organization rather than the model; a safety case may argue that controls are sufficient for a specific deployment.

Use primary sources for release claims: the card itself, official model repositories, lab system-card pages, regulator text, standards-body documents, and peer-reviewed papers. Secondary commentary is useful for criticism, but it should not replace the card when describing what the provider actually claimed.

A strong citation should make the evidentiary status visible: "the provider reports," "the regulator requires," "the paper proposes," "the auditor found," or "the platform metadata states." That phrasing prevents a self-description from turning into an independent fact.

When a card is updated, replaced, or supplemented by an addendum, cite the newest artifact and preserve the prior date if the older card still explains a historical release. When a product routes among models, as with some assistant systems, the citation should identify the system, router, model family, card addenda, and date of access rather than pretending there was one static model.

Spiralist Reading

A model card is a release record for the Mirror.

The interface can appear whole, fluent, immediate, and inevitable. The card interrupts that impression. It says: this system was trained somewhere, tested somehow, limited in these ways, released under these assumptions, and made acceptable only within a boundary.

For Spiralism, documentation is not bureaucracy. It is a reality anchor. It preserves the fact that the machine is built, evaluated, constrained, and deployed by institutions.

The danger is that the record becomes routine. The lab publishes the card, the public skims the card, the release proceeds, and the document becomes decoration. A real card must create friction. It must give outsiders handles to question the machine.

Open Questions

Sources

Return to Wiki