A system card is the document a lab ships with a model to describe what it tested, what it found, and what it would rather you not use the model for. Typically: evaluation results across capability and safety categories, known failure modes, red-teaming summaries, deployment restrictions, and the mitigations applied before release.
It evolved from the narrower "model card," which described a single model's training data and intended use. A system card covers the deployed product — model plus safety layers plus tooling — because that combination is what users actually meet.
Why it matters at your desk. It is the only vendor document that routinely admits weaknesses, which makes it more useful than the launch post. Launch posts carry the benchmark wins; system cards carry the refusal rates, the categories where performance degrades, and the populations the model was not evaluated on. If you are assessing a model for regulated work, that section is the one to read first.
For procurement and compliance it is increasingly the evidentiary record. When a lab cancels or reworks a release on safety grounds, the reasoning usually surfaces here before anywhere else, and "we reviewed the published system card" is a defensible step in a diligence file.
What to watch for: system cards are written by the vendor, cover the configuration the vendor shipped, and are not independently audited. They tell you what the lab chose to measure and disclose — valuable, but not the same as a third-party assessment, and no substitute for testing the model on your own material.