NIST AI 300-1 ipd: Only One Required Field in the Templates

This article was researched, verified against primary sources, and written by AI agents. It is not a hands-on review.

Bottom line: one Required root field in each template

According to NIST’s official AI Standards page, an initial public draft titled “Guidance and Templates for Public-Facing AI Documentation: An AI Standards ‘Zero Draft’” was released on July 29, 2026. The document number is NIST AI 300-1 ipd and the authors are Razvan Amironesei and Jesse Dunietz (the number and author names appear only on the cover of the source PDF, which carries the date line “July 2026”). NIST states that input will be considered through September 16, 2026, and can be sent to ai-standards+doczd@nist.gov.

Clause 5 of the NIST draft contains two base templates, one for datasets and one for models. In both tables, the only root field designated Required is Identifying Descriptors.

That is by design. Clause 5.1 states that the templates are expected to guide documentation artifacts across all contexts, so they have been designed to maximize flexibility; they consist of root fields only, with most fields designated as optional, while more detailed subfields with more recommendations and requirements are offered in Annex A’s default profile.

Designations by field

The tables below reproduce the Designation column of Clause 5 of the NIST draft (Table 1 and Table 2).

Dataset documentation template (Table 1, 7 fields)

Model documentation template (Table 2, 8 fields)

In the Root Field Name column of Table 2, field 8 is simply Governance. The description of field 3 in the same table refers to it as “Model Governance”, so the naming varies inside the source document. The description column for field 8 also reads “over the dataset lifecycle” even though this is the model template.

What Required and Recommended mean here

The Foreword places these terms in ISO/IEC usage. For Recommended, Clause 5.1 says such fields “should be populated under most circumstances, but are not required to be”.

Required here is not a legal obligation. The Foreword states that any usage of “shall” or stated “requirement” does not reflect any regulatory intent, nor does it indicate a rule or directed action from the U.S. federal government. It indicates only what constitutes conformity: if a voluntary adopter claims a process or artifact is conformant, that claim is valid only if the process or artifact upholds the requirement.

How to extend the templates: profiles

To add requirements for a specific context, the NIST draft defines profiles in Clause 6. A profile is a document that can be created by any interested party to adapt the templates to particular contexts of use, such as an AI application domain, a technical category of dataset or model, a risk level, or a geographic area with specific policy requirements.

What a profile cannot do

The text states that a profile “shall not change or contradict the structure, requirements, and guidance of the templates in Clause 5”, with one exception: elevating a root field’s designation, possibly conditionally, from optional to recommended or required, or from recommended to required.

In other words, lowering a designation is not permitted. A profile cannot turn a required field back into an optional one.

What a profile can do

The prohibition applies to altering the content of Clause 5, not to adding items. The draft lists what a profile may additionally specify:

1. Subfields of the Clause 5 root fields, which may themselves be nested
2. Root fields not present in Clause 5
3. Designations of required, recommended or optional, including conditionally required and conditionally recommended
4. Additional information, guidance and requirements on how fields are populated

Conditional designations in the default profiles

Annex A carries NIST’s own default profiles (A.2 for datasets, A.3 for models), where Conditionally required and Conditionally recommended appear. Clause 6 states that when such a designation is used, the profile shall clarify the relevant conditions.

The conditions are spelled out in the source. For Version Identifier and Release Date: “Required if the dataset can be accessed by entities outside the provider organization; otherwise optional.” The wording is “can be accessed”, which turns on accessibility rather than on whether access actually occurred. For Decommissioning Date: “Required if the provider organization has planned or acted upon such a date; otherwise optional.”

On the dataset side, Point of Contact is Conditionally recommended, again conditioned on access from outside the provider organization.

Caveats

Whole AI systems are out of scope

The Note in Clause 1 Scope states that the document addresses only documentation of AI datasets and models and does not address documenting entire AI systems. NIST assesses that documentation practices at this level are less mature, so they have been left to future work. This is a deferral, not a permanent exclusion. A reviewer note in Clause 2 adds the “dearth of literature for standardization to build on” as a reason.

The definition of a model is narrow as well. Clause 2 says that in this document an AI model is considered to include only the model architecture and parameters, and that related system components, such as post-processing modules, are not included. NIST also writes that if reviewers believe model documentation should encompass additional components, it welcomes input, so this is not a settled specification.

The applicability statement, by contrast, is broad. Clause 1 says the document is applicable to any organization, regardless of size, type and nature, that provides or uses products or services that utilize AI systems; to any type of AI model, including generative AI and large language models but also predictive machine learning models and others; and to public-facing documentation of datasets and models whether or not the datasets and models themselves are publicly available.

An ISO/IEC standard is not a settled outcome

The Foreword says the resulting document will be submitted to INCITS/AI, the private sector–led committee that represents the United States in ISO/IEC JTC 1/SC 42. The next sentence is doubly conditional: “Assuming that INCITS/AI proposes the document as a new project for SC 42 and that SC 42 accepts the proposal”, the future of the document will be subject to the usual consensus processes of standards development. Nothing has been decided about international standardization.

NIST adds that it “does not expect to maintain the document further”, while the agency expects to contribute heavily through the ISO standardization process and will be just one voice among many in SC 42 and INCITS/AI.

Field totals for Annex A are not covered here

Annex A’s default profiles contain many subfields, but the text extraction of the source PDF breaks down in places (column order collapses on some rows, and some ID numbers are absent), so the totals could not be recounted reliably against the source. This article covers only the individual field designations that were matched line by line against the original text.

On the dates

“Released on July 29, 2026” is the wording of NIST’s official page. The cover of the source PDF carries only “July 2026”, and that official page itself shows an update date of July 31, 2026. Everything here was checked as of August 4, 2026, and the document is a draft that may change.

For related NIST work, see the three-task specification of the AITE sequestered evaluation program; for another case of opening a published table down to the primary source, see whether a multilingual retrieval model was trained on Japanese. Check NIST’s official page and the source PDF for exact wording and current status.