Engineer the Yes: A Systems Approach to Data Centers and Community Acceptance

A lot of data-center arguments are being forced into a bad frame.

One side says we need compute, jobs, tax base, and digital infrastructure. The other side sees a huge industrial facility coming to town and worries about electricity, water, noise, roads, property values, emergency services, and whether the public is being handed the costs while the developer keeps the upside.

The second group is not crazy.

A large data center is not just a private building on private land. It is a coupled infrastructure system. It touches the electric grid, water system, land-use plan, road network, emergency services, tax base, utility planning, and the daily life of the surrounding community.

That does not mean the answer must be no.

It does mean the standard for yes should be much higher than a polished presentation and a promise of progress.

The better question is this:

What would a serious systems-engineering plan for a data center look like if community acceptance were treated as a top-level requirement?

That question changes the whole debate.

First, "data center" does not automatically mean "AI factory"

I touched on this a few days ago in my article “Why Do We Need So Many Data Centers?”, but this point bears repeating.

Online arguments often collapse several different things into one scary label.

A data center is basically a physical facility that houses computing, storage, networking, power, cooling, security, and support equipment so digital services can run reliably. Those services may include cloud storage, banking, hospital records, streaming video, business software, e-commerce, telecom, government services, research computing, artificial intelligence, cryptocurrency mining, or ordinary enterprise IT. [1][2]

AI is part of the story, and for some new projects it is a very large part. AI-heavy facilities can have unusually dense racks, high power demand, and difficult cooling problems. But not every data center is an AI training site. Not every data center has the same workload. Not every site has the same impact.

That distinction matters because communities should not be asked to approve or reject a slogan. They should be asked to evaluate a real proposed system, in a real place, with real operating commitments.

The scale is now large enough to matter

The U.S. data-center electricity story has changed quickly.

Berkeley Lab and the Department of Energy report that U.S. data centers used about 176 terawatt-hours of electricity in 2023, roughly 4.4 percent of U.S. electricity use. Their projection range for 2028 is 325 to 580 terawatt-hours, about 6.7 to 12 percent of U.S. electricity depending on total demand growth. [3][4]

That is national context.

Local context is what residents feel.

A single large data-center campus can be a very large electric load. Modern hyperscale campuses are commonly discussed in the hundreds of megawatts, and some planned campuses are moving toward gigawatt scale. At that point the project is no longer just "another commercial customer." It is a utility-planning event.

So when people ask, "What happens to our grid?" that is a serious question deserving a serious answer.

When they ask, "Who pays for the substation, transmission line, or distribution upgrade?" that is a serious question.

When they ask, "What happens during a heat wave, drought, fuel shortage, or utility emergency?" that is a serious question.

The way to answer is not to shame the questioner. The way to answer is to design the project so the answer can be inspected.

What systems engineering is, and why it applies here

Systems engineering is the discipline of making complex things work as a whole.

NASA describes systems engineering as a methodical, multidisciplinary approach to the design, realization, operation, and retirement of a system. A system is not just hardware. It includes equipment, software, facilities, personnel, processes, procedures, interfaces, constraints, and life-cycle behavior. The key point is that the value and risk of a system often come from how the parts interact, not from any one part in isolation. [5]

That is exactly the right frame for data-center siting.

A proposed data center and its host community are not separate systems that merely happen to share a fence line. They become a system of systems.

The data center brings servers, cooling, backup power, transformers, fiber, security, staff, construction traffic, tax arrangements, and operating procedures.

The community brings an electric grid, water supply, roads, zoning rules, neighbors, emergency services, local politics, utility customers, taxpayers, and long-term land-use plans.

The important engineering happens at the interfaces:

• Data center to grid
• Data center to water system
• Data center to roads
• Data center to neighbors
• Data center to emergency services
• Data center to utility ratepayers
• Data center to local government
• Data center to future expansion plans

Those interfaces are where opposition usually forms.

That means opposition is not merely a public-relations problem. Often it is an interface-control problem.

If the project team treats the building as the system and the community as an external obstacle, it will tend to optimize the wrong thing. It may design a facility that works technically but fails civically.

A systems approach says the design object is larger: Data Center + Community.

The facility has to work, but the host system has to work too.

Acceptance is a design requirement

The central mistake is treating community acceptance as something that happens after the engineering is mostly done.

A systems engineer should put it near the top.

That does not mean every objection gets veto power. It does not mean every project must become perfect. It does mean acceptance has to be translated into requirements that can be designed, tested, monitored, and enforced.

In plain English:

Do not ask the community to trust the slide deck.

Show the load.
Show the water.
Show the noise.
Show the traffic.
Show the grid upgrades.
Show who pays.
Show the emergency plan.
Show the benefits.
Show the monitoring.
Show the enforcement.
Show the exit plan.

If those questions cannot be answered before approval, the design is not mature enough for approval.

I would make a proposed data center close six loops.

1. The power loop

The first loop is power.

A serious proposal should publish the expected load in terms ordinary residents can understand:

• Megawatts of expected load
• Annual energy use
• Peak demand
• Load ramp rates
• Expansion phases
• Whether the facility operates during local peak stress
• Whether it can reduce load during emergencies
• Who has authority to request or require curtailment
• Who pays for grid upgrades
• Will there be onsite power generation

This is where a lot of public trust is won or lost.

If a developer funds upgrades that also improve local reliability, that is one story. If costs are quietly shifted to ratepayers through utility planning, tariffs, or later recovery, that is another.

The Department of Energy has explicitly pointed to data-center flexibility, onsite generation and storage, and innovative rate structures as part of meeting rising electricity demand without turning data centers into a pure grid burden. [4]

That is the right direction, but the community should not accept vague language. It should ask for measurable commitments.

If the facility can curtail, how many megawatts can it drop?

How fast?

For how long?

How often?

Under whose dispatch authority?

With what penalties if it fails?

With what protection for ordinary ratepayers?

The North American Electric Reliability Corporation has been warning that emerging large loads, including data centers and other computational loads, are creating new reliability, planning, operations, security, and modeling challenges for the bulk power system. NERC-related summaries have warned that existing standards and planning practices were not originally built for the operating characteristics of these new large loads. [6]

That does not mean every project is dangerous. It means the power loop deserves serious engineering, not hand-waving.

2. The water and heat loop

The second loop is water and heat.

This is also where slogans fail.

Some data-center cooling designs use a great deal of water. Some newer designs can use little onsite water. Direct liquid cooling does not automatically mean high water consumption, because water use depends heavily on how heat is ultimately rejected from the facility.

Evaporative cooling, dry cooling, hybrid cooling, reclaimed water, local climate, drought rules, backup operating modes, and peak-day behavior all matter.

Uptime Institute's useful phrase is that "water is local." Each site has its own water signature, and a serious assessment has to examine local restrictions, competing water uses, watershed limits, cooling-system design, and climate. [7]

That is the standard communities should demand.

Annual averages are not enough.

People live through peak days. They live through drought restrictions. They live through hot afternoons when the grid and water system are already stressed.

A serious proposal should disclose:

• Annual water use
• Peak-day water use
• Water source
• Whether the water is potable, groundwater, surface water, or reclaimed water
• Expected use during drought conditions
• Discharge or wastewater impacts
• Cooling mode during extreme heat
• Whether expansion changes the water profile
• Whether power generation used to serve the data center creates indirect water demand elsewhere

The Environmental and Energy Study Institute notes that data-center water consumption is already a local concern in several communities and that some larger facilities can consume very large daily volumes depending on design and operating mode. [8]

That does not justify a blanket national answer. It argues for honest local accounting.

A data center in a water-stressed basin should face a different standard than one using reclaimed water in a water-abundant industrial district. The point is not to declare every project bad. The point is to stop pretending water is an abstraction.

3. The land, noise, and traffic loop

The third loop is what neighbors actually experience.

Calling a data center a warehouse misses the engineering reality.

These sites can bring cooling equipment, fans, chillers, transformers, backup generators, fuel systems, security lighting, substations, transmission corridors, fencing, berms, construction traffic, and heavy-haul road use.

Noise deserves special attention because ordinary compliance numbers can miss the lived problem.

A low continuous hum, tonal noise, low-frequency vibration, nighttime operation, and generator testing can be more irritating than a simple daytime dBA number suggests.

EESI has documented community complaints around constant hum, fans, cooling systems, generators, and local ordinances that were not designed for this type of 24/7 industrial sound profile. [9]

A serious proposal should include receptor-based acoustic modeling before approval and measured compliance after operation.

The plan should address:

• Setbacks
• Berms
• Acoustic walls
• Equipment selection
• Building orientation
• Low-frequency and tonal noise
• Nighttime limits
• Generator-test rules
• Construction traffic
• Road repair obligations
• Complaint response
• Corrective-action deadlines

If the answer is "we will fix it after people complain," the project has not closed the loop.

The community should not be used as the test range.

4. The workload loop

The fourth loop is the compute workload itself.

Not all compute has the same siting logic.

Some workloads are latency-sensitive. They need to be near users, networks, or existing cloud regions. Others are more flexible. Training, fine-tuning, batch processing, backup processing, rendering, analytics, and some AI workloads may be more movable in time or place.

That matters.

Flexible work can, in principle, be placed where power and cooling are abundant. It can be scheduled around grid stress. It can be curtailed during emergencies. It can be split across regions. Latency-sensitive work may need a different architecture, sometimes smaller and more distributed.

But this should not be treated as magic.

Workload flexibility has to be verified.

If a developer says the facility can curtail, the useful questions are concrete:

• Which workloads can be interrupted?
• Which cannot?
• How much load can be dropped?
• How fast?
• How long can reduced operation continue?
• How often can it happen?
• Who decides?
• What happens to customer commitments?
• Is there telemetry the utility or public authority can inspect?

A real curtailment commitment can make a large load less threatening.

A vague promise does not.

5. The resilience loop

The fifth loop is emergency behavior.

A community needs to know what the facility does during abnormal conditions:

• Grid outages
• Heat waves
• Droughts
• Water restrictions
• Fires
• Floods
• Fuel shortages
• Cyber incidents
• Utility emergencies
• Regional transmission constraints
• Local road closures

Does the facility curtail load?

Does it run generators? If so, what fuel, what emissions, what noise, and how often?

Does it compete with residents, hospitals, fire departments, or emergency services for fuel, water, repair priority, or road access?

Can any onsite storage or generation support critical local loads, or is it purely private backup?

There may be good answers.

But again, they need to be designed into the project, not improvised after approval.

6. The legitimacy loop

The sixth loop is legitimacy.

This is where many projects get into trouble.

A community is asked to absorb visible impacts. In return it hears about jobs, tax revenue, infrastructure, and economic development.

Sometimes those benefits are real.

Sometimes they are inflated.

The public deserves a net fiscal picture with and without abatements. It deserves plain distinctions between temporary construction jobs, permanent operations jobs, imported specialist labor, and actual local training or apprenticeship commitments.

It also deserves enforceable commitments.

That could include:

• Tax floors
• Road upgrades
• Local hiring or apprenticeship commitments
• Reclaimed-water commitments
• Public dashboards for power and water where security permits
• Independent noise monitoring
• Complaint resolution timelines
• Emergency coordination protocols
• Phase-by-phase expansion gates
• Decommissioning bonds
• Ratepayer-protection provisions
• Public reporting on compliance

Trust is not built by asking people to believe a slide deck.

Trust is built by making promises measurable and enforceable.

What a good approval gate looks like

Before a large data center is treated as locally acceptable, I would want seven gates answered in public language.

Grid gate: Can the utility or grid operator show a credible interconnection path, reliability impact, upgrade scope, timeline, operating limits, and cost allocation?

Water gate: Are annual and peak-day water uses acceptable in this watershed under drought and competing-use conditions?

Noise gate: Can the site meet strict receptor-based limits, including low-frequency, tonal, and nighttime concerns, with measured compliance after startup?

Cost-shift gate: Is any material infrastructure, reliability, water, emergency-service, or rate burden being hidden from residents or general ratepayers?

Land-use gate: Is the site compatible with surrounding uses, buffers, roads, transmission corridors, emergency access, and realistic expansion?

Emergency gate: Is facility behavior defined during outages, heat waves, droughts, fires, floods, fuel disruptions, cyber incidents, and utility emergencies?

Legitimacy gate: Can the public inspect the key impacts, benefits, monitoring, enforcement, and exit plan before approval?

Failing a gate does not always mean permanent rejection.

Sometimes it means redesign.

Sometimes it means a different site.

Sometimes it means a smaller first phase.

Sometimes it means the project is simply too big for that place.

That is what responsible siting looks like.

The standard communities should demand

A data center can be a local asset.

It can fund grid upgrades. It can use reclaimed water or low-water cooling where that is the right local choice. It can be placed in an industrial or brownfield area with real buffers. It can segment flexible workloads so some load can drop during grid stress. It can publish water and noise data. It can pay its way. It can support emergency planning. It can make expansion depend on performance, not on a blank check granted in phase one.

But if it will not show those things, residents should be skeptical.

The strongest public standard is not blanket opposition. It is conditional acceptance with teeth.

That position is neither anti-technology nor blindly pro-development.

It says yes is possible, but yes has to be engineered.

Show the load. Show the water. Show the noise. Show the upgrades. Show who pays. Show the emergency plan. Show the benefits. Show the monitoring. Show the enforcement. Show the exit plan.

If those loops close, many communities could reasonably say yes.

If they do not close, opposition is not anti-technology.

It is systems common sense.

[Disclaimer: Article was AI-assisted in: proof-reading, reference checking, artwork generation. Also, since systems engineering is a team sport and I'm just me, I held systems engineering discussions with AI to sketch out the rough Systems Engineering Plan this article is based on.]

Sources

[1] Cisco, "What is a data center?"
https://www.cisco.com/site/us/en/learn/topics/computing/what-is-a-data-center.html

[2] Cloudflare, "What is a data center?"
https://www.cloudflare.com/learning/cdn/glossary/data-center/

[3] Berkeley Lab, "Berkeley Lab Report Evaluates Increase in Electricity Demand from Data Centers"
https://newscenter.lbl.gov/2025/01/15/berkeley-lab-report-evaluates-increase-in-electricity-demand-from-data-centers/

[4] U.S. Department of Energy, "DOE Releases New Report Evaluating Increase in Electricity Demand from Data Centers"
https://www.energy.gov/articles/doe-releases-new-report-evaluating-increase-electricity-demand-data-centers

[5] NASA, "Fundamentals of Systems Engineering"
https://www.nasa.gov/reference/2-0-fundamentals-of-systems-engineering/

[6] American Public Power Association summary of NERC large-load white paper, "NERC Publishes Second Large Load White Paper"
https://www.publicpower.org/periodical/article/nerc-publishes-second-large-load-white-paper

[7] Uptime Institute, "Water is local: generalities do not apply"
https://intelligence.uptimeinstitute.com/resource/water-local-generalities-do-not-apply

[8] Environmental and Energy Study Institute, "Data Centers and Water Consumption"
https://www.eesi.org/articles/view/data-centers-and-water-consumption

[9] Environmental and Energy Study Institute, "Communities Are Raising Noise Pollution Concerns About Data Centers"
https://www.eesi.org/articles/view/communities-are-raising-noise-pollution-concernsabout-data-centers

Further reading

• Reuters, "US power use to beat record highs in 2026 and 2027 as AI use surges, EIA says"
  https://www.reuters.com/business/energy/us-power-use-beat-record-highs-2026-2027-ai-use-surges-eia-says-2026-05-12/
• EPRI, "Data Center Load Growth in Context"
  https://powering-intelligence.epri.com/load-growth.html