MAP 2.2 Knowledge limits and human oversight: evidence

What MAP 2.2 asks for and why a missing limits document causes downstream failures

When a customer, contract or internal review asks how your AI system is limited and who oversees its output, MAP 2.2 is the part of NIST AI 100-1 that tells you what a good answer contains. The subcategory expects information about the system's knowledge limits and about how humans may use and oversee its output to be documented in enough detail that the AI actors making decisions can act on it. In practice that means writing down the settings outside the intended use, the upstream data and other AI systems the system depends on, the connections to external networks or critical infrastructure, and the human-AI configurations that were actually tested under conditions close to production. The framework is voluntary. NIST AI 100-1 is not a law and carries no certification, so no body issues a MAP 2.2 certificate. Whether an assessor or a contract accepts your document depends on how well it matches your system and the evidence behind it.

The failure this guards against is simple: people trust output beyond the scope it was validated for. A model tuned on one document type gets used for another, a reviewer rubber-stamps recommendations because nobody defined when review is required, or a downstream team builds on a vendor model whose limitations never reached them. Each of these traces back to a limits statement that was never written, or was written by one team and never shared. The difficulty is that limits are scattered. Product owns the intended use, data teams know the training gaps, operations knows the failure modes in production, and vendors hold the details of the models they supply. Before drafting anything, ask each of those owners what the system must not be used for, which inputs it has never seen, and which external services it cannot function without.

Which systems, teams and dependencies MAP 2.2 reaches

MAP 2.2 documentation is only as complete as the boundary drawn around the system. The cards below cover the scoping decisions that most change what must be written down: the kind of system, what it feeds, where its models and data come from, and who acts on its output. Settle each one before drafting, because each shifts the knowledge limits and oversight details an AI actor needs.

Generative versus predictive systems

A generative system produces open-ended text, images or code, so its knowledge limits include fabricated content and gaps the user cannot see from the output alone. A predictive system, such as a classifier or scorer, has bounded outputs and documented error rates on known populations. For a generative system, the Generative AI Profile ties MAP 2.2 to information integrity and content provenance, so document how users should verify outputs. Check which category applies before choosing the documentation template.

Systems that feed other systems

When an output becomes an input to another application, a queue or a downstream model, the system is an upstream dependency. Errors then propagate beyond the team that owns it, and the people reviewing the downstream result may never see the original context. Record every consuming system, the fields passed, and whether a human reviews the output before it moves on. The Generative AI Profile specifically asks organizations to document whether the system serves as an upstream dependency for other systems.

Third-party models and data

Pre-trained models, hosted APIs and external datasets bring knowledge limits that the organization did not train or curate itself. Document the provider, model version, training data sources where known, update cadence and the settings the organization controls. Where a provider's changes can alter behavior without notice, record how the organization would detect the change. Ask vendors for documentation of limitations, and state in the record what the vendor did not disclose.

Connections to external networks and markets

Some systems reach external networks, financial markets or critical infrastructure through tools, APIs or actuators. The Playbook suggests documenting these connections because the consequences of a wrong output change sharply when it can trigger an action. List each external connection, the actions it can take without approval, and the conditions under which a person must intervene. This entry should be read alongside the scoping of out-of-scope settings, since those are where unplanned connections usually appear.

Teams acting as end users

End users are the people who take the system's output and act on it. Their skill, training and workload determine whether stated limits are actually read. Document who the end users are, what they are authorized to do with the output, and what training they received on verification. A team that uses the system occasionally needs different oversight instructions from one that relies on it daily. Confirm these details with the business owner rather than assuming the intended users match the actual ones.

Teams acting as overseers

Overseers review, override or stop the system, and their documentation must say how they do it. Record who holds the authority to override, the criteria that trigger review, the escalation path and how an overseer learns that the system is operating outside its documented limits. Test whether overseers can realistically intervene at the speed the system operates, under conditions close to real use, and keep the results as evidence for the human-AI configuration.

How an assessor tests MAP 2.2 in practice

This table walks through how an independent assessor would test MAP 2.2, from reviewing limits documentation to tracing dependencies, with the evidence requested and the gaps that commonly appear. Read it as a description of testing, since AI RMF has no certification and only an independent assessor issues any report on your controls.

Test step	What the assessor does	Evidence requested	Common finding
Review limits against intended use	Compares the stated knowledge limits with the intended-use statement and the system's real operating context	Limits register, intended-use statement, model or system card, version history	Limits written once at launch and never revised after the scope changed
Check out-of-scope settings	Confirms that settings, user groups and data types the system must not handle are named explicitly	Documented out-of-scope list, access configuration, usage policy	Out-of-scope settings implied but not written down, so users discover them in production
Sample human-AI configurations	Selects configurations and observes or reviews tests run under conditions close to production	Test plans, test records, reviewer scripts, sampled outputs with reviewer decisions	Tests run on clean sample data only, with no operator workload or time pressure
Confirm oversight roles are held	Checks that each named reviewer, approver or override role has a person assigned and trained	Role assignments, training records, escalation paths, override logs	Oversight roles named in the document but nobody holds them after staff changes
Trace upstream dependencies	Follows each input from its source through the system to every downstream consumer	Dependency records covering data sources, other AI systems, provenance metadata	Undocumented upstream data feeds, or content provenance not recorded for generated outputs
Check external connections	Confirms links to external networks, financial markets or critical infrastructure are documented and bounded	Interface inventory, network diagrams, connection approvals	Integrations added by other teams that never reached the system record
Test change control of the records	Checks that limits and dependency documents change when the system or its use changes	Document version history, change tickets, review dates	Records are current on paper but do not reflect the version in production

How to document limits and oversight step by step

This sequence turns MAP 2.2 into a dated, reviewable record that tells AI actors where the system should not be used, what it gets wrong, who checks its output, and what it depends on. Each step closes with a specific artifact that the next step builds on.

Inventory intended and out-of-scope uses
The product owner and the AI risk lead list the tasks the system is meant to support, then write down the settings it must not be used for, such as populations, languages, decision types or data sources outside its design. Compare this list against the MAP 1 context record so the boundaries match what was approved. The step is done when every out-of-scope setting has a named owner and a written reason, and the list is attached to the system inventory entry.
Record knowledge limits and failure modes
Engineers and domain experts document what the system does not know or cannot do reliably, including gaps in training or retrieval data, time-sensitive information, rare cases, and known error patterns from prior testing. For generative systems, include hallucination and misattribution risks and note where content provenance cannot be confirmed. The step closes with a limits register that states each failure mode, how it would show up to a user, and the evidence behind it.
Define the human role at each decision point
For every point where the output influences a decision, the process owner states whether a person reviews, approves, overrides or only receives the output, and what information that person needs to judge it. Record the operator skill or training assumed and what the person is authorized to do when the output looks wrong. The step is complete when each decision point maps to a named role, and the oversight procedure is reviewed by the people who will perform it.
Test human-AI configurations under realistic conditions
The team runs the planned human-AI workflow with the people who will use it, using inputs close to production conditions, and records where reviewers accept errors, miss them, or slow down. Results are compared with the limits register so that gaps in oversight or unclear instructions are documented. The step closes with a test record that lists the scenarios, reviewer outcomes, and changes made to the workflow or user guidance as a result.
Map upstream and downstream dependencies
Engineers document every upstream data source, model, retrieval index, and third-party service the system relies on, and every downstream system that consumes its output. For generative systems, this includes how content provenance is captured and whether other systems treat the output as trusted input. The step ends with a dependency map showing the owner, change process and failure impact of each connection, including links to external networks, financial markets or critical infrastructure where they exist.
Confirm connections to external systems
Security and platform engineers verify the dependency map against the running environment, checking network paths, API credentials, and data flows that actually exist rather than those that were planned. Any connection not in the map is either removed or documented and assessed. The step closes with a reconciled connection inventory that the team can compare against the next configuration review.
Approve and version the record
The accountable owner reviews the scope list, limits register, oversight roles, test record and dependency map together, then approves or returns them with comments. The approved package is stored under version control so each later change to limits or oversight is traceable to who made it and when. The step is done when the approval is recorded, the version is published to the AI actors who rely on it, and a review trigger is set for changes to the system, its data or its dependencies.

How the Playbook and the Generative AI Profile shape MAP 2.2 actions

The NIST AI RMF Playbook gives teams a set of suggested actions for MAP 2.2, and the most useful ones point at the boundaries of the system. Organizations are expected to document settings outside the intended use, test human-AI configurations under conditions close to real-world use, document dependencies on upstream data and other AI systems, and document connections to external networks, financial markets and critical infrastructure. For a self-hosted platform, that means writing down which tenants, data stores, identity providers and downstream services the system touches, and recording which operator roles are expected to review or override its output. Treat these as prompts for documentation, not as a checklist: the Playbook states that it is neither a checklist nor a set of steps, so the job is to decide which actions fit the system and to justify the ones you skip.

NIST AI 600-1, the Generative AI Profile published July 26, 2024, adds two MAP 2.2 actions, MP-2.2-001 and MP-2.2-002, tagged to the risks Information Integrity and Value Chain and Component Integration. The first asks you to identify and document how the system relies on upstream data sources, including for content provenance, and whether it serves as an upstream dependency for other systems. For a generative deployment, that is where you record which retrieval corpora and model providers feed answers, and which downstream applications consume generated text without review. Confirm the exact wording of MP-2.2-002 in the profile itself before you map it to your own records. Also check the Playbook's audit log, which shows its last content update as August 2023. Its suggested actions have not been refreshed since, so verify each one against the current revision status of AI RMF 1.0 before you cite it to an assessor, regulator or customer.

Which evidence artifacts pass MAP 2.2 and how to keep them current

MAP 2.2 asks for knowledge limits and human oversight to be written down in enough detail for AI actors to make decisions. The artifacts below connect that documentation to what an assessor or internal reviewer can inspect, and each one needs an owner and a refresh trigger to stay accurate between reviews.

Knowledge limits and out-of-scope statement

This is the core document for MAP 2.2. It states the intended use, the settings and populations the system was not tested for, known failure modes, and the conditions under which outputs should not be relied on. Check that every limit traces to a test result or a documented assumption, and that the statement names the version of the system it describes. Review it whenever the model, prompt set, data source or user population changes, since a limit written for one configuration may not hold for another.

Human oversight procedure with named roles

This procedure records who may use the system's output, who reviews or overrides it, and what triggers escalation. Named roles matter more than job titles alone, so list the individual or role owner, the decision each person may make, and the backup. An assessor will look for evidence that these roles are assigned and understood, not only that a procedure exists. Confirm the named people still hold these roles at each review cycle.

Human-AI configuration test records

The Playbook suggests testing human-AI configurations under conditions close to real use. Keep records showing the test scenarios, the operators who took part, the outputs they accepted or rejected, and where reviewers missed errors. These records show whether the oversight design works in practice, which is the evidence that matters most for MAP 2.2. Retest after any change to the interface, the output format or the review workflow, because a new layout can change how reviewers behave.

Dependency register

The register lists every upstream data source, other AI system, retrieval index, external network connection and downstream system that relies on this system's output. For generative systems, NIST AI 600-1 specifically asks how the system relies on upstream data sources, including for content provenance, and whether other systems depend on it. Record the owner and the failure impact for each dependency. Update the register when an integration is added, retired or re-pointed, and check that connections to financial or critical infrastructure systems are included.

Versioned change history

A change history shows what was altered in the limits statement, oversight procedure and dependency register, when, and by whom. Version control matters because an assessor may ask what the documentation said on the date a decision was made. Keep the wiki or document system's history intact rather than overwriting pages, and tie each change to the related test run or review. Ask the platform owner to confirm retention and rollback behavior before relying on it for evidence.

Operational traces and access records

Request traces and permission records show how the system was used in production and who could change its documentation. Traces that capture inputs, outputs, tool calls and retrieval steps help reviewers confirm that the system stayed within its stated limits. Role-based access settings show that only authorized people could edit the oversight records. Review trace coverage and access roles on a fixed schedule, and confirm with the tooling vendor which fields are captured by default and how long they are kept.

Which open-source tools produce MAP 2.2 evidence

garak is an open-source scanner, licensed under Apache-2.0, that probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. For MAP 2.2, its value is evidence that the system's behavior outside its intended use was actually tested, which supports documenting out-of-scope settings. Its output is a JSONL report covering every attempt and evaluation, plus a hit log listing only the attempts that found a vulnerability.

What it proves: that named probe categories were run against a specific model configuration on a specific date, with results stored per attempt.
What it does not prove: that the probes cover your application's out-of-scope use cases, prompts or tool integrations. It tests the model, not the surrounding system.
Human-AI configuration: garak does not test how people read, trust or override outputs, so it cannot evidence the oversight half of MAP 2.2.
Retention: keep the JSONL report and hit log with the model version and probe settings used, so the run can be reproduced.
Illustrative example: a team runs a scan before each model change and files the hit log with the change ticket.

Confirm with your security team which probe families match your declared out-of-scope settings, and whether the scan runs in a sandboxed environment that cannot reach production data.

What meeting MAP 2.2 costs in money and effort

The largest cost of MAP 2.2 is people's time, not software. NIST AI 100-1 has no certification to buy and no fee schedule, so the spend is the work of documenting knowledge limits, designing and testing human-AI configurations, and mapping dependencies. The organization pays its own staff for most of that work, usually product owners, model owners, operations leads and the people who will actually review outputs. Documentation time is one-time at the start and then recurring as the system changes. Test engineering for human-AI configurations is also mostly one-time setup, followed by repeat runs whenever the workflow, model or reviewer role changes. Ask any implementation partner to price these as separate line items so you can see which parts are fixed and which are per release.

Tooling is where open-source platforms change the math. Tools such as garak, Langfuse, XWiki and BookStack carry no license fee, but the cost moves to installation, integration with your identity provider and logging stack, permission design, backups, upgrades and the staff who keep them running. A self-hosted tool has no license line but still has an operating cost. Dependency mapping across teams is a recurring cost that is easy to underestimate, because the upstream data feeds, downstream consumers and external network connections that MAP 2.2 asks you to document sit with different owners. External review or testing is optional but common, and you should ask for its scope in writing, including whether the reviewer tests human oversight under near real-world conditions or only reads the documents.

Four drivers move the total up or down: the number of AI systems in scope, whether generative AI is included (NIST AI 600-1 adds suggested actions for MAP 2.2 tied to information integrity and value chain risks), the scope of out-of-scope settings you must describe, and how often the system or its dependencies change. Confirm each driver with your own environment before accepting a quote. When requesting a quote, ask the provider to separate one-time setup from recurring upkeep, state which documents and test runs are included, name who owns each evidence artifact after handover, and state what happens when the NIST AI RMF is revised, since NIST has said the framework is being revised and the Playbook will be updated after that.

Who owns MAP 2.2: your team, a partner and the auditor

Your organization owns the knowledge limits of the AI system and the decisions about how people may use and oversee its output. Those are business and risk judgments. Nobody outside the organization can decide that a system is unsafe outside a given customer-support workflow, or that a reviewer must approve every output before it reaches a patient or a borrower. The people who sign off on these statements should be accountable owners named in your governance records, not the engineers who happened to write the documentation.

Limits and out-of-scope use: Decide which settings, populations, languages, data types and decision types the system is not approved for, and record who approved that boundary.
Human oversight roles: Name the reviewers, their authority to override or stop the system, and the training they need before they act on its output.
Dependencies: Confirm which upstream data sources, other AI systems, and external networks the system relies on, and who owns each one.
Decisions and sign-off: Keep the approved documentation under version control, with dated approvals and a review trigger tied to changes in scope.

Before relying on any document, confirm that a named business owner, not only the technical team, has accepted the stated limits in writing.

Where MAP 2.2 programs usually fall short

Most MAP 2.2 gaps are not missing documents. They are limits that were never tested, roles that have no named person behind them, and dependencies nobody has traced. Each card below pairs one common gap with the step that closes it, so the documentation can support real decisions by the AI actors who rely on it.

Limits written as marketing claims

Knowledge limits often appear as phrases such as "highly accurate" or "designed for all customers." Those statements tell a reviewer nothing about where the system fails. MAP 2.2 expects documentation detailed enough for relevant AI actors to act on. Replace each claim with the conditions under which the output is known to be unreliable, the data the system was not trained or tested on, and the evidence behind each limit. Ask the team to name the last test that supports each statement.

No defined out-of-scope settings

Teams usually describe the intended use but not the settings the system should never be used in. The Playbook suggests documenting settings outside the intended use, so reviewers can see where the system is not supported. Write a short list of excluded populations, languages, geographies, input types and decision types. Then check that access controls, product configuration or usage terms actually block those cases, and record who approved the list.

Oversight roles without named people

A policy may say that a qualified reviewer approves high-impact outputs, but not name anyone. Oversight that exists only as a job title cannot be exercised or evidenced. For each oversight step, record the role, the named person or rotation, their authority to override or stop the system, and how they are trained on its limits. Confirm that the people named know they hold the role and that their availability covers the hours the system runs.

Untested human-AI configurations

Documents often describe a human reviewing the output without testing whether that review works. The Playbook suggests testing human-AI configurations under conditions close to real use. Run reviewers through realistic cases, including ones where the system is wrong, and measure whether they catch the errors. Record time pressure, interface design and automation bias findings, then adjust the workflow before the record is treated as evidence of oversight.

Unknown upstream dependencies

Systems rarely run alone. They depend on data feeds, retrieval indexes, embedding services, pre-trained models and downstream consumers that may not be listed anywhere. Generative AI guidance under MAP 2.2 asks teams to document reliance on upstream data sources, including content provenance, and whether the system feeds other systems. Build a dependency map with an owner, a version and a failure behavior for each link, and review it whenever a connected system changes.

How much effort does MAP 2.2 take, and can we do it in-house?

Is there a fixed price or duration for MAP 2.2?

No supplied figure sets a fixed price or duration for MAP 2.2, and NIST does not publish one. Effort depends on how many AI systems are in scope, how complex each one is, and how much documentation already exists. Ask any partner for a written scope that lists the systems covered, the documents to produce and the review cycles before accepting a quote. Because DeployOpen works from fixed, written scopes, the quote follows from that scope rather than from a published price list.

What drives the effort of documenting knowledge limits?

The main drivers are the number of systems, how many upstream data sources and other AI systems each one depends on, and how many settings sit outside the intended use. A single system with few dependencies takes far less work than a platform that feeds several downstream tools. Effort also rises when human-AI configurations must be tested under conditions close to real use, because that testing needs staff time, test environments and records of results.

Which costs are one-time and which recur?

The first documentation of limits, dependencies and oversight roles is largely one-time work. Recurring costs come from keeping that record current when the system, its data or its users change, and from reviewing it periodically. Ask a partner to separate the initial build from the ongoing review in the quote, and to state who performs each recurring task after handover.

What does MAP 2.2 need from engineering, product and risk owners?

Engineering must map data sources, model dependencies, integrations and network connections, and must set up the logging needed to show how the system behaves. Product owners must define the intended use, the settings that fall outside it, and the points where a person reviews or overrides output. Risk owners must decide which limits are acceptable, approve the oversight design and sign off on the record. Each group owns its part, and none can complete MAP 2.2 alone.

Can our in-house team manage MAP 2.2 without outside help?

Yes, many organizations can, provided they have staff who understand the system's architecture, a risk owner who can make decisions, and time to test human-AI configurations. The NIST AI RMF is voluntary, so no outside body must approve the work. Teams that lack experience with dependency mapping or test design often find the first pass takes longer than expected. Confirm internal capacity before committing, and check whether the team can keep the record current after the first version.

When does outside help make sense for MAP 2.2?

Outside help is most useful when many systems share dependencies, when no one in-house has mapped those links, or when the work must be finished within a set period. Partners can also build the documentation structure and test plans, then hand them over. DeployOpen prepares systems, controls and evidence for assessments and runs security testing, but it does not issue audit reports or certifications. Where a customer or regulator asks for independent review, that review comes from an independent assessor.

What should a quote for MAP 2.2 include?

Ask for the list of systems and dependencies in scope, the deliverables such as limit statements, oversight design and test records, and the roles of each party. Request the testing approach, the tools to be used, and what the client must provide, such as access, staff time and approvals. Also ask how updates are handled after handover and which items remain the client's responsibility. A written scope makes it possible to compare offers on equal terms.

How can open-source tools help keep the MAP 2.2 record current?

Wiki platforms with version history, such as XWiki, record what changed, when and by whom, which supports an audit trail for limit statements and oversight rules. Observability tools such as Langfuse can capture traces of inputs, outputs, retrieval steps and tool calls, giving evidence of how the system behaves in use. Testing tools such as garak can probe language models for failures and produce reports that feed the record. Confirm each tool's fit with your environment before relying on it.

How DeployOpen prepares MAP 2.2 evidence

DeployOpen's part in MAP 2.2 starts with a written scope. Before any work begins, the organization and DeployOpen agree in writing which AI systems, workflows and human reviewers are in scope, which settings are declared out of scope, and which upstream data sources and connected systems must be documented. The organization owns the knowledge limits and the oversight decisions. DeployOpen plans, implements and hardens the self-hosted tooling that records them inside the client's own cloud accounts, data centers or air-gapped networks, then prepares the documentation and test records that an internal reviewer or independent assessor can examine. Ask any implementation partner to name the artifacts it will deliver and who signs off each one.

On the tooling side, the usual pattern is a versioned knowledge base for the system's limits and oversight procedures, tracing for the operations behind each output, and role-based access so that only named reviewers can change the oversight record. For example, an illustrative setup might use XWiki for version-controlled limit statements, Langfuse traces to show which retrieval and tool steps fed an output, and BookStack roles to separate authors from approvers. DeployOpen configures these components, tests that the records capture what they are meant to capture, and documents the configuration. Confirm the exact features, retention settings and export options against each product's current documentation before committing to a design.

Support after handover is usually a retainer, not a new project. Retainers can cover upgrades to the tooling, periodic re-testing of human-AI configurations, and updates to the limit statements when the system, its data sources or its connected systems change. Keep in mind that the NIST AI RMF Playbook has not been updated since August 2023 and that NIST is revising AI RMF 1.0, so the documentation should name the framework version it was built against. DeployOpen does not issue audit reports, attestations or certifications, and NIST does not certify use of the AI RMF. Any statement that an organization meets MAP 2.2 must come from its own governance process or from an independent assessor, which the organization selects and engages directly.

MAP 2.2 Knowledge limits and human oversight of outputs