Every developer learns the same documentation types. The README. The API reference. Code comments. Maybe an architecture doc if the team is disciplined. That was the whole vocabulary for decades.
Then AI arrived and quietly created an entire new category of documentation — one nobody taught us to write, that isn't in any bootcamp or CS degree, and that you're increasingly expected to produce anyway. Sometimes because a teammate needs it. Sometimes because an auditor does. And, as of 2026, sometimes because it's the law.
This is a field guide to that new landscape. I'll walk through the real doc types, grouped by what they document, with what each one is, when you need it, and why it exists. But first, the one idea that ties all of them together — because once you see it, every one of these makes sense.
For our entire careers, documentation described deterministic behavior. A function takes an input and returns the same output every time. You could document exactly what it does, because it does exactly one thing. The code itself was, in a sense, the ultimate documentation of what would happen.
AI shattered that assumption. A generative model can produce a different output for the same input twice in a row. An agent can take a path nobody wrote. You cannot document exact behavior for a system that doesn't behave the same way twice — so documentation had to shift from "what it does" to a different set of questions: What was it trained on? How did we measure it? What is it allowed to do? What did it actually do?
Every doc type below is an answer to one of those four questions. They aren't paperwork — they're trust artifacts. In a deterministic world, trust came for free from the code. In a probabilistic world, trust has to be manufactured through documentation, because it's the only way anyone — a teammate, an auditor, a regulator, a user — can believe your AI does what you claim. Keep that in mind and the whole landscape organizes itself.
These are the foundational ones — the docs that describe the ingredients of an AI system.
What it is: A short, structured document describing a single trained model — its intended use, the data it was trained on, its evaluation results, its limitations, and its out-of-scope uses. Think of it as a nutrition label for a model: at a glance, what's in it and what it's safe for.
When you need it: Any time you ship, publish, or hand off a model someone else will rely on. Introduced by Mitchell et al. in 2019, model cards are now standard on model hubs like Hugging Face — and under the EU AI Act, they (or an equivalent) are a regulatory requirement for high-risk systems. If you fine-tune a model and give it to another team, they need a model card to use it responsibly.
Why it exists: Because "here's a model, good luck" is how you get someone deploying a system into a context it was never meant for. The model card answers what is this model, really, and where should it not be used — the questions the weights themselves can't tell you.
What it is: The data-side twin of the model card. A structured document describing a dataset — where it came from, how it was collected, its composition, its known biases, consent and licensing, and what it should and shouldn't be used for. Introduced by Gebru et al. (2018/2021).
When you need it: Whenever a dataset outlives the person who made it — which is always. If your model's behavior is ever questioned, the first question is "what was it trained on?", and a datasheet is the answer you'll wish you'd written at the time.
Why it exists: Because most AI failures trace back to the data, and data provenance is almost never obvious after the fact. A datasheet forces the dataset's creators to be intentional and honest about its origins and limits — before those limits become someone's incident.
What it is: A step up from a model card. Where a model card documents one trained model, a system card documents the complete AI system — often a pipeline of multiple models, plus architecture, safety evaluations, operational constraints, and deployment context. Crucially, a system card documents how the system behaves, not how it's used (that's the difference from traditional product docs).
When you need it: When your AI isn't one model but a stack — a router, a fine-tune, retrieval, chained components (which, in 2026, is most real systems). Frontier labs publish system cards for their big models (the GPT system cards are the canonical examples) precisely because "the model" is really a system.
Why it exists: Because modern AI is rarely a single model, and documenting only the model misses everything that emerges from the combination. The system card is where a forward-deployment engineer figures out whether the whole thing fits their use case.
This is the newest and most underrated genre — and arguably the most important, because it's where trust is actually earned or faked.
What it is: Documentation of how you evaluated an AI system and what you found — the test set, the methodology, the assumptions behind the metrics, and how confident you should be in the results. "Eval factsheets" formalize this with the same rigor datasheets brought to data.