System cards: what the document actually certifies.
A system card is a safety-testing record about one checkpoint, written by the party with the most to lose from it — and the question you brought to it, can this model do my job, is the one question it never answers. Read it for the elicitation methodology and the refusal boundary, because those are the two things that transfer; treat every capability number as a claim about a build you may not be the one being served.
Model card, system card, technical documentation — three different documents.
The vocabulary got muddled because the artefacts arrived a decade apart, and knowing which one you are holding tells you what it is allowed to omit.
- A model card is the 2019 research convention: intended use, training data provenance, evaluation results broken out by population, known limitations. It describes weights. Most open-weight releases still ship this shape, and for a model you host yourself it is nearly the whole story.
- A system card describes the deployed system: the model, plus the safety classifiers wrapped around it, plus the usage policy, plus the refusal training, plus whatever the serving stack does before and after the forward pass. It exists because frontier labs ship a product, not a checkpoint, and the safety properties are mostly not in the weights.
- Regulatory technical documentation is a third thing again. Article 53 of the EU AI Act obliges general-purpose model providers to maintain technical documentation and to give downstream providers enough to understand capabilities and limitations; the AI Office has had formal enforcement authority over general-purpose models since 2 August 2026. That file is written for a regulator with subpoena power. The system card is the public subset, and the two are not the same document.
The practical consequence: a system card's safety claims are claims about a configuration. Route the same weights through your own inference provider without the vendor's classifiers, and you have kept the capability numbers and discarded the mitigations the card was describing. That is a legitimate thing to do — see open vs closed models — but you now own the half the card was actually about.
The three questions it structurally cannot answer.
These are not omissions a better card would fix. They follow from what the document is.
- Whether the model is good at your task. The evals are public benchmarks, chosen partly for comparability with the previous release, and public benchmarks are the ones most exposed to contamination. A card reporting a strong agentic-coding score is telling you about a distribution; your distribution is not in it. This is the same argument as reading benchmarks critically, with one aggravating factor — the author is also the vendor.
- What you are being served. The card is frozen at launch; the endpoint is not. Aliases move to new snapshots, safety classifiers are updated continuously, quantised and speculative-decoding variants get rolled out for capacity, and a router may hand your request to a different tier under load. None of that produces a new system card, and none of it is visible in your response.
- How hard they tried. Every dangerous-capability number is a function of elicitation effort — scaffolding, tool access, sample count, how a refusal was scored. A "the model could not complete the task" result obtained with a bare chat interface and one attempt is a different claim from the same result obtained with an agent harness and a hundred. The number without the method is uninterpretable, which is why the method is the part worth reading.
Read it for these four things instead.
There is real signal in a good card. It is mostly not in the tables.
- The elicitation description. Did they give the model tools? A scaffold? How many attempts, and was best-of-n or pass@1 reported? This tells you how much headroom sits between the published number and what a determined user gets, and it is the closest thing to a capability forecast the document contains. It also tells you how seriously to take the safety result, because a weak elicitation produces a reassuring number for free.
- The refusal and gating boundary. Which categories are refused outright, which are gated behind an enterprise agreement or a verified account, and which were tightened relative to the last release. This is the part that will break your product, and it changes more often than capability does. See refusals & capability gating.
- The safeguard inventory. Classifiers, monitoring, rate limits on specific capabilities, account-level enforcement. Each of these is a control the vendor operates on your behalf and can change without notice — and each is a control you inherit or lose depending on how you access the model.
- The capability-threshold declarations. Frontier labs now publish tiered frameworks that commit them to specific mitigations when a model crosses a defined capability level. When a card says a model was deployed under a higher tier than its predecessor, that is a forward-looking statement about the access controls, latency and audit obligations coming to that family — and often the earliest public signal that a migration is on your calendar.
Read consecutive cards from the same lab as a diff, not as standalone documents. The interesting content is what moved: an eval quietly retired, a threshold restated, a refusal category added, a mitigation described in the previous card and absent from this one. A single card tells you what the vendor wants to say; two cards tell you what changed.
What to do with it once you have read it.
The card is an input to two processes and a substitute for neither.
- Keep your own acceptance eval, and run it per snapshot. Twenty to a hundred cases from your real traffic, scored the way you actually care, pinned to an explicit model version rather than an alias. This is the only instrument that measures the thing the card cannot, and it is the one that catches a silent serving change. Evals are the whole answer here; the card just tells you where to point them.
- Pin the version, then diff the card on every release. Aliases are convenient and they are the mechanism by which a model you never evaluated reaches production. Pin, upgrade deliberately, and make the card diff a step in that upgrade.
- File it into vendor risk with an owner. The card is evidence for the due-diligence record a deployer has to produce anyway — see third-party model & vendor risk. Store the PDF, not the URL: cards get edited in place.
- Do not cite it as a safety argument for your system. The vendor tested a model against generic misuse. You are shipping that model with your tools, your data and your users' authority, and none of those were in scope. Your threat model is yours.
If you read one section, read the elicitation methodology, and read it before the results table. Everything downstream — how much capability headroom exists, whether the safety result means anything, whether the comparison to the previous model is like-for-like — is decided by how the evals were run, and that is the one part of the document nobody's launch-day summary quotes.
Related: choosing a model for the decision the card feeds into, the agent harness for why elicitation effort dominates published scores, and knowledge cutoffs for the other launch-day number that ages badly.