Model Card Writer

A model card is the contract between the team that built a model and the people who will use or be affected by it. It documents not just what the model does but what it must not be used for - and the cost of skipping it is a model quietly repurposed for a use case it was never validated on, discovered only after harm. This skill produces a card a consumer can act on, not a compliance checkbox.

Operating procedure

Write sections in the order below; intended use (Step 2) constrains everything else, and limitations (Step 5) cannot be written honestly until evaluation results (Step 4) are in front of you.

Step 1: Gather inputs

Collect before writing; label anything unverified as a guess and chase it before publishing.

1. Model name, version, and owning team or contact.
2. Architecture family in plain language (gradient boosted trees, transformer, logistic regression).
3. The evaluation report - if none exists, stop and produce one via model-evaluation-report first; a card without real numbers is fiction.
4. Training data sources, collection method, time range, and geographic/demographic scope.
5. Who consumes the model: internal team, other teams, external users, or the public. External sharing raises the honesty bar on every section.

Step 2: Model overview and intended use