Model Card

A model card is documentation designed to communicate how a machine-learning model was developed, evaluated, and intended to be used. The concept encourages reporting beyond a single performance score.

A useful model card may describe model purpose, training context, evaluation datasets, subgroup performance, limitations, ethical considerations, and conditions under which the model should not be used. The exact format varies by organization and model type.

Model cards support transparency and responsible deployment by making important assumptions and limitations visible to users and integrators. They complement broader artifacts such as System Card and dataset documentation.

See also System Card, Datasheets for Datasets, and Safety Evaluation.

Assume fictional model DOC-QA-1.2 is intended to answer questions grounded in public AI product documentation. Record model/tokenizer versions, collection and evaluation dates, input/output forms, languages, evaluation sets, instructions and scoring procedures. A model name does not promise performance on unsupported sources or successful external tool tasks. Keep undisclosed fields explicitly unknown.

This is an ORBiS Tree teaching template, not a mandatory universal form. The original Model Cards study ↗ proposes reporting intended uses, performance conditions and limitations together.^[1] Inspect actual use conditions and evidence rather than relying on the document title or model size.

These results are fictional. If 94 of 100 English questions and 28 of 40 Korean questions are correct, aggregate accuracy is 122 / 140, approximately 87.1%. Korean accuracy is separately 28 / 40 = 70%. Reporting only the aggregate hides the language mixture and the weaker slice. Retain per-language denominators and accuracy.

Choose task-relevant slices such as language, document length, product identifiers and negation, explaining overlapping membership. Language slices here are not equivalent to measuring demographic groups of people. Connect multi-dimensional metrics and aggregation rules so readers can distinguish scores with different formulas or data composition.

Link dataset purpose, composition, collection and transformations through dataset documentation, and describe how each dataset was used by the model. The Datasheets study ↗ proposes communicating that context between dataset producers and consumers.^[2] Unavailable details of private training data remain unknown, not evidence that no issue exists.

Record data versions, the scope of overlap investigations and material used to choose settings before final evaluation. Include where use conditions and known limits can be checked. Having a card does not substitute for independent validation, all usage permissions or safety certification.

An unchanged model can behave differently after changes to retrieval, instructions, tool authority or output filters. Preserve model-level findings in the model card and link the version and tests of the complete service. Standalone question-answering accuracy does not measure publication or saving success.

Record dates, changed components, retested data and remaining limitations. Do not transfer an old result into a claim for a new release. Task-specific safety coverage and untested areas should both remain visible for the card to support decisions.