Specify the documentation profile before assessing conformity
A documentation standard helps buyers only when its scope and required evidence match the decision. NIST’s July 2026 draft separates base templates from profiles that buyers can make more demanding.
Keep development and test groups separate before comparing performance. No measured results are shown.
A procurement questionnaire can confirm that model documentation exists without establishing whether it answers the buyer’s questions. The useful test is whether the document identifies the deployed version, provides the evidence needed for selection and states what remains outside its scope.
NIST’s July 2026 initial public draft of Guidance and Templates for Public-Facing AI Documentation proposes templates for datasets and models. It also defines profiles that adapt those templates to a particular context. A requirement should identify which template or profile applies rather than treat conformity as a general assurance of quality.
The base templates require an identifying field for each dataset or model. Other information can be recommended or optional. A buyer who needs evaluation results, training information or provenance should therefore specify the relevant profile and its designations. The existence of a field does not mean a supplier must populate it.
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 artefact 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 artefact 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 artefact. 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.
- Layer 01 Base templates Seven dataset root fields, eight model root fields. One required in each.
- Layer 02 The profile mechanism May elevate a designation, add fields and add guidance. May never relax one.
- Layer 03 The chosen profile NIST's default, a sector profile, or one the buying organisation writes.
- 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 artefact 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 artefact therefore describes an object sitting one or two layers below the thing an enterprise actually procures.
What to do about it
Name the profile and its version in the requirement. Then check that its mandatory fields cover the selection decision. Referring to the default model profile in Annex A is more precise than asking for conformity to an unspecified recognised standard, but the default profile may still leave important evidence optional.
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.
Where the default is insufficient, use the profile mechanism to elevate the relevant fields. An organisation may require evaluation results, model lineage and independent testing for a particular use. Record why each requirement matters and what constitutes an adequate response. A reusable profile can then support consistent supplier assessment without implying that every purchase needs identical evidence.
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 artefact answering every question in the default profile still leaves those unanswered, and treating the artefact 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 artefact 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.
Keep the requirement current
The published input deadline was 16 September 2026. That date has passed. The initial draft remains the version discussed here, and buyers should check for revisions before incorporating its designations into a contract.
The practical decision remains within the buyer’s control: specify the documentation needed for the intended use, distinguish model evidence from system evidence and review the response. A conformity statement is useful when its scope is clear and its contents support that decision.