What should a model or system card contain?

Document the thing that was evaluated

A model card describes a particular model or model family: version, task, architecture at an appropriate level, training and evaluation data, intended use, metrics, slices, limitations, and ethical or safety considerations. It travels with the model artifact or service.

A dataset record—often called a datasheet, data card, or similar name—describes why data was collected, what it contains and excludes, provenance and permission, collection and labelling, transformations, recommended uses, distribution, retention, and maintenance.

A system card expands the boundary to the deployed product: model, prompts, context construction, retrieval, tools, permissions, human workflow, interfaces, storage, infrastructure, monitors, and possible real-world effects. Two products using the same model need different system cards when their data, authority, users, and risks differ.

flowchart LR
  D[Dataset records] --> M[Model card]
  M --> S[System card]
  H[Harness, tools, policy, UI] --> S
  E[Evaluation manifests and reports] --> S
  O[Operations and incidents] --> S
  S --> R[Release and use decisions]

The title should identify an immutable version or release. If an API alias, retrieval index, policy, or prompt can move independently, list those revisions in the system manifest. A document named after a brand but detached from deployable versions cannot support rollback or comparison.

Begin with claims and exclusions

State who the intended users are, what decision or workflow the system supports, under which languages and operating conditions, and what the system may do with user data or external tools. Name excluded and unsupported uses. Avoid phrases such as “general purpose,” “safe,” or “human level” unless the document defines an observable scope and evidence.

For every important claim, link to:

• the case population, slices, environment, and time period;
• baseline and candidate system manifests;
• graders, thresholds, trial counts, exclusions, and uncertainty;
• outcome, trajectory, permission, latency, cost, and safety evidence as relevant;
• the owner who accepted the result and the decision it informed.

Report counts and conditions, not only selected percentages. Show important slice results and severe events. A model-level benchmark does not support a claim about an agent's tool use, and a sandbox test does not prove production authorization works.

Make limits operational

“May produce inaccurate answers” is too broad to guide anyone. Describe observed failure modes, affected conditions, severity, detection, and the expected fallback. For example: long retrieved documents can cause evidence in the middle to be underused; the application therefore limits candidate passages, shows citations, and routes unsupported high-impact answers to review.

Record dependencies and assumptions: data freshness, supported input types, context and output limits, tool availability, identity, network access, human response time, and the population represented by evaluation. Name what was not tested and why. Known unknowns are useful when they change deployment scope or monitoring.

Separate inherent model behaviour from system controls. A content filter, permission gate, schema validator, and human approval are not properties of the base model. Conversely, a prompt asking the model to be careful is not a durable access-control mitigation.

Connect release, operations, and change

The card should name deployment scope, staged rollout, monitoring signals, alert owners, incident and disclosure paths, rollback criteria, retention, and review cadence. Link aggregates back to reproducible evidence while protecting sensitive traces and evaluation data.

Maintain a change log for model, data, prompt, harness, tools, policies, graders, and relevant dependencies. Classify whether a change invalidates earlier evidence. A formatting-only documentation edit and a new tool permission do not deserve the same review.

Keep old cards available. A current page that silently replaces previous limits destroys the historical record needed to understand an incident. Corrections should identify what changed, when, and whether earlier decisions are affected.

Write for several readers

Engineers need versions, interfaces, failure modes, and tests. Product owners need intended use, outcomes, trade-offs, and owners. Security and privacy reviewers need data flow, authority, threats, and controls. Operators need telemetry, alerts, limits, and rollback. Affected users need plain-language capabilities, important limits, data use, recourse, and contact paths.

Use a short overview with links into structured evidence rather than one dense public-relations narrative. Protect exploit details, personal data, secrets, and proprietary evaluation items, but state the nature of redactions and who can inspect the restricted evidence. Transparency does not require publishing information that creates another vulnerability.

A card is evidence, not certification

A card is not a certification, warranty, terms-of-service substitute, security assessment, or one-time launch post. A long list of benchmark scores is not a system card, and a diagram of model architecture does not document product authority or real outcomes.

Documentation cannot compensate for missing tests or controls. Nor should it imply that all risk is knowable. Its value is traceability: a reader can see which version, claim, evidence, limit, decision, and owner belong together.

Audit the evidence record

Schema-check required sections, identifiers, owners, dates, evidence links, and source references. Verify every model, dataset, prompt, tool, policy, grader, and deployment revision resolves to an existing artifact. Detect stale or moving links and fail publication when a critical claim points to missing evidence.

Challenge the claims. Select each headline statement and ask whether the linked evaluation actually covers the population, system boundary, outcome, and current version. Recompute a sample of reported metrics from frozen trial records. Confirm denominators, exclusions, and severe failures were not lost in aggregation.

Run a change-impact exercise: replace the model alias, retrieval index, permission scope, grader, or prompt and verify that the review process flags the relevant claims. Rehearse an incident and confirm an operator can identify the deployed manifest, known limitation, control owner, rollback condition, and affected historical card.

Finally, usability-test the public layer with an engineer and a non-expert user. Each should be able to answer what the system is for, what it can affect, what evidence exists, where it is weak, what data it uses, and what to do when it fails—without mistaking the card for proof that failure is impossible.