MAP 1.2 context team requirements and evidence

What MAP 1.2 asks for and why teams struggle with it

If you are responsible for an AI system, MAP 1.2 asks you to make sure the people who establish its context come from several disciplines and reflect a range of demographics, domain knowledge and user experience, and that their participation is written down. MAP 1.2 is an outcome in *NIST AI 100-1*, the AI Risk Management Framework, and it carries no certification. No assessor will issue a MAP 1.2 pass or fail. What you will be asked, by a customer, a contract or an internal reviewer, is whether you can show who took part in framing the system and why that group was chosen.

The NIST AI RMF Playbook suggests concrete moves: build an interdisciplinary team, record its composition, and bring in disciplines beyond machine learning engineering, such as law, sociology, psychology, anthropology, public policy and systems design and engineering. Most teams can find engineers and a product owner. The harder part is getting a lawyer, a domain practitioner and someone who understands the affected users into the same context discussions, and keeping a record of what each contributed. Teams usually struggle with documentation and breadth of disciplines far more than with headcount. A group of six people from the same department can fail this outcome, while a smaller group that covers the right disciplines can pass it.

The Generative AI Profile, *NIST AI 600-1*, connects this outcome to harmful bias and homogenization, and to human-AI configuration. For generative AI, the same logic extends to the data, benchmarks and public feedback exercises used to measure risk: they should reflect the population the system will actually serve. Before you finalize your team, confirm which disciplines your use case needs, who represents the in-context users, and where each person's input will be recorded. Those three answers form the core of the evidence file an assessor or customer will want to see.

Which AI systems, teams and third parties does MAP 1.2 cover?

NIST lets each organization choose which categories and subcategories it applies, so the scope of MAP 1.2 is a documented decision rather than a fixed list. The cards below cover the decisions that most often determine who sits on the context team, which AI systems the team reviews, and how vendor and generative AI work changes the job.

Which AI systems need a context team

Start with an inventory of AI systems in use or planned, then decide which ones get a documented context team. A reasonable approach is to set the threshold by impact on people, such as systems that affect hiring, lending, care decisions or access to services. Record the criteria in your AI policy so an assessor can see why a system was in or out. Systems that fall below the threshold still need a stated reason for being excluded.

Internal disciplines that count

MAP 1.2 expects interdisciplinary participation, so the team should include more than data scientists and engineers. The Playbook points to disciplines such as law, sociology, psychology, anthropology, public policy, and systems design and engineering. For each system, name the discipline that covers each perspective, and record who attended the context sessions. A team with no legal, privacy or domain expert usually has a gap that an assessor will notice.

User and affected-community representatives

Diverse context requires input from the people the system is used on or used by, not only staff who build it. Decide how you will involve operators, end users and, where relevant, affected groups, and document how their input shaped the context. Select representatives whose experience differs from the core team's, and record the selection method. Confirm with your legal team whether any participation rules apply to your sector or region before you recruit.

Vendor and third-party AI actors

When a vendor supplies the model, data or platform, decide whether the vendor's staff join your context team, whether you rely on their published documentation, or both. Document which vendor claims you accepted and which you tested yourself. Ask vendors for the information they hold about training data, intended uses and known limits, and note where they will not share it. This decision links to the GOVERN 6 supply chain work and to MAP 4 component risks.

Generative AI deployments under the profile

The Generative AI Profile (NIST AI 600-1) lists two suggested actions for MAP 1.2. The second asks that data or benchmarks used in risk measurement, and participants in structured public feedback exercises, represent the diverse in-context user population. For a generative system, this means your context team must also review who will prompt the system and who reviews its output. Check that your feedback panels reflect the users in your deployment context, not only the people who tested the model in development.

Documenting scope and team changes

Scope is a decision you own, so record it in a form that survives staff turnover and audit requests. Keep a roster of context team members, their disciplines, the systems they covered and the dates they joined or left. Note any system that was reviewed by a smaller team and why. When a system changes purpose or user population, reassess whether the team still matches the context. Have the owner of AI governance approve the scope record.

How to build and document a context team in six steps

This sequence turns the MAP 1.2 outcome into a working roster, a diversity gap assessment, a participation log and a review cycle, so you can show who established context for each AI system and why that group was chosen.

Identify the AI actors who establish context
Start by listing the AI actors whose competencies, skills and capacities shape how the system's context is set. NIST AI 100-1 Appendix A describes the actor categories, so use those as a checklist rather than inventing your own labels. Include people who build, deploy, operate and oversee the system, plus those who represent its users. The output is a named candidate list for each AI system in scope, with the actor category recorded beside each name. The step is done when every actor category relevant to the system has either a named person or a documented reason for its absence.
Map the disciplines the team must cover
Compare the candidate list against the disciplines the Playbook suggests for MAP 1.2, including law, sociology, psychology, anthropology, public policy and systems design and engineering, alongside the engineering, data science and domain operations already in the room. Add affected user groups as a discipline in their own right. Mark each discipline as covered, partly covered or missing. The output is a discipline matrix for the system, showing which expertise is present and which must be sourced from inside or outside the organization. The step is done when every discipline has a status and every gap has an owner.
Assess gaps in demographic and experience diversity
Review the roster against the outcome that the context team reflects demographic diversity and broad domain and user experience. Ask whether the people involved have experience with the deployment setting, the population the system will affect, and the work the system will change. Where the team cannot be fully diverse within the organization, record how you will reach the missing perspectives, such as structured input from user representatives. Keep this assessment factual and role-based, and check it against the organization's own legal obligations on employee data before recording any personal characteristics. The output is a short gap assessment with agreed remedies. The step is done when each gap has a remedy or a recorded decision to accept the gap.
Record the roster and roles
Write the context team roster for each AI system: name or role, organization, actor category, disciplines covered, decision rights during context-setting, and the date the person joined the team. Define the lines of communication so it is clear who signs off on the intended purpose and who can escalate a concern. This record is the primary evidence for MAP 1.2 because it shows the team was assembled deliberately. The output is a version-controlled roster document stored with the system's AI inventory entry. The step is done when an assessor could trace each participant to a named role and a documented discipline.
Set a participation log for review sessions
Create a log that records each context-setting or review session: date, purpose, attendees by role, disciplines present, decisions taken, and any absent actors with the reason. Record dissent and open questions, not only agreed outcomes, because MAP 1.2 expects documented participation and the log shows whether the interdisciplinary input changed anything. For generative AI systems, also note any structured public feedback exercises and the user populations they reached. The output is a session log linked to the roster. The step is done when a sample session can be reconstructed from the log alone.
Schedule a periodic review of team composition
Set a review cycle for the roster and gap assessment, and trigger an earlier review when the system's use, deployment setting or user population changes. NIST AI 100-1 does not prescribe a fixed interval in the facts supplied for this topic, so confirm your review frequency against your own governance policy and any sector rules that apply. At each review, confirm that departed members are replaced, new disciplines are covered and the participation log is current. The output is a dated review record that ties back to the roster and the AI inventory. The step is done when the next review date and its trigger conditions are recorded and assigned to a named owner.

How an assessor tests the context team

This table compares what an assessor does, what evidence they request and where teams usually fall short when testing MAP 1.2. Read it as a guide to preparing your own records, since the assessor reviews your documentation and NIST does not certify or validate the approach.

Test area	What the assessor does	Evidence requested	Common findings
Interviews with the team lead	Asks how the context team was formed, who decided its membership and how disagreements about context were settled	Named team lead, charter or kickoff notes, description of the selection process	Team lead cannot explain how disciplines were chosen or who was consulted
Roster review against system context	Compares listed members with the disciplines, user groups and deployment settings named in the system context	Current roster with roles, disciplines and organizational units, plus the system context document	Roster names only AI engineers or data scientists, with no legal, domain, or user representation
Coverage of user groups	Checks whether the people named reflect the in-context user population, including affected groups	User population description, representation notes, records of who was consulted	No documented user or affected-community representation for the deployment setting
Sampling of meeting records	Selects several context-setting sessions and checks who attended and what they contributed	Meeting minutes, attendance logs, decision records, sign-offs by each contributor	Attendance not recorded, or sessions held without the disciplines named in the roster
Sign-off and approval trail	Confirms that participants reviewed and approved the context documentation	Dated approvals, version history of the context document, reviewer names and roles	Approvals missing, undated or given only by the project owner
Changes to the team over time	Looks for updates to the roster when the system, use or deployment setting changed	Change log for roster, rationale for additions and removals, dates of reviews	Roster frozen since initial design despite a later change in use or user base

Which evidence passes a MAP 1.2 review

MAP 1.2 asks whether the people who establish context for an AI system are interdisciplinary, reflect diverse users and domains, and have their participation recorded. The artifacts below connect those three questions, and each one should be kept current between assessments rather than rebuilt when a reviewer asks.

Dated context team roster

A roster lists each person who took part in establishing context for the system, with their discipline, role in the team and dates of participation. Include disciplines outside AI practice, such as law, sociology, public policy, systems engineering or the domain of the deployment, because the Playbook suggests drawing on them. Update the roster on every personnel change and date each revision, so a reviewer can see who was present at each decision point.

Competency and skills matrix

A matrix maps each team member's competencies, such as domain expertise, legal review, user research or model evaluation, against the context decisions they informed. It shows that the team covers the disciplines the system needs and exposes gaps, such as no one with direct knowledge of the affected user group. Review the matrix when the roster changes and when the system's purpose or deployment setting changes.

Participation logs and minutes

Minutes or logs from context-setting sessions record the date, attendees, the disciplines they represent and the decisions reached. Documented participation is the outcome MAP 1.2 names directly, so a reviewer will look for records showing that non-AI disciplines contributed rather than only attended. Store logs in the same system as the roster and keep them searchable by system name and date.

Sign-off records

Sign-off records show who approved the context definition, with the version of the context document they approved and the date. Approvals from business owners, legal or compliance, and the technical lead together show that the interdisciplinary team reached agreement. When a team member dissents, record the objection and how it was resolved, since an unrecorded disagreement weakens the evidence.

Evidence of user and domain representation

This artifact shows which users, affected groups and domain experts informed the context, and how they were selected. For generative AI, NIST AI 600-1 asks that data, benchmarks or feedback participants represent the in-context user population, so keep records of the sampling approach and gaps. Document where representation is incomplete, because an honest gap statement is easier to defend than an overstated claim.

Review cadence record

A review cadence record shows when the context team last reassessed composition and participation, and what triggered each review, such as a new user population, a major model change or a staffing change. Set a recurring schedule the organization can keep and log each review even when nothing changed. Ask your assessor which review interval they expect, since the framework does not set one.

What meeting MAP 1.2 costs in money and effort

This table lists the cost components behind a MAP 1.2 context team, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written quote request, since NIST publishes no price or duration for this outcome and the figures depend on your scope.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Context team staff time	Your interdisciplinary staff from AI, law, domain, UX and risk functions	Recurring while systems are in scope	Number of AI systems, and whether one roster covers several of them
Facilitation and documentation	Internal facilitator or an implementation partner preparing the team record	One-time setup, then recurring updates	Number of composition changes and how often the roster is reviewed
Gap analysis of team composition	Internal governance lead or external consultant reviewing who is missing from the team	One-time per system, then recurring	Breadth of disciplines and user groups already represented in existing teams
Recruiting user or domain representatives	Internal HR or business owners, plus any compensation you pay participants	One-time per user group, with recurring refresh	Number of user groups and how hard those groups are to reach
Evidence upkeep	Internal compliance or program staff maintaining rosters, meeting records and participation logs	Recurring	Frequency of audits, staff turnover and how well records are kept in one place
External review	Independent reviewer or consultant checking team composition against the Playbook suggestions	Optional, typically one-time per review cycle	Scope of generative AI use and whether reviewers need domain-specific expertise
Assessor time	Independent auditor or assessor testing your records, if an outside party is engaged	Recurring per assessment cycle	Number of systems sampled and the completeness of your documented participation

Who does what for the context team: your team, a partner and the auditor

Your organization owns the MAP 1.2 outcome. The framework expects the AI actors who establish context to be interdisciplinary, to reflect demographic diversity and a broad range of domain and user experience, and to have their participation documented. Only your leadership can decide who those people are, because they depend on the system, its users and your risk appetite. Your team also decides whether affected users or their representatives take part in establishing context, and it signs off on the final roster and any changes to it.

Roster decisions: Name the people who establish context, their roles and the disciplines they bring, such as law, risk, operations, engineering and frontline users.
Affected user decision: Record whether users or community representatives are included, and if not, why.
Diversity and gaps: Decide how you will judge whether the team reflects the population the system touches, and what you will do when it does not.
Sign-offs: Assign an accountable owner to approve the roster before context is finalized and to re-approve it when people change.
Participation records: Keep the dated record of who attended which context sessions and what they contributed.

Confirm internally that the people named in the records are the ones who actually did the work, since an assessor will compare the two.

Where context teams usually fall short

Most gaps under MAP 1.2 are not missing intent. They are records that stop matching reality: a roster without disciplines, a team list written after launch, or a team model carried into a generative AI deployment without checking who will actually use it. Each card below pairs a common gap with the check or fix that closes it.

Roster lists names, not disciplines

A roster that gives only names and job titles cannot show whether law, privacy, domain operations, security and affected-user perspectives were present when context was set. For each member, record the discipline, the domain experience and the decisions they shaped. Then check the list against the disciplines the Playbook suggests for MAP 1.2, such as law, sociology, psychology, public policy and systems design. Gaps should appear as open items, not be hidden.

Team documented only after deployment

Teams often write up composition when an audit or customer questionnaire arrives, which makes the record look reconstructed. MAP 1.2 expects the team that establishes context to be identified while context is being set. Capture the composition at the start of the context work, date the entry, and link it to the intended-purpose record so reviewers can see who defined the system's context before it was built.

Affected user groups not represented

Context teams frequently include builders and sponsors but no one who speaks for the people the system will affect, such as applicants, patients, customers or frontline staff. Name the affected groups for each deployment setting, then decide how each one is represented: a seat on the team, a documented consultation, or a feedback channel. Record which option was chosen and why, so the gap is a decision rather than an oversight.

Participation not recorded

Meetings, reviews and sign-offs happen, but attendance and contributions are rarely captured in a form an assessor can test. Keep a participation log that records who attended each context session, who reviewed the outputs and who approved them. Store it with the team roster in the governance system, so a reviewer can trace a decision back to the people who made it.

Roster not updated after staff changes

A roster that was accurate at launch can drift within months as people move teams, leave or change responsibilities. The record then shows experts who no longer work on the system and omits those who now do. Set a review trigger tied to access changes and role changes in the identity system, and require the owner of the AI system to confirm the roster at each scheduled review of the context record.

Generative AI reuses an old team model

A team that set context for a traditional model may be reused for a generative AI deployment serving a different, wider user population. NIST AI 600-1 suggests checking that data, benchmarks and public feedback participants represent the diverse in-context user population. Before reusing a team model, confirm the new user groups, add the disciplines and user perspectives they require, and document the difference from the earlier context record.

What buyers ask about MAP 1.2 before hiring help

How much effort does MAP 1.2 take to put in place?

The effort depends on how many disciplines your AI system touches and how much of the team composition is already documented. MAP 1.2 asks that the people who establish context reflect demographic diversity and broad domain and user experience, and that their participation is recorded. For a single internal tool used by one department, the work may be a short exercise. For a system that affects customers, clinicians, applicants or citizens, it means identifying the legal, domain, user and engineering perspectives that should be present, confirming who holds each one, and writing the roster down. NIST's Playbook lists disciplines such as law, sociology, psychology, public policy and systems engineering as candidates. Ask any provider for a scoped estimate tied to your system and your current documentation, not a generic figure.

Is there an AI RMF certificate for MAP 1.2?

No. There is no AI RMF certificate, and no one can certify that your team meets MAP 1.2. NIST describes the AI RMF as voluntary and does not validate or endorse any organization's use of it. Your organization owns the outcome and the documentation. An implementation partner can help you design the team, prepare the records and organize the evidence. Only an independent assessor, auditor or certification body can issue a report or certificate, and the AI RMF has no such program. If a customer or contract asks for a certificate against the AI RMF, ask them what document or assessment they actually expect.

How long does MAP 1.2 setup usually take, and what drives it?

Setup time is driven by the number of AI actors involved, how many gaps exist in current team records, and how many approvals the roster needs. Three factors matter most. First, the breadth of the system's context of use, since a system affecting many user groups needs more perspectives. Second, whether your organization already has an AI inventory and governance roles defined under the GOVERN functions. Third, how quickly stakeholders in legal, HR, product and operations can review and sign off on the composition. No supplied timeline applies to every organization, so ask a prospective partner to break the timeline into discovery, roster design, documentation and review, with the dependencies for each step named in writing.

What does our team need to provide for the engagement?

Your team needs to supply the facts that define the context and the people who hold it. Expect to provide:

A description of the AI system, its intended purpose and the populations it affects
Your current AI inventory entry or project records, and any existing governance roles
Names and roles for legal, privacy, domain experts, user representatives and engineering owners
Access to decision-makers who can approve the final team composition and its documentation
Any feedback channels or user research already in place, so they can be reflected in the record

Without named decision-makers, the documentation will stall. Confirm these inputs and their owners before any fixed-scope agreement is signed.

Can our organization meet MAP 1.2 without outside help?

Yes, many organizations can meet MAP 1.2 with internal staff, because it is a governance and documentation outcome rather than a technical build. The work is mainly deciding who should be at the table, recording why, and showing that the perspectives they bring are broad enough for the system's users. Internal teams often struggle with objectivity when the people setting context are the same people building the system, and with identifying user experience and domain perspectives outside their own department. Test your own position by asking whether a non-AI discipline could challenge the context you have written down. If it cannot, outside review may add value.

What does an implementation partner add to MAP 1.2?

A partner adds structure, a second view of who is missing from the context team, and a consistent record that your assessors can follow. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. For MAP 1.2, that can mean organizing the team roster, documenting participation and linking the record to the wider AI RMF work in your environment. The partner does not decide your team composition on your behalf, does not certify it and does not issue any report. Ask for the deliverables in writing before work starts.

How could the planned NIST revision change MAP 1.2 wording?

NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan and has not yet published a revised version. The July 2025 AI Action Plan recommends removing references to diversity, equity and inclusion, so the wording of MAP 1.2 and GOVERN 3 could change. The underlying intent, that the people shaping context bring varied experience and that their participation is documented, is a sound governance practice regardless of wording. Confirm the current version on the NIST site before you finalize documentation, and ask any partner how they will update the record if the text changes. NIST also expects a formal review no later than 2028.

How DeployOpen prepares context team evidence

DeployOpen helps organizations prepare the systems, records and documentation that show who took part in establishing context for an AI system and how their participation was recorded. The organization keeps ownership of its team composition, its decisions and its governance, and DeployOpen works within a written scope agreed before work starts.

How we scope

Confirm which AI systems and deployment contexts the MAP 1.2 evidence must cover, in writing.
Agree which team records, meeting logs and sign-off artifacts the client already keeps and which must be created.
Define the roles that the client, not DeployOpen, assigns to context team members and approves.

How we build

Set up a documented register of context team members, their disciplines and their participation dates.
Configure self-hosted tooling so participation records and review sign-offs are versioned and retained.
Test that the records answer the questions an assessor would ask about team composition and participation.

How we hand over

Deliver the team composition record, participation log and supporting procedures in formats the client can maintain.
Document how the context team was assembled, including any gaps in discipline or user experience and how they were addressed.
Walk the client's owners through the evidence so they can explain it to internal reviewers and independent assessors.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
Ongoing support, updates and periodic review of team records are available as a retainer.
Ask any implementation partner to confirm in writing which findings an independent assessor, not DeployOpen, will issue.