Evaluating language models
System cards, explained
What a system card is, how it differs from a model card, what Anthropic's and OpenAI's published cards contain, and what a card does and does not prove.
Oct 25, 202613 min read13 sources
Why it matters
A program office that buys or integrates a frontier model gets the developer's own account of the model's testing in a system card, and has to know what that document can and cannot settle.
The short version
- 1A model card documents one trained model; a system card, a term Meta introduced in February 2022, documents the whole system around a model, including the non-model safeguards.
- 2The Claude Opus 4.5 System Card runs from capabilities through safeguards, honesty, agentic safety, an alignment assessment, a model welfare report, and the Responsible Scaling Policy evaluations that set its AI Safety Level.
- 3OpenAI's GPT-4 System Card says in its own text that it is not comprehensive and that its examples were cherry picked, and the GPT-5 System Card's external assessors list the limits of their own tests.
A system card is a document a developer publishes alongside an artificial intelligence (AI) system that describes what the system is made of, how it was tested, what safeguards surround the model, and what is known to go wrong. The term comes from Meta, which introduced system cards on February 23, 2022 as documentation for a whole AI system rather than a single model. OpenAI and Anthropic adopted the name for the long reports they publish with each frontier language model. For a buyer, a system card is the developer's own account of its testing: the place to start due diligence, and not the place to end it.
System card vs model card
The model card came first. Mitchell and colleagues proposed model cards in a paper first posted on October 5, 2018 and presented at the 2019 Conference on Fairness, Accountability, and Transparency. The abstract describes them as short documents accompanying trained machine learning models that report benchmarked evaluation across conditions, disclose the intended use context, and give details of the evaluation procedures. A model card is about one model. The post on model cards and datasheets walks through its nine sections.
Meta's System-Level Transparency of Machine Learning, by Procope and eight co-authors and dated February 22, 2022, argues that a model card can miss what matters about a product. The paper names two situations. First, complex systems such as content ranking involve many models, the datasets used to train them, and technologies that are not machine learning at all, including human-in-the-loop steps, so the documentation has to show how data moves across components. Second, a model often takes another model's outputs as inputs, for example embeddings or a baseline model used for transfer learning, so the documentation has to account for those dependencies. The paper's answer is the System Card, which gives stakeholders an overview of the components of a system, how they interact, and how data and protected information are used. The authors also flag a tension: providing information about how a system works could invite adversarial attacks, and with enough detail a malicious actor could reverse-engineer the system, so a card has to choose what to leave out.
The companion blog post defines an AI system as a group of machine learning models and AI and non-AI technologies that work together, and says the first system card, for Instagram feed ranking, explains how the system takes posts from accounts a person follows and ranks them by predicted interest. The post says system cards are meant to be readable by experts and non-experts alike.
So the distinction is one of scope. A model card answers "what is this model and how does it score." A system card answers "what is deployed, with what controls around it, and what did the developer find when it tried to break it."
How OpenAI uses the term
OpenAI's first use of the format was for an image model. The DALL-E 2 Preview - Risks and Limitations document, last updated April 11, 2022 and assessing the system as of April 6, 2022, says it takes inspiration from the concepts of model cards and system cards, and links to Meta's post. The document's "System Components" section covers the model, the restrictions on access, and the policies and enforcement, which is the system-level view in practice: the DALL-E 2 model is one part of the Preview, and the risks depend on the filters, access controls, and monitoring around it. The remaining sections cover the risk assessment process, including external red teaming, probes and evaluations by category, relation to existing technologies, and future work.
The GPT-4 System Card applied the format to a language model. The card's first footnote says the document takes inspiration from model cards and system cards and often takes the system level of analysis, with the system including non-model mitigations such as use policies, access controls, and monitoring for abuse. The card analyzes two versions of the model, GPT-4-early, fine-tuned for instruction following, and GPT-4-launch, fine-tuned for helpfulness and harmlessness with the mitigations the card describes. OpenAI engaged more than 50 experts for adversarial testing. The card's section on observed safety challenges runs through hallucinations, harmful content, harms of representation, disinformation and influence operations, proliferation of conventional and unconventional weapons, privacy, cybersecurity, potential for risky emergent behaviors, interactions with other systems, economic impacts, acceleration, and overreliance. Sections on deployment preparation and system safety follow, covering model mitigations, usage policies and monitoring, and content classifier development. The card also records a preliminary evaluation by the Alignment Research Center of whether the model could autonomously replicate and gather resources, with the conclusion that it probably could not. Red teaming as a method is the subject of the post on red teaming language models.
The OpenAI GPT-5 System Card, posted to arXiv on December 19, 2025 and revised on May 1, 2026, is the card published with the GPT-5 launch in August 2025. The abstract says the document focuses primarily on two models, gpt-5-thinking and gpt-5-main, with other models in an appendix. The structure shows what a frontier system card had become by 2025:
| Section | What it covers |
|---|---|
| Model data and training | How the models were built |
| Observed safety challenges and evaluations | Safe-completions, disallowed content, sycophancy, jailbreaks, instruction hierarchy, prompt injections, hallucinations, deception, image input, health, multilingual performance, fairness and bias |
| Red teaming and external assessments | Expert red teaming for violent attack planning, expert and automated red teaming for prompt injections |
| Chain of thought evaluations | Monitorability and controllability of the model's reasoning |
| Preparedness Framework | Capabilities assessment, a research category update on sandbagging, safeguards for high biological and chemical risk |
The card reports more than 5,000 hours of testing from over 400 external testers and experts, and says gpt-5-thinking is treated as High capability in the biological and chemical domain under the Preparedness Framework, which activates safeguards, while the series did not meet the High threshold in cybersecurity or AI self-improvement. Two outside evaluators appear with their own findings. METR concluded over three weeks of testing that the model was unlikely to speed up AI research by more than 10 times and estimated a 50 percent time horizon of about 2 hours 15 minutes. Apollo Research ran 26 evaluations and found covert actions in about 4 percent of trajectories, against 8 percent for the earlier o3 model.
The framework that organizes the Preparedness section is public. OpenAI's Preparedness Framework, Version 2, dated April 15, 2025, names three Tracked Categories, biological and chemical, cybersecurity, and AI self-improvement, defines High and Critical capability thresholds for each, and describes a Capabilities Report and a Safeguards Report submitted to an internal Safety Advisory Group. The framework tells readers that they can learn more about the capability evaluations in past system cards, which makes the card the public record of that process.
How Anthropic uses the term
Anthropic keeps an index page of model system cards. The page says system cards document the capabilities, safety evaluations, and responsible deployment decisions for Claude models, and lists cards from Claude 2 in July 2023 to Claude Haiku 5.5 in October 2026. The files for Claude 2 and for the June 2024 Claude Sonnet 3.5 addendum carry the words "Model Card" in their file names, so the naming shift happened inside one developer's own series.
The System Card: Claude Opus 4.5, dated November 2025, shows the sections as they appear. The abstract says the card describes a detailed assessment of the model's capabilities and then a wide range of safety evaluations: tests of model safeguards, honesty, and agentic safety; an alignment assessment including sycophancy, sabotage capability, and evaluation awareness; a model welfare report; and a set of evaluations mandated by the Responsible Scaling Policy (RSP). The abstract states that the model was deployed under the AI Safety Level 3 (ASL-3) Standard. The table of contents has seven main sections, followed by an appendix:
- Introduction, including training data, crowd workers, and the release decision process
- Capabilities, opening with a decontamination section on benchmark data and then more than 20 benchmarks
- Safeguards and harmlessness, with single-turn, ambiguous-context, multi-turn, child safety, and bias evaluations
- Honesty, with factual questions and false premises
- Agentic safety, including malicious use of agents and prompt injection within agentic systems
- Alignment assessment, including an automated behavioral audit, sycophancy, deception, sandbagging, evaluation awareness, reward hacking, sabotage capability, external testing from the UK AI Security Institute, and a model welfare assessment
- RSP evaluations, covering chemical, biological, radiological, and nuclear (CBRN) risks, autonomy, and cyber, with third-party assessments
The release decision process section explains how the ASL was set. Anthropic's Frontier Red Team evaluated the model and wrote a report, the Alignment Stress Testing team reviewed and critiqued it, both went to the Responsible Scaling Officer and the chief executive, who made the determination. The card states that the model does not cross either the AI R&D-4 or the CBRN-4 capability threshold, and in the same passage says that confidently ruling out these thresholds is becoming increasingly difficult, because the model is approaching or passing high levels on the rule-out evaluations that serve as early proxies. For autonomy, the rule-out leaned on a survey of 18 Anthropic employees who use the model intensively, none of whom believed it could fully automate an entry-level remote research role.
The System Card: Claude Opus 4.7, dated April 16, 2026, reorders the sections and opens with an executive summary. After the introduction, RSP evaluations come first, followed by a standalone section on cyber, then safeguards and harmlessness, agentic safety, alignment assessment, model welfare assessment, capabilities, and an appendix. The summary says the model does not advance the capability frontier because Claude Mythos Preview, released to a limited number of users, scored higher on every relevant evaluation, and reports an external evaluation from the UK AI Security Institute in which Opus 4.7, unlike Mythos Preview, could not complete the full cyber range. The card adds an election integrity evaluation. Comparing the two cards shows that the format is not fixed even within one developer; the sections track what the developer judged most important at release.
The policy behind the ASL language is also public. Anthropic's Responsible Scaling Policy page gives the current version as 3.4, effective July 8, 2026. An October 15, 2024 entry on the page, written under an earlier version, describes the ASL-3 Security and Deployment Standards and says the policy commits Anthropic to publicly release key information about the evaluation and deployment of its models, not including sensitive details. Version 3.4 itself says earlier editions defined AI Safety Levels with specific lists of required controls, and that Anthropic still uses the concept to describe present levels of risk mitigation. The page also lists redacted Risk Reports as a separate publication.
What a system card typically reports
Reading across the cards, five kinds of content recur.
Evaluations. Benchmarks for capability, and a separate battery for safety: refusal rates on violative and benign requests, bias tests, factual accuracy, and in the GPT-5 card a claim-level hallucination rate reported as 65 percent lower than o3. The Opus 4.5 card's decontamination section addresses whether benchmark data leaked into training, a question the post on held-out test sets covers in general.
Red teaming. The GPT-4 card describes more than 50 experts; the GPT-5 card describes over 400 external testers, 25 red teamers on violent attack planning, and two external groups on a two-week prompt-injection assessment. The Opus 4.5 card describes ASL-4 expert red teaming and red teaming with the U.S. Center for AI Standards and Innovation (CAISI).
Framework-tied risk evaluations. Both developers run a defined set of dangerous-capability tests and report which threshold the model did or did not cross: High in biological and chemical for GPT-5, ASL-3 for Opus 4.5.
Safeguards. The GPT-5 card describes a two-tier real-time monitoring system covering gpt-5-thinking traffic, account-level enforcement, and a new safety identifier field in the application programming interface (API). The GPT-4 card covers usage policies, monitoring, and classifiers. An October 15, 2024 entry on the RSP page described planned ASL-3 deployment safeguards as a four-layer defense of access controls, real-time classifiers, asynchronous monitoring, and post-hoc jailbreak detection.
Known limitations. Every card has them, and the next section is about reading them.
How a buyer should read one
A system card is written by the party whose product it describes. That is not a reason to dismiss it, since the cards contain admissions no marketing document would, but it sets the reading posture. Five habits help.
Read the limitations passages first. The GPT-4 card says plainly that it is not comprehensive, that the examples throughout are cherry picked from evaluation efforts to illustrate specific concerns, and that custom fine-tuning and image capabilities are out of scope. The Opus 4.5 card, in a section on sabotage evaluations, notes that predeployment testing involves substantially fewer queries than a full deployment, so a rare harmful behavior could go undetected in testing and still occur in use.
Read the third-party sections as the independent evidence, and read their caveats too. The UK AI Security Institute's statement in the Opus 4.5 card says it tested an early snapshot over 8 days, found no research sabotage, and adds that it tested only a limited set of scenarios and that evaluation awareness complicates the results. METR's section in the GPT-5 card says its evaluations lacked rigorous countermeasures against sandbagging and that its conclusions depend in part on background information OpenAI provided. The card notes that Apollo's evaluations are designed to elicit deceptive behavior, so the rates are not expected to reflect production traffic.
Match the version. Cards evaluate specific snapshots. The Opus 4.5 card says Anthropic tested multiple snapshots, including helpful-only versions with safeguards removed, and generally reports results from the final deployed model while noting that many dangerous-capability evaluations report whichever snapshot scored highest. A buyer should confirm that the model identifier delivered is the one the card covers.
Check the changelog. The Opus 4.5 card's changelog records a November 24, 2025 correction: an earlier version had said the model trained only on the public training set of ARC-AGI-1, when it had trained on a reshuffled split that included the public test set, with reported scores coming from a semi-private set. A card can be wrong and later fixed, and the fix is dated.
Place the card in a governance process. The National Institute of Standards and Technology (NIST) Generative AI Profile, NIST AI 600-1 of July 2024, lists among its suggested actions reviewing transparency artifacts such as system cards and model cards for third-party models (MG-3.1-005), and re-assessing risks after fine-tuning or retrieval-augmented generation and for third-party models used in ways not evaluated in initial testing (MG-3.1-003). The post on the NIST AI Risk Management Framework explains where that profile sits.
What a system card does not prove
A system card does not prove that a model will behave on a buyer's documents or task. The evaluations are the developer's, run on the developer's benchmarks and prompts, often with tools and harnesses the developer built. The Opus 4.5 card describes agentic evaluations in which the model had access to domain-specific tools and in which prompting was iteratively refined by analyzing failure cases. A program office's use case was not among them.
A system card does not prove that the safeguards hold in a buyer's configuration. The GPT-4 card's own abstract says the mitigations are limited and remain brittle in some cases. The GPT-5 card lists residual risks that include undiscovered universal jailbreaks and the difficulty of distinguishing malicious developers from end users in the API. Both cards exclude fine-tuned variants.
A system card does not prove the absence of a capability. The Opus 4.5 card's conclusion that the model does not cross the CBRN-4 or AI R&D-4 threshold is accompanied by the statement that parts of those thresholds have fundamental epistemic uncertainty, and the card's autonomy rule-out rests partly on a staff survey. A "does not cross" finding is a judgment under a stated policy, dated to a release, not a measurement with a confidence interval.
And a system card does not replace the buyer's own evaluation. The cards say so themselves, in the limitations language quoted above, and NIST AI 600-1's actions on third-party models assume the buyer does further work. The card tells the buyer what the developer looked for and what it found; the gaps between that and the buyer's deployment are the buyer's to test.
What to check
- Does the card name the exact model version and snapshot evaluated, and does that match the model identifier being delivered?
- Which tests were run by the developer and which by outside groups, and what limits do the outside groups state about their own tests?
- Which uses does the card put out of scope, for example fine-tuning or image input, and does the planned deployment fall inside them?
- Which safeguards described in the card are properties of the model, and which depend on the developer's hosted monitoring that a self-hosted or air-gapped deployment would not have?
- Has the card been revised since release, and what did the changelog correct?
- What did the card not test that the buyer's task requires, for example the buyer's own documents, language, or refusal behavior on unanswerable questions?
Azcuna's ELLMENT, the E-2D Large Language Model Entity, was proposed to NAVAIR PMA-231 under Navy SBIR Phase I topic DON26BZ01-NV010. The prototype, built at private expense on publicly available doctrine, answers with a page-level citation and refuses when the documents do not support an answer. The proposal has been submitted.
Questions people ask
What is a system card?
A system card is a document a developer publishes with an AI system that describes the system's components, how they were evaluated, what safeguards surround the model, and what is known to go wrong. Meta introduced the term in February 2022 for documentation of a whole AI system, meaning a group of models and non-AI technologies working together. OpenAI's GPT-4 System Card and Anthropic's Claude system cards are the best known examples for language models.
What is the difference between a system card and a model card?
A model card, proposed by Mitchell and colleagues in 2018, documents a single trained model: intended use, evaluation data, metrics, and caveats. A system card documents the whole deployed system. Meta's 2022 paper says model cards may not capture system-level information when a product uses many models and non-machine-learning components. OpenAI's GPT-4 System Card says it takes the system level of analysis, including use policies, access controls, and monitoring for abuse.
What does an AI system card typically report?
The published cards report capability benchmarks, safety evaluations such as refusal rates on violative and benign requests, red teaming by employees and outside groups, evaluations tied to a risk framework such as Anthropic's Responsible Scaling Policy or OpenAI's Preparedness Framework, third-party assessments, and known limitations. The Claude Opus 4.5 System Card also includes a decontamination section on benchmark data and a model welfare assessment.
Who publishes system cards?
Meta published the first, for Instagram feed ranking, in February 2022. OpenAI published a system card for GPT-4 in 2023 and for GPT-5 in August 2025, and its Preparedness Framework points readers to past system cards for its capability evaluations. Anthropic maintains an index page of system cards for Claude models from July 2023 to October 2026, and its Responsible Scaling Policy names system cards as one place it has publicly analyzed model risks.
What does the Claude Opus 4.5 System Card contain?
The November 2025 card has seven main sections and an appendix: an introduction with the release decision process, capabilities, safeguards and harmlessness, honesty, agentic safety, an alignment assessment, and Responsible Scaling Policy evaluations covering chemical, biological, radiological, and nuclear risks, autonomy, and cyber. The abstract says the model was deployed under the AI Safety Level 3 Standard. The card's changelog records corrections made on November 24, November 25, and December 5, 2025.
What does a system card not prove?
A card is the developer's own account. The GPT-4 System Card states that it is not comprehensive and that its examples were cherry picked to illustrate concerns. The Claude Opus 4.5 System Card says predeployment testing involves far fewer queries than a full deployment, and the UK AI Security Institute's note in that card says it tested a limited set of scenarios. None of these cards evaluates a buyer's own documents or task.
What is a model system card meaning in practice for a buyer?
For a buyer, the card is the starting document for due diligence on a third-party model. NIST AI 600-1, the Generative AI Profile, lists reviewing transparency artifacts such as system cards and model cards for third-party models as a suggested action, MG-3.1-005. The card tells the buyer which version was tested, under what safeguards, with what results, and what the developer itself flags as unresolved, so the buyer's own testing can start from those gaps.
Does a system card cover fine-tuned or retrieval-augmented versions of a model?
Usually not. The GPT-4 System Card says custom fine-tuning and image capabilities were explicitly out of scope. The Claude Opus 4.5 System Card evaluates specific model snapshots and the final release candidate, not a customer's later configuration. NIST AI 600-1 action MG-3.1-003 says to re-assess risks after fine-tuning or retrieval-augmented generation, which a card written at release cannot have done.
How often are system cards updated after release?
The published cards show two patterns. Anthropic's Claude Opus 4.5 System Card carries a changelog with three dated revisions in November and December 2025, one of which corrected a statement about which ARC-AGI-1 data the model had trained on. OpenAI posted the GPT-5 System Card to arXiv in December 2025, four months after the August 2025 launch, and revised it in May 2026. Each new model gets a new card rather than an edit to the old one.
Sources
- 1Model Cards for Model Reporting · arXiv (Mitchell et al.)
- 2System Cards, a new resource for understanding how AI systems work · Meta AI
- 3System-Level Transparency of Machine Learning · Meta AI (Procope et al.)
- 4DALL-E 2 Preview - Risks and Limitations · OpenAI (GitHub)
- 5GPT-4 System Card · OpenAI
- 6OpenAI GPT-5 System Card · arXiv (OpenAI)
- 7Preparedness Framework, Version 2 · OpenAI
- 8Model system cards · Anthropic
- 9System Card: Claude Opus 4.5 · Anthropic
- 10System Card: Claude Opus 4.7 · Anthropic
- 11Anthropic's Responsible Scaling Policy · Anthropic
- 12Responsible Scaling Policy, Version 3.4 · Anthropic
- 13Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1) · National Institute of Standards and Technology
Where this shows up in our work
- CALIBER, the market testbed for AI agents measures from an AI agent's trades whether it is gullible, herds, overpays, or can be steered.
- ELLMENT, the offline LLM for E-2D crews answers a crew's question from the aircraft's own manuals and cites the page, with no network.
