Documentation
Documentation turns scattered knowledge into reusable evidence. It helps builders, users, auditors, and affected people understand what an AI system is intended to do, how it was evaluated, where it is likely to fail, and what responsibilities surround it.
Common artifacts include model cards, system cards, data cards, evaluation reports, risk assessments, change logs, deployment notes, and user-facing notices. The right artifact depends on who needs to act on the information.
Build a Model Card
A resume-screening model needs a model card before launch. Toggle sections in and watch the card on the right fill in — or stay blank.
Card coverage
33%
Model Card — Resume Screener v2
Intended use
Rank job applicants for recruiter review; not a sole basis for rejection.
Out-of-scope use
Not documented
Evaluation design
Held-out resumes scored against recruiter-labeled outcomes, evaluated by job family.
Slice performance
Not documented
Known limitations
Not documented
Monitoring plan
Not documented
A strong model card names the intended use, out-of-scope use, training data summary, evaluation design, slice performance, limitations, monitoring plan, and contact or owner. It should be written so that a downstream team can decide whether the model fits their workflow.
Documentation also has a maintenance problem. A beautiful report from launch day becomes misleading if the model, data, thresholds, or product context change and the report does not.
Decision Making
Good documentation supports decisions: Can we use this model here? What should we monitor? When should we stop using it? Who owns the next review?
What is one limitation that belongs in a model card for a resume-screening model?