What a system card is written to survive
A system card is a document a vendor publishes alongside a model to describe behaviour, risks and mitigations. Its useful property is not candour but exposure: it exists to be read closely by people who will hold it to its word. As of 2026-09-12.
| Part of the card | Why it survives review |
|---|---|
| A bulleted list of measures | Each item can be checked separately |
| A scope attached to a claim | An unscoped claim invites a counter-example |
| A stated limit | Admitting a boundary is cheaper than defending a gap |
| An absence of prices | Commercial detail belongs on a different page |
Inclusion rule. Features common to cards published alongside a released model. Order. In the order they usually appear in such a document.
1Exposure produces better sentences than goodwill does
Marketing copy is read once and forgiven. A card is read by reviewers, journalists and competitors, all of whom benefit from finding an overstatement. Writers anticipate that and hedge where they are unsure.
The hedges are the valuable part. A claim with a scope attached can be applied to a specific file; an unhedged claim usually cannot be applied to anything, because nobody can tell what it covers.
2A list is easier to hold to account than a paragraph
Three measures in three bullets can be quoted individually, and each one either describes something or does not. A paragraph blending them gives a reader an impression and no separable claims.
So a card's format carries information about its own reliability. A register can quote a bullet with confidence and has to paraphrase a paragraph, and paraphrase is where accuracy leaks away.
3What a card will not tell you
Prices, tiers and account behaviour are not its subject. Neither is what happens to a file after it leaves the vendor, because that depends on somebody else's pipeline.
A reader who needs those has to go to a plan page or test the route. Expecting one document to answer both kinds of question is the commonest way to end up quoting the wrong page for the wrong purpose.
4Cards go stale in a specific way
They describe a version. The document usually stays up while the product moves, and every sentence in it remains true about the version it described, which is not the same as remaining the whole picture.
That is the argument for recording a reading date next to a quotation rather than treating the card as current. An old card and a current card can be equally accurate and describe different software.
Background on mechanism and practice. Nothing here is attributed to a product, and nothing here is a reading of any instrument. The sourced material is on the generator table. Related: Reading an API reference, Reading a support article.