What MAP 1.3 asks for in the NIST AI RMF
A customer, board member or regulator asks how the purpose of your AI system fits your organization's mission. MAP 1.3 is the NIST AI RMF outcome that answers that question on paper. It sits in MAP 1 (context) of the Map function in NIST AI 100-1, and it asks that the organization's mission and its relevant goals for the AI technology are understood and documented. The framework is voluntary and has no certification, so no body will issue a MAP 1.3 pass. Your evidence is the documented purpose itself and the reasoning behind it, which an independent assessor or customer can then test.
The hard part is writing purpose down in a form that can be challenged. A statement such as improve efficiency tells a reviewer little. The Playbook suggests reviewing the documented system purpose from a socio-technical perspective, checking for misalignment between societal values and the organization's stated principles and codes of ethics, and flagging latent incentives that may contribute to negative impacts. In practice, that means someone outside the product team should be able to read the purpose, the intended beneficiaries and the metric the team is rewarded for, and see whether they point the same way. Confirm which internal principles or codes of ethics apply before the review starts, because the check is only as good as the reference documents.
The risk this outcome addresses is a system built to hit a goal that conflicts with the organization's values, or one whose incentives reward outcomes that harm people. Examples include a screening tool optimized for throughput at the expense of fair treatment, or a content system rewarded for engagement that the organization has publicly committed to avoid. The Playbook notes that a clear business purpose, read against societal values, makes go or no-go decisions easier, and that risk avoidance is a valid answer when risks outweigh benefits. Record who signed off on the purpose, the date, and any decision to narrow or stop the system, so the record can be audited later. Your documentation platform, such as a version-controlled wiki, should keep that history.
Which AI systems, teams and third parties MAP 1.3 covers
Before a team can document a mission and goals for AI, it has to decide which systems, owners and suppliers fall inside the exercise. Each decision below changes how much work MAP 1.3 becomes and how defensible the resulting documentation is.
New builds versus purchased tools
Decide whether a mission link is required for AI systems you are building, for tools you are buying, or for both. Built systems usually need a full statement of purpose, intended users and the business problem they solve. Purchased tools still need a documented reason for adoption, even though the vendor wrote the model. A narrow scope that covers only internal builds leaves embedded vendor features outside the record, which is where many unexamined purposes sit. Confirm with procurement which SaaS features use AI before you draw the line.
Re-evaluated existing systems
Decide whether systems already in production must be re-examined against the current mission and goals, or only documented when they change. A broad answer means every live system gets a mission check, which surfaces purposes that drifted after launch. A narrow answer limits the review to systems with material changes, which is faster but can miss a model that now serves a use nobody approved. Ask for a dated inventory of existing systems and their last purpose review.
Ownership of the mission statement
Decide who signs the organization's AI mission statement and the goals beneath it. Executive ownership gives the goals authority over funding and go or no-go calls. Ownership sitting only with a technical team tends to produce goals written around the system rather than the organization's stated principles. Name one accountable owner, record who reviews the statement, and state how changes reach the teams building AI systems.
Vendor-supplied AI and third-party models
Decide how far the mission record extends into vendor-supplied AI, including foundation models, hosted APIs and AI features inside platforms. A broad scope requires the organization to document why each vendor system serves its goals and what the vendor's stated purpose does not cover. A narrow scope relies on contract language alone. Request the vendor's intended use statement and any restrictions, then compare them with your own purpose and principles.
Alignment with risk tiers
Decide how the depth of the mission review follows the risk tier assigned to each system. High-impact systems warrant a detailed check of purpose against societal values and stated principles, including latent incentives that could drive harm. Low-impact tools may need a short justification and a periodic confirmation. Tie the tiers to the risk tolerances your organization sets under MAP 1.5 so that the review depth is consistent and can be explained to an assessor.
Scope of the principles check
Decide which organizational principles and codes of ethics the purpose must be tested against. A broad list might include legal obligations, sector codes, customer commitments and internal values. A narrow list covers only a published AI policy. The NIST AI RMF Playbook suggests looking for misalignment between societal values and stated principles, so the list you choose defines what a misalignment looks like. Write the list down and version it, so a later reviewer can see which principles were in force when the decision was made.
How an assessor tests MAP 1.3
This table sets out how an assessor would test MAP 1.3, the test step, the evidence requested and the findings that usually come up. Read each row as a question the assessor asks and the record the organization should be ready to show. NIST AI RMF is voluntary and has no certificate, so any review of this outcome is an internal or customer-driven assessment unless a contract or regulator says otherwise.
| Test step | What the assessor does | Evidence requested | Common finding |
|---|---|---|---|
| Leadership interviews | Asks executives and the system owner why the system exists, which goals it serves and who decided them | Named owner, interview notes or a sign-off record showing the stated mission and goals | Leaders describe benefits differently from the written record |
| Purpose statement review | Reads the documented purpose statement and checks it covers the mission, goals and intended users | Dated purpose statement with version history and the approver's name | Purpose written only in technical terms, such as model type or data sources, with no business or societal goal |
| Goal record review | Checks each goal is written down, measurable where possible and linked to the system | Goal documents with owners, approval dates and links to the AI inventory entry | Goals exist only in slide decks or emails and were never approved |
| Principles traceability | Traces the purpose and goals to the organization's published principles and code of ethics | Mapping table showing which principle each goal addresses and where conflicts were discussed | Published principles never appear in the system record |
| Societal values check | Looks for evidence the team tested the purpose against societal values and asked whether misalignment exists | Review notes that record questions asked, affected groups considered and outcomes | Review is absent, or it repeats the business case without testing it |
| Latent incentive review | Checks whether incentives that could drive negative impacts were identified and recorded | Risk log entries or meeting minutes naming incentives and the response chosen | No incentive analysis exists, so pressure to deploy is never documented |
| Change control | Compares the current goals with earlier versions and checks each change was reviewed and approved | Version history, change tickets and review minutes for every revision of purpose or goals | Goals changed in practice without a record, so the deployed system no longer matches the documented purpose |
| Go or no-go linkage | Confirms the documented purpose informed the deployment decision and any decision to accept or avoid risk | Deployment approval record that references the purpose statement and goals | Approval cites a project plan but not the purpose or goals it was meant to serve |
Steps to document mission and goals for each AI system
This sequence gives each AI system a short, dated record of why the organization is building or buying it, what goals it serves, who it affects, and whether leadership has decided to proceed, so an assessor can trace the decision back to stated mission and values.
Confirm the organization's mission and published AI principles
Start by collecting the current mission statement, board-approved AI principles, code of ethics and any published responsible AI commitments. The system owner and the governance lead compare these documents and note which ones apply to the system in scope. Record the document names, version numbers and approval dates in a short reference table. The step is complete when every later statement about purpose can point to a specific, approved source that an assessor can open and read.
Write a purpose statement for the system
The system owner writes a plain-language purpose statement that names the task the AI system performs, the decision or process it supports, and the setting where it runs. Keep it short enough that a non-specialist can explain the system after reading it. Store the statement with the system's entry in the AI inventory and link it to the intended purpose and context of use record. The step is complete when the statement has been reviewed by the governance lead and approved in the documentation system, with the reviewer and date visible in the version history.
Record the goals and affected people
List the business or operational goals the system is meant to serve, and for each goal, name the groups of people who will be affected by it, including employees, customers, applicants, patients or members of the public, depending on the setting. Note which goals are measurable and which are qualitative, and state what success would look like for each. Keep the list in the same record as the purpose statement. The step is complete when each goal has a named owner and each affected group is identified, so that later measurement work has a clear reference point.
Review the purpose against societal values and codes of ethics
A small review group that includes people beyond the development team reads the purpose statement and goals against the societal values and organizational principles recorded in the first step. Reviewers look for places where the system's purpose conflicts with stated principles or codes of ethics, or where affected groups could be harmed even when the goal is met. Record each finding, the reasoning and any change to the purpose statement or goals. The step is complete when the review record lists the reviewers, the date, the principles checked and the outcome of each finding.
Flag latent incentives that could drive harm
The review group asks what incentives sit behind the system, such as cost targets, speed metrics, engagement goals or pressure to automate a decision, and whether those incentives could push the system toward negative impacts. The group records each incentive, the harm it could contribute to and the safeguard or design change that addresses it. Where an incentive cannot be removed, the record states who accepts that residual concern. The step is complete when each flagged incentive has an entry in the risk register or the MAP record, with an owner assigned.
Record the go, no-go or risk avoidance decision
Leadership with authority over AI risk reviews the purpose, goals, review findings and flagged incentives, then records one of three outcomes: proceed, do not proceed, or avoid the risk by changing or dropping the system because its risks outweigh its benefits. The decision record names the accountable executive, states the reasons, lists any conditions attached to proceeding and sets a date for the next review. The step is complete when the signed or approved decision record is stored with the system's documentation, and the assessor can trace it back to the purpose statement and review findings.
What evidence shows MAP 1.3 is met
MAP 1.3 is met when the organization can show its mission and AI goals in writing, tested against its own stated values. The six artifacts below form one record: each one feeds the next, and each needs a named owner and a review trigger so it stays current between assessments.
Dated mission and goals record
A dated record for each AI system that states the organization's mission and the specific goals it holds for that system. Assessors look for the date, the approver and the system version it describes. Check that the record names the business function that owns the goal and that it is updated when the system's scope changes, not only at annual review.
Purpose statement linked to principles
A written purpose statement for the system with explicit links to the organization's published AI principles and code of ethics. Reviewers check that each principle cited in the purpose statement maps to a stated design or deployment choice. A purpose statement that cites principles without tying them to the system is weak evidence.
Societal values review with findings
A documented review of the system's purpose from a socio-technical perspective, looking for misalignment between societal values and the organization's stated principles. The record should list each finding, who reviewed it, the disposition chosen and the open items. A review with no findings for a high-impact system invites questions about how the review was run.
Latent incentive check log
A log of checks for latent incentives that could push the system toward negative impacts, such as usage targets that reward volume over accuracy or cost savings that shift errors onto affected users. Each entry names the incentive, the evidence reviewed and the mitigation. Refresh the log when success metrics or staffing incentives change.
Go, no-go or avoidance decision record
A decision record that shows whether the system was approved for deployment, rejected or retired through risk avoidance, with the trade-off reasoning tied to its business purpose. The Playbook notes that defining the business purpose in the context of societal values makes these decisions clearer. Record the approver, the date and the conditions attached to any go decision.
Change history of the statement
A version history showing how the mission statement, goals and purpose text changed over time, including who changed them, when and why. Keep the history for the life of the system, not only the current version. Auditors compare versions to confirm that changes after an incident or a scope expansion were reviewed rather than silently edited.
What meeting MAP 1.3 costs in money and effort
This table breaks down the cost of documenting AI mission and goals under MAP 1.3 into its components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to scope internal effort and to build the questions you put to any outside help. No prices are shown because none are supplied for this outcome; the drivers and quote questions are what matter.
| Cost component | One-time or recurring, who is paid | What drives it up or down |
|---|---|---|
| Staff time to write purpose and goals | One-time per system, paid from internal product, legal, ethics and business budgets | Up with the number of systems and public exposure; down with a reusable template covering purpose, goals and societal values |
| Review by ethics, legal and business leaders | Recurring at each approval gate, internal staff or outside counsel | Up with regulated use and cross-border deployment; down when review criteria are written once and reused |
| Documentation system | Licence spend or none; self-hosted open-source wikis carry hosting and admin time instead | Up with fragmented storage across tools; down with a single documentation home and defined page ownership |
| Recurring review tied to system change | Recurring, internal staff, triggered by model, data, user or purpose changes | Up with frequent model updates and new use cases; down with clear change triggers written into the AI change process |
| Societal values and misalignment analysis | One-time, plus recurring refresh, internal staff or an external reviewer | Up with high public impact; down when internal reviewers handle routine systems and external review is reserved for high-impact ones |
| External independent review (optional) | Per engagement, paid to an outside reviewer, scoped in writing | Up with scope breadth and number of systems; ask for named deliverables and a fixed review boundary |
| Auditor or assessor sampling time | Recurring when an assessment occurs, paid to the independent auditor | Up when records are scattered or missing dates and owners; down when purpose statements are versioned and easy to sample |
How self-hosted open-source wikis keep MAP 1.3 records current
MAP 1.3 expects the organization's mission and AI goals to be understood and documented, which only holds if the record is kept current and traceable. The two wikis below cover different parts of that job: one keeps the history of every change, the other controls who can change what.
Version history for purpose statements
XWiki keeps every change to a page under version control, recording what changed, when and by whom. For a MAP 1.3 record, this means a revised statement of AI purpose can be compared against the version that was approved last quarter, and an earlier wording can be restored if a change turns out to be wrong. Confirm whether your team needs a formal approval step before a change goes live, since version control records edits but does not by itself decide who signs off.
Role-based access to goal records
BookStack takes each user's abilities from the roles assigned to them, and permissions can be overridden at the shelf, book, chapter or page level. A practical pattern is to let the wider organization read the mission and AI goals while limiting edit rights on the page that records business purpose to the accountable owners. Confirm that your role design matches the people named in your AI governance records, and review overrides when staff change roles.
Traceable links to review decisions
Purpose statements matter most when they link to the go or no-go decisions made against them. Use one page per AI system that states its intended purpose and goals, and cross-reference it from the risk and deployment decision pages. Check that each cross-reference still resolves after a page is moved or renamed, because a broken link breaks the trail an assessor follows from mission to decision.
Export and retention of records
Keeping a wiki current does not mean keeping it forever. Decide how long superseded versions of purpose and goal records must be retained, and whether they must be exported to a separate evidence store that the wiki administrators cannot alter. Confirm the export formats and backup schedule in your own environment, and test a restore before relying on the wiki as the system of record for MAP 1.3 evidence.
Review cadence for societal alignment
MAP 1.3 asks teams to check the stated purpose against societal values and organizational principles, which is a periodic judgment, not a one-time edit. Set a review date on each purpose page and assign an owner who records the outcome of the review, including any decision to change scope or to avoid a use case altogether. The wiki supplies the history; the review record supplies the reasoning.
Who writes, who reviews and who audits MAP 1.3
The organization owns MAP 1.3 in full. Its leaders decide the mission and the goals it sets for AI technology, and no outside party can supply them. The product owner writes the system's purpose statement in operational terms, and ethics or risk staff then check that the stated purpose lines up with societal values and the organization's published principles. This is the group that flags latent incentives, such as a metric that rewards behavior the mission does not endorse. Their work is ongoing, not a one-time sign-off.
- Leadership: approves the mission and AI goals and records who signed them and when.
- Product owner: drafts the system purpose statement, intended use and the business context it serves.
- Ethics or risk staff: reviews the purpose against societal values, codes of ethics and internal AI principles, and records misalignments.
- Records owner: keeps version history so every change to the mission or purpose text can be traced.
- Decision owner: decides whether a misalignment is resolved, accepted or leads to no-go.
Confirm that a named executive owns the mission statement and that review dates are set on the calendar, not left to ad hoc requests.
An implementation partner such as DeployOpen prepares the scaffolding around MAP 1.3. It can set up the documentation structure, write templates for the purpose statement and goal records, define the review workflow with named reviewers and approval steps, and assemble the evidence set an assessor will ask for. It works inside the client's own wiki or document system. It does not decide what the organization's mission is, and it does not write the values judgment that the organization must own.
- Documentation structure: page hierarchy, required fields and naming for mission, goal and purpose records.
- Templates: a purpose statement form that prompts for societal values, principles and latent incentive review.
- Review workflow: routing, reviewer roles and approval gates recorded in the system.
- Evidence set: a defined list of artifacts, such as signed approvals, review notes and version history, mapped to the MAP 1.3 outcome.
- Handover: training for the client's staff on keeping records current after the engagement ends.
Confirm in the written scope exactly which templates and workflows are delivered and that the partner's role excludes drafting the mission or signing approvals.
An independent auditor, assessor or certification body tests the record and the decisions behind it. It samples purpose statements, checks whether reviews happened with the right people, and asks how misalignments were resolved. The assessor must be separate from the people who wrote the material it tests. If the same consultant drafts the purpose statement and then assesses it, the independence of the assessment is lost. NIST does not validate or endorse any organization's approach to the AI RMF, and no AI RMF certificate exists, so any outside report must come from a party the organization has engaged for a defined purpose.
- Record testing: checks that mission and purpose documents exist, are dated and carry approvals.
- Decision testing: reviews how values misalignments were weighed and whether go or no-go outcomes followed from them.
- Version testing: compares historical versions to confirm changes were authorized.
- Interview testing: asks product, ethics and leadership staff to explain the purpose in their own words.
- Scope limits: states clearly what was tested and what was not, and does not rewrite the organization's mission.
Confirm the assessor's engagement letter defines the testing scope, the sample and the report recipients before fieldwork begins.
Where MAP 1.3 records usually fall short
MAP 1.3 is easy to claim and hard to evidence. The gaps below recur across AI programs, and each one leaves a reviewer unable to tell what the system is for, who decided it, or whether the purpose still holds. Read them as a checklist for your current records.
Purpose written only in engineering terms
The system record states what the model does (classifies tickets, ranks applicants, drafts summaries) but never states the business mission it serves or the outcome people expect. An assessor cannot test whether the system's purpose matches a stated goal if the goal is missing. Fix: add one paragraph that links the system to a named organizational mission and a measurable goal, and have the business owner sign it.
Goals that ignore published principles
Mission statements exist, and so do AI principles or codes of ethics, but the goals for a specific system never cite them. MAP 1.3 expects the team to check the system's purpose against societal values and stated organizational principles, and that check leaves no trace when the goals are written in isolation. Fix: map each goal to the principle it serves, and record any principle the system does not support.
No record of latent incentive review
Teams document benefits but rarely write down the incentives that could push the system toward harm, such as throughput targets that reward automated denials or engagement metrics that reward manipulative outputs. The Playbook suggests flagging these latent incentives from a socio-technical view. Fix: keep a short incentive review section with the incentives identified, who reviewed them and the disposition of each.
Go or no-go decisions made informally
The purpose was agreed in a meeting or a chat thread, and nobody recorded who had authority to approve deployment or to stop it. When the system drifts from its purpose, no one can say who should act. Fix: name a single accountable owner for the purpose statement and record the approval date, the approver and any conditions attached to deployment.
Documents updated without version history
The purpose statement was edited in place, so earlier wording and the reasons for changes are lost. Auditors and incident reviewers need to see what the stated goal was at the time a decision was made. Fix: keep purpose records in a system that tracks every change with its author and date, and retain prior versions for review. XWiki, for example, keeps page revisions that can be compared and restored.
Vendor AI without a stated mission link
The organization buys a third-party AI feature and adopts its vendor-written purpose without relating it to its own mission, goals or principles. The vendor's stated use may not match the organization's context. Fix: write an internal purpose statement for each purchased AI system, check it against the vendor's documented intended use, and record where the two differ.
Questions buyers ask about MAP 1.3 cost, time and effort
How much effort does MAP 1.3 take for one AI system?
The effort depends on how many people must agree on the system's purpose, how many stakeholders and societal concerns sit around it, and how much documentation already exists. MAP 1.3 is a documentation and review outcome, so the work is mostly discussion, record writing and sign-off rather than engineering. A system with a narrow internal use, a clear sponsor and existing product documentation needs far less than a system that affects customers, employees or regulated decisions. Ask any provider to break its estimate into the review sessions, the stakeholders involved and the records it will produce, so you can see which of those drivers it has assumed.
Can we do MAP 1.3 in-house without outside help?
Yes. NIST AI RMF is voluntary and no outside party is required to carry out MAP 1.3. Most organizations can do the work in-house if they have an owner for the AI system, a person who can challenge the stated purpose against their own values and principles, and a place to store the record. Outside help is most useful when internal teams lack experience with socio-technical review, when the purpose is contested across business units, or when the record must be prepared quickly for a customer or regulator. An implementation partner can prepare the template, run the review and organize the evidence, but the organization keeps ownership of the purpose statement and the decisions it records.
What does MAP 1.3 need from leaders and product staff?
Leaders need to state the organization's mission and its goals for the AI technology in terms that can be written down and tested. Product staff need to describe what the system does, who uses it, what it is meant to replace or improve and where its outputs go. Both groups must be willing to examine the stated purpose for misalignment with societal values and the organization's own principles and codes of ethics. Practically, expect a sponsor to approve the final statement, a product owner to supply facts, and a reviewer outside the delivery team to question assumptions. Leaders should also decide in advance what happens if the review finds that risks outweigh benefits, since the Playbook treats risk avoidance as a valid response.
How long does a first MAP 1.3 record take, and how often is it reviewed?
No researched figure supports a fixed duration, so confirm the timeline with your team and any provider before work starts. The first record usually takes longer than later ones because the organization must agree on the mission and goals for AI, not just describe a system. Review frequency is also a decision for the organization. It should be revisited when the system's purpose changes, when its context of use or user population changes, when new risks appear or when the organization's principles are updated. Ask who triggers each review and where the previous versions are kept so that changes to the purpose can be traced over time.
Will an auditor certify our MAP 1.3 work?
No. The NIST AI RMF has no certification, accreditation or conformity assessment program, and NIST does not validate or endorse any organization's use of the framework. No independent auditor issues a MAP 1.3 certificate. A buyer or regulator may still ask for evidence that the purpose was documented and reviewed, so the practical question is what documents you can show, not whether a certificate exists. If a customer asks for an external attestation, clarify whether they want an assessment against a different framework, such as ISO/IEC 42001, which does have a certification route, or a written statement of your own practice.
What should we ask an implementation partner to put in a written scope?
Ask for a written scope before any work starts that names the AI systems covered, the stakeholders who will take part in review, and the records to be produced. Confirm the deliverables in writing, such as the purpose statement template, the review notes, the documented alignment with organizational principles and the version history. Ask which tasks the partner performs and which remain with your staff, and who signs off each record. Request a clear statement of what the partner will not do, including that it does not issue audit reports or certifications. Finally, ask how changes to scope are priced and approved, and what support is included after the first record is complete.
How DeployOpen prepares MAP 1.3 evidence
DeployOpen helps organizations build the working records behind MAP 1.3, from a documented mission and AI goals to a purpose review against stated principles. The organization owns the mission, the goals and the decisions, and DeployOpen prepares the systems, documentation workflows and evidence that show them. Assessors and auditors are the only parties who issue reports or certificates.
How we scope
- Agree in writing which AI systems, business units and documents fall under the MAP 1.3 scope.
- Confirm who in the organization owns the mission statement, AI goals and principle reviews.
- Set deliverables, timelines and acceptance criteria before any work starts, since most engagements are fixed-scope.
How we build
- Set up a versioned documentation space where mission, AI goals and system purpose statements are recorded.
- Configure roles and permissions so approvers can sign off purpose statements while other teams can only read them.
- Build a review template that compares each documented system purpose against stated organizational principles and codes of ethics.
How we hand over
- Deliver the purpose records, review templates and change history in the client's own infrastructure.
- Walk the owning team through how to record latent incentives and misalignments, and where each record is kept.
- Document the go or no-go decisions and any risk avoidance choices so reviewers can trace them later.
How we support
- Offer ongoing support and periodic reviews as a retainer when purposes or goals change over time.
- Update the documentation workflow when the NIST AI RMF Playbook or related guidance is revised.
- Confirm with your assessor or auditor which evidence formats they expect before the review begins.
