A model card and a specification table are not the same

Start here

'Model card' gets used loosely, but the documents vendors actually publish come in at least two shapes, and a non-expert reader benefits from knowing which one is open before drawing conclusions from it. A specification table lists what a model can technically do: context length, cost, cutoff date. A system card is a longer safety document describing what was tested, by whom, and what went wrong during testing. Confusing the two means missing what a page does not cover.

What the documents say

Anthropic's models overview page is the first shape: a comparison table naming, for each current model, a 'reliable knowledge cutoff,' a separate broader training data cutoff, a context window size, and a retirement date after which the model stops being served. It says nothing about how a model was tested for safety. OpenAI's GPT-4o system card is the second shape: a document with named sections including Model data & training, External Red Teaming, Preparedness framework evaluations and Third party assessments, stating that the company worked with 'more than 100 external red teamers,' across '45 different languages' and '29 different countries,' to probe the model before release. Google's Gemini API models page sits closer to the first shape, naming each model with a short description and an identifier, leaving fuller technical fields to each model's own page. None of the three claims to be the complete picture; each covers what its own format is built to cover.

Check this

This is an editorial guide built from the three pages above. Before trusting a claim about a model, check which document made it. A cutoff date or context size can be verified against a specification table like Anthropic's. A claim about behavior under adversarial testing needs a system card like OpenAI's, not a spec sheet. If only a spec table exists for a model, treat safety-testing claims about it as unverified rather than assumed, since the table itself makes none.

What holds and what fails

This distinction holds whenever a vendor actually publishes both document types, which is not universal or guaranteed to continue. It fails if a reader treats a marketing page, which describes neither testing nor specifications rigorously, as either kind of document. This is an editorial reading of the three pages above, retrieved 16 September 2026; retirement dates, cutoffs and testing summaries change as vendors update their own documentation.

• Find the specification table for a model before quoting its context size or cutoff date.
• Look for a system card, not a spec table, before repeating a safety claim.
• Note the retrieval date on any of these pages, since the fields in them change.

A non-expert does not need to evaluate the science in a system card to benefit from knowing it exists and what it covers that a spec table does not.