Model Cards and System Cards as Evidence

Model Cards and System Cards as Evidence

The model card began as a good idea: a short, standard document describing what a model is, what it was trained on, how it performs, and where it should not be used. A decade later it has been absorbed into the machinery of compliance, and in the process most of it has become a brochure.

The tell is easy to spot. Read a card and ask, of each claim: how would I check this? In the typical card, the answer to nearly every claim is "you would take our word for it." That document is not evidence. It is a description, and a description written by the party with an interest in the conclusion.

The distinction matters now because model and system cards are increasingly being submitted as evidence — to procurement, to internal risk committees, to regulators operating under regimes that require technical documentation of AI systems. A document that was written to inform is being asked to do the work of a document written to be audited, and it cannot.

Descriptive versus evidentiary

A descriptive claim tells the reader what is true. An evidentiary claim tells the reader what was done, by whom, to what, and how they could establish it independently.

Every row on the right is longer, more specific, and considerably more uncomfortable to write. That discomfort is the signal that the document has begun to carry information.

The six properties that make documentation auditable

There is a compact set of properties that separate a card an auditor can use from one they cannot. None require new science. All require a willingness to be pinned down.

1. It identifies the exact artefact. Not "our assistant" but a versioned system: model identifier and version, prompt version, retrieval corpus and its snapshot date, tool schemas, guardrail configuration, decoding parameters. A card that does not say which system it describes cannot be matched to any system you are running, and the moment the provider ships a new checkpoint behind the same name, the card silently becomes fiction.

2. Every quantitative claim names its population. A number without a denominator is a rhetorical device. What was the sample, how was it drawn, over what period, and does it resemble your traffic? A score on the vendor's evaluation set tells you about the vendor's evaluation set.

3. It reports uncertainty. A point estimate from a finite sample is a range pretending to be a fact. Documentation that reports 94% with no interval and no sample size is not merely incomplete; it is misleading in a direction that always favours the author.

4. It states who evaluated, and their independence. An evaluation performed by the team that built the system is not worthless, but it is a different kind of evidence than one performed by a party with no stake in the result, and the reader is entitled to know which they are holding.

5. It records negative results. The most credible thing a card can contain is a failure. A document that reports only strengths has either been filtered or the evaluation was not adversarial enough to find anything — and both explanations are bad. Findings, their severity, and their remediation status belong in the document.

6. It is dated, versioned, and superseded. Every claim has an expiry, because the system, its inputs, and the definition of correct all move. A card with no version history is a claim about a moment nobody can identify.

The gates are strict on purpose. A single "no" anywhere on the path drops the claim back to description, because a claim whose population is unstated cannot be rescued by being precisely versioned, and a claim with no underlying record cannot be rescued by anything.

Model card, system card, and the gap between them

The two documents are not interchangeable, and conflating them is how organisations end up documenting a component while deploying a system.

A model card describes a model in isolation: architecture family, training data characteristics, intended use, evaluation results, known limitations. If you buy a model from a provider, this is the document you receive — and it is the document that will not answer the question your regulator asks.

A system card describes what you built around it: the prompt, the retrieval layer, the tools the model can call and what they can do, the guardrails, the human oversight step, the escalation path, the logging, the fallback when the model is unavailable. These are all things the provider cannot document because the provider did not build them, and they are where a very large share of real-world harm originates.

The gap between the two is the part of your AI system that nobody has documented, and it is usually the part you actually control. If you have a model card from your vendor and nothing else, you have documentation of the one component you did not build and none of the components you did.

Documentation that points at something

The property that converts a card from assertion into evidence is traceability: each claim points at an underlying record that a third party could examine.

A statement that the system was evaluated on 1,200 sampled queries should be linked to the evaluation itself — the sample, the rubric version, the scores, the evaluators, the findings raised, the adjudications where evaluators disagreed. That underlying material is the evidence. The card is a summary of it, and a summary is only as trustworthy as the reader's ability to go and look.

This is what a structured evaluation produces as a matter of course. An Evidence Report is versioned, states what was assessed against which rubric and taxonomy configuration, identifies the credentialed Evaluators who performed the work and their calibration, reports findings with severity and root cause, and records the adjudications where judgements differed. The platform actions that produced it are captured in a tamper-evident, hash-chained audit log, so the sequence of events behind the document is itself reviewable rather than reconstructed from memory.

The point is not the artefact. The point is that a claim in a card should be a pointer, not a promise — and if there is nothing to point at, the claim should not be in the document.

The reader's test

If you are on the receiving end of a card — from a vendor, from an internal team, from anyone asking you to sign something — there is a short and brutally effective exercise.

Take the five claims in the document that would matter most if they were false. For each, write down what you would need in order to verify it, and ask for that. Not a restatement. The underlying material: the sample, the rubric, the scores, the identity and independence of the evaluators, the findings that were raised and what happened to them.

The response is the actual evaluation. A party that can produce those things has done the work. A party that responds with a longer version of the same prose has told you exactly what you needed to know.

What to do tomorrow

Open your most important AI system's documentation and mark every claim as descriptive or evidentiary using the five gates above. Count the ratio. Then pick the three descriptive claims whose falsehood would hurt most and either produce the underlying record or delete the claim.

Deleting it is a legitimate outcome, and a more defensible one than leaving a sentence in a compliance folder that nobody can back. The purpose of documentation is not to reassure the reader. It is to survive the reader who does not believe you.