The Model Card Nobody Read
Model cards get written for compliance and ignored in production. Here's what they should actually contain — and why your on-call team needs them.
Your team shipped a model card. It’s thorough. It covers intended use, training data, evaluation results, and known limitations. It lives in a README nobody opens. When something breaks at 11 PM, nobody reads it.
That’s not a documentation problem. It’s a design problem.
The Compliance Trap
Model cards were designed as transparency artifacts — a way to communicate what a model does, how it was built, and where it shouldn’t be used. That’s valuable. But in practice, they get written once during deployment, reviewed by whoever approves the ticket, and filed away.
The people who need them most — the engineers debugging production failures, the stakeholders asking why the model is behaving differently this week, the new team member trying to understand what they inherited — never read them because they’re not written for those people.
They’re written to satisfy a process. So that’s all they do.
What a Useful Model Card Actually Looks Like
A model card that earns its place in your runbook answers operational questions, not just conceptual ones.
What inputs does this model expect, and what breaks it? Not “structured text” — the actual format, tokenization limits, preprocessing assumptions, and known failure modes for edge-case inputs. If your model degrades badly on inputs longer than 512 tokens, say that explicitly.
What are the known performance cliffs? Every model has distributional boundaries where quality drops sharply. Document them. Out-of-vocabulary terms, specific domains, data from before the training cutoff. If you’ve seen it fail in a particular way, that belongs here.
What does healthy inference look like? Latency range, confidence score distribution, output length expectations. If your monitoring doesn’t have a baseline to compare against, your alerts are just noise.
When was this model last validated, and against what? Not trained — validated. If your eval dataset is from 18 months ago and the world has changed, your model card should say so.
What’s the rollback plan? Which previous version is known-good, where it’s stored, and how long a rollback takes. This is the one section most model cards omit entirely.
Make It Findable
A useful model card lives in your incident runbook, not a repo README. Link it from your monitoring dashboards. Include the critical sections in your deployment checklist. If your on-call engineer can’t get to it in two minutes at midnight, it doesn’t exist when it matters.
Write the model card for the person debugging the 11 PM alert. They don’t have time for background context and training methodology. They need to know what the model expects, how it fails, and what to do about it.
If your model card can’t answer that, it’s documentation theater. Useful until audited, useless when needed.
Rewrite it for the person who’s about to have a bad night.