The NIST documentation draft requires one field. Ask for the profile.

The row sits near the bottom of almost every AI supplier questionnaire now, and it is usually the last one anybody argues about. Model documentation provided, conformant to a recognised standard. The supplier ticks it. The evaluator marks the response complete. Nobody opens the artifact, because the purpose of the row was to establish that an artifact exists.

That row is about to acquire a standard it can point at. NIST released the initial public draft of Guidance and Templates for Public-Facing AI Documentation in July 2026, and it is the closest thing the field has had to an agreed shape for a dataset card and a model card. It is also built in a way that makes the questionnaire row weaker rather than stronger, and the reason is worth understanding before anyone writes it into a contract.

The claim is this. In the base templates, one field is required for a dataset and one for a model. Everything a buyer would actually read — how the data was assembled, what the model was trained on, what it scored and on what — is optional at that level. The informative floor does not live in the standard. It lives in a profile, and a profile is a document that any interested party may write, which includes the party doing the buying.

What a claim of conformity actually asserts

The draft sets out two base templates. The dataset template has seven root fields and the model template has eight. In each, the only required field is Identifying Descriptors, which exists so a reader can tell whether the artifact describes the thing in front of them. Composition and Provenance is recommended for a dataset and Governance is recommended for a model. Training and Evaluation, on the model side, are optional.

Two rules in the same clause do bite. If a field appears, it must hold information matching that field and nothing else. If the artifact contains information matching a field’s description, that field must be present and must hold it. Those rules stop a provider scattering the training-data account through a product page and leaving the Training field absent. They govern where information sits inside an artifact. They do not require the information to exist.

Conformity to the base template is a claim about structure. It is not a claim about substance, and it was not designed to be one.

The substance is carried by the profile mechanism. A profile adapts the templates to a context — a sector, a risk tier, a jurisdiction — and it may only elevate. It can move a root field from optional to recommended or required, add subfields, add root fields, and add guidance. It cannot relax anything the base template sets. And when an attestation of conformity is made, the draft requires it to name either the base templates or one specific profile.

1. Layer 01 Base templates Seven dataset root fields, eight model root fields. One required in each.
2. Layer 02 The profile mechanism May elevate a designation, add fields and add guidance. May never relax one.
3. Layer 03 The chosen profile NIST's default, a sector profile, or one the buying organisation writes.
4. Layer 04 The attestation Names the base templates or one named profile. It asserts nothing wider.

NIST supplies default profiles in Annex A, and they are more demanding than the templates. For datasets, Composition and Provenance is elevated to required. For models, Design, Training, Evaluation, and Maintenance and Monitoring all move up from optional, and all four stop at recommended. That distinction is the one to hold on to. The draft states plainly that where a recommended field is missing or empty, an attestation of conformity to the profile remains valid. Under NIST’s own default model profile, an artifact carrying no evaluation results at all is still conformant.

Below those fields, the pattern repeats where an assurance reader would most want it not to. Lineage — which prior model this one was fine-tuned or distilled from — is optional. Third-party evaluation is optional. Quantitative and qualitative performance analyses are optional. Risk and impact analyses are recommended only where negative impacts have already been publicly documented and traced to this model or one like it.

There is a scope boundary underneath all of this that matters more than any designation. The draft documents datasets and models. A model, in its definition, is the architecture and the parameters. Components shipped or served alongside it, such as guardrail classifiers acting on output, are outside the scope, and entire AI systems are excluded altogether — NIST records that documentation practice at the system level is less mature and has been left to future work. The artifact therefore describes an object sitting one or two layers below the thing an enterprise actually procures.

What to do about it

Name the profile in the requirement. “Documentation conformant to the default AI model profile in Annex A of NIST AI 300-1” is a sentence somebody can check. “Documentation conformant to a recognised standard” is a sentence that has already been satisfied by the artifact you did not read.

Read the designations, not the field names. A profile table is reassuring to skim, because it is long and the field names are the right field names. The designation beside each one is the part that determines what arrives, and it is the part a skim reader passes over.

Write a profile where the default is not enough. This is not a workaround — it is the mechanism working as designed, it can only add obligations, and it is a short document. An organisation that needs evaluation results, the lineage of a fine-tuned model, and any third-party testing has three fields to elevate and one requirement to reword. Doing that once produces something reusable across every supplier assessment, and it converts a preference into a condition a supplier either meets or declines to meet.

Ask separately for the system. Retrieval, tool access, orchestration, output filtering and the human review step are where enterprise behaviour is actually determined, and none of them is in scope here. A model documentation artifact answering every question in the default profile still leaves those unanswered, and treating the artifact as coverage of the deployed system is the error this scope boundary invites.

Ask who attests to the documentation version identifier. Both default profiles make that field required, separately from the version of the model or dataset itself. It is the field that lets an assessor establish, a year later, whether the artifact reviewed at selection described the model now running. Worth noticing while reading, and worth raising if you agree it is wrong: in the default profiles a dataset version identifier is required once the dataset can be reached from outside the provider, while the equivalent model field under the same condition is only recommended.

What this does not tell you

This is an initial public draft of a voluntary document, and it is not regulation. NIST states directly that its use of “shall” and “requirement” carries no regulatory intent and directs nothing — the words indicate only what a voluntary adopter must uphold for a conformity claim to hold. NIST also does not expect to maintain the document beyond this stage. It is intended for INCITS/AI and then for ISO/IEC JTC 1/SC 42, where NIST has said it will be one voice among many. Designations quoted here can change, and some of them probably will.

Nothing in the draft creates readiness under the EU AI Act or alignment with ISO/IEC 42001. Mapping a documentation field to an obligation under either is separate work, and the legal interpretation stays with your counsel. Nor have we assessed any supplier’s published documentation against these templates. The argument here is about the structure of the draft, which anyone can check against the text.

The window is three weeks

NIST will consider input received by 16 September 2026, and the draft asks explicitly for views on whether the designations in the default profiles are right. That request is addressed to whoever will spend the next several years reading these artifacts: the assurance lead who has to conclude something from one, the architect signing off a supplier selection on the strength of one. If evaluation evidence should not be a recommendation, three weeks is the period in which saying so is cheap.

After that the designations become a committee’s business, on a timetable nobody in a procurement function controls. What remains controllable is the profile on your own side of the table — and that one has never needed anybody’s permission.