NIST is developing Guidance and Templates for Public-Facing AI Documentation through its AI Standards “Zero Draft” pilot.
Structured Ink submitted the following recommendations during the public-input period.
The central issue is simple: model documentation is necessary, but model identity alone may be insufficient as the unit of documentation for deployed AI systems.
As AI systems gain tools, credentials, memory, network access, delegated authority, and the ability to take actions, documentation needs to describe not only the model but the conditions under which that model actually operates.
Document the deployed system, not only the model
For increasingly agentic systems, model identity and model capability alone may not adequately describe the capabilities, risks, or controls that users encounter.
The same model can have substantially different effective capabilities depending on its deployment environment, including its access to tools, credentials, networks, persistent memory, external data, other agents, and state-changing interfaces.
We recommend that public-facing documentation identify, where applicable:
1. Deployment context
Whether the documented artifact describes a model, a hosted model service, an application incorporating the model, or a larger agentic system.
2. Tool and external-system access
The categories of tools, APIs, networks, data sources, execution environments, and state-changing interfaces available to the deployed system.
3. Identity and delegated authority
Whether the system can act using user, service, organizational, or delegated credentials, and the general mechanism used to scope that authority.
4. Persistence and memory
Whether the system maintains state across interactions, what categories of information may persist, and whether that persistent state can influence future actions.
5. Data retention and use
The applicable retention mode, material exceptions, whether submitted data may be used for model improvement or training, and whether these properties vary by deployment surface or service configuration.
6. Human authorization and intervention boundaries
Which consequential actions require human authorization, what forms of human intervention or shutdown are available, and whether actions already delegated or queued can continue after intervention.
7. Effective versus authorized capability
Where practical, documentation should distinguish between what a system is technically capable of doing in its deployed environment and what organizational or technical controls authorize it to do.
This distinction is increasingly important for agentic systems.
A system may be intrinsically capable of an action, gain additional effective capability through its deployment environment, yet be authorized to exercise only a subset of that capability.
Conversely, intended permissions may not describe the complete operating boundary when an agent can reach interfaces or environmental conditions that yield unintended authority.
A compact way to represent this relationship is:
model capability + deployment environment → effective capability
effective capability + authorization and constraints → authorized operating envelope
Public documentation should not expose sensitive security configurations, credentials, or exploitable implementation details.
The goal is instead to document the categories and boundaries that materially affect system behavior and risk.
This would also help prevent an ambiguity that is becoming increasingly important in AI inventories and procurement: an organization may describe a particular model as “approved,” even though approval actually applies only to a particular service configuration, retention mode, tool set, data classification, or authorization boundary.
For that reason, we recommend that the guidance explicitly recognize that:
Model identity alone may be insufficient as the unit of documentation for deployed AI systems, particularly systems capable of autonomous or delegated action.
Future Zero Draft topic: AI system reference architectures
We also encourage NIST to pursue its proposed future work on reference architectures or design patterns for AI systems and clarification of the AI technology stack.
One useful approach would be to distinguish the layers that determine AI capability from the mechanisms that control its use.
A deployed AI system can include models, compute and hosting infrastructure, data, identity services, credentials, orchestration, tools, external interfaces, monitoring, human decision points, and organizational policy.
Different actors may control different layers.
Reference architectures could therefore make both technical capability and control relationships visible.
In particular, they could identify where identity, authentication, authorization, delegated authority, tool access, monitoring, revocation, auditability, and human intervention operate across the system.
This becomes especially important as AI systems cross organizational and jurisdictional boundaries.
Two systems may use similar technical control mechanisms while operating under very different governance regimes. Conversely, systems operating under the same organizational policy may expose very different effective capabilities because their deployment architectures differ.
A reference architecture that separates system layers, interfaces, control mechanisms, and governance authority could provide a common vocabulary for documenting these differences without prescribing a particular technical implementation or governance model.
Such work would complement the documentation guidance by helping answer two related questions:
What system has actually been deployed?
Where does effective control over that system reside?
Structured Ink submitted these comments to the National Institute of Standards and Technology on September 16, 2026, in response to the initial public draft of Guidance and Templates for Public-Facing AI Documentation: An AI Standards “Zero Draft.”