Software Water Intensity Is Trying to Give Software a Water Metric

Software Water Intensity (SWI) is an in-development Green Software Foundation measurement standard intended to express the water footprint of software relative to useful work performed. The project is still a pre-draft, so SWI is not yet a finalized industry metric. Its current importance is methodological: it gives software teams a common place to discuss direct cooling water, water associated with electricity generation, embodied water in hardware, and location-specific water stress instead of treating “water use” as one universal number. Green Software Foundation SWI specification

Why software needs a water measurement layer

Software does not consume water directly in the way a factory does. The physical systems running software do.

A software workload can create water impacts through at least three pathways:

software workload
      |
      +--> data-center cooling
      |
      +--> electricity generation
      |
      +--> semiconductor manufacturing
      |
      +--> location / water stress

The first two are operational impacts. The third is embodied impact in the hardware supply chain. Location matters because the same quantity of water can have very different consequences in different watersheds.

The Green Software Foundation is therefore trying to avoid a metric that simply says “this workload used X liters” without explaining where the water came from, what boundary was measured, or whether the location was already water-stressed.

SWI is modeled on Software Carbon Intensity, but water is harder

The project borrows the broad idea behind Software Carbon Intensity: measure environmental impact as a rate relative to useful work rather than as an isolated total.

That makes a conceptual form like this useful:

water impact
-------------
useful work

The goal is comparability across workloads, regions and systems.

But water does not behave like carbon.

A kilogram of carbon dioxide has the same atmospheric identity regardless of where it was emitted. A liter of water consumed in a water-abundant basin is not equivalent to a liter consumed in a drought-stressed watershed.

That is why SWI's current specification leaves important methodological decisions open rather than pretending the problem has already been solved.

The four components now visible in the project

The Green Software Foundation's current material describes four components that the specification and accompanying Handbook are trying to connect:

1. Direct operational water — water consumed by software infrastructure, especially cooling systems.
2. Indirect electricity-generation water — water associated with producing the electricity used by the workload.
3. Embodied water — water associated with manufacturing the compute hardware.
4. Scarcity-weighted impact — a way to account for the fact that location changes the meaning of water consumption.

This is more useful than a single headline number because each component has a different measurement problem.

Direct cooling is only the obvious part

Data-center cooling is the most intuitive component.

Evaporative cooling can consume water directly by transferring heat into water vapor. Closed-loop and air-based systems can change that profile substantially.

But even here, terminology matters.

Withdrawal is not necessarily the same as consumption. A facility may withdraw water, use it in a cooling process and return some portion to the environment. Measuring only withdrawal can exaggerate permanent consumption; measuring only consumption can hide local infrastructure pressure or water-quality concerns.

The Green Software Foundation's Software Water Handbook explicitly highlights this distinction as one of the practical issues that the emerging standard needs to handle.

Electricity adds an invisible water footprint

A cloud workload also inherits some of the water footprint of the electricity system that powers it.

Thermal generation can require water for cooling. Hydropower interacts with reservoirs and evaporation. The exact relationship depends on the electricity mix, generation technology, geography and accounting boundary.

That makes a simple “data-center water usage” number incomplete if it excludes the electricity layer.

It also creates a difficult allocation problem: how much of a power plant's water impact should be attributed to one software workload?

SWI is explicitly trying to develop the data and methodology needed to make that calculation defensible rather than pretending the allocation problem does not exist.

Hardware manufacturing creates a third boundary

Semiconductor fabrication is another water-intensive physical process.

If software is evaluated only at runtime, that embodied water disappears from the calculation. Including hardware manufacturing makes the measurement more complete, but it also makes attribution much harder.

A workload might run on a GPU for years. The same physical accelerator can serve many models and organizations. Allocating its manufacturing footprint requires assumptions about utilization, lifetime and useful work.

This is one reason the SWI project should be understood as a measurement framework under development, not as a ready-made calculator.

Location changes the meaning of the number

The project's most consequential methodological question may be water stress.

Suppose two data centers each consume 100 liters.

The raw consumption is identical. The environmental meaning may not be.

The Green Software Foundation's September 15 Handbook announcement gives a concrete example: different water-risk frameworks can assign different impacts to the same physical consumption in different locations. The point is not that one framework is automatically correct. The point is that water assessment answers different questions depending on the chosen boundary and impact method.

This is why SWI's current page treats regional water stress as an open design question.

The Software Water Handbook is important because the data is messy

The Green Software Foundation transferred the Software Water Handbook into its project in September 2026.

The Handbook complements the specification by gathering data sources, worked examples, provider disclosures and methodological context.

That is significant because standards often fail at the boundary between a formula and the data required to populate it.

A formula can be elegant while the underlying inputs are missing.

For example, a team may know:

• total data-center electricity;
• annual site water consumption;
• a cloud region;
• and workload runtime.

It may still lack the workload-level energy allocation needed to make a defensible water estimate for one application.

The Handbook explicitly documents these kinds of gaps rather than hiding them.

Why this connects directly to AI infrastructure

The Observatory's AI data-center flexible-load analysis examines how large AI facilities could respond to constrained electricity systems.

SWI adds another physical constraint: water.

The two measurements are related but not interchangeable.

A data center can have an attractive electricity profile and still operate in a water-stressed location. A cooling design can reduce direct water consumption while the electricity and hardware supply chain retain other water impacts.

That means future infrastructure decisions may need a multi-resource view:

compute demand
     |
     +--> electricity
     +--> water
     +--> land
     +--> hardware
     +--> network

The Observatory's AWS Middle East resilience analysis shows another reason geography matters: infrastructure location affects more than latency and price. Physical risk, resilience and resource availability all become properties of the deployment environment.

SWI could become useful for workload placement, but that is not solved yet

If a water metric becomes reliable enough, software placement could eventually incorporate it alongside carbon and cost.

For flexible workloads, an optimizer might consider:

minimize
  cost + carbon + water impact

subject to
  latency
  capacity
  availability
  data residency
  reliability

That is an interesting future direction, but it should not be confused with current SWI capabilities.

The project is still working through measurement definitions and data availability. It does not currently provide a universally accepted workload-placement algorithm.

The hard problem is allocation, not arithmetic

Computing a ratio is easy once all inputs are known.

The hard questions are upstream:

• How much electricity did this workload actually cause?
• How much cooling water should be allocated to it?
• Which electricity-generation water factors apply?
• How should hardware manufacturing be amortized?
• Which water-stress method should be used?
• What happens when providers disclose only annual or regional totals?
• How should uncertainty be reported when one component is measured and another is estimated?

Those questions determine whether SWI becomes a credible engineering metric or merely another sustainability score.

What engineers can measure today

Even before the standard is finalized, teams can improve their observability.

Useful data to collect includes:

1. workload-level energy consumption where available;
2. data-center or region identifiers;
3. cooling technology and direct water-consumption data;
4. provider-reported water withdrawal and consumption;
5. hardware utilization and expected lifetime;
6. electricity-region information;
7. and the water-risk framework used for location assessment.

The goal is not to invent a private “SWI score” and present it as a standard. The goal is to preserve the inputs needed for a future defensible calculation.

Why this is meaningfully new for Digital Observatory

The Observatory already tracks AI data-center energy, cloud infrastructure and semiconductor systems. It did not have a dedicated observation of software water measurement as a standards-development problem.

SWI adds that missing measurement layer.

It is also a useful example of the Observatory's own methodology: separate what is measured from what is calculated, preserve context, and label interpretation and uncertainty rather than collapsing them into one number.

Limitations and uncertainty

SWI is currently a pre-draft specification. Its substantive design choices—including some treatment of electricity-related water and regional water stress—remain open to the working group and contributors. The Handbook is intended to improve practical data coverage, but missing workload-level allocation data can still prevent a defensible calculation.

The project should therefore not be used as evidence that a particular cloud, model or data center has a lower water impact unless the underlying measurement boundary, data quality and methodology are explicitly comparable.

Sources and further reading

• Green Software Foundation — Software Water Intensity
• Green Software Foundation — Software Water Handbook
• Purdue ECE — Yi Ding and the SWI project
• Environment Variables — Software Water Intensity discussion

Related Digital Observatory coverage: AI data centers as flexible grid loads, AWS Middle East data loss and geographic resilience, and Semicon 2.0 and India's semiconductor ecosystem.