AI Regulation Tracker  /  Initial public draft

NIST Put Real Documentation Templates in a Draft AI Standard

NIST AI 300-1 ipd is an initial public draft, not a rule, and it creates no duty for anyone. It contains a dataset documentation template, a model documentation template, eight artifact qualities, a profiles mechanism and a named internal role. NIST says it will consider input received by September 16, 2026 for the next, possibly final, revision, and that the resulting document will go to INCITS/AI for proposal to ISO/IEC JTC 1/SC 42.

By Anthony Guerriero  ·  Reviewed by Anthony Guerriero  ·  Published August 3, 2026  ·  Updated August 3, 2026  ·  Initial public draft

Key facts

Regulatory briefing

Instrument

NIST AI 300-1 ipd, an initial public draft in the NIST AI 300 series

Authority

National Institute of Standards and Technology, U.S. Department of Commerce

Jurisdiction

United States, federal, with an intended route into international standardization

Status

Draft. Initial public draft open for input

Bindingness

Voluntary. The draft states that any usage of shall or stated requirement does not reflect any regulatory intent and indicates only what constitutes conformity

Effective date

None. Input considered if received by September 16, 2026

Primary source

NIST AI 300-1 ipd, nvlpubs.nist.gov

What NIST actually released

On July 29, 2026 NIST posted the initial public draft of a document with an awkward name and a practical payload: Guidance and Templates for Public-Facing AI Documentation: An AI Standards Zero Draft, numbered NIST AI 300-1 ipd. The Foreword says the Zero Drafts pilot was announced in March 2025, and that the topic here was chosen from community input: documentation of AI datasets and models for transparency between AI stakeholders. NIST's project page lists the other pilot topic as AI testing, evaluation, verification and validation, still at outline stage.

Be precise about what this is, because this is where readers of AI news get burned. It is a publication, not a rule. The invitation to comment is a Note to Reviewers printed inside the draft and it directs input to an email address, not to a rulemaking docket. It carries no compliance date, no penalty provision and no enforcing office. And it sits in the NIST AI 300 series, which is not the series that holds the AI Risk Management Framework: the AI RMF is NIST AI 100-1, and the Plan for Global Engagement on AI Standards is NIST AI 100-5. Different number, different job.

The Foreword explains the mechanism and the destination:

Based on community input, NIST selected two topics for the Zero Drafts pilot, one of which is documentation of AI datasets and models for transparency between AI stakeholders. This document is the initial public draft for the forthcoming zero draft on AI dataset and AI model documentation. NIST will publish a final and complete version of this document based on feedback received. 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.NIST AI 300-1 ipd, Foreword, July 2026

The second half of the Foreword is the part I would paste into any internal memo about this document. It states that the document is intended for voluntary use, as would be any voluntary consensus standard that derives from it, and 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. Rather, use of shall indicates only what constitutes conformity: if a voluntary adopter of the document claims a process or artifact is conformant, that claim is valid only if the process or artifact upholds the requirement.

That is a careful sentence and it is doing two things at once. It disclaims coercion, and it preserves the ability to test a claim. If you say your model card conforms to this document, the document gives a counterparty a basis to check the sentence. That is a materially different posture from a framework of principles, and it is why the draft adopts ISO/IEC drafting conventions, spelling out shall, should, may and can in the Foreword before it uses them.

One more thing to note before anyone circulates this as finished work. Clause 1 opens after an Introduction heading whose entire content reads that it is to be completed with the final draft. The document is deliberately unfinished, and the reviewer notes scattered through it ask open questions, including whether documentation artifact is even the right term. Read it as a working text soliciting help, which is what NIST says it is.

The scope is narrower than the headline suggests

Clause 1 is short and worth reading before anything else, because it sets both the reach and the boundary.

This document provides guidance on objectives for and approaches to documenting AI datasets and models with the intent of releasing the resulting documentation artifacts publicly. The document provides recommendations for documentation processes, as well as requirements for documentation artifacts in the form of templates against which conformity of documentation artifacts can be assessed.NIST AI 300-1 ipd, Clause 1, Scope, July 2026

Three things follow. First, the applicability is deliberately universal: the draft says it applies to any organization, regardless of size, type, and nature, that provides or uses products or services that utilize AI systems, and to any type of AI model, including generative AI and large language models but also predictive machine learning models and others. If you run a credit model or a claims triage model, you are inside the stated scope every bit as much as a frontier lab.

Second, and this is the sentence most summaries drop, Clause 1 says the document applies to public-facing documentation of datasets and models whether or not the datasets and models themselves are publicly available. A closed model with a published model card is in scope. The trigger is that you publish the documentation, not that you publish the weights.

Third, and more usefully for scoping your own work, the draft carves out the hardest case. A note in the Scope clause says the document addresses only documentation of AI datasets and models, does not address documenting entire AI systems, which may consist of large, complex arrangements of components that rely on or interact with a given dataset or model, and that NIST assesses documentation practices at that level to be less mature, so they have been left to future work. The terms clause reinforces it: an AI model is defined to include only the model architecture and parameters, and a reviewer note says post-processing modules such as guardrail classifiers are outside that boundary.

I read that as an honest admission rather than a gap. System-level documentation is where most enterprise pain actually lives, because the thing that hurts you in an audit is rarely the model weights and usually the retrieval layer, the prompt scaffolding, the human review step and the downstream decision. Nobody has a settled vocabulary for that yet, and NIST says as much rather than papering over it. The consequence for you is that this draft will not, on its own, produce a complete file on an AI-enabled business process. It will produce two good components of one.

Clause 3 is the part reviewers will skim and shouldn't. It sets out what NIST calls outcome dimensions, the variables that documentation choices move: organizational resource demands, internal collaboration, internal decision-making, release speed, reuse and integration, malicious use or attacks, accountability, privacy preservation, proprietary information protection, legal obligations and trust. The framing is that these are sliding scales rather than benefits and drawbacks, and that the same outcome can be good or bad depending on who is judging. The legal obligations dimension is written generically, as obligations under relevant laws, regulations, or contracts. No specific regime is named anywhere in the draft, which matters for the mapping question I address below.

What is inside the templates, and how conformity actually works

The structure is conventional standards architecture, which is a compliment. Clause 3 describes outcomes. Clause 4 sets qualities and process. Clause 5 holds the templates and the conformity rules. Clause 6 lets you extend them. Annex A supplies defaults.

Clause 4.2 lists eight qualities a public-facing documentation artifact should have: correctness, comprehensibility, informativeness, judiciousness, freshness, interoperability, findability and availability, and maintainability. Two qualifications the draft states about its own list are worth carrying into any summary you write. The draft calls it a noncomprehensive list, so it is not a closed set. And every entry is framed with should, which in the document's own conventions is guidance, not a requirement. These are the criteria against which you would criticize your existing model cards, not a checklist you can fail. Freshness and maintainability are the two most in-house documentation fails, because documentation gets written once at launch and then quietly diverges from the deployed artifact. Freshness is specific about the fix: the artifact should clearly indicate when it was last updated, at least regarding the post-release portions.

Clause 4.3 turns to process. Setting aside 4.3.1, which is a general introduction, there are seven named recommendations: define documentation objectives, provide organizational support, keep processes manageable, provide guidelines, document continuously, distribute documentation work, and incorporate audience input. None of those will surprise anyone who has run a control function. Taken together they describe documentation as an operating process with an owner and a cadence rather than a launch deliverable, which is the correct diagnosis. Clause 4.4 then does something most frameworks avoid: it names four trade-offs between the qualities, including informativeness against judiciousness and informativeness against freshness, and says organizations should choose based on context and objectives. A document that admits its own recommendations conflict is more useful than one that pretends they stack.

The draft also defines a role, the documentarian, in Clause 2, as a member of an organization's staff who coordinates documentation processes and release of documentation artifacts, and notes that the role can be held simultaneously with other roles. Clause 4.3.4 adds the guardrail: documentarians should not be expected to do all the work of documenting, because accurate documentation depends on subject matter experts. I like this more than it probably deserves. Half of the documentation failures I have seen are not knowledge failures, they are ownership failures. The data scientist assumes legal will write it, legal assumes the model owner will, and the artifact goes out thin. Naming the role costs nothing and closes that gap.

Clause 5 is the reason to open the PDF at all, and Clause 5.1 is the reason to read it carefully. The dataset template at 5.2 has seven root fields: Identifying Descriptors, Intended Use, Usage Rights and Restrictions, Composition and Provenance, Evaluation, Maintenance and Monitoring, and Dataset Governance. The model template at 5.3 has eight: Identifying Descriptors, Intended Use, Usage Rights and Restrictions, Design, Training, Evaluation, Maintenance and Monitoring, and Governance. In both base templates exactly one root field is designated Required, Identifying Descriptors, and most of the rest are Optional. The templates consist of root fields only, by design, to maximize flexibility.

That looks permissive until you read the three conformity rules in 5.1, which are where the document has teeth. If an artifact includes a field from the clause, that field shall be populated with information matching the field description and guidance, and information not relevant to the field's stated description and guidance shall not be included. If an artifact includes information matching the description and guidance of a field, that field shall be present and shall contain that information or a reference to it. And all fields designated required shall be present and populated. Read the second rule twice. It means you cannot bury your evaluation results inside a marketing narrative and claim conformity: if the information is in the artifact, it has to sit in the field the standard names for it. That is a structural discipline, and it is the single most consequential sentence in the draft for anyone who already publishes model cards.

Clause 6 specifies profiles, the mechanism for adapting the templates to a domain, a risk level or a geography. A profile may add subfields and root fields, add guidance, and change designations, but the draft is explicit that a profile shall not change or contradict the structure, requirements and guidance of Clause 5 except to elevate a designation, from optional to recommended or required, or from recommended to required. Ratchets go one way. Clause 6 also states that an attestation of conformity shall indicate either conformity to the base templates or conformity to a specific profile, which is what makes a claim comparable across two vendors.

Annex A supplies default profiles: A.2 for datasets and A.3 for models, each expanding the root fields into subfields with their own designations. This is where the real prescriptiveness lives. In the default dataset profile, Identifying Descriptors and Composition and Provenance are Required at root level, Governance is Recommended, and several subfields are conditionally required in ways a compliance reader will recognize immediately: a Sensitive Data subfield required if the dataset is known to contain personally identifiable information, a Release Date and Version Identifier required if the dataset can be accessed by others, a Risk and Impact subfield required if negative impacts have previously been observed. The default model profile follows the same shape, with a License subfield required if the model can be accessed by outside entities. If you are going to test anything against your own artifacts, test Annex A, not Clause 5.

Where this document is going, and what I would not claim

The intended trajectory is stated plainly and should be read with equal care. NIST 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, and that it does not expect to maintain the document further, though it expects to contribute heavily and will be one voice among many.

Note the conditionals in the Foreword itself: the outcome assumes that INCITS/AI proposes the document as a new project for SC 42 and that SC 42 accepts the proposal, after which the document is subject to the usual consensus processes. Neither step is recorded as having happened. Nobody should write in a board memo that this is on track to become an ISO standard. What is accurate is that NIST has declared that path and drafted to it, which is why the document reads in ISO house style. Note also that the September 16 window is not necessarily the last one. NIST's own AI Standards page describes the input as feeding the subsequent, possibly final, revision.

Why the destination matters commercially: SC 42 is the subcommittee behind the ISO/IEC AI standards family that includes 42001, the AI management system standard many corporate governance programs are already certifying against. If a documentation standard eventually lands in the same family, the natural consequence is that documentation artifacts become auditable inside a management system firms already run. That is a plausible future, not a fact, and the honest version of the sentence keeps the conditional.

Two claims I would refuse to make. First, this draft does not present itself as satisfying or implementing any particular regulator's technical documentation duties. I read the text looking for a mapping to the EU AI Act and found none; the only treatment of regulation is the generic legal obligations dimension at Clause 3.4.4. If a vendor tells you conformity to this draft discharges an EU obligation, ask them to point at the clause. Second, it is not a successor to or a revision of the AI RMF. Different series, different function, and the AI RMF is not withdrawn by this publication.

Here is the interpretation, offered as interpretation. NIST is not writing a rule. It is trying to get a US-shaped input into an international standards process early, before the process settles around someone else's structure. The precedent is close at hand: the AI RMF was also voluntary, and Colorado's Senate Bill 24-205 named the latest version of the NIST Artificial Intelligence Risk Management Framework, alongside ISO/IEC 42001, in the statutory text as a benchmark for a reasonable risk management program. That happened inside two years of the framework's release. I would not assume the same arc for a documentation template, and Colorado's own implementation timing has moved since, so I would not rely on any date there. The narrow point stands: a voluntary NIST document became a reference point in binding text faster than most people expected.

What to do about it on Monday

There is no duty here, so all of this is optional. It is also cheap, which changes the calculation.

First, decide whether you want input on the record. The window is genuinely open and genuinely short: NIST states it will consider input received by September 16, 2026, by email to ai-standards+doczd@nist.gov, and strongly encourages use of its optional commenting template, though marked-up documents, bulleted lists and reaction letters are accepted. Submissions become part of the public record. If your firm documents models under an existing regime, whether that is model risk management practice at a bank, medical device documentation, or an ISO/IEC 42001 management system, you are exactly the reviewer this pilot is trying to reach, and two pages on field mismatches is worth more to the drafters than a general endorsement.

If you want concrete comment material, the draft supplies it. The contents listing orders the Clause 4.2 qualities differently from the body text, so 4.2.1 is comprehensibility in the table of contents and correctness in the clause itself. The cross-reference in 4.2.6 points readers to Clause 4.2.6 for continuous documentation processes, where the continuous documentation guidance is at 4.3.6. And the model template in 5.3 carries dataset language into model fields: Root Field 2 refers to applications the dataset is known to be unsuitable for, Root Field 3 describes redistribution of the dataset, and Root Field 8 Governance describes practices applied over the dataset lifecycle. None of that is fatal, all of it is the sort of thing a careful reviewer catches and a drafting team is glad to receive. NIST also asks reviewers to disclose any use of AI assistants in preparing feedback, which is a small and slightly amusing test of the reader's own documentation discipline.

Second, run the templates against one real artifact. Pick a model you already documented and a dataset you already described, put the Annex A subfields and designations next to what you have, and list what is missing. Use Annex A rather than Clause 5, because Clause 5 marks almost everything optional and will flatter you. This is an afternoon of work and it produces a defensible internal answer to the question every board eventually asks: how do we know our AI documentation is adequate. Comparing against a public federal draft is a better answer than comparing against nothing.

Third, test yourself against the Clause 5.1 placement rule specifically, because it is the one that catches mature teams. Take your existing model card and ask, for each paragraph, which root field it belongs in. Information about training data scattered through a narrative, evaluation results in an appendix nobody links, license terms in a separate web page with no reference from the card: each of those breaks the rule that information matching a field's description has to sit in that field or be referenced from it. Fixing placement is usually a reorganisation, not new writing.

Fourth, assign the documentarian. Whatever you call the role internally, write one name against each material model and dataset, write down when documentation gets refreshed, and record that the named person coordinates rather than authors. The eight qualities give you a short review checklist for that refresh, and freshness is the one to enforce, with a visible last-updated stamp on the artifact.

Fifth, be precise in how you describe this internally and externally. It is a draft. Saying NIST requires anything here is wrong, and a counterparty who reads the Foreword will notice. If you align to it, the accurate formulation is that your documentation is structured to follow the templates in NIST AI 300-1 ipd, a voluntary initial public draft, and if you go further and attest conformity, Clause 6 says you have to state whether that is to the base template or to a named profile. Get in the habit of that sentence now, because it is the sentence a procurement questionnaire will ask for if any of this hardens.

The cost of reading the document is one afternoon. The cost of misdescribing it to your board is higher than that, in both directions: treat a draft as a mandate and you burn budget on a deadline that does not exist, treat it as academic and you may find the structure quoted back at you in a vendor questionnaire before you have looked at it.

Last verified: August 3, 2026 against the primary sources listed above.