MEASURE 2.9 Explainability and interpretability: evidence guide

What MEASURE 2.9 explainability evidence must show before deployment

A customer, regulator or internal risk committee asks how your model reaches its decisions, and whether anyone has checked that the explanation holds up. MEASURE 2.9 asks for exactly that: the AI model is explained, validated and documented, and its output is interpreted within the context identified in MAP, so that responsible use and governance can rely on it. Before deployment, the evidence should show that each of those four verbs was done and can be inspected by someone outside the team that built the model. NIST AI 100-1 separates three related ideas in Section 3.5. *Transparency* answers what happened in the system, *explainability* answers how a decision was made, and *interpretability* answers why it was made and what it means to the user. A model card that lists training data does not show how a specific loan was declined, and a feature attribution chart does not tell a claims handler what action to take. Each of the three needs its own evidence. The framework also calls this a voluntary framework with no certification, so no body will issue a MEASURE 2.9 badge. Your evidence is only as credible as the independent review it can withstand.

This is hard in practice for three reasons. Explanation methods approximate a model rather than report its internal logic, so an explanation can be plausible and still wrong. Explanations that satisfy a data scientist often fail a domain expert or an end user. And the people who need to validate the explanation (TEVV staff, domain experts, operators and end users, as the Playbook tags them) rarely work from the same documents. Before deployment, confirm with your TEVV lead which explanation methods were tested for fidelity, consistency and robustness, and ask end users to check whether the explanations they receive lead to the right action. Record decision thresholds, features and training data in the model documentation, and keep those records under version control so a reviewer can see what changed and when. Confirm the exact Playbook actions your assessor will test with the current NIST AI RMF Playbook.

Which models, teams and third parties fall under MEASURE 2.9

MEASURE 2.9 applies to any AI system whose output a person acts on, but the depth of explanation, documentation and testing depends on the model type, whether the system generates content, who supplied the model and who relies on the output. The cards below list the scoping decisions that change the work and the actor categories the NIST AI RMF Playbook ties to this subcategory.

Inherently interpretable versus opaque models

Start by classifying each model as inherently interpretable (for example, a short decision tree or a linear scoring model whose logic can be read directly) or opaque (for example, a deep neural network or large ensemble). The Playbook suggests preferring inherently explainable approaches where they meet the need, and it asks for post-hoc explanations where they do not. Record the classification in the model documentation, because it determines which explanation methods and fidelity tests are needed. Confirm with the model owner which family each production model belongs to.

Generative AI systems under AI 600-1

Generative AI systems fall under the actions in NIST AI 600-1, the Generative AI Profile, which lists two suggested actions for MEASURE 2.9 (MS-2.9-001 and MS-2.9-002). These are tied to the Confabulation, Harmful Bias and Homogenization, and Information Integrity risks. The profile's suggested methods include embedding analysis, counterfactual prompts and gradient-based attributions where the model architecture allows them. Decide early which chatbots, summarizers and content tools count as in scope, since they are often deployed without a formal model review.

Purchased and pre-trained models

Models bought from a vendor or downloaded as pre-trained weights still need explanation and documentation in your environment, even when the vendor's model card is incomplete. The Playbook asks for documentation of model type, features, training algorithms, decision thresholds and data, and many vendors will not disclose all of these. Ask the vendor in writing which items they can provide, and record gaps as open risks. Pair this scope with the third-party controls in the GOVERN 6 and MANAGE 3 content groups.

Decision contexts where people rely on output

The explanation work is most important where a person acts on the output, such as credit, claims, hiring, clinical triage or fraud review. Map each system to the decision it informs, the people who can override it and the consequences of an unexplained error. Systems that only feed an automated process with no human review still need explanation tests, but the depth of documentation and end-user testing should follow the impact. Record the decision context in the MAP outputs so MEASURE 2.9 work can reference it.

TEVV and domain expert roles

The Playbook tags MEASURE 2.9 with the TEVV and Domain Experts actor categories. TEVV staff test explanation fidelity, consistency and robustness, while domain experts judge whether an explanation is meaningful for the task. Name an owner for each role in the system record, and confirm that the people who sign off on explanations are not the same people who built them where your governance requires separation. AI 100-1 Appendix A describes the tasks of each actor category.

Operation, monitoring, impact and end-user roles

The remaining Playbook tags are Operation and Monitoring, AI Impact Assessment, AI Deployment and End-Users. Operators need to know what an explanation means in their workflow, monitoring staff need to detect explanations that change over time, impact assessors need to record who is affected by unclear decisions, and end users need to be able to question an output. Confirm which team owns each of these actions for every in-scope system, and make sure end-user feedback routes back into the model documentation.

Which explanation methods fit which model

Some model families expose their reasoning directly. Linear and logistic models with documented coefficients, shallow decision trees and rule lists show how each input contributes to an output, which makes them the simplest case for MEASURE 2.9. The NIST AI RMF Playbook suggests preferring inherently explainable approaches where the task allows, and that preference should be a recorded design decision, not an assumption. Transparency in this sense answers what the system did, explainability answers how a decision was reached, and interpretability answers why it matters to the user. A simple model can satisfy the first two more easily than the third.

What it can show: the direct mapping from features to outputs, including the weight or split that drove a given decision.
Limits: explanations stay faithful only while the model stays small. Added features, interactions or depth can remove the direct readability.
What to document: model type, feature list, training algorithm, decision thresholds and the data used to fit them.
Testing: check that explanations are consistent across retraining and that end users can restate them correctly.
Trade-off record: note why a simpler model was chosen or rejected against accuracy requirements.

Confirm with TEVV and domain experts that the documented thresholds match what the deployed system actually applies.

How an assessor tests MEASURE 2.9

This table compares what a reviewer typically tests for MEASURE 2.9, the evidence they request and the gaps they most often record. Read it as a preparation checklist: each row shows where your own documentation will be examined. No NIST attestation or certificate is issued; any assessment conclusion comes from your independent reviewer or internal audit, based on your records.

Test approach	Evidence requested	Common findings
Review model documentation against the MAP context	Model card or equivalent covering model type, features, training algorithm, data sources and intended use	Documentation exists but predates the last retraining or omits feature lists and data provenance
Check explanation outputs against logged decisions	Sample of decisions with the matching explanation, timestamp and model version	Explanations cannot be traced to the specific decision or model version that produced them
Test explanation fidelity, consistency and robustness	Test plan, results for fidelity to model behavior, stability across similar inputs, and sensitivity to small input changes	No documented test method, or results reported only as a pass without metrics or thresholds
Test interpretability with end users	Records of user sessions, questions asked, comprehension results and resulting changes to explanations	Explanations were written by the development team and never checked by the people who act on them
Verify decision thresholds are recorded and justified	Threshold values, the date set, the rationale, the approver and the change history	Thresholds live in code or configuration with no recorded rationale or owner
Confirm Domain Experts and End-Users were involved	Named participants, their roles, meeting or review records and how their feedback was adjudicated	Domain experts are listed in a RACI chart but no review output exists
Confirm explanation methods match the model type	Method selection note explaining why an inherently explainable model or a post-hoc method was chosen	Post-hoc explanations are used on a model where a simpler, inherently explainable approach was feasible, with no recorded reason
Check for generative AI documentation where applicable	Records of applied methods such as embedding analysis or gradient-based attributions, with data provenance notes	Generative AI outputs are described without any attribution or provenance record, and the choice is undocumented

How to implement MEASURE 2.9 in sequence

This sequence turns MEASURE 2.9 from a statement of intent into documented, tested explanations that a reviewer can trace from the MAP context through to the decisions they inform. Each step produces an artifact that the next step depends on.

Confirm the MAP context and decisions
Start by reviewing the MAP outputs for the system, including its intended purpose, the people who act on its output, and the decisions that output informs. Product owners, domain experts and the risk function should agree on who needs an explanation, for what decision, and at what level of detail. The step is done when a written statement names each decision, its affected users and the explanation audience, and the TEVV team has signed off on it. Without this, the explanation work has no defined target.
Choose the explanation approach per model
For each model, the TEVV lead and the domain experts decide whether an inherently explainable model is adequate or whether a more complex model needs post-hoc explanation methods. The NIST AI RMF Playbook suggests preferring inherently explainable approaches where they meet the performance and risk requirements. The output is a short decision record per model that states the chosen approach, the reason for it and the limits it imposes on explanations. Confirm with the business owner that the trade-off between accuracy and explainability has been accepted in writing.
Document model type, features, algorithms and data
The model owner documents the model type, input features, training algorithms, decision thresholds and the provenance of training and evaluation data. Good practice is to keep this in a versioned model card or equivalent record, so that each retrained model has its own entry. The step is complete when a reviewer who did not build the model can state what it takes as input, how it was trained and where each threshold came from. Link these records to the MEASURE 2.1 documentation of test sets and metrics.
Produce post-hoc explanations and audit logs
Engineers implement the explanation methods selected in step two and configure logging so that each prediction or recommendation can be traced to its explanation, inputs, model version and any human override. The output is a sample of generated explanations for representative cases and a log schema that the operations team can query. Confirm that logs are retained for the period your governance policy sets, and that access to them is restricted to authorized roles. Generative AI systems may need additional methods, which NIST AI 600-1 describes for MEASURE 2.9.
Test explanation quality with end users
Testers, with domain experts and representative end users, assess explanations for fidelity to the model's behavior, consistency across similar cases, robustness to small input changes and whether people can interpret them correctly. The Playbook suggests testing these properties with end users rather than only with engineers. The output is a written test report listing the cases, the participants, the criteria, the failures and the fixes made. Ask the independent assessor or internal audit function to review the report before it is used as evidence.
Record decisions and approve use
The accountable owner reviews the documentation, the explanation test report and the audit log sample, then records whether the model may be used for each identified decision, with any conditions on explanations. This record connects MEASURE 2.9 to the go or no-go and governance processes that GOVERN and MANAGE describe. The step is complete when the approval, the conditions and the named approver are stored with the model documentation. Do not treat an approval as permanent, because later steps can change the conditions.
Set a review cadence tied to MEASURE 2.4
Agree a review schedule for explanations and model documentation and link it to the production monitoring defined under MEASURE 2.4. When monitoring shows distribution drift, unusual outputs or new complaints, the explanation tests should be rerun and the documentation updated. The output is a written review calendar with named owners, triggers for an unscheduled review and a record of each review's findings. Confirm the cadence with your governance committee, because the required frequency depends on the system's risk and your own policies.

Which evidence artifacts pass and how to keep them current

MEASURE 2.9 is only as credible as the records behind it. The artifacts below show an assessor or customer how the model was explained, validated and interpreted, and each one must point to the exact model version it describes. Keep them under version control so that a change to the model forces a review of every record that depends on it.

Model documentation record

This is the reference record for the model itself: model type, input features, training algorithm, training data provenance and decision thresholds. The Playbook suggests documenting these items for MEASURE 2.9, so an assessor can see what was explained. Check that the record names a model version and a data snapshot, and that the owner signs off each revision before deployment.

Explanation method report

For each explanation technique in use, record the method, its parameters, the model version it was run against and its known limits. Post-hoc methods can give different answers for the same prediction, so the report should say why the chosen method fits the use case. Check that a reviewer can rerun the method on the same version and get the same output.

Explanation quality test results

These results show whether explanations are faithful to the model, consistent across similar inputs, robust to small input changes and understandable to end users. Pair the test scores with notes from user sessions, since MEASURE 2.9 expects testing with end users and not only technical checks. Store each run with the model version and the test set used.

Decision threshold register

A threshold register lists each cutoff that turns a model score into a decision, with its value, the reason it was set, who approved it and the date. Thresholds often change without a model retrain, so changes to them must be logged as carefully as model changes. Check that each entry links to the model version and to the explanation reports that describe its effect.

Audit log of served explanations

Log which explanation was shown for which prediction, to which user role, and under which model and explanation version. These logs let a team reconstruct what a user saw during a disputed decision and detect explanations that drift after an update. Confirm your retention period with the accountable owner and your legal team, since the planned retention depends on the use case.

User interpretation guidance

This guidance tells operators and affected users what an explanation does and does not mean, what actions are expected, and when to escalate. It addresses the interpretability question of what a result means to the user, which MEASURE 2.9 treats separately from how the decision was made. Version it with the model, review it after each material change and record who approved each edition.

How explanation and documentation records connect in a running system

For MEASURE 2.9, the explanation of a model's output is only as useful as the record that ties it to the inference that produced it. In a running system, a single request should pass through the model, an explanation step and a logging layer in a way that lets an assessor later reconstruct which model version, which inputs and which explanation produced a given decision. The model itself should not be the place where those records are kept. Explanation generation should be a separate service that reads the inference output and writes its results to the trace store, so that a compromised or misbehaving model cannot silently rewrite its own explanations.

The trust boundaries sit in three places. The first is between the model and the explanation service, where the explanation should be computed from logged inputs and outputs rather than from anything the model returns about itself. The second is between the logging layer, such as an LLM observability tool like Langfuse, and the knowledge base. Traces capture timing, inputs, outputs and metadata, and they can contain personal data or sensitive prompts, so the reader should confirm who can read them and how long they are retained. The third is between the knowledge base and its editors. Model documentation in a wiki such as XWiki is versioned, which gives a change history, but page-level permissions in a tool like BookStack must be set so that only the accountable owners can approve changes to model documentation.

Practically, a team should decide three things before go-live: which trace fields are mandatory for each explained decision, which documentation pages must link to a specific model version and trace sample, and who signs off when an explanation is found to be inconsistent with the documented behavior. Test that these links work end to end with a sample decision, and confirm with the platform vendors which features, retention settings and export formats are available in the version you deploy. The diagram that follows shows these links, and an independent assessor will expect to follow them from a documented decision back to its explanation and its model record.

What meeting MEASURE 2.9 costs in money and effort

This table breaks the cost of MEASURE 2.9 into components, shows who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for building a quote, since no price or duration is given here because none has been published for this work. The main takeaway is that most of the recurring cost comes from keeping explanations and documentation current as the model changes, not from the initial setup.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling and licenses	Recurring if subscription; one-time if self-hosted	Number of models, trace volume and whether the team needs hosted or self-managed tools	Self-host open-source tools such as Langfuse (MIT) and garak (Apache-2.0) to remove license spend for those tools; confirm hosting, storage and support costs in your own environment
Engineering time for explanation methods	One-time build, then recurring upkeep	Model type, number of explanation methods chosen, and whether post-hoc explanations are added to an existing model or designed in from the start	Prefer inherently explainable approaches where the use case allows, and standardize on a small set of explanation methods with documented limits
Documentation upkeep	Recurring	Frequency of retraining, changes to features or decision thresholds, and the number of documented model details (type, features, training algorithm, data provenance)	Use version-controlled wiki or documentation tools such as XWiki (LGPL-2.1-or-later) and tie each documentation update to a model change record
Explanation quality testing	Recurring with each model release	Number of explanations tested for fidelity, consistency, robustness and interpretability, and the test design needed for each	Automate repeatable checks in the TEVV pipeline and limit manual review to high-impact decisions identified in MAP
External testing with end users or domain experts	Recurring per evaluation round	Number of user groups, the need for domain experts, recruitment effort and any human subject protection review	Plan evaluation rounds around release cycles, reuse protocols across releases and confirm which groups are mapped as relevant AI actors
Audit logs and trace storage	Recurring	Volume of inferences, retention periods set by policy or regulation, and depth of logged inputs, outputs and metadata	Set retention by risk tier, log only the fields needed to reconstruct a decision, and confirm retention requirements with legal counsel
Assessor sampling and evidence preparation	Recurring per assessment cycle	Scope of the assessment, number of systems sampled and how easily evidence can be retrieved for a chosen decision	Keep evidence indexed by model version and decision, so a sampled case can be traced to its explanation and documentation quickly
Implementation partner support	One-time for setup, optional recurring retainer	Fixed-scope work agreed in writing, number of systems covered and whether testing or monitoring is retained	Define deliverables and evidence in a written scope before work starts and ask the partner to separate one-time build from ongoing support in the quote

Which open-source tools support MEASURE 2.9 evidence

Can garak produce evidence for MEASURE 2.9 explainability?

garak can support MEASURE 2.9 evidence for language models, but it does not generate explanations itself. It is an Apache-2.0 licensed scanner that probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. Each run writes a JSONL report of every attempt and evaluation, plus a hit log of the attempts that found a vulnerability. Those records can show how a model behaved under adversarial prompts, which supports the testing of explanation quality with end users and domain experts. Your team still has to choose the probes, decide what counts as a failed explanation, and interpret the results. Confirm the current probe list in the garak README before you rely on a specific probe for your evidence file.

How does Langfuse help with MEASURE 2.9 audit logs?

Langfuse, licensed under MIT, records traces that capture each operation in a request, including LLM calls, retrieval steps, tool executions and custom logic. Each trace stores timing, inputs, outputs, token usage and metadata. For MEASURE 2.9, these traces give you a reviewable record of what the system received and returned, which is the raw material for checking how an output was reached and whether it was interpreted in context. Langfuse does not produce explanation methods such as feature attributions. Your engineers still need to instrument the application, decide which metadata fields matter for governance, and set retention and access rules for logs that may contain personal data. Review the Langfuse observability overview to confirm which trace features apply to your deployment.

Is XWiki good for keeping model documentation records?

XWiki, licensed under LGPL-2.1-or-later, is a suitable place to keep model documentation because it keeps every change to a page under version control. It records what changed, when and by whom, lets users compare any two versions, and supports rollback to an earlier version. Those features help you show how a model card, decision threshold record or explanation method description changed over time, which supports the documentation expected under MEASURE 2.9. XWiki does not check whether the documentation is accurate or complete. Reviewers, domain experts and the accountable owner still need to approve content, and your team should define a template that covers model type, features, training algorithm, thresholds and data sources. Confirm the version history behavior in your installed version, since it is described in the XWiki blog.

How does BookStack control who can edit AI documentation?

BookStack, licensed under MIT, controls editing through roles. A user's abilities come from the roles assigned to them, and permissions can be overridden per role at the shelf, book, chapter or page level. For MEASURE 2.9, this lets you separate authors of explanation documentation from reviewers and approvers, and restrict edits to validated model documentation so that a change cannot slip in unnoticed. BookStack does not, on its own, prove that a review took place or that a document is correct. Your governance process must define who approves each document, and your access settings must match that process. Check the BookStack roles and permissions documentation and test the configuration with your own role model before an assessor reviews it.

Do these open-source tools replace explainability methods?

No. None of garak, Langfuse, XWiki or BookStack performs explanation methods such as feature attributions, post-hoc explanations or inherently interpretable modeling. They store, test or organize the evidence that those methods produce. The explanation work itself belongs to your data science and TEVV teams, who choose methods suited to the model, validate their fidelity and consistency, and test them with end users. The tools then help you keep the records: probe results, traces, versioned documentation and controlled access. Treat them as evidence infrastructure. Your readiness assessment should list which explanation methods you use and which tool holds each piece of evidence for them.

Who pays for setting up these tools and keeping evidence current?

Costs fall into two groups: software and people. The four tools named here are open-source, so license fees are not the main cost. Your organization or an implementation partner pays for installation, integration with your model pipeline, configuration of roles and retention, and the design of documentation templates. These are one-time costs. Recurring costs include upgrades, log storage, reviewing traces and probe reports, and maintaining documentation as models change. Costs rise with the number of models, the volume of traces, and the number of teams that need access. Ask any quote to separate setup work, integration work and ongoing operation, and to state who owns each evidence record. DeployOpen plans, implements, integrates and documents self-hosted platforms in your own infrastructure on a fixed-scope basis, but DeployOpen does not issue assessment reports, and an independent assessor still reviews the evidence.

What should an assessor check in these tool records?

An assessor will usually ask whether the records are complete, unaltered, traceable to a named owner and retained long enough to support review. For garak, that means the JSONL reports and hit logs from each test run, tied to the model version tested. For Langfuse, it means traces covering the operations relevant to explanation outputs, with access controls and retention rules documented. For XWiki and BookStack, it means version history showing who changed each explanation document and who approved it, plus role settings that match your approval process. Prepare a short map that links each MEASURE 2.9 activity to the record that proves it. Confirm with your assessor which evidence format they accept before you build the map.

Who owns explainability work and what an auditor can do

Your organization owns the AI system, its explanations and the decisions that rest on them. MEASURE 2.9 asks that the model be explained, validated and documented, and that its output be interpreted in the context identified during MAP. Those judgments cannot be delegated to a vendor or a consultant, because they determine how the system is used and who answers for it.

Model decisions: Choose the model type and decide whether an inherently explainable approach is adequate or whether a post-hoc explanation method is needed.
Decision thresholds: Set and approve the thresholds that turn scores into actions, and record who approved them and why.
Interpretation rules: Define what staff may conclude from an explanation and where a human must review the output before acting.
Documentation content: Own the model documentation covering features, training algorithms, data and thresholds, and keep it current when the model changes.
Explanation quality sign-off: Accept or reject test results on fidelity, consistency, robustness and interpretability with end users.

Before engaging anyone else, confirm that each of these decisions has a named owner in your own governance records.

Where MEASURE 2.9 programs usually fall short

Most MEASURE 2.9 gaps are not missing tools. They are explanations that were never checked, documentation that drifted from the deployed model, and generative AI systems that sat outside the review. Each card below pairs one gap with a step that closes it.

Post-hoc explanations without fidelity tests

Teams often attach an explanation method to a model and treat its output as the reason for each decision. A post-hoc explanation is an approximation, so it can look plausible while misrepresenting the model. For MEASURE 2.9, check whether each explanation method has been tested for fidelity to the model, consistency across similar inputs and robustness to small input changes. Record the results alongside the method and its settings, and re-run the tests when the model is retrained.

Documentation written once, never versioned

Model documentation is often written at launch and then left alone while the model, features and training data change. Documentation that no longer matches the running system is a weak basis for explaining decisions or for governance review. Keep explanation and model documentation in a version-controlled wiki, tie each version to a model release, and confirm that reviewers can compare any two versions and see who changed what and when.

Missing decision threshold records

Explanations depend on the thresholds that turn a score into a decision, yet thresholds are often set in code or a configuration file and never recorded with the explanation. When a threshold changes, past explanations can no longer be interpreted. Record each threshold with its value, the date it took effect, the accountable approver and the reason for the setting. Store these records next to the model documentation so an assessor can reconstruct any decision.

Explanations never tested with end users

An explanation can be technically accurate and still fail the people who must act on it. The Playbook suggests testing explanations with end users for interpretability, which means checking whether a reviewer understands what the output means for the decision in front of them. Run structured sessions with the operators and affected users named in MAP, record what they misread, and feed those findings back into the explanation design and training material.

Generative AI systems left out of scope

Explainability work often covers classical models and skips generative AI systems, even when those systems answer customers or drive decisions. NIST AI 600-1 lists suggested actions under MEASURE 2.9 for generative AI, including applying explanation methods such as embedding analysis, counterfactual prompts and gradient-based attributions, and documenting data provenance and model architecture. Confirm the generative AI systems in your inventory, decide which of these methods apply to each, and document the reasons for any method you do not use.

Explanation outputs without audit logs

Explanations are only useful for governance if they can be retrieved for a specific past decision. Teams often keep model outputs but not the explanation, the inputs, the model version or the threshold in effect at the time. Confirm that each decision record stores these items together, and that retention periods match the review needs of your accountable owners and any regulator you answer to. Test retrieval by picking a decision at random and rebuilding its explanation.

How much effort does MEASURE 2.9 take and what does it need from us?

Does MEASURE 2.9 have a fixed price or effort figure we can budget against?

No published figure applies to MEASURE 2.9, so the effort depends on your system, its risk and how much explanation work already exists. NIST AI 100-1 describes the outcome in general terms and does not size the work. The main cost drivers are the number of models in scope, whether they are inherently explainable or need post-hoc explanation methods, how many stakeholder groups must review the explanations, and how complete your model documentation already is. Ask any partner for a written scope that lists the models, the explanation methods, the documentation deliverables and the end-user testing included, then price against that list.

Can our own team implement MEASURE 2.9 without an outside partner?

Yes, many organizations do the work in-house, because the framework is voluntary and NIST does not require a specific provider. The work spans data science (explanation methods and tests), model owners (documentation), domain experts (interpretation of outputs), and operations and end-user groups (testing whether explanations are useful). The usual gap is not technical skill but time and independence: the same team that built a model often tests its explanations. Outside help is most useful for setting up logging, documentation templates and a repeatable test plan, and for an independent review of the results.

How long does it take to get MEASURE 2.9 in place?

No researched timeline exists for MEASURE 2.9, so treat any duration you hear as unverified until it is tied to a written scope. The schedule depends on how many systems are covered, whether model documentation already exists, whether logging and audit trails are in place, and how long it takes to schedule reviews with domain experts and end users. Ask for milestones that separate documentation, explanation method selection, testing with users and final sign-off, because the user testing step is the one most often delayed by calendar availability.

What do we need to provide before any implementation work starts?

The team needs to provide access and information, not just approval. Typically this includes a list of the AI systems in scope, their intended purpose and decision context, model artifacts or access to the training pipeline, training data descriptions, decision thresholds, existing logs and any prior model cards or datasheets. You also need named owners for each system, a domain expert who can judge whether an explanation makes sense, and a route to end users for testing. Confirm access to a non-production environment in your own infrastructure before work begins, since explanation tests should not run against live decisions.

Does NIST certify that our models meet MEASURE 2.9?

No. NIST does not certify, accredit or validate any organization or its use of the AI RMF, and it publishes no conformity assessment program for MEASURE 2.9 or any other subcategory. Evidence that you meet the outcome is internal documentation and test results that you can show to customers, regulators or auditors. If a vendor offers an AI RMF certificate, ask who issued it and what standard it tests against, because the framework itself does not provide one.

Can a consultant replace an independent auditor for explainability evidence?

A consultant can prepare explanation methods, documentation and test evidence, but cannot issue an independent opinion on whether your system meets a framework or regulation. Consultants and implementation partners prepare systems and evidence. Only an independent auditor, assessor or certification body issues reports or certificates, and the AI RMF has none of these. If a customer, contract or regulator asks for independent assurance, ask that party which assessor it accepts and what scope it expects, before you commission preparation work.

Which parts of the MEASURE 2.9 work recur after the first delivery?

The one-time work is the initial documentation, explanation method selection and first round of user testing. Recurring work includes re-running explanation tests after each model retraining or significant data change, keeping model documentation current, reviewing logs for explanation drift, and repeating end-user testing when the decision context changes. Ask any partner which items are covered by the fixed scope and which would fall under an ongoing support arrangement, and confirm who maintains the explanation tooling after handover.

What tooling can reduce the effort, and what should we confirm first?

Open-source tools can capture evidence that supports MEASURE 2.9 without buying a proprietary product. Langfuse records traces of model calls with inputs, outputs and metadata, which helps for generative AI systems. XWiki keeps version history of documentation, showing what changed, when and by whom, and BookStack lets you set role-based permissions on documentation. Confirm each tool's capabilities against its current documentation in your environment, since these tools support evidence collection rather than explanation methods themselves, and explanation libraries still need to be selected and validated for your models.

Where to read the requirement and the Playbook

Start with the primary text. The requirement for MEASURE 2.9 sits in MEASURE 2 of the Measure function, and NIST AI 100-1 lists it in Table 3. Read the outcome statement in that table before anything else, because it is the language an assessor or customer will compare your evidence against. Note that the outcome is about explaining, validating and documenting the model and interpreting its output in the context identified during MAP, so your documentation should trace back to the context you recorded for the system. Also read Section 3.5 of AI 100-1, which separates transparency, explainability and interpretability. Teams often use these words interchangeably, and a clear definition in your own documents will prevent confusion when reviewers ask which property a given control addresses. Confirm the current version of the PDF on the NIST site before you cite it, since NIST has said AI RMF 1.0 is under revision.

Next, use the NIST AIRC Playbook Measure page as the working reference for suggested actions and documentation prompts under MEASURE 2.9. The Playbook is voluntary and NIST states it is neither a checklist nor a set of steps, so treat each suggested action as a question to answer for your system, not a box to tick. The Playbook also lists the AI actor categories tagged to MEASURE 2.9, including TEVV, Domain Experts, Operation and Monitoring, AI Impact Assessment, AI Deployment and End-Users. Assign a named owner to each category. Check the Playbook's audit log before relying on any guidance, because NIST records August 2023 as the last content update and says the Playbook will be updated after the framework is revised. Where the Playbook and the revised framework diverge later, the framework text governs.

If the system is generative, add NIST AI 600-1, the Generative AI Profile, which maps two suggested actions for MEASURE 2.9 (MS-2.9-001 and MS-2.9-002) to the risks Confabulation, Harmful Bias and Homogenization, and Information Integrity. These actions cover explanation methods such as embedding analysis, counterfactual prompts and gradient-based attributions, along with model details like data provenance and architecture. Decide early which of these methods your team can apply to the model you actually run, especially if you consume a hosted model whose internals you cannot inspect. In that case, the documentation you can obtain from the provider becomes the core evidence, and you should confirm what the provider will supply in writing.

How DeployOpen prepares explainability evidence for MEASURE 2.9

DeployOpen helps teams running AI systems inside their own infrastructure set up the explanation methods, model documentation and explanation tests that MEASURE 2.9 asks organizations to show. The organization owns its AI system and its governance decisions, and DeployOpen prepares the systems and evidence those decisions rely on. NIST AI RMF has no certification, so the evidence is reviewed by the organization's own assessors or internal audit.

How we scope

Engagements are fixed-scope, with the AI systems, models and MAP-identified contexts covered agreed in writing before work starts.
The written scope names which MEASURE 2.9 actions apply, such as explanation methods, model documentation and explanation quality tests.
Scope also records which AI actors own each task, such as TEVV, domain experts, end users and operations staff.

How we build

We deploy explanation tooling and audit logging inside the client's cloud accounts, data centers or air-gapped networks.
Model documentation templates capture model type, features, training algorithms, decision thresholds and data sources in version-controlled pages.
Test harnesses check explanation fidelity, consistency and robustness, and record results alongside the model version they describe.

How we hand over

Handover packages list each MEASURE 2.9 artifact, its owner, its location and the review cadence the client chose.
Operators receive runbooks for regenerating explanations, reviewing test results and documenting changes to the model.
Clients confirm with their own assessors which artifacts meet their evidence expectations before the package is treated as final.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainers can cover re-running explanation tests when a model is retrained, updated or moved to a new environment.
Open questions about interpretation in context are referred to the client's domain experts and governance owners, who make the decisions.