The AI Project Documentation Checklist: Docs That Survive Handoffs

Documentation advice for AI projects tends to come in two useless flavors: 'document everything' (nobody does, so nothing gets documented) and 'the code is the documentation' (true right up until the person who wrote the code rolls off the project). The workable answer is a small fixed set. Six documents cover roughly 90% of what an AI project needs to survive contact with reality — a team member leaving, a vendor changing, an auditor asking, a model degrading at 2am. Each exists because of a specific, expensive failure mode, and each has a natural owner and a lightweight-but-real minimum version. Skip one and you don't save the work; you defer it to the moment it's most expensive, which is usually a handoff.

The six documents, who owns each, and what breaks without them

The set is deliberately small — small enough that 'is our documentation done' is a checkable question. The third column is the important one: each doc earns its place by a specific failure it prevents, and if you've run an AI project before, you've likely met at least half of these failures personally.

Lightweight but real: the minimum version of each

The reason documentation dies is that teams aim at the maximal version, produce it once under duress, and never update it. The minimum versions below are honest floors: small enough to maintain, complete enough to be load-bearing. Format matters less than location — all six live where the team already works, findable in one hop, not in a personal drive.

• Project brief: the problem, the metric, the users, the scope boundary — essentially the outline session's output kept current. If it exceeds two pages it's absorbing the scoping doc's job.
• Scoping doc: the nine-section anatomy (problem, users, metrics, data, constraints, risks, phasing, team, budget) with a changelog on top. This is the doc the others hang off.
• Data inventory: one table — source, location, owner, access path, measured completeness, known quirks, refresh cadence. One row per source; ten rows beat ten pages.
• Decision log: one line per decision — date, decision, why, who. 'Chose managed API over self-hosting: volume too low to amortize infra; revisit at 500k requests/month. — MR, 3 Feb.' Fifteen of these lines are worth more than any architecture deck.
• Model/eval card: what's deployed (model, version, key config), what it was evaluated on (the frozen test set, by name), the scores including the counter-metrics, known failure modes, and what it must not be used for. One page per deployed model.
• Runbook: how to tell it's broken (the dashboards, the thresholds), the three most likely failures and their fixes, how to roll back, how to retrain or refresh, and who to call. Written for the person who didn't build it — that's the whole point.

When documentation is waste, and when it's load-bearing

The six-doc set works only if you also refuse to write the other stuff. Documentation is waste when it duplicates a source of truth that already exists: prose restating what the code does (drifts within weeks), status reports that repeat the ticket board, exhaustive API docs for internal interfaces one team consumes, meeting minutes nobody assigned actions from. Documentation is load-bearing when it holds information that exists nowhere else and is expensive to reconstruct: why a decision was made (not recoverable from code), what the data actually looks like (recoverable only by re-doing the analysis), what the model was tested on (unrecoverable if the eval set wasn't frozen and named), what to do at 2am (reconstructed, expensively, during the incident itself). A simple test for any proposed document: if we deleted this in six months, would anyone need to recreate it, or would they just not notice? The six survive that test; most other project documentation doesn't. And one anti-pattern deserves naming: documentation written to prove work happened rather than to transfer knowledge. If a doc's primary reader is a steering committee rather than a future team member, it's reporting, not documentation — fine, but it doesn't count toward the six.

Docs as the knowledge-retention answer for external and augmented teams

The strongest argument against bringing in external AI engineers has always been knowledge walk-out: the engagement ends, the people leave, and the understanding leaves with them. The six-document set is the concrete answer to that objection — not 'good documentation' as a vague aspiration, but a named, checkable artifact list that makes the knowledge transfer inspectable before the last week of the engagement. This is how Aiporate frames its own delivery model: the intake process produces the brief and the scoping document before the team starts, and the engagement isn't complete until the data inventory, decision log, model card and runbook are current and have been walked through with the client's own people. Whether you work with us or anyone else, the checklist below is worth writing into the engagement terms — it converts 'we'll document as we go' from a promise into an acceptance criterion.

• Write the six-doc set into the statement of work as a deliverable, with the runbook walkthrough as an explicit acceptance step.
• Insist the decision log is kept from week one — it cannot be reconstructed retroactively, and a log started in the final month is fiction.
• Have an internal person co-own the data inventory and runbook during the engagement, not receive them at the end; handover of a living document beats handover of a finished one.
• Run the 'bus test' before sign-off: an internal engineer who didn't build the system uses only the runbook to execute a rollback and a retrain in staging. If they can't, the documentation isn't done, whatever it weighs.
• Schedule one post-handoff review 4-6 weeks out: the questions that surface in real operation are the gaps in the doc set, and they're cheap to fix while context is fresh.

When each document gets written

The set has a natural order that matches the project's lifecycle, which is why it never has to be a documentation sprint. The brief comes out of the initial outline session. The scoping doc follows discovery. The data inventory starts as the scoping doc's data section and graduates to its own artifact once engineering starts touching sources. The decision log opens in week one and accumulates. The model/eval card is born the first time a model is evaluated seriously, and the runbook is written just before the first production deployment — then edited by every incident afterward. At any point in the project, exactly the documents that should exist, exist. That's the difference between documentation as a phase (which gets cut) and documentation as a byproduct of decisions being made (which doesn't).

1. 1Outline session → project brief.
2. 2Discovery (the 30-day window) → scoping document.
3. 3Engineering start → data inventory graduates from the scoping doc; decision log opens.
4. 4First serious evaluation → model/eval card.
5. 5First production deployment → runbook.
6. 6Every incident, retrain and scope change → the relevant doc gets its one-line update.