What MAP 2.1 asks you to define before anything else
An audit, a customer questionnaire or an internal review asks whether the tasks and methods of your AI system are defined, and the honest answer is often that they live in several people's heads. MAP 2.1 is the NIST AI RMF outcome that the specific tasks the system will support, and the methods used to implement them, are defined. Tasks are what the system is for, such as triaging support tickets, scoring credit applications or summarizing contracts. Methods are how it does them, such as a classifier, a generative model or a recommender. The outcome also expects known assumptions and limitations to sit beside those definitions, so a reviewer can see what the system was never designed to do.
Vague or drifting task definitions are the most common reason an AI risk review fails. A model approved to rank leads quietly starts scoring applicants. A vendor replaces the underlying model and nobody records the change. A pipeline gains a retrieval step, a tool call or a fine-tune that no document mentions. Each change alters the risks the organization mapped, and the gap is hard to see because the system still appears to work. Vendor-supplied models and undocumented pipelines make this harder, because the facts that matter sit in contracts, release notes and code that the deploying team may not control.
NIST AI RMF is voluntary and no one certifies compliance with it, so no external body will hold this record for you. The organization owns it, and an implementation partner or assessor can only help prepare and test it. Before you start, confirm who can approve a change to a task or method, where the definition is stored, and how a model swap or new data source triggers an update. Those answers decide whether MAP 2.1 is a living record or a document that was accurate only on the day it was written.
Which systems and teams the MAP 2.1 scope covers
MAP 2.1 asks for the tasks an AI system supports and the methods behind them to be defined. The decisions below determine which systems, components, tasks and owners sit inside that definition, and they change how much work the outcome requires. Settle them in writing before any task list is drafted.
Systems and components in scope
Define the AI system boundary before listing tasks. Include the model, the retrieval layer, prompts, fine-tuning data, evaluation harnesses and any wrapper that changes outputs. Pre-trained and third-party models count as components of your system, even when a vendor hosts them. Record which versions and providers are covered, because a model swap can change the tasks the system actually performs. Confirm with engineering whether shadow pilots or internal tools built on the same model belong in the same record.
Pre-trained and third-party models
Where you adopt a pre-trained or vendor model, the task definition still belongs to you. Document the task you configured it for, not only the vendor's general capability. Ask the provider for documented intended uses, known limitations and any restrictions on the tasks it was evaluated for. Where the vendor cannot supply these, treat that gap as a scope limitation to record under MAP 2.1 and carry forward to MAP 4 and GOVERN 6.
Tasks in scope versus planned
Separate tasks the system performs today from tasks on the roadmap. A recommender that ranks products is a different task from one that also sets prices or screens applicants. Mark each task as in scope, planned or excluded, with a named reviewer for any change from one status to another. Planned tasks should not appear in production documentation until they pass the same review as current ones.
Method choices for each task
Name the method used for each task: a classifier, a generative model, a recommender, a rules-plus-model hybrid or another approach. The method determines the failure modes you must document and the tests MEASURE will later need. Record the assumptions behind each method, such as training data representativeness or stable input formats, and the limitations the team already knows about.
Product, data science and risk ownership
Task definition usually spans three teams. Product owns the business purpose and user population, data science owns the method and its evaluation, and risk or compliance owns whether the task is acceptable. Write down who signs off each part and who resolves disagreements. Without a named owner for the combined task statement, the list tends to reflect whichever team wrote it last, which weakens its use as evidence.
Generative AI Profile actions MP-2.1-001 and MP-2.1-002
If the system generates text, images, code or other content, NIST AI 600-1 adds two suggested actions under MAP 2.1: MP-2.1-001 on data origin and content lineage, and MP-2.1-002 on testing data and content flows. They are tagged to Data Privacy, Information Integrity and Intellectual Property risks. Confirm with your risk owner whether generative components sit in scope, then decide whether these actions are adopted, adapted or documented as not applicable with a reason.
How an assessor tests MAP 2.1 in practice
The first test is a documentation review of the task and method record. The assessor checks whether the organization has defined the specific tasks the AI system supports, such as classification, generation or recommendation, and the methods used to carry them out, along with known assumptions and limitations. The question is whether a person who did not build the system could read the record and understand what it is for and where it stops. NIST's Playbook suggests documenting existing and potential learning tasks alongside those assumptions, so assessors look for both.
- Task statement: A written description of each task the system supports, with the business function it serves and the decision or output it produces.
- Method record: The model type, training approach and key components named in the record, matching the architecture actually in use.
- Assumptions and limitations: Stated conditions under which the method is expected to work, and known failure modes.
- Change history: Dated revisions showing when tasks or methods changed and who approved the change.
- Common findings: Tasks described only in marketing material or sales decks, and methods that changed in production without any update to the record.
Before the review, confirm the record lives in a controlled location with version history, not in slides or email threads.
The second test checks that deployed behavior matches the stated tasks and methods. The assessor compares the documented record against the running system, its configuration, its logs and its test results. This is where a gap between paper and production becomes visible, for example a system documented as a ranking tool that is also being used to make automated decisions, or a model replaced in one environment but not updated in the record.
- Configuration comparison: Model versions, pipeline steps and enabled features in each environment set against the documented method.
- Usage sampling: Logs or traces showing which tasks the system actually performs, including requests that fall outside the stated purpose.
- Change control linkage: Deployment records tied to updates in the task and method documentation.
- Test coverage: Evaluation results that cover the stated tasks, not only a generic benchmark.
- Common findings: Undocumented fallback models, shadow deployments, and tasks added through prompt or plug-in changes without a record update.
Ask the team to walk through a recent change and show both the deployment record and the matching documentation update.
For generative AI systems, NIST AI 600-1 adds two suggested actions under MAP 2.1, MP-2.1-001 and MP-2.1-002. They cover practices for determining data origin and content lineage, and testing data and content flows within the system. An assessor therefore asks where training, retrieval and prompt content came from, how that origin is recorded, and whether the flow of data through the system has been tested. These actions tie to the data privacy, information integrity and intellectual property risks named in the profile.
- Data origin records: Sources of training, fine-tuning and retrieval data, with license terms and collection dates.
- Content lineage: Traces showing how a generated output was assembled from inputs, retrieved documents and tool calls.
- Flow testing: Results from tests that check what data reaches the model, what leaves it, and whether sensitive content is exposed.
- Tooling evidence: Trace data from an observability platform such as Langfuse and probe results from a tool such as garak, where used, with the test scope stated.
- Common findings: Retrieval sources added without recorded lineage, and data flow tests that cover only the model and not the retrieval or tool layers.
Confirm which of these actions your program has adopted, since the profile lists them as suggestions rather than requirements.
How to define tasks and methods in six steps
This sequence turns a loose idea of what an AI system does into a documented task register, method record, limitations note and review trigger that other MAP 2 and MEASURE work can rely on. Each step closes with a named output so the team can show its work to an assessor or auditor.
Inventory the AI systems in scope
Start by listing every AI system the organization builds, buys, configures or relies on, including generative AI features inside third-party products. The owner of each system confirms its name, business owner, deployment location and status in a single inventory. Done means every system has a named owner and a status, and anything not yet classified is flagged for follow-up rather than left out. This inventory is the input the rest of the sequence depends on, and it should match the AI inventory kept under GOVERN 1.
Define each task in operational terms
For each system, write the specific tasks it supports in plain operational language, such as routing support tickets to queues or summarizing policy documents for internal staff. Name the input, the output, the user who acts on the output and the decision the output feeds. Avoid general labels like improve efficiency. The product or AI lead drafts the entries with the business owner, and a reviewer from risk or compliance checks that each task can be tested. Done means each task has one written entry in the task register.
Record the method used for each task
Next, record the technical method behind each task, such as a classifier, a generative model, a recommender, a retrieval-augmented pipeline or a rules-based component that works alongside a model. Note the model family or vendor, whether it is trained in house or pre-trained, and whether it is fine-tuned or run as a hosted service. The engineering lead completes this entry, because the method determines which tests and controls apply later. Done means every task entry names one or more methods and links to the component records kept under MAP 4.
List assumptions and known limitations
For each task and method, document the assumptions the design depends on, such as data representativeness, input language, stable user behavior or a fixed set of categories. Record known limitations, including inputs the system handles poorly and failure modes observed in testing or vendor documentation. Ask the vendor or model provider to confirm any limitation claims they make. Done means a signed-off limitations note exists for each system, approved by the system owner and the risk reviewer, and the note is version controlled so later changes are visible.
Record existing and potential learning tasks
The NIST AI RMF Playbook suggests documenting the system's existing and potential learning tasks along with its assumptions and limitations. Existing learning tasks are what the system already learns or adapts to, such as retraining on new data or updating prompts from feedback. Potential learning tasks are changes the team could plausibly enable later, such as adding fine-tuning or connecting new data sources. Record both, and mark which ones would change the system's behavior enough to need a fresh review. Done means each system has a learning task section with items marked as existing or potential.
Set a review trigger and approve the record
Finally, define the events that send a task or method entry back for review, such as a new model version, a change in data sources, a new user group, a new task added to the system or a serious incident. Assign who decides whether a change needs review and where the approved record is stored. The accountable owner approves the full record and the review triggers. Done means the task register, method record, limitations note and learning task list are approved, dated and stored in a location with version history, ready for MAP 2.2 and MAP 2.3 work.
What the Generative AI Profile adds for MAP 2.1
The *Generative AI Profile* (NIST AI 600-1, published July 26, 2024) adds two suggested actions to MAP 2.1, numbered MP-2.1-001 and MP-2.1-002. They are tagged to three generative AI risks: data privacy, information integrity and intellectual property. For a team that has already named the tasks and methods of a generative system, such as a retrieval-augmented assistant or a content drafting tool, these actions push the task definition one step further. They ask the team to show where the model's inputs and outputs come from and how data moves through the system. The profile presents these as suggested actions, not requirements. Your organization decides which ones it adopts, how it documents them and whether a given action fits the system at hand.
The first action concerns data origin and content lineage. In practice, this means recording the source of each training, fine-tuning, retrieval and prompt-template dataset, along with the license or usage terms that apply to it. For a generative system, the list should also cover the documents a retrieval step can surface and the third-party model weights the system depends on. Ask the owners of each source to confirm rights and retention terms, and keep the lineage record in a system that tracks changes over time so an auditor can see what was in place when a given output was produced.
The second action asks the team to test how data and content flow through the system. Map each path from user prompt to model, from retrieval store to context window, and from output to logs, downstream users or external tools. Then run tests that check whether personal data, confidential content or copyrighted material crosses a boundary it should not. Tools such as garak can probe a language model for data leakage and prompt injection, and an observability platform such as Langfuse can record the inputs, outputs and tool calls of each request for later review. Confirm with your own security and legal teams which flows are in scope and which tests they will accept as evidence, since the profile does not set pass or fail thresholds.
Evidence that passes a MAP 2.1 review
An assessor reviewing MAP 2.1 looks for a current record of what each AI system is meant to do, how it does it, and what it cannot do. The cards below name the artifacts that carry that record and explain how to keep each one current between reviews.
Task and method register
A register lists every AI system in scope, the specific tasks it supports (for example, ranking support tickets or drafting customer replies), and the method behind each task, such as a classifier, a generative model or a recommender. Each row names an accountable owner and the date the entry was last confirmed. Keep it as a versioned page so a reviewer can see when a task was added, narrowed or retired. Review it when a system changes model, vendor or use case, and at a fixed interval the organization sets.
System card for each AI system
A system card is a short document per AI system that records its purpose, method, inputs, outputs, intended users and the people who approve changes. It gives MAP 2.1 reviewers one place to confirm that tasks and methods match what is deployed. Store the card beside the code or configuration it describes, and require a new version whenever the model, prompt template or data source changes. A card that still describes last year's model fails review even when the text is accurate.
Assumptions and limitations record
This record lists the assumptions the system relies on, such as input language, document quality or user behavior, and the known failure modes that follow from them. The NIST AI RMF Playbook suggests documenting known assumptions and limitations for MAP 2.1, so reviewers expect to see each one tied to a task. Record who reviewed each entry and what evidence supports it. Revisit the record after incidents, after test results change, and whenever the population of users or inputs shifts.
Data origin and lineage records
Lineage records trace where training, evaluation and retrieval data came from, under what license or consent, and how it moved through preprocessing into the system. NIST AI 600-1 lists practices for determining data origin and content lineage as a MAP 2.1 action for generative AI. Keep one record per dataset with source, owner, collection date and transformations. Update it whenever a dataset is refreshed or a new source is added, because a lineage gap found during an audit is hard to close after the fact.
Data and content flow test outputs
Test outputs show how data and content move through the system and whether the flow matches the documented design. For generative AI, NIST AI 600-1 suggests testing data and content flows within the system under MAP 2.1. Teams can use open-source probes such as garak, which writes a JSONL report of every attempt and a hit log of attempts that found a vulnerability. Archive each run with the system version it tested, so reviewers can compare results across releases.
Version history and review dates
Each artifact above is only as credible as its change history. Wiki platforms such as XWiki keep every page change with what changed, when and by whom, and let reviewers compare or roll back versions. Access controls such as BookStack's role-based permissions keep owners in charge of edits. Set a review date on every page and require the owner to confirm or revise it. Ask the auditor which history format they accept before building the archive.
What meeting MAP 2.1 costs in money and effort
This table breaks down the cost components of defining AI tasks and methods under MAP 2.1, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request, since NIST AI RMF is voluntary and no fee is set by NIST. No price is estimated here; a quote follows from written scope.
| Cost component | Who is paid, and for what | One-time or recurring | What drives it |
|---|---|---|---|
| Internal time to define tasks and methods | Your staff: product owners, data scientists and engineers documenting each system's tasks, methods, assumptions and limitations | One-time for the initial record, then recurring reviews | Number of AI systems in scope and how often their tasks or methods change |
| Tooling and licenses | Software vendors for model registries, documentation wikis and tracing tools; self-hosted open source can remove most license fees | Mostly recurring for commercial licenses; one-time for setup of open-source tools | Choice of commercial versus open-source tools and the hosting effort they need |
| Evidence upkeep | Your staff keeping task definitions, version history and change records current | Recurring | Frequency of model or prompt changes and the number of teams editing records |
| Third-party model review | Your staff, and sometimes an implementation partner, reviewing vendor and pre-trained models named in MAP 2.1 records | One-time per model, then recurring when vendors update | Number of third-party models and whether vendor documentation on tasks and limits is available |
| Generative AI testing | Your staff or a security testing provider running probes for data leakage, hallucination and prompt injection against defined tasks | Recurring with each major model or prompt change | Use of generative AI, number of model versions and the depth of testing agreed in scope |
| External review or testing | An independent reviewer or security testing firm, paid under a written scope | Usually one-time per review cycle | Scope size, number of systems reviewed and whether testing is included |
| Auditor time if an assessment is commissioned | An independent assessor, if you commission one; NIST AI RMF has no certification | One-time per engagement, repeated at each review | Assessor's rates, scope and the readiness of your records when they arrive |
Who owns MAP 2.1 and what a partner can take on
The organization that builds, buys or deploys the AI system decides which tasks it will support and which methods implement them. Those decisions belong to named people with authority over the use case, not to an outside party. MAP 2.1 asks that the specific tasks be defined and that the methods, such as classifiers, generative models or recommenders, be identified. The owner also decides which assumptions and limitations are accepted and who signs off on them.
- Task scope: a named owner states what the system will do, what it will not do, and who the users are.
- Method choice: the owner records which model family or technique is used and why it fits the task.
- Assumptions and limits: known assumptions about data, users and environment are written down and reviewed.
- Sign-off: a documented approval by someone accountable for the risk, tied to the Govern accountability structure.
- Review triggers: the owner sets when task definitions must be reopened, such as a new model version or new user group.
Before engaging anyone, confirm that an internal owner can sign these definitions and that the sign-off is recorded where auditors can find it.
An implementation partner can prepare the systems and records that hold the organization's task definitions. This work is technical and often takes more hours than teams expect. The partner does not decide the tasks or accept the risk. Its deliverables should be written in the statement of work so that the boundary is clear from the start.
- Register setup: a structured register of AI tasks, methods and assumptions, built with the owner's content.
- Tracing configuration: tracing for model calls, retrieval steps and tool use, for example through Langfuse, so runtime behavior can be compared with the documented task.
- Test tooling: setup of probe tools such as garak for generative systems, with reports kept as evidence.
- Versioned records: wiki or documentation platforms such as XWiki or BookStack configured to keep change history, roles and approval trails.
- Hosting in your environment: all of this runs in the client's own cloud account, data center or air-gapped network.
Ask the partner to list every artifact it will produce and who keeps administrator access to each system after handover.
An independent auditor, assessor or certification body tests the evidence and issues any report. NIST does not validate or endorse any organization's use of the AI RMF, and the AI RMF has no certification or conformity assessment program. A statement that an organization 'complies with NIST AI RMF' is therefore an internal claim unless a separate standard or contract defines a formal assessment. Assessors may be engaged for a readiness review, a formal examination under another framework, or a customer audit.
- Evidence testing: the assessor samples register entries, traces and version histories and checks they match.
- Independence: the assessor cannot design the controls it later tests, or the review loses its value.
- Scope agreement: the assessor confirms which systems, periods and subcategories are in scope before testing.
- Report ownership: only the assessor issues findings or reports, and it does so in its own name.
- Readiness review: an advisory review of gaps is useful but is not an assessment and should not be presented as one.
Confirm with any assessor which framework or contract its work will be measured against before you begin.
Organizations commonly outsource the build of supporting systems and the collection of records, and keep decisions and approvals in-house. Where the line falls depends on the organization's size, regulatory exposure and internal skills. The boundary should be written down so that no one assumes an outside party has accepted a risk that remains internal.
- Usually outsourced: tooling setup, tracing and logging configuration, initial register population, and test runs.
- Usually kept in-house: task definitions, method selection, risk acceptance and go or no-go decisions.
- Shared work: keeping the register current, which needs an internal owner and partner support under contract.
- Handover items: credentials, documentation, runbooks and ownership of every system at the end of the engagement.
- Ongoing support: retainers can cover upgrades and continuous testing if the organization wants them after the initial work.
When you request a quote, ask for the scope split as a table listing each deliverable and its owner.
Where MAP 2.1 usually fails and how to close each gap
MAP 2.1 fails less from missing effort than from descriptions that drift away from the running system. The gaps below share one root cause: the task, method and assumption records stop matching what the system actually does. Each fix keeps those records tied to the system's configuration and change history.
Tasks written as marketing language
Descriptions such as "intelligent customer insight" or "automated decision support" tell an assessor nothing about what the system outputs. Rewrite each task as an operational statement: the input, the output, the decision it feeds and the population it applies to. Ask whether a reviewer could build a test case from the sentence alone. If not, the task is still undefined. Keep the wording in the same record the team uses for design reviews so the two cannot diverge.
Method changes without a record update
Swapping a classifier for a generative model, changing a retrieval index or upgrading a base model often happens in a pull request and never reaches the system description. Treat any change to model family, training data, prompt templates or tool access as a trigger for a MAP 2.1 review. Store the method record under version control so each change shows what changed, when and by whom. Confirm the review step is part of your change process, not an optional follow-up.
Third-party model behavior assumed
Teams often describe a pre-trained or vendor-hosted model as if its behavior were known, when the documentation covers only general capabilities. Record the model version, the provider's stated limitations and the behavior you tested in your own context. Where the provider does not publish a limitation, list it as an open question with an owner. Ask vendors for documentation of training data sources, known failure modes and change notices before each version update.
Generative AI data lineage unknown
For generative systems, MAP 2.1 expects practices for determining where data and content originate and how they flow through the system. Many teams cannot say which documents feed retrieval, which prompts and outputs are retained, or which third-party tools receive user data. Trace each data source and content path, then test those flows with a documented method. Traces from an observability tool can show the actual call chain, which helps confirm the documented flow matches production.
Assumptions and limits never reviewed
Assumptions about input quality, user behavior and operating conditions are usually written once at launch and never revisited. Keep a register of each assumption and limitation, with an owner, a test or monitoring signal that would show it no longer holds, and a review date. Include known limits such as languages, populations or inputs outside the design envelope. When a review finds an assumption false, update the task and method records in the same change so the documentation stays current.
How much work and cost does MAP 2.1 take?
Does MAP 2.1 require a certificate or an official audit?
No. NIST AI RMF 1.0 is a voluntary framework and has no certification, accreditation or conformity assessment program. NIST does not validate or endorse any organization's use of the framework, so there is no certificate to buy for MAP 2.1. Your evidence is a documented, reviewable record that your team defined the tasks the AI system supports and the methods behind them, along with the assumptions and limitations. If a customer or regulator asks for proof, an independent assessor can review that record, but the assessor's review is an assessment of your documentation, not a NIST certification. Confirm with the requesting party exactly what form of evidence they expect.
What does the team need to do the MAP 2.1 work?
MAP 2.1 asks for a clear definition of what the system is for and how it works, so the work draws on several roles rather than one specialist. Typically this means a product owner who can state the supported tasks, an engineer who can name the model type and the data and tools it uses, and someone from risk or compliance who records assumptions and limitations. The Playbook suggests documenting existing and potential learning tasks along with known assumptions and limitations, so the team must also be able to describe what the system should not be used for. Plan for these people to review the same document, since the output is only useful if it matches how the system behaves in production.
Can we do MAP 2.1 in-house without outside help?
Yes, many teams do. MAP 2.1 is documentation-heavy, and the NIST AI RMF is voluntary and designed to be tailored, so an organization with people who understand its AI systems can write the task and method definitions itself. Outside help becomes more useful when the system is complex, when several business units share one model, or when the team has no one who can describe the methods accurately. Useful outsourced work includes preparing the documentation structure, testing the system so its described behavior matches reality, and setting up tools that keep the record current. The organization still owns the decisions and the final content.
What drives the time and cost of MAP 2.1?
The main drivers are the number of AI tasks, the number of models and third-party components involved, and how well existing documentation already describes them. Each additional task, model or data source adds definitions to write and assumptions to check. Generative AI systems add more work, because NIST AI 600-1 has suggested actions under MAP 2.1 on data origin, content lineage and testing data and content flows. Costs are mostly internal staff time, plus any external help you buy. No fact supplied for this page gives a duration or price, so ask any provider to show how each driver changes its estimate.
What should a written scope for MAP 2.1 include?
A written scope should name the systems covered, the specific tasks and methods to document, the people who review and approve the records, and the format of the deliverables. It should state which items the organization owns, such as the final task definitions and sign-off, and which items the partner prepares, such as documentation templates, test plans or logging setup. Ask for the list of AI systems in scope, the expected documents, the acceptance criteria and the dates for review. Also confirm that the partner prepares evidence only and does not issue audit reports or certifications, since only independent auditors and certification bodies do that.
Which open-source tools help produce MAP 2.1 evidence?
Several open-source tools can support the evidence without replacing your judgment. Garak (Apache-2.0) probes language models for hallucination, data leakage, prompt injection and other weaknesses, and writes a JSONL report of every attempt and a hit log of successful attempts, which helps test the data and content flows described in the documentation. Langfuse (MIT) records traces of LLM calls, retrieval steps, tool executions, inputs, outputs and token usage, which shows how a deployed system actually behaves. XWiki (LGPL-2.1-or-later) keeps a version history of each page, showing what changed, when and by whom, and BookStack (MIT) controls who may edit the records through role-based permissions. Confirm each tool's fit with your environment before adopting it.
Do we need to document MAP 2.1 again when the NIST framework is revised?
Possibly, so plan for it. 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 as of October 2026, and NIST expects a formal review no later than 2028. The Playbook is also due for an update after the framework is revised. Keeping MAP 2.1 records in a version-controlled system makes any later update easier to trace. Ask any partner how it will track changes to the framework and whether updating the records is included in the written scope or handled as a separate retainer.
Who owns the MAP 2.1 record after the work is finished?
Your organization owns the record and the decisions it contains. A partner may prepare the template, populate the initial content with your staff, and set up tools, but the task definitions, assumptions and limitations must be approved by people accountable for the system. Keep ownership of the source documents and the version history in your own environment. Before work starts, confirm in writing who maintains the record after handover, who reviews changes, and whether ongoing updates require a retainer or internal staff.
Scoping MAP 2.1 with DeployOpen
DeployOpen starts MAP 2.1 work by agreeing a written scope that names each AI task the system will support (for example, a classifier that routes support tickets or a generative model that drafts internal summaries), the method behind each task, and the owner who signs off on it. The scope document lists which systems, data sources and third-party models are in and out, and which team members from your side must review drafts. Because most engagements are fixed-scope, the deliverables, review rounds and completion criteria are fixed in the same document before any work begins. Your organization owns the decision about which tasks the system performs and which methods are acceptable; DeployOpen documents and implements what you decide.
Within that scope, DeployOpen prepares the records and tooling that show what the system does. The task and method register is kept in a wiki or documentation platform such as XWiki, where page version history records what changed, when and by whom, so reviewers can compare versions. Known assumptions and limitations are written beside each task, and generative components are traced with observability tooling such as Langfuse, whose traces capture inputs, outputs, retrieval steps and tool calls. Where generative models are involved, the work also covers the data origin and content lineage actions listed for MAP 2.1 in NIST AI 600-1. Confirm with your team which of these platforms already exist in your environment, since the scope should reuse them where they fit.
The handover is a set of written deliverables: the task and method register, the assumptions and limitations log, the configured tooling and a record of the review decisions. DeployOpen does not issue audit reports, attestations or certifications, and NIST does not offer an AI RMF certification, so none of these deliverables is a certificate. Your internal governance owns the controls and any external assessment is performed by a party you choose. Ask any implementation partner to confirm in writing which deliverables are included, who approves them, and what happens when the system's tasks change after handover, since that change will require the register to be updated under your change process.
How DeployOpen works on this
DeployOpen helps teams record the tasks an AI system supports and the methods behind them, then sets up the self-hosted tooling that keeps that record current. The organization still owns its AI tasks, assumptions and sign-off, and an independent assessor reviews the evidence.
How we scope
- Engagements are fixed-scope, with the MAP 2.1 deliverables agreed in writing before work starts.
- The written scope names each AI system, its tasks, its model types and the components whose records we will set up.
- Ongoing support for documentation upkeep and tooling is available as a retainer, priced separately from the initial scope.
How we build
- We set up a self-hosted wiki with version history so task and method definitions show who changed them and when.
- We configure tracing for LLM calls, retrieval steps and tool executions so the methods in use can be confirmed against records.
- We run structured probing of language model deployments and keep the attempt logs and findings alongside the task documentation.
How we hand over
- You receive the task and method register, assumption and limitation records, and the access roles that govern who edits them.
- Test reports from probing runs are delivered with the raw logs so your team and assessors can trace each result.
- We walk your owners through how to update the records after changes, so the evidence stays accurate between reviews.
How we support
- Support covers upgrades and patching of the wiki, tracing and testing tools running in your own infrastructure.
- We can repeat probing runs when a model, prompt or tool changes, and add the new results to the existing record.
- Confirm with us, in the written scope, which systems and review cycles the support retainer will cover.
