Module 5 · 7 min read

Documentation and the Approval Gate

Model cards, system cards and datasheets as distinct artefacts, and why the people who build a model cannot be the people who approve it.

An auditor asks for the artefact that documents the deployed end-to-end behaviour of your assistant: the guardrails around it, the tools it may and may not call, what happens when it escalates to a human, and the failure modes you already know about. Somebody hands over the model card. It is a good model card. It is also the wrong document, and this near-miss is common enough to be worth treating as a distinct skill: knowing which artefact answers which question.

Artefact	What it documents	What it does not tell you
Model card	The model in isolation: intended uses and explicitly out-of-scope uses, a summary of training data, evaluation results including performance by subgroup, known limitations and ethical considerations	Anything about the production wrapper: no guardrails, no tool restrictions, no escalation paths, no integration behaviour
Datasheet	A dataset: motivation for collection, composition, collection process, consent and lawful basis, preprocessing, known gaps and biases, maintenance and distribution terms	How any model trained on it behaves, and how a deployed system built from that model behaves
System card	The deployed system end to end: architecture and data flow, guardrails and filters, tool and integration restrictions, escalation and fallback paths, the human oversight arrangement, known failure modes and the mitigations applied	Fine-grained model internals and dataset provenance, which live in the other two artefacts

Hold that split as a working frame rather than as a description of the world. These are conventions, not standards, and vendors blur them constantly: published system cards routinely carry extensive model-level evaluation content, and plenty of model cards include deployment and safety guidance. The governing question is always what a given document actually covers, not what it is called, so read the contents before you accept the label.

Documentation only carries assurance weight if it is versioned and tied to what is actually running. An undated, unversioned card describes intent. A card that names the exact model version, the system prompt version, the guardrail configuration and the date of the evaluation results it cites can be checked against production, and that checkability is the whole point. The same discipline applies to vendor-supplied documentation: a supplier's model card for a version alias you no longer pin to is a document about a different system.

Which artefact answers this question?

Select a card to turn it over.

Check yourself

An auditor asks how the fine-tuning corpus behind your assistant was assembled, whether the people whose text it contains had any expectation it would be used this way, and what is known to be missing from it. Which artefact is the primary answer?

The approval gate and segregation of duties

Now the second half. A team builds and tunes a credit model. The same team runs its validation, signs off its release, and monitors it in production. The argument offered is that they know it best, and the argument is true. It is also the wrong argument, because the question is not who understands the model but whose interests conflict with challenging it. The build team is measured on shipping. Asking it to also be the function that finds reasons not to ship is a segregation of duties failure, and it is the same failure that made self-certified financial reporting untenable long before anyone trained a model.

Build is separated from validation: the validation function reproduces results, tests on data the builders did not choose, and probes for the failure modes the builders have an interest in not finding.
Validation is separated from approval: an independent validation opinion informs a release decision taken by an accountable owner or committee, so a negative finding cannot be quietly absorbed.
Production monitoring has an escalation route that does not run solely through the build team, so a degradation signal cannot be triaged away by the people whose work it reflects.
Access controls prevent the build team from altering evaluation results, approval records or monitoring history after the fact. Evidence integrity is part of segregation of duties.

Independent approval

Validation reproduces results, and tests on data the build team did not choose.
An accountable owner or committee takes the release decision on an independent validation opinion.
Production monitoring has an escalation route that does not run only through the build team.
Evaluation results, approval records and monitoring history cannot be edited by the builders.
Builders are consulted for expertise, and are not the signatories.

Marking your own work

The team that built and tuned the model runs its validation.
Sign-off sits with the manager who owns the delivery date.
Degradation signals are triaged by the people whose work they reflect.
Test sets and thresholds are chosen by whoever needs the result to pass.
The justification offered is that they know it best.

Independence should be proportionate to tier. A small firm cannot stand up a separate model validation department, and pretending otherwise produces an unfollowed policy. Workable alternatives include a reviewer from a different team who did not contribute to the model, a validation role held within a risk or audit function, or periodic external review for the highest tier. The principle that must survive at any size is narrow and non-negotiable: the person with the shipping incentive does not sign the release.