Model Card
Maintain a versioned structured document covering intended use, known limitations, eval results, and risks — the single source of truth for every stakeholder asking "what does this agent actually do?"
Intent & Description
🎯 Intent
Maintain a structured document describing the model/agent’s intended use, limitations, evaluation results, and risks.
📋 Context
Legal teams reviewing deployment, compliance officers prepping for a regulator visit, customers reading documentation, and new engineers onboarding all need to understand what the agent actually does. Without a model card, that knowledge lives in Slack threads, tribal memory, and one engineer’s mental model.
💡 Solution
Maintain a markdown document at a known location with sections: intended use, out-of-scope use, training/data lineage, evaluation results, limitations, risks, and contact. Version it alongside the agent — card updates ship with agent changes.
Real-world Use Case
- Multiple stakeholders need a shared understanding of agent capabilities and limits.
- Intended use, out-of-scope use, and known risks are stable enough to document.
- Evaluation results exist or can be produced periodically.
Source
📌 TL;DR
Write the model card and version it alongside the agent — it’s the document that answers “what does this thing do?” for every stakeholder, from engineers to regulators.
Advantages
- Stakeholder alignment — everyone works from the same document.
- Regulatory and audit defensibility — you have a dated, versioned record of what you claimed the agent could do.
Disadvantages
- Maintenance burden — the card must be kept current to stay useful.
- Card drift when not enforced in PR reviews — it quietly becomes stale.