The Data Center Problem Is Mostly a Zoning Problem

A Bright Meadow Group position paper

We are spending an extraordinary amount of time arguing about data centers.

They use too much electricity. They use too much water. They strain local infrastructure. They raise utility costs. They generate heat. They are ugly. They are loud. Artificial intelligence is destroying the planet.

Fine.

Now that everyone has finished shouting, can we please regulate the buildings?

Because most of the environmental problems associated with data centers are infrastructure problems — specifically, the problems created when a private industrial facility pushes part of its operating cost onto the surrounding community. Society already has a name for the body of rules designed to prevent exactly that.

Zoning.

We may need better zoning. We certainly need technically competent zoning — regulators who understand modern compute infrastructure well enough to write standards that survive a glossy environmental-impact presentation and three pages of carefully selected averages. But the underlying concept is old and settled. Your facility goes here. It may produce this much noise. It may discharge this material. It may consume resources within these limits. It must contain its hazards. It must build the infrastructure required to support its own operation.

Welcome to civilization.

Observe: Follow the Property Line

Bright Meadow Group begins every systems problem the same way: observe before designing, design before intervening. So observe the pattern that plays out every time a hyperscale facility comes to town.

The developer arrives and announces an enormous new demand. The municipality expands water treatment and distribution. The utility expands generation and transmission. Ratepayers finance substations. The facility reshapes the local load profile, land use, emergency response requirements, road traffic, and decades of utility planning. Then everyone gathers around a conference table to calculate how many jobs the project might create.

Wrong meeting.

The first meeting should be about the property line. What enters the property? What leaves it? What risks cross it? What infrastructure costs are being transferred to people who will never own a share of the facility?

Imagine a machine designed to spray hot oil across the factory floor. When management complains, the designer explains that a return line would have increased project costs. Nobody treats this as a philosophical disagreement. The machine is badly designed, and everyone in the room knows it.

Infrastructure that externalizes its operating costs is the same machine at municipal scale. We have simply grown so accustomed to subsidizing infrastructure-intensive development that asking a corporation to fully support its own industrial process now sounds radical. It sounds radical only because we have underwritten the alternative for so long.

You profit. You pay your operating costs. We should probably put that on a plaque somewhere.

Design: The Containment Standard

Once the system boundary is drawn, the design principle nearly writes itself. Bright Meadow Group proposes a single standard for large compute facilities:

A facility shall contain the environmental and infrastructure costs of its own operation to the greatest technically practical extent.

Call it the Containment Standard. Notice what it immediately does to the conversation.

Instead of asking whether a town has enough water for a data center, we ask why the data center requires a permanent draw from the town’s drinking-water system. Instead of asking whether the regional grid can absorb another 500 megawatts, we ask how much generation and storage the facility is providing for itself. Instead of debating whether ratepayers should fund new substations, transmission lines, pipelines, and treatment capacity, we ask a much simpler question: who needs the infrastructure?

The data center? Excellent. The data center can pay for it. This is accounting.

The critical design discipline is that regulation defines the boundary condition, and engineering solves the system inside the boundary. Two examples.

Water. Closed and highly recirculating systems are mature technology. Industry has recirculated cooling water for generations — aquaculture does it, industrial process systems do it, refrigeration moves thermal energy without pouring a river through the machinery. There are real tradeoffs: closed loops still require heat rejection, evaporative cooling is efficient but consumes water, dry cooling saves water at the cost of equipment, land, or electrical energy. Site climate matters. Waste-heat temperature matters. Water chemistry matters.

All of which is irrelevant to the regulatory question, because we do not need to design the cooling system from the zoning office. We need to establish the result:

The facility may not create a harmful permanent draw on local potable water resources.

There. Engineers may now begin engineering. Maybe the answer is closed-loop liquid cooling, or immersion, or a hybrid dry system. Maybe the facility treats wastewater, captures stormwater, builds storage, or feeds its waste heat into another process. Maybe the final design combines six systems. Wonderful. That is what engineers are for.

Today we run this backwards. Developers present the cheapest available design, and communities are asked whether they can tolerate its impacts. Of course the cheapest design appeals to the developer — the developer is only paying part of its costs.

Power. There is nothing magical about generating electricity. Solar works. Wind works. Hydro, geothermal, nuclear, natural gas, combined heat and power, waste gas, biogas — humanity has become remarkably good at all of it. Every technology carries constraints, environmental consequences, and safety requirements.

Good. Regulate those things. Can the facility generate safely? Can emissions be captured or controlled to standard? Are the scrubbers, filtration, containment, and monitoring systems installed and operating? Are regulators receiving data proving they are operating? Then generate the power.

The largest obstacle here is rarely electrical engineering. It is the inherited structure of utility territories, interconnection agreements, and the economic interests of companies that profit by moving electricity through their systems. Some of that structure exists for excellent reasons — nobody wants amateurs synchronizing homemade generators to the grid from a shed, because electrical systems kill people efficiently. But there is considerable distance between maintaining electrical safety and protecting an established business model, and we need to become very comfortable distinguishing the two.

A firm capable of financing billions of dollars in processors, networking, structures, and cooling is capable of financing professionally engineered generation. Let it. Require islanding capability where appropriate. Require protection systems, environmental monitoring, trained operators, fuel containment, emissions control, periodic inspection — whatever the engineering and the ecology demand. Then get out of the way.

Compute should follow energy. A data center should locate where energy can be produced efficiently and responsibly. It should never arrive in a community, announce an enormous new electrical demand, and wait for the public infrastructure around it to reorganize itself.

Intervene: Write the Pattern Once

This is where regulation earns its keep. Stop negotiating every data center as though humanity has never seen a server before.

Establish facility classes based on electrical demand, thermal output, water demand, and site impact. For large compute facilities, adopt a consistent standard set:

  • No harmful net impact on municipal potable water capacity.
  • No uncompensated public electrical infrastructure expansion.
  • Facility-scale resource monitoring, with public reporting of major water and energy flows.
  • Closed or highly recirculating cooling, except where a technically justified alternative demonstrates equal or lower ecological impact.
  • Continuous monitoring of regulated generation emissions.
  • Developer-funded construction of infrastructure required specifically for facility operation.
  • Emergency shutdown, containment, and islanding standards appropriate to the system.
  • Periodic independent inspection.

There will be regional differences — a data center in northern Pennsylvania faces a different environment than one in Arizona, and good regulation recognizes the environment it protects. But the pattern holds everywhere:

Contain your process. Measure your impacts. Pay your costs.

Communities built zoning in the first place because they understood that different activities create different burdens. A house differs from a steel mill. A grocery store differs from a refinery. And a hyperscale compute facility remains industrial infrastructure no matter how many people call it an office building with computers inside. Treat it like what it is.

None of this is an argument against compute — Bright Meadow Group has already made the affirmative case for public compute and resident dividends in The Data Center Dividend, and the case only strengthens when facilities carry their own weight. We need computation. Machine learning is already surfacing relationships across bodies of information no individual human could hold in working memory, with consequences for medicine, materials science, logistics, energy, and agriculture. Slowing that work because we failed to write a competent industrial zoning standard would be absurd.

We know how to move heat. We know how to generate electricity. We know how to recirculate water, monitor emissions, and meter consumption. None of this is an undiscovered branch of physics. The failure is administrative.

Then Can We Please Get Back to the Interesting Part?

Humanity is standing at the beginning of an extraordinary period in information science. There are serious questions ahead. How do we preserve provenance? How do we identify machine error? How do we prevent a model from laundering repeated misinformation into apparent consensus? How should attribution work? What should be open? How do humans and machines divide exploration, judgment, and responsibility?

Those are interesting problems. Those are new problems. Those are problems worth arguing about.

Instead, we are spending our time debating whether a building full of computers should be allowed to drain a municipal water system and make the neighbors finance a substation.

No. It should not.

Require the facility to contain its resource use. Require safe generation. Require responsible cooling. Monitor the systems. Enforce the rules. We have zoning. We have engineers. We have meters.

Fix the boring infrastructure problem. Then let’s get back to figuring out what the machines can teach us.

Spread the love

Related Posts