MAP 1.1 Intended purpose and context of use: evidence guide

What MAP 1.1 asks an AI team to document before anything else

When a customer, regulator or internal review asks how an AI system is meant to be used and where it is not meant to be used, the answer has to come from documentation written before the system went live. MAP 1.1 is the NIST AI RMF outcome that covers this ground. It asks an organization to understand and record the intended purposes and beneficial uses of the system, the context-specific laws and norms that apply, the deployment settings, the users and their expectations, the positive and negative impacts, and the assumptions and limitations. It is the broadest MAP outcome and the starting point for the go or no-go decision that AI 100-1 expects a team to reach after completing the Map function. The NIST AI RMF is voluntary and has no certification, so no outside body will issue a stamp on this record. The evidence is internal, and its credibility depends on who reviews it and how it is kept.

The usual difficulty is drift. A purpose statement is written once for the launch review, then the system is connected to new data, handed to a new team or used by staff for tasks nobody listed. The documented context then describes a system that no longer exists. Teams should set a review trigger for changes in users, data sources, deployment settings and decisions the output informs, and should record which intended purposes are explicitly excluded. For a generative system, the Generative AI Profile ties MAP 1.1 to identifying foreseeable illegal uses that exceed organizational risk tolerances, so the exclusions list should be checked against that question as well.

Before drafting, confirm three things with the business owner: the non-AI alternative that was considered, the human oversight roles and their documented requirements, and the people who will sign off the context record. The Playbook suggests each of these actions for MAP 1.1, and the NIST AIRC Playbook lists them with documentation prompts. Store the record where changes are versioned and approvals are traceable, so that an assessor or customer can see what the team believed about the system at each stage.

Which AI systems and deployments fall under MAP 1.1 scoping

MAP 1.1 asks an organization to document the intended purpose and context of use before it decides whether to build, buy or deploy an AI system. The decisions below change how much context must be written down, who must review it, and which assumptions and limitations need their own record.

In-house versus purchased AI

A system you build lets you document design intent, training data and known limits from the start. A purchased system moves much of that knowledge to the vendor, so MAP 1.1 documentation depends on what the vendor discloses about intended use, deployment settings and limitations. Check whether the vendor's stated purpose matches how your staff will actually use the output, and record the gaps as assumptions to test.

Generative versus predictive systems

Generative systems produce free-form content, so the documented context must cover foreseeable misuse, prompts users may enter and content the system must not produce. Predictive systems score or classify inputs within a narrower decision, so the context centers on the decision, the population and the thresholds. The NIST AI 600-1 Generative AI Profile adds suggested actions under MAP 1.1 that target generative risks, so generative scope usually carries a longer list.

Internal versus customer-facing deployment

An internal tool used by trained staff has a narrower set of affected people and a clearer operating environment. A customer-facing deployment brings in users who did not select the system, may be vulnerable, and may rely on its output for consequential decisions. Document who the users are, what they expect, and what the organization will tell them about the system's limits before launch.

One model serving several use cases

When a single model supports hiring, customer support and internal search, each use case has its own intended purpose, affected groups and acceptable error costs. Write a separate context record for each use case, even if the model, weights and training data are shared. Otherwise the documentation describes an average purpose that fits none of the actual deployments.

Systems that feed other decisions

An AI output that a person reviews before acting carries different context than one that triggers an automated action. Record where human oversight sits, who can override the output and what the reviewer needs to know about the system's limits. Confirm the oversight roles with the operating teams, because documented oversight that nobody performs is a common gap.

Third-party components in the chain

A system built on a third-party model, dataset or API inherits that component's intended uses and restrictions. Map each component's documented purpose against your own use case and note any mismatch, such as a model licensed for research only. Keep the component inventory with the context record so that a change upstream triggers a review of the downstream purpose.

How to document intended purpose and context of use step by step

This sequence turns MAP 1.1 from an abstract outcome into a dated record that states what the AI system is for, where it will run, who it affects and where it must stop. Each step produces a document or record that a reviewer can check, and the set feeds the go or no-go decision the framework expects after the MAP function.

Define the task, purpose and minimum functionality
Start by writing one short statement of the task the system performs, the purpose it serves and the minimum functionality needed to achieve that purpose. The product or AI owner drafts it with input from the people who will use the output. Record the expected benefits next to it, stated in terms that can later be checked. The step is done when a reviewer who did not build the system can restate the task and purpose in their own words and identify what the system is not expected to do.
Consider non-AI alternatives
Before going further, record whether the same outcome could be reached with rules, a simpler statistical method, a process change or no automation at all. The team that owns the business problem writes the comparison, including the cost of each option and what the AI system would add. Keep this comparison in the context record because it explains why the system exists at all. The step is complete when the record states either why the AI approach is justified or that the alternatives were judged inadequate, with reasons.
Delineate the expected context of use
Describe the setting in which the system will operate. Cover the social norms that apply, the groups affected by its outputs (including people who never interact with the system directly), and the operational environment, such as the systems it connects to, the data it receives and the conditions under which it runs. Product, operations and domain experts should contribute, and the description should name the places where the system will not be used. The record is complete when every affected group is named and each stated environment condition can be tested.
Identify applicable laws, norms and expectations
List the laws, regulations, contractual terms, sector rules and professional norms that bear on the system in its stated context. Legal or compliance staff confirm each entry and note which obligations depend on the deployment country, sector or data type. Record expectations from customers and from the public as well, since MAP 1.1 asks for context-specific norms and expectations, not only legal duties. The step produces a register of obligations with an owner for each one. Confirm current requirements with counsel, because the legal landscape changes.
Document users, their expectations and foreseeable misuse
Write down each user group, what they expect the system to do, their level of AI literacy and the decisions they will make from its output. Add the foreseeable uses that fall outside the intended purpose, including misuse, and state whether the team accepts, restricts or prohibits each one. For generative AI, the Generative AI Profile suggests identifying foreseeable illegal uses that exceed organizational risk tolerances, so record those explicitly. The record is complete when each user group has a documented expectation and each foreseeable misuse has a decision attached.
Record positive and negative impacts with assumptions and limitations
Capture the benefits and potential harms the system could cause, along with the assumptions the design relies on and the known limitations of the data, model and operating conditions. The risk owner reviews the list and marks which assumptions could fail in production. Link each limitation to the use restriction or user instruction that addresses it. The output is an impact and limitation register that feeds later MEASURE and MANAGE work. The step is done when every assumption has a stated test or monitoring idea, or an explicit reason it cannot be tested yet.
Assign human oversight roles and requirements
Document who oversees the system, what they are expected to check, when they can override or stop its output and what training they need to do so. Name the accountable owner for each oversight role and record the escalation path. Governance owners should confirm the roles match the accountability structure set out in GOVERN 2. The record is complete when each oversight role has a named position, a defined authority and a documented requirement for the people who fill it.
Approve the context record and version it
Bundle the outputs from the earlier steps into one context record, have the accountable owner and the people who contributed sign it, and store it under version control so every change is traceable. Note the date, the reviewers and the triggers that require a new review, such as a change of use, a new user group or a new jurisdiction. This record is the input to the go or no-go decision in MANAGE 1. Confirm the record's review cadence with your governance policy before relying on it.

How an assessor tests MAP 1.1 and what they ask to see

This table lists the steps a reviewer typically takes when testing MAP 1.1, the evidence each step relies on, and the findings that appear most often. Use it as a preparation checklist for your own documentation. NIST does not run a certification program for the AI RMF, so any review of this kind is an internal or independent check, but it shows whether the stated context matches how the system actually runs.

Test step	Evidence requested	Common finding
Document review	Approved purpose statement, system description and dated version history	Purpose text is generic and not tied to a named system or owner
Interviews with system owners	Interview notes and owner sign-off on the context description	Owners describe a use that the written purpose never mentions
Comparison with production use	Deployment records, configuration exports, usage logs and change tickets	Logs show users, data sources or settings outside the stated purpose
Limitations and assumptions	Limitations register and user-facing guidance that carries the limits	Limitations are missing or do not reach the people who operate the system
Affected users and impacts	Stakeholder list and documented analysis of positive and negative impacts	Affected groups appear in design notes but not in the context record
Legal and sector norms	Requirements register with compliance or legal sign-off	Context-specific obligations are listed but not linked to the purpose
Human oversight roles	Role definitions and oversight procedures naming accountable people	Oversight appears in policy but no named person holds the duty
Change review	Records showing context was re-evaluated after material changes	Scope expanded to new users or settings with no re-evaluation on file

How a purpose statement stays tied to real use

A MAP 1.1 context record only stays accurate if it is linked to what the system actually does in production. Treat the intended purpose statement as a versioned record that points to the deployed configuration: the model or model version, the prompts or system instructions, the retrieval sources, the tools the system can call, the enabled features and the operating environment. When any of those change, the record should be reviewed, because the assumptions and limitations written for the previous configuration may no longer hold. Ask the system owner to name each of these elements in the record and to state which ones were in scope when the context was assessed.

Define explicit trigger points for revisiting the context. Useful triggers include a new user group or a change in who can access the system, a new data source or a change in what data feeds it, a new jurisdiction or market where the system is offered, a change in the decisions the output influences, and a sustained shift in monitoring data such as usage outside the documented scope, rising complaints or new categories of error. Each trigger should have a named owner and a documented outcome: confirm the context still holds, update the record, or stop and escalate. Illustrative example: a support assistant documented for internal staff is later opened to customers, which should trigger a new review of users, impacts and limitations before the change goes live.

Confirm with your legal and compliance team which jurisdictions and sector rules attach to each deployment setting, since the context-specific laws and norms recorded under MAP 1.1 must follow the system's actual footprint. Access logs, usage analytics and trace data from the monitoring stack are the most direct evidence that real use matches the stated purpose, and the review cadence should be set in the governance policy so that reviews happen even when no obvious change has occurred. Keep the review history with the record so an assessor can see when the purpose was last confirmed and against which configuration.

Evidence that satisfies MAP 1.1 and how to keep it current

MAP 1.1 is met by a set of written records that describe what the AI system is for, where it runs, who it affects and where it falls short. Each artifact below has an owner who signs it off, and each needs a trigger for review, because context drifts as systems, users and laws change.

Intended-use statement

A short, signed statement of the task, purpose, minimum functionality and expected benefits of the system, plus the non-AI alternatives considered and why they were rejected. The product owner drafts it and the accountable executive signs it before any go or no-go decision. Review it whenever the task, user group or model changes, and confirm that the statement still matches what the system actually does in production.

Context-of-use record

A versioned record of the social norms, operational environment and conditions under which the system is expected to be used. Keep it in a page history so each change shows what changed, when and by whom. Assign the risk owner as approver, and reopen the record when the operating environment or regulatory setting changes.

User and affected-group register

A register listing each user role, each affected group and each person who could be harmed by the output, with the expectations and possible impacts for each. The system owner maintains it with input from people outside the build team. Check it after onboarding a new user population and after any incident involving an unexpected group.

Deployment setting description

A description of the hosting environment, integrations, data sources, access paths and any downstream systems that consume the output. It should be detailed enough that an assessor can trace a request from the user interface to the model and back. Infrastructure engineering prepares it and the system owner approves it. Update it with every architecture change, not only at audit time.

Legal and norms review

A written review of the context-specific laws, sector rules, contractual terms and stakeholder expectations that apply to the deployment. Legal counsel or the compliance lead signs it off, and the review names the jurisdictions and sectors it covers. Repeat it when a law the system depends on changes, and ask counsel to confirm which parts of the review fall outside their scope.

Assumptions and limitations register

A register of the assumptions behind the system's design, its known limits, and the conditions under which its output should not be relied on. Each entry links to the test or monitoring result that supports it. The model or product owner maintains it, and the register is reviewed after each evaluation cycle and each material change in input data.

Human oversight roles

A roster defining who reviews, overrides or stops the system, what authority each role holds and how they are trained. Document the escalation path and the people who may deactivate the system. Human resources and the accountable executive approve the roster. Check it whenever staff change, and confirm that named reviewers still hold the access and skills their role requires.

What meeting MAP 1.1 costs in money and effort

This table breaks down the cost components of documenting intended purpose and context of use, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request and to separate internal effort from outside spend. No dollar figures are given because none are supplied for this outcome; confirm rates with your own staff and any providers.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Product, legal and risk staff time	Internal teams defining purpose, users, deployment settings and limitations	One-time for the first context record, recurring at each material change	Number of use cases, number of affected user groups, and how often the system's scope shifts
Engineering staff time	Internal engineers describing system behavior, data flows and operating environment	One-time, then recurring with releases	System complexity, number of components, and how well existing architecture documents are kept
Legal or privacy counsel review	External or internal counsel reviewing context-specific laws and norms	Recurring at review cycles and jurisdiction changes	Number of jurisdictions, sector rules, and whether generative AI or personal data is involved
Version-controlled documentation tooling	Licensed wiki or document platform, or self-hosted open-source wiki with hosting staff	Recurring license or hosting cost; one-time setup	Seat count, hosting model, and whether an existing wiki already offers version history and role permissions
Monitoring data for real-use checks	Observability tooling and the staff who review traces and logs	Recurring storage and review effort	Request volume, retention periods, and how much usage detail the context record must confirm
Partner fees for fixed-scope work	Implementation partner paid under a written, fixed scope	One-time for scoped deliverables; optional retainer for upkeep	Number of systems in scope, depth of documentation required, and whether internal staff prepare inputs
Auditor or assessor sampling time	Independent auditor or certification body, who alone issues reports or certificates	Recurring at each assessment cycle	Number of AI systems sampled, quality of records, and whether context decisions are traceable
Self-hosted tooling as a cost lever	Hosting staff or infrastructure owner instead of a per-seat vendor license	Recurring infrastructure and maintenance effort	Ability to run open-source wiki and observability tools in your own environment; confirm features and licensing with each project

Who owns MAP 1.1 and what a partner can prepare

Your organization owns the substance of MAP 1.1. Only the people accountable for the AI system can state its intended purpose, the decisions it supports, the users it will serve and the impacts you are willing to accept. A partner can organize that thinking, but it cannot decide it for you, and an assessor will look for evidence that the owners made and signed those choices.

Purpose and use decisions: Define the task, the minimum functionality and the benefits the system must deliver, and state where it should not be used.
Context of use: Describe the social norms, affected groups and operational environment, including the laws and contractual terms that apply in each deployment setting.
Human oversight: Assign who reviews outputs, who can override the system and what training those people need.
Non-AI alternatives: Record whether a simpler method was considered and why it was set aside.
Sign-off: Name the accountable executive or governance body that approves the documented context and the go or no-go input it provides.

Confirm that each of these items has a named owner and a date of approval before any preparation work starts.

Where teams usually fall short on intended purpose documentation

Intended purpose documentation often reads well at approval and drifts as the system moves into production. The gaps below share one cause: the context of use was written once and never tested against how people actually use the system.

Purpose written for a demo

The first purpose statement often describes what a pilot showed, not what the system will do once it is deployed. Teams write it for a sponsor review and then never revisit it when users, data sources or scope change. Under MAP 1.1, the purpose should state the task, the minimum functionality needed and the benefits expected. Closing action: set a named owner and a review trigger, such as a change in users, data or deployment setting, so the purpose statement is re-approved before the scope moves.

Limitations left out

Documents tend to describe what the system does well and omit where it fails, such as input types it was not tested on, populations it was not validated for, or outputs that require human review. MAP 1.1 asks for assumptions and limitations to be understood and recorded, and these omissions are what downstream teams most often miss. Closing action: require a limitations section that lists each known failure condition and the control that addresses it, reviewed by the team that will operate the system.

Affected groups not named

Purpose statements usually name the intended user but not the people the output affects, such as applicants, patients, employees being evaluated or members of the public. MAP 1.1 asks teams to consider users' expectations and the positive and negative impacts on them. Closing action: list every affected group in the document, state how each one is affected, and record who was consulted on that list before deployment.

No link to non-AI alternatives

Many purpose documents assume an AI system is the right answer and never record what a rules-based process, a human workflow or an existing tool would achieve. The Playbook suggests considering non-AI alternatives as part of defining the context of use. Without that comparison, a go or no-go decision later has no baseline. Closing action: add a short comparison table of the AI option against at least one non-AI option, covering cost, error impact and oversight effort, and file it with the purpose statement.

Human oversight roles undefined

The purpose may say that a person reviews outputs without naming who that person is, what authority they hold or what training they need. An assessor will ask whether the oversight described can actually happen in the stated operating environment. Closing action: document each oversight role, its decision rights and its operator proficiency requirements, and confirm the staffing exists in the deployment setting.

Documentation kept outside version control

Purpose and context documents often live in slide decks or shared drives where changes are not recorded. When an auditor or a regulator asks what the stated purpose was at a given date, the team cannot show it. A wiki or documentation platform with page history answers that question directly. Closing action: keep the context document in a system that records each change, who made it and when, and that allows comparison and rollback between versions.

Which self-hosted tools can hold MAP 1.1 evidence

MAP 1.1 asks for documented intended purposes, deployment settings, users, assumptions and limitations, so the evidence is mostly written records that change over time. XWiki is a practical place to hold them because every change to a page is kept under version control, recording what changed, when and by whom. Assessors and internal reviewers can compare any two versions and roll back to an earlier one, which shows when a context statement was first written, who revised it, and whether a limitation was quietly removed. Confirm with your own environment that the XWiki version you run keeps this history for the spaces where context records live, and that page deletion and history retention settings do not prune it before your review cycle ends.

Access to those records matters as much as their history. BookStack assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. This lets a team keep the intended-purpose and context-of-use pages editable by the system owner and the AI actors who define the task, while giving risk, legal and privacy reviewers read or approval rights. Map the MAP 1.2 team and the human oversight roles that MAP 1.1 calls for onto these roles, then test the overrides with a non-administrator account, because a permission granted at a higher level can be easy to miss during setup.

Operational tools can test whether the documented context still matches reality. Langfuse (MIT) records traces that capture each operation in a request, including LLM calls, retrieval steps, tool executions, timing, inputs, outputs, token usage and metadata. Reviewing those traces against the stated users and deployment setting shows whether the system is being used for purposes the context document does not cover. For language models, garak (Apache-2.0) probes for hallucination, data leakage, prompt injection, misinformation, toxicity and jailbreaks, and writes a JSONL report of every attempt plus a hit log of successful attempts. Its results can support checks on the limitations you documented, but they only test the probes you run, so you should confirm which probes match your stated limitations. Verify that each license fits your legal review and your environment before adopting any of these tools.

Questions buyers ask about MAP 1.1 before hiring help

How much effort does MAP 1.1 take to complete?

The effort depends on how many AI systems are in scope, how many user groups and deployment settings each one has, and how much of the context already exists in product specs, risk registers and legal reviews. MAP 1.1 is a documentation and analysis outcome, not a single test, so the work is mostly interviews, reviews and writing. Effort rises when a system has several intended purposes, serves regulated users, or relies on third-party models whose documentation is thin. Ask any provider to break the work into discovery, drafting, review and upkeep, and to state who in your organization must attend each step.

How long does a first MAP 1.1 context record take?

The duration depends on scope, and no single figure applies across organizations. The main drivers are the number of AI systems, the number of stakeholders who must confirm intended use and limitations, and whether the organization already keeps an AI inventory. A single system with a clear owner and existing product documentation moves much faster than a portfolio spread across several business units. Ask for a timeline tied to a written scope with named milestones, including the review points where product, legal and risk owners sign off.

Can an in-house team complete MAP 1.1 without outside help?

Yes, an in-house team can complete MAP 1.1 if it has people who understand the system's technical design, the business purpose and the affected users, and if someone owns the record. The framework is voluntary, so no certificate depends on who writes the document. Outside help tends to add value when internal teams lack a neutral facilitator, when the system spans several departments, or when the context must be documented in a format that engineers, auditors and customers can each use. Whichever route you choose, the organization keeps ownership of the intended purpose and limitations.

What does MAP 1.1 need from product and legal teams?

Product teams supply the task definition, minimum functionality, expected benefits, user groups and the operational environment where the system will run. Legal and compliance teams identify the context-specific laws, contractual terms and sector norms that apply, and they flag uses that may be prohibited or restricted. Both groups should review any listed foreseeable misuse, since MAP 1.1 asks the organization to record uses that fall outside its risk tolerances. Plan calendar time for these reviews, because they are often the slowest part of the work.

Can a partner sign off on MAP 1.1 for our organization?

A partner can prepare the context record, facilitate workshops and check it for gaps, but it cannot approve it on your behalf or issue any assessment result. Sign-off belongs to the accountable owner inside your organization, and the record should name who approved it and when. NIST does not certify or validate any organization's use of the AI RMF, so no partner can provide that status. If a customer or regulator asks for independent evidence, that request goes to an independent assessor, and the partner's role is to make the evidence ready for that review.

How often must the MAP 1.1 record be revisited?

Revisit the record whenever the intended purpose, user population, deployment setting or known limitations change, and at a scheduled review interval your governance policy sets. Changes to the underlying model, a new third-party component or a new jurisdiction can each change the context of use. The NIST AI RMF Playbook is also being revised, so teams should check the current guidance before each review cycle. Ask any provider how it will version the record, track changes and keep a log of who reviewed each update.

What should a quote for MAP 1.1 help include?

A quote should list the systems in scope, the stakeholder groups to be interviewed, the documents the provider will review, and the deliverables, such as the context record, the list of assumptions and limitations, and the review checklist. It should separate one-time drafting work from recurring review support. Ask which tasks the organization must perform itself, such as approving the record or supplying legal input, and how changes after delivery are priced. Fixed-scope quotes give the clearest basis for comparing providers.

How DeployOpen prepares MAP 1.1 evidence for your team

DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside your own infrastructure. For MAP 1.1, we prepare the systems and written records that show an AI system's intended purpose, context of use, users, limitations and foreseeable impacts, while your organization owns the decisions and an independent assessor reviews the outcome.

How we scope

We agree the AI system, its intended purpose and the deployment settings in writing before work starts.
The written scope lists which user groups, operational environments and affected parties the MAP 1.1 records will cover.
Engagements are fixed-scope, and ongoing support for updated context records is available as a retainer.

How we build

We set up a version-controlled documentation space where the purpose statement, context of use and assumptions live.
We configure role-based access so product, risk, legal and oversight owners can each edit and review their sections.
We document foreseeable misuse and limitations, then test the stated limits with tooling such as garak where relevant.

How we hand over

You receive the context of use document, limitation register and a record of who reviewed each section and when.
Each record is mapped to the MAP 1.1 suggested actions in the NIST AI RMF Playbook so reviewers can trace coverage.
We walk your team through the records so they can maintain them after handover without our involvement.

How we support

We help your team revisit context records when the system, its users or its deployment setting changes.
Retainer support can cover updates for the revised NIST AI RMF or a generative AI profile, once your scope requires it.
Your organization decides whether to engage an independent auditor or assessor to review the evidence we prepared.