Documenting AI: Model Cards, Datasheets, Object Packs

This is Unit Eight of Generative AI at Work, on documenting AI. Unit Seven set the rules for letting tools in. This unit covers the documents that make AI understandable and auditable: model cards, proposed by Margaret Mitchell and colleagues; datasheets for datasets, proposed by Timnit Gebru and colleagues; and the M-CaReM-AI method's Object Packs. Carry one question through this unit: when someone hands you a model, a dataset or an AI-drafted specification, what should you ask before trusting it? The answer arrives with a pack seeded from one policy page. By the end you will be able to explain what a model card reports. To describe a datasheet's questions. To describe the method's Object Packs. To read a model card critically. And to seed, draft and update a pack with AI.

Six entries on why documentation matters, and on what a model card reports.

Why document at all.

GAI 176 Why Document

NIST's framework ties documentation to trust: transparency about a system enables accountability and redress, and documented systems are easier to audit and govern, as when an auditor traces a wrong decision back through a record of the model, data and settings that produced it. Documentation written after a problem is reconstruction, not documentation.

The model card.

GAI 177 The Model Card

A model card, proposed by Margaret Mitchell and colleagues in twenty nineteen, is a short document published with a model, reporting what it is for and how well it performs, for whom. Its standard sections let people choosing a model compare candidates on the same terms. A model card describes the model, not your use of it.

What a model is for.

GAI 178 Intended and Out-of-Scope Use

A model card's intended-use section names the primary uses and users the model was built for, and the uses it should not be put to, such as news articles in scope and medical records out of scope. Out-of-scope is the most useful line on the card; using a model there means you carry the risk alone.

Factors and metrics.

GAI 179 Factors and Metrics

A model card's factors section names the groups and conditions across which performance may vary, and its metrics section explains which measures were used and why, like a speech model reported separately for different accents and for noisy and quiet recordings. Mitchell and colleagues advise metrics that reflect real-world impact, not only those that flatter the model.

Evaluation data and results.

GAI 180 Evaluation Data and Analyses

A model card describes the evaluation data and reports results both for single groups and for combinations of groups, which Mitchell and colleagues call intersectional analysis: results for women, for older people, and for older women, where a gap neither alone shows can appear. Training data details may not be shareable; evaluation data matters more to you.

The card's closing sections.

GAI 181 Ethics, Caveats, Recommendations

A model card closes with ethical considerations, then caveats and recommendations: what the developers worry about and advise, such as a warning that the model was not tested on non-English text. Caveats are the developers' own warnings, so read them before the performance numbers, not after.

Three entries on documenting the data a model learns from or reads.

The datasheet.

GAI 182 The Datasheet

Timnit Gebru and colleagues proposed datasheets for datasets, a structured set of questions the creators of a dataset answer, inspired by the datasheets that accompany electronic components, such as one published with a dataset of customer reviews. A datasheet reflects what its creators knew and chose to say.

Why the data exists, and what it holds.

GAI 183 Motivation and Composition

A datasheet's opening questions cover motivation, why the dataset was created and by whom, and composition: what it contains, how it is labelled, and whether it holds sensitive information. A datasheet might admit that its reviews come from one country and one year. Composition answers tell you whose data is in it and whose is missing.

Collection, uses and upkeep.

GAI 184 Collection, Uses, Maintenance

Gebru and colleagues' remaining questions cover how the data was collected and cleaned, which uses suit it and which do not, how it is distributed, and who maintains it. A datasheet might name a task the data should not be used for, because its labels were not designed for it. An unmaintained dataset slowly stops matching the world it describes.

Four entries on the M-CaReM-AI method's Object Packs, and on documenting provenance limits.

The method's documentation unit.

GAI 185 The Object Pack

The M-CaReM-AI method documents each core business object in an Object Pack: a compact, living mini-specification of what it is, how it behaves, where it is used, and what is undecided, such as a few-page pack for an incident record, kept current. The method calls packs the right size for a prompt; that is its own claim.

Three levels of pack.

GAI 186 Bronze, Silver, Gold

The method defines three pack levels: Bronze for simple, low-risk objects; Silver, the default for most core objects; and Gold for anything audit-critical, legally sensitive, or central to money, safety or rights. A meeting-room booking gets Bronze; an eligibility decision gets Gold. The level follows the object's risk, not the time available.

Ownership and versions.

GAI 187 Owner and Version

In the method, every pack has a named steward, a version and date, and a short change log, and high-risk updates go through as small change requests, like version four noting which lifecycle state was added and who approved it. An unowned pack goes stale, and a stale pack misleads every prompt it grounds.

What provenance cannot show.

GAI 188 Documenting Provenance Limits

NIST's profile asks organizations to document the limits of their provenance tracking, not only the tracking itself, such as noting that watermarks are not applied to text outputs. Unstated limits invite false confidence, because readers assume a record covers what it does not.

Five procedures for reading and producing documentation.

Reading a model card critically.

GAI 189 Reading a Model Card Critically

A model card is the developer's claim, so read it against your use. Read the intended and out-of-scope uses first, and stop if you are out of scope. Read the caveats before any figure. Check whether the factors include your groups, languages and conditions. Compare the evaluation data with your real material. Note what the card does not report, and treat each gap as untested. NIST's warning about benchmarks applies: test on your own cases before relying on the numbers.

Questioning the data you rely on.

GAI 190 Asking the Datasheet Questions

When your work relies on a dataset, Gebru and colleagues' question groups make a checklist even without a datasheet. Motivation: who assembled it, and why? Composition: what is in it, how current, and is any of it personal? Collection: how did it get here, and what was changed? Uses: what is it suited for, and not? Maintenance: who keeps it current, and how will you know it changed? Questions nobody can answer are findings in themselves.

Seeding a Bronze pack.

GAI 191 Seeding a Bronze Pack

The method's Bronze level sets the minimum a pack needs. Write the header: the object's name, steward, version and date. State its purpose in one or two sentences. Write a short definition of one instance. List its fields, marked required or optional. Add a small index of what people and systems do with it, such as create, read, update and archive. Bronze is a floor; if the object touches money, safety or legal obligations, it needs Silver or Gold.

Drafting a pack with AI.

GAI 192 Drafting a Pack With AI

The method uses AI to draft packs from existing material, then puts a person in charge. Supply the pieces: name and description, fields, rules, lifecycle notes and policy passages. Supply the template, with the instruction not to invent unreferenced fields. Then review: remove invented fields, clarify wording, correct the lifecycle against how work really happens, and tighten links to real policy. The method notes AI is fast but occasionally careless, which is why review is half the procedure.

Updating a pack.

GAI 193 Updating a Pack With a Change Log

When an object changes, the method has AI update its pack from the old version plus a description of the change, with a change log. Give the current pack and the change. Ask for the updated pack and a change-log section. Check each logged change against its source. Check the rest of the pack for unlogged edits. Route high-risk updates through change requests. The method's phrase for the person is editor-in-chief: AI does much of the routine work, but the person remains the editor.

Two worked examples: a model card questioned, and a pack seeded from one policy page. The opening question is answered here.

A model card, questioned.

GAI 194 A Model Card, Questioned

A worked example, constructed for this course, follows a legal operations team reading a vendor's model card for a contract-summarizing tool. They read intended use first, then the caveats, which warn that performance falls on long and scanned documents, and many of theirs are long scans. The headline accuracy was measured on short agreements unlike theirs. Their own test on twenty contracts matches the caveats: long scans miss clauses, including two liability caps. The tool is approved for short contracts only. The headline figure was accurate and irrelevant; the caveats predicted the result.

A pack from one page.

GAI 195 A Bronze Pack From One Policy Page

A worked example, constructed for this course, seeds a Bronze pack for a library's equipment loans from a one-page policy, using the approved tool with the grounding line and the open-questions rule. The draft has a useful structure and two good questions, about renewals and waived fees, but it invents a deposit field and marks the required return date optional. The service manager fixes both, gets the questions answered, names herself steward and dates it version one. That answers this unit's question: before trusting any model, dataset or drafted specification, ask what it is for, what it leaves out, and who has checked and owns it.

Look at what you can now do. You can explain why documentation matters, and what a model card reports, from intended use to caveats. You can describe a datasheet's questions, from motivation to maintenance. You can describe the method's Object Packs, their Bronze, Silver and Gold levels, and why each has an owner and a version. You can read a model card critically and question the data you rely on. And you can seed, draft and update a pack with AI. Unit Nine puts the course together.