MEASURE 2.12 Environmental impact and sustainability: evidence guide

What MEASURE 2.12 asks for and why it is hard to evidence

MEASURE 2.12 expects the environmental impact and sustainability of AI model training and management activities, as identified in MAP, to be assessed and documented. When a customer, board or regulator asks how an AI system's energy, water and emissions are measured, the honest answer starts with whether those impacts were identified during mapping at all. The subcategory does not prescribe a metric set, a threshold or a calculation method. It asks the organization to decide what matters for its system, measure it, and write down what it found. The NIST AI RMF Playbook suggests concrete steps: include environmental indicators in design plans, track energy and water consumption and greenhouse gas emissions, set measurable baselines and acceptable levels with actions to take when they are exceeded, weigh performance against sustainable operation, and estimate lifecycle emissions with carbon calculators. These are suggestions, not a checklist, so the reader must choose and justify the indicators.

Baselines and acceptable levels carry most of the weight. A reading of kilowatt-hours or tonnes of emissions means little until it is compared with an earlier training run, a comparable model or a level the organization has agreed to tolerate, and an assessor will look for the action taken when that level is crossed. Ask the team which training, fine-tuning and inference workloads are in scope, who owns the meters or cloud billing exports that feed the numbers, and where the acceptable levels were approved. Note that the Playbook is tagged to TEVV, Domain Experts, Operation and Monitoring, AI Impact Assessment and AI Deployment, so the evidence will come from several teams, not one sustainability function. NIST AI 100-1 sets out the tasks of each actor category in its Appendix A.

The subcategory is hard to evidence for three reasons. First, the framework is voluntary and there is no certification or conformity assessment against it, so no external body will set the metrics for you. Second, the Generative AI Profile in NIST AI 600-1 adds four suggested actions for MEASURE 2.12, covering energy and water use for training, fine-tuning and deployment and verifying carbon capture or offset claims, but these are suggestions too. Third, the America's AI Action Plan of July 2025 recommends that NIST remove references to climate change, and NIST says AI RMF 1.0 is being revised and has not published the revised text. As of October 2026, MEASURE 2.12 remains in the published text. Confirm with your legal and sustainability leads which version your contracts cite, and record the indicators you chose and why, so the evidence still makes sense if the subcategory is later reworded.

Which AI systems and infrastructure fall under MEASURE 2.12

MEASURE 2.12 applies to the environmental impact of AI model training and management, but the impacts in scope are set earlier in the MAP function. The cards below cover the decisions that determine what an organization must measure, who holds the data, and which actor categories own each part of the work.

Training versus fine-tuning versus inference

Pre-training a model, fine-tuning an existing one and serving predictions each draw energy differently and occur at different scales. MEASURE 2.12 asks for assessment of the activities identified in MAP, so the first check is which of these three the organization actually runs. An organization that only calls a hosted API may have no training energy to measure, while one that fine-tunes on its own hardware should expect fine-tuning runs to appear in its indicators. Record each activity separately so the baseline does not blur them together.

Self-hosted GPU clusters

On hardware the organization operates, energy and water use can be measured at the rack, node or facility level, provided metering exists. Check whether power draw is logged per device, whether cooling water is metered or estimated, and whether the data center operator reports these figures. Idle capacity, cooling overhead and scheduling of training jobs all change the totals, so the indicators should capture utilization alongside consumption.

Cloud-metered compute

Cloud providers often expose carbon or energy estimates, but the granularity, methodology and time window differ from one provider and service to another. Confirm whether the figures cover the specific regions, instance types and services used, and whether they are estimates or metered values. Note that cloud accounts may show spend and usage without showing energy, so the organization may need to convert usage into energy with a documented method.

Third-party model providers

When the organization consumes a model from an external vendor, the training energy belongs to that vendor, and the organization may hold no energy data for it. MEASURE 2.12 still expects the organization to decide what it can assess and document. Ask providers whether they publish energy or emissions figures for the model, what boundary they use, and whether they will share data under contract. Where none is available, document the gap and the reason it is accepted.

Scope set by the MAP function

MEASURE 2.12 measures the impacts identified in MAP, so the MAP outputs decide which environmental indicators matter. An impact characterization that omits energy or water use for a system will leave MEASURE 2.12 with nothing to test for that system. Review the MAP records for each AI system, confirm they name environmental impacts where relevant, and carry the decision forward into the measurement plan so scope does not drift.

Actors who own the measurement

The Playbook tags MEASURE 2.12 to the TEVV, Domain Experts, Operation and Monitoring, AI Impact Assessment and AI Deployment actor categories. For this subcategory, Domain Experts, Operation and Monitoring, and AI Deployment are the groups most likely to hold the energy and infrastructure data, so name an owner in each for collection and review. Confirm which team runs the metering, which team signs off the baseline, and who acts when an indicator crosses its threshold.

How an assessor tests MEASURE 2.12

This table compares what an independent assessor looks for under MEASURE 2.12 with what organizations often present instead. Read each row as a test question, the evidence that answers it, and the common gap that leads to a finding. Because AI RMF 1.0 is voluntary and has no certification, the assessor's conclusions are a view for your own governance, not a NIST determination.

Test question	Evidence an assessor expects	Common finding
Is an environmental impact assessment tied to MAP outputs?	A documented assessment that names the AI systems, training and management activities in scope and links back to the MAP context and impact records	The assessment exists as a general sustainability statement with no link to the mapped systems
Are environmental indicators defined and sourced?	A list of indicators (energy, water, greenhouse gas emissions) with the named measurement source for each, such as cloud provider reports or facility meters	Indicators are named but no source or collection method is stated
Is there a measurable baseline?	Dated baseline values for each indicator, with the period and scope they cover	No baseline exists, so later changes cannot be shown as improvement or regression
Are thresholds set, with actions when they are exceeded?	Acceptable levels for each indicator, the owner who receives alerts, and the response steps written in advance	Thresholds are absent, or they exist without any documented action or escalation path
Is the trade-off between performance and sustainable operation reviewed?	Meeting records or decision logs showing that model size, retraining frequency or hosting choices were weighed against indicator levels	No record of the review, or the review happened only at the time of initial model selection
Are estimates produced with a stated method?	Written method for each estimate, including the carbon calculator or tool, input data, assumptions and the date of the estimate	Emission figures appear with no method, version of the tool or assumptions, so they cannot be repeated
Does each metric have an accountable owner?	A named owner per indicator and a record of who reviews results and how often	Metrics are collected by a platform team with no business or risk owner who acts on them
Is the evidence current and retained?	Versioned records showing collection and review over time, kept with other AI RMF documentation	Records are one-off snapshots, or the last update predates changes to the systems in scope

Implementing MEASURE 2.12 in five steps

This sequence turns the MEASURE 2.12 outcome into a documented environmental measurement program, moving from the indicators named in design plans to baselines, trade-off decisions and a lifecycle emissions estimate that an assessor can trace back to the Map and Measure records.

Identify environmental indicators in the design plan
Before any system is built or changed, the AI team and domain experts list the environmental indicators that matter for the system, such as energy use for training and serving, water consumption, and greenhouse gas emissions. The Playbook suggests putting these indicators into design plans from the start. The owner is usually the AI system owner with input from TEVV and the sustainability or facilities function. The artifact is a design plan section naming each indicator, its unit, its system boundary (training, fine-tuning, serving or all three) and the MAP entry it traces to. The step is done when every indicator has a named owner and a defined data source.
Instrument energy, water and emissions collection
The operations team connects the indicators to real measurements for training runs and production serving. Where the platform runs on the organization's own infrastructure, metrics can be exposed from the compute, cluster and facility layers and stored in a time-series system such as Prometheus, then queried and displayed in Grafana. Where the organization relies on cloud or data center providers, the team must confirm which energy, water and emissions data the provider supplies and how often. The artifact is a collection specification plus working dashboards. The step is done when a test training job and a test serving workload each produce a traceable record of every indicator.
Set baselines and acceptable levels with triggered actions
Using the collected data, the accountable owner sets a measurable baseline for each indicator and an acceptable level above which the system is considered out of tolerance. For each level, the owner writes the action that follows an exceedance, such as pausing a retraining job, reviewing the serving configuration or escalating to the go or no-go decision holder. Grafana Alerting can build alert rules from these queries so that exceedances notify the responsible team. The artifact is a signed threshold register with alert rules and an escalation path. The step is done when a deliberate test breach fires the alert and the documented action is recorded.
Assess trade-offs between performance and sustainable operation
Before a model is retrained, scaled or moved to a larger configuration, the product owner, TEVV lead and operations lead compare the expected gain in performance against the expected change in energy, water and emissions. The Playbook asks organizations to weigh these trade-offs explicitly rather than optimize one measure alone. The output is a short decision record for each significant change, showing the options considered, the indicator impact, the performance effect and the accountable approver. The step is done when no significant change reaches production without this record.
Estimate lifecycle emissions with a documented calculator method
The sustainability or compliance lead estimates emissions across the system lifecycle, covering training, fine-tuning, deployment and retirement where the scope applies. The team uses a carbon calculator and records its name, version, emission factors, assumptions and boundary so another assessor can reproduce the result. Measured energy from step two is used as input where it exists, and estimates are labeled as estimates. The artifact is a lifecycle emissions worksheet with its method note. The step is done when the worksheet can be regenerated from the stored inputs and has been reviewed by someone outside the team that produced it.

How energy and emissions data becomes audit evidence

A MEASURE 2.12 file is only as strong as the data behind it, so the first decision is which sources feed the energy, water and emissions records. For training and fine-tuning runs, the usual candidates are cloud billing and usage exports, facility meters or utility invoices for on-premises or colocated GPU clusters, and GPU and node telemetry collected by the platform itself. Each source measures something different. Billing data reflects what was purchased, telemetry reflects what ran, and meter readings reflect what the building drew. Record which source produced each figure, the collection frequency (for example, per job, hourly or monthly), and the unit (kilowatt-hours, cubic meters, kilograms of CO2 equivalent). Without those three fields, a reviewer cannot tell whether two numbers from different months are comparable.

Assessors will expect estimates and metered values to be kept visibly apart. A metered value comes from a meter, log or invoice. An estimate comes from a model, such as a carbon calculator applied to hardware specifications or an assumed grid intensity factor. Label every estimate with its method, its assumptions and the version of the tool used, and never let an estimate silently replace a missing meter reading. The NIST AI RMF Playbook suggests estimating lifecycle emissions with carbon calculators, so the estimation method is a reasonable thing to document, but its outputs still need the labels above. Confirm with your metering and cloud providers which of these figures they can actually export, and at what granularity, before you commit to a baseline.

The Generative AI Profile adds two actions that change the evidence scope. MS-2.12-003 calls for measuring or estimating energy and water consumption across training, fine-tuning and deployment, so the records must cover inference as well as training. MS-2.12-004 asks organizations to verify the effectiveness of any carbon capture or offset program they rely on. Offset claims need their own evidence: the provider's contract, the offset registry or certificate reference, the period and quantity covered, and an independent check of whether the reduction happened. A purchased offset is not a measured reduction in your own emissions, and your file should say so. Retain raw exports, estimate worksheets, offset documents and change notes for each reporting period, so the records survive from one assessment to the next.

Evidence that passes a MEASURE 2.12 review

MEASURE 2.12 asks whether the environmental impact of training and managing AI is assessed and documented. The cards below are the records that let an assessor trace each claim back to a MAP output, a measured value and a dated decision. Keep them linked to one another so that a reviewer can follow the chain from assessment to logs to approved thresholds.

Environmental impact assessment

This is the document that records which environmental impacts were identified during MAP for the system, including training, fine-tuning, deployment and hosting. Each entry should point to the MAP output that raised it, name the affected lifecycle stage and state who reviewed it. Check that the assessment covers the whole model lifecycle rather than training alone, and that it is dated and versioned so the reviewer can see what changed after a material update to the model or infrastructure.

Indicator register with definitions

The register lists every environmental indicator in use, such as energy consumed, water consumed and greenhouse gas emissions, with a plain definition, unit, measurement boundary and data source for each. An assessor tests whether two teams measuring the same indicator would get the same result. Record the owner of each indicator and the collection method, and note any indicator that is estimated rather than metered so the uncertainty is visible.

Baselines and threshold approvals

Baselines are the measured starting values for each indicator, and thresholds are the acceptable levels above which a defined action follows. Record the approver, the date of approval and the response that applies when a threshold is exceeded, such as a review, a capacity change or a pause in retraining. Confirm that thresholds were set before the monitored period began, because a threshold adjusted after an overrun is difficult to defend.

Consumption and emissions logs

These are the time-stamped records of energy and water use and emissions from the metering, cloud billing or infrastructure monitoring systems. Metrics platforms such as Prometheus can store energy and resource series as time series, and Grafana Alerting can fire on a threshold breach and route the alert to an owner. Confirm that the logs are retained for the period the assessor will sample, that gaps are documented, and that the alert history shows how each breach was handled.

Lifecycle emission estimates

Where direct measurement is not possible, the estimate of lifecycle emissions must state the method, the emission factors used, the boundary and the version of the calculator or tool. A reviewer should be able to rerun the calculation and get the same figure from the same inputs. Record the input data, the assumptions and the reason each estimate was needed, and flag any estimate that relies on a provider-supplied figure that could not be independently checked.

Trade-off and offset records

Trade-off decision records show where performance was weighed against sustainable operation, for example a smaller model chosen over a larger one, or a retraining schedule reduced. Where the organization claims carbon offsets, keep the verification files that show the offset was delivered, including the registry, the vintage and the verifier's statement. NIST AI 600-1 asks organizations to verify the effectiveness of carbon capture or offset programs, so an offset claim without this file will not survive review.

What meeting MEASURE 2.12 costs

This table lists the cost components of meeting MEASURE 2.12, who is paid for each one, whether it is one-time or recurring, and what drives it up. Read it as a checklist for building a quote, since no fixed figures are supplied for these items.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it and what to ask for
Instrumenting energy and water metering	Internal platform engineers, or an implementation partner for hours of configuration	One-time build, then recurring upkeep	Number of training clusters and hosts. Ask the partner to list each metered source and the exporter or agent used for it.
Metrics and alerting tooling	Open-source software is free to license, but hosting, storage and staff time are not	Recurring infrastructure and operations	Retention period and sample volume. Ask for the storage and retention assumptions behind any sizing estimate.
Setting baselines and acceptable levels	Domain experts and sustainability owners inside the organization	One-time, then revisited at each review	Number of models and workloads in scope. Ask who approves thresholds and what happens when a threshold is exceeded.
Lifecycle emissions estimation	Internal analysts or an external specialist using a carbon calculator	Recurring per training run or major model change	Training run count, fine-tuning frequency and the calculator's method. Ask which calculator and emission factors the estimate uses.
Provider data validation	Internal procurement and engineering, sometimes a cloud or hardware vendor's reporting team	Recurring per reporting cycle	Multi-cloud sourcing and data quality of provider figures. Ask each provider for the methodology and whether figures are measured or modeled.
Tradeoff assessment of performance and sustainable operation	Internal engineering and product owners	Recurring at major design or model decisions	Frequency of model changes and the number of accountable decision makers. Ask what evidence is required before a tradeoff is accepted.
Periodic review and documentation	Internal governance and TEVV staff, who must also keep records for assessors	Recurring, aligned to the organization's review cycle	Depth of records kept for each indicator. Ask how the review schedule links to the wider AI RMF documentation program.
External review, if purchased	An independent reviewer or assessor, chosen and paid by the organization	Optional, usually one-time per review cycle	Scope of the review and whether the reviewer tests the data or only the documentation. Ask for a written scope before work starts.

Open-source tooling that collects the indicators

MEASURE 2.12 asks for environmental indicators that are tracked over time against baselines and acceptable levels. Two open-source components can carry that work: one collects and stores the time series, the other turns thresholds into alerts and a shared record of responses. Neither measures energy or emissions on its own, so the cards also flag what the organization must supply.

Prometheus collects indicator time series

Prometheus (Apache-2.0) collects metrics from instrumented jobs through a pull model over HTTP and stores them as time series identified by metric name and labels. For MEASURE 2.12, each indicator such as GPU energy draw, cluster water use or estimated emissions becomes a named series with labels for model, environment and training run. Check that the labels let you compare a training run against its baseline, and that retention on local storage is long enough to show trends across model lifecycles.

PromQL queries show trends against baselines

PromQL is the query language used to read Prometheus series, so the same expression can compute a rolling average of energy per inference or the change in emissions since a baseline month. Write these queries as versioned files so an assessor can see how each reported figure was calculated. Confirm that the expressions match the definitions in your design plan, including the units and the time window used for each indicator.

Grafana Alerting enforces acceptable levels

Grafana Alerting (AGPL-3.0-only) builds alert rules from queries and expressions across multiple data sources, so a threshold breach can be evaluated on metrics and logs together. Use it to encode the acceptable levels set in MEASURE 2.12 and to route a breach to a named owner. Record the action taken after each alert, since the Playbook expects actions when a level is exceeded and that record is what an assessor will ask to see.

Licensing review before deployment

Grafana is licensed under AGPL-3.0-only, which has obligations that apply when software is modified and offered to users over a network. Before deployment, have legal or open-source counsel confirm that your intended use, internal dashboards or any customer-facing views, meets those obligations. Prometheus is licensed under Apache-2.0, so the review for it is usually lighter, but the same check should be recorded for both components in the evidence file.

Energy data still needs supplied meters

Prometheus and Grafana store and display what they receive, but they do not measure electricity, water or emissions by themselves. Energy figures usually come from exporters, smart power meters, data center building management systems or cloud provider reporting that the organization supplies and validates. Ask each source for its measurement method and accuracy, and document any estimates derived from a carbon calculator separately from metered values.

Who owns MEASURE 2.12 and what to outsource

Your organization owns MEASURE 2.12. Nobody else can decide which energy, water and emissions levels are acceptable for your AI systems, what happens when a baseline is exceeded, or whether a performance gain justifies higher consumption. Those are business and governance decisions tied to your risk tolerance, which MAP and GOVERN set out. The Playbook lists documentation prompts and suggested actions, but it is not a checklist, so your team has to choose which actions fit each system and record why.

Thresholds and acceptance: Approve the baselines, acceptable levels and the actions taken when they are exceeded, and name the accountable owner.
Trade-off decisions: Decide how performance is weighed against sustainable operation for each model, and record the rationale.
Scope and inventory: Confirm which training, fine-tuning and inference workloads fall under MEASURE 2.12, drawing on your AI inventory.
Review cadence: Set how often indicators are reviewed and who signs off on changes to the design plan.
Documentation: Keep the decisions, the evidence and the reasons for them in one place.

Before engaging anyone, confirm internally who will sign the threshold decisions, because a partner cannot accept them on your behalf.

Where MEASURE 2.12 programs usually fall short

MEASURE 2.12 asks for environmental impact to be assessed and documented, but most gaps come from missing baselines, unclear sources and unstated methods. The cards below cover the failure points an assessor or customer is most likely to find, with a practical fix for each.

No baseline before training

Teams often record energy use after a training run without measuring the starting point, so they cannot show whether a change improved or worsened impact. Set measurable baselines for energy, water and emissions before the first training run, and record the hardware, region and schedule used. Check that each later run is compared against a named baseline rather than a memory of past runs.

Indicators without named sources

A dashboard figure for kilowatt-hours or emissions means little if no one can say which meter, cloud billing export or facility report produced it. For each indicator, record the data source, the owner and the collection frequency. Confirm that the source covers the full training and serving footprint, including shared infrastructure that is not billed to the AI team.

Estimates without stated method

Lifecycle emissions estimated with a carbon calculator are only defensible if the assumptions are visible. Document the calculator version, the grid intensity values, the hardware power assumptions and the boundary of the estimate. An assessor should be able to rerun the calculation and reach the same figure from the stated inputs.

Thresholds with no action

Setting an acceptable level for energy or emissions has little value unless someone is required to respond when it is exceeded. Pair each threshold with a named owner, an alert in the monitoring stack and a documented response, such as pausing a retraining job or reviewing the model size. Check that alerts actually fire in test conditions and that the responses are recorded.

Water omitted from indicators

Programs often track energy and emissions but leave out water consumption, even though the Generative AI Profile specifically names energy and water use for training, fine-tuning and deployment. Add water to the indicator set, including cooling water at the data center where the provider reports it. Where a provider does not disclose water use, record that gap as a known limitation and ask the provider for the figure.

Offset claims without verification

Statements that a model is carbon neutral because of offsets or capture programs need evidence that the program works. Ask for the offset methodology, the independent verification report and the period it covers, and compare those claims with measured consumption. The Generative AI Profile calls for verifying the effectiveness of these programs, so keep the verification record with the indicator data.

No review after framework revision

NIST is revising AI RMF 1.0 under the White House AI Action Plan, and climate references are a target of that revision, while MEASURE 2.12 remains in the published text. Record which version of the framework the program follows, set a review date tied to any published revision, and decide in advance whether climate-related indicators stay in place for customers or regulators who still ask for them.

Questions buyers ask about MEASURE 2.12

Is MEASURE 2.12 mandatory, and can it be certified?

No. MEASURE 2.12 is a subcategory of the NIST AI RMF, which NIST describes as voluntary, and no one can be certified against it. NIST has not published a certification, accreditation or conformity assessment program for the framework, and it does not validate or endorse any organization's use of it. A customer, contract or regulator may still ask you to show how you assess environmental impact. In that case, the evidence is a documented assessment that you can walk through, and an independent assessor can review it if the requester asks for that. Confirm the exact wording of any contract or regulation that cites the framework, since a voluntary framework can still become a contractual reference.

How much effort does MEASURE 2.12 take, and what drives it?

The effort depends mostly on how much AI your organization trains or runs and how many of those systems you must measure. Training and fine-tuning large models, or running them on shared infrastructure, produces the energy, water and emissions data that the subcategory asks you to track. Effort rises when metering is absent, when cloud providers report energy or emissions only at account level, and when several teams operate separate model pipelines. Effort falls when systems share one metering and monitoring stack and when baselines already exist for compute use. Ask for a quote that separates the one-time setup of data sources and baselines from the recurring cost of collection, reporting and review.

How long does a first MEASURE 2.12 assessment usually take?

The duration depends on the inventory of AI systems in scope, the state of your infrastructure telemetry and the number of teams that must provide data. No supplied source gives a typical duration, so treat any figure from a vendor or consultant as an estimate to test against your own environment. The steps that usually take the longest are identifying which systems the MAP function covered, agreeing on indicators and units, and collecting one full cycle of data so that baselines mean something. Ask any provider to break the timeline into scoping, instrumentation, baseline collection and documentation, and to state which of those depend on your staff's availability.

What must our team supply before an assessment starts?

Your team must supply the facts about the systems and infrastructure, because no outside party can measure them for you. The list usually includes:

An inventory of AI systems, models and training runs, with the MAP context for each
Access to compute, storage and cloud billing data, and any energy or emissions reports from providers
Named owners in engineering, operations and domain areas who can confirm indicators and acceptable levels
Decisions on which thresholds trigger action, and who approves them
Permission to retain monitoring data and metrics for the review period

Agree these inputs in writing before work begins, so that gaps show up in scoping rather than during reporting.

Should we measure MEASURE 2.12 in-house or hire a partner?

Many teams do the measurement in-house and bring in a partner only for the parts that need specialist engineering. The organization always owns its AI governance, its risk decisions and its controls. An implementation partner such as DeployOpen can prepare self-hosted monitoring, document metric definitions and build the evidence pipeline inside your own infrastructure, on a fixed scope agreed in writing. DeployOpen does not issue reports or attestations; an independent auditor or assessor does that if you need one. Choose in-house work when your team already runs metering and monitoring well, and consider a partner when metrics must be wired into several platforms or when the timeline is fixed.

What happens to MEASURE 2.12 after the AI RMF revision?

The subcategory remains in the published AI RMF 1.0 text, but its future is uncertain. NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan, and the July 2025 plan recommends removing references to climate change. NIST also expects a formal review with community input no later than 2028, and versions use a two-number scheme in which minor revisions add a decimal. Since no revised text has been published, do not assume the subcategory will be removed or kept. Keep the measurement and documentation regardless, because the underlying indicators are useful for cost and resource management. Track the revision through NIST's own announcements and review any contract that cites a specific version.

How DeployOpen prepares MEASURE 2.12 evidence

DeployOpen plans, implements and documents self-hosted open-source monitoring and measurement inside your own infrastructure so that environmental indicators for AI model training and management can be tracked and recorded. The organization owns its controls and its environmental acceptable levels, and an independent auditor or assessor, not DeployOpen, decides whether any assessment conclusion holds.

How we scope

Agree in writing which AI systems, training and fine-tuning workloads, and deployment environments fall inside MEASURE 2.12 for your organization.
Confirm with your domain experts and AI impact assessment owners which environmental indicators from MAP apply, such as energy, water and emissions.
Record who owns each baseline and acceptable level, and what action follows when a threshold is exceeded, before any build work starts.

How we build

Configure metric collection for energy, water and emissions sources where your infrastructure exposes them, using Prometheus scrape jobs you can inspect.
Build Grafana dashboards and alert rules that compare measured indicators with the baselines and thresholds your organization approved.
Document the tools, data sources, query logic and assumptions so that TEVV staff can reproduce every reported figure.

How we hand over

Deliver the configuration, dashboards, alert rules and runbooks as versioned files in your environment, with a record of each change.
Provide documentation that maps each indicator to the MEASURE 2.12 suggested actions your organization chose to adopt, including tradeoff assessments.
Walk your teams through how to review alerts, escalate exceedances and produce evidence for an independent assessor or auditor.

How we support

Offer ongoing support, upgrades and monitoring of the measurement stack as a retainer, once the fixed-scope delivery is complete.
Update baselines and dashboards when the NIST AI RMF is revised, since the Playbook will be updated after that revision and MEASURE 2.12 may change.
Ask your assessor early which evidence they expect for environmental indicators, because requirements can differ by sector and by the frameworks you are measured against.