Legitimacy Is Infrastructure

Thesis

AI data centers are not bad by default. They are infrastructure.

But hyperscale AI campuses are not ordinary infrastructure either. They concentrate power demand, water anxiety, land-use change, construction disruption, tax politics, backup generation, noise, security opacity, workforce claims, local utility risk, hardware turnover, and strategic national capacity inside one physical site. That combination changes the burden of proof.

My thesis is simple: legitimacy is now infrastructure.

The answer is not PR. The answer is proof.

The stronger answer is a different build philosophy: design data centers more like football clubs and less like black-box compounds.

I do not mean fandom. I do not mean sportswashing. I do not mean stadium-subsidy politics. I do not mean putting a logo on a youth program while unresolved water, power, noise, tax, or land issues sit underneath the surface. I mean the opposite. A serious football club is rooted in place. It has a scoreboard. It has rituals. It has public criticism. It has visible failure. It has supporters who demand better training facilities, better recruitment, better coaching, better ownership, better governance, and better performance while still wanting the institution to survive.

That is the useful analogy for hyperscale AI infrastructure. The goal is not to make a town blindly love a data center. The goal is to build the institutional conditions under which residents have rational reasons to want the facility improved instead of removed.

Right now, many AI data centers do not have that relationship with the communities they enter. They are experienced as extraction without relationship: land, power, water, patience, silence, public capacity, and tax treatment go in; most of the upside goes somewhere else.

If frontier AI companies and hyperscalers keep building large, opaque compounds that communities experience only as walls, substations, construction traffic, secrecy, water questions, electricity-bill anxiety, backup generators, and vague promises about jobs, they should not be surprised when the public starts rooting for them to fail. That does not mean every critic is right. It means the companies left too much ambiguity unmanaged.

A data void does not stay empty. It fills with fear, rumor, politics, resentment, and sometimes conspiracy.

The industry needs category discipline. It needs to stop letting every water issue, construction issue, grid issue, noise issue, tax issue, e-waste issue, and AI anxiety collapse into one anti-AI object. It needs to separate real harm, construction failure, operating impact, exaggeration, misinformation, unresolved uncertainty, and strategic anti-build fatalism before those categories fuse into one permanent public story.

The crisis is not one issue.

It is what happens when many unresolved issues are allowed to become one public story.

That is not a communications problem in the small sense. It is an operating problem. It is a design problem. It is a permitting problem. It is a governance problem. It is a proof problem.

Do not let something that has nothing to do with your company ambitions become part of the narrative against your industry.

That sentence is blunt because the issue is blunt. If your company exists to build frontier AI systems, do not let a pipe strike, a missing construction meter, a bad stormwater inspection, a ratepayer cost-shift, a poorly muffled generator, a sloppy tax deal, or a weak community-benefit promise become the public's proof that your entire industry is institutionally reckless. These issues may be "non-core" to the model lab. They are not non-core to the facility. They are your responsibility the moment your project creates them.

The standard is not "data centers are fine." That would be lazy. The current public concern is not imaginary. People are looking at giant compounds, utility load, water headlines, AI anxiety, construction incidents, noise complaints, tax incentives, limited local upside, and vague reporting, and they are asking a rational question: why should my community carry this burden?

The right answer is not to tell them they are wrong.

The right answer is to make the infrastructure good enough across the board that the burden, benefit, and proof can survive public inspection.

The Ask

The ask is not complicated.

Build the data centers.

But build them like strategic infrastructure that has to survive public inspection, not like private compounds that only need to satisfy an internal launch schedule.

That means:

• publish the local proof package before the rumor does the work for you;
• separate construction water, operating cooling water, indirect power water, water quality, and utility capacity before the public collapses them into one scandal;
• show who pays for grid upgrades and what protects existing customers;
• prove the difference between backup generation, bridge power, and a local power plant;
• model noise at the receptors people actually live in, not only at the boundary that makes the spreadsheet look clean;
• treat heat rejection, liquid cooling, thermal storage, and heat reuse as public-impact design questions, not only facility-efficiency questions;
• make community benefit durable, funded, maintained, and visible after the launch event;
• define redesign and no-build gates before the project becomes too politically expensive to correct;
• protect legitimate security details without using security as a blanket excuse for civic opacity.

This is not a request to slow down for the sake of slowing down.

It is a request to stop confusing speed with thin proof.

The companies that can build frontier AI systems can also build a better public operating model for the facilities that make those systems possible.

The proof layer should be engineered with the same seriousness as the campus.

The goal is not to win a comment thread.

The goal is to prevent avoidable facility failures from becoming a referendum on AI itself.

Do not mistake this for a paperwork agenda. The artifact is not the point. The point is to make it impossible for non-model failures to become the public definition of AI infrastructure.

The Backlash Is Real

This is not a theoretical future problem.

Gallup reported in May 2026 that 71% of Americans opposed building AI data centers in their local area, including 48% who strongly opposed them. The same polling found that opposition to a local AI data center was higher than opposition to a local nuclear plant. The concerns were not random. People mentioned electricity, water, pollution, quality of life, utility bills, taxpayer cost, and broader AI anxiety.

That number should scare serious builders.

Not because public opinion should automatically veto every project. Not because the public is always technically right. Not because a viral local post is the same thing as hydrology, grid modeling, acoustical engineering, or utility-rate design.

It should scare them because it means the legitimacy layer is no longer a soft communications problem. It is becoming a hard buildout constraint.

You can already see the shape of it in local moratoriums, zoning fights, water-transparency bills, tax-incentive fights, utility proceedings, federal reporting proposals, and town halls. Some governance will be healthy. Some will be reactive. Some will be symbolic. Some will be wrong. But it is happening because the industry did not make the tradeoffs legible early enough.

This is the point where many companies reach for better messaging.

That is too small.

Messaging cannot solve missing proof. If the community is worried about water, show the source, type, withdrawal, consumption, discharge path, drought plan, local utility impact, and independent verification. If the community is worried about electricity prices, show the rate structure, new generation, grid upgrades, interconnection status, who pays, and what protects existing customers. If the community is worried about noise, publish the model, the monitoring points, the low-frequency and tonal analysis where relevant, the mitigation design, the testing schedule, and the complaint process. If the community is worried that jobs are a weak excuse for a massive industrial facility, stop pretending a generic jobs paragraph is enough.

You are not building a coffee shop.

You are building frontier compute infrastructure.

Treat it like that.

The public's knowledge gap is part of the risk. Polling does not prove that every concern is technically correct. It proves that public trust is low enough that projects can become politically fragile before the facts are sorted. That is the danger. When the proof layer is missing, people build their own theory of the project. Some of those theories will be wrong. Some will be directionally right. Some will be amplified by bad actors. Some will be shaped by legitimate past disappointments with utilities, developers, industrial projects, tax deals, and public-private promises.

You do not fix that by asking for trust on credit.

The credit is running out.

The Critics Are Not All Wrong

A serious pro-build paper has to begin here: many concerns are real.

The Lawrence Berkeley National Laboratory 2024 U.S. data center energy report estimated that U.S. data centers used about 176 TWh in 2023, equal to about 4.4% of U.S. electricity use, and projected a wide 2028 range depending on AI hardware, operations, and cooling assumptions. It also separated direct water consumption from indirect water consumption through electricity generation.

That does not mean "data centers are destroying the country." It means the subject is technical.

Water impact depends on source, withdrawal, consumption, watershed stress, cooling architecture, discharge path, drought mode, utility capacity, and timing. Grid impact depends on peak load, transmission, interconnection, generation, rate design, and whether the facility can flex or curtail. Carbon impact depends on hourly generation and physical grid conditions, not just annual renewable matching. Local impact depends on land use, noise, backup generators, construction traffic, substations, air permits, stormwater, tax treatment, and proximity to homes.

This is exactly why the discourse is so vulnerable.

The public sees huge buildings, hears "millions of gallons" or "as much power as a city," and has no trusted local proof package to inspect. The company sees a technically complex project and assumes a global sustainability report, a local open house, and a community donation will be enough.

That mismatch is the problem.

Data centers are not uniquely evil. They are not the only infrastructure that uses water, electricity, land, concrete, steel, tax incentives, skilled trades, political capital, and community patience. But hyperscale AI campuses concentrate these issues in a way that changes public perception and planning risk. A Target, Walmart, or Costco can create land-use and traffic issues. A hyperscale AI campus can reshape utility planning, transmission needs, local tax politics, water governance, regional emissions, and strategic industrial capacity. It deserves a different proof burden.

And this is where the industry has to be careful. The wrong pro-build posture is denial. The wrong opposition posture is fatalism. Denial says the concerns are fake. Fatalism says the sector is morally unrecoverable. Both are too easy.

The better posture is: make the facility worthy.

Some sites should pass. Some should be redesigned. Some should not be built. A pro-build movement that cannot say no to bad sites will lose credibility. A critical movement that cannot recognize good sites will become anti-build religion.

This paper is trying to build the middle path: disciplined buildout.

The Industry Is Not Starting From Zero

It would also be lazy to pretend hyperscalers have done nothing.

That is not true. The leading companies already publish efficiency metrics, water commitments, renewable procurement claims, circularity programs, facility design work, and community-facing language. Some of that work is real. Some of it is ahead of ordinary industrial practice. Some of it is too global or portfolio-level to answer a local town's question. All of those things can be true at the same time.

Google publishes data-center efficiency work, PUE reporting, 24/7 carbon-free-energy materials, and environmental reporting that includes data-center construction emissions. Microsoft has published sustainability reports, community-first AI infrastructure promises, water and cooling claims, and public discussion of the emissions pressure created by AI/cloud growth. AWS publishes PUE/WUE metrics, water-positive goals, and reverse-logistics/circularity language. Meta publishes sustainability data and site-level environmental reporting in some forms. The European Commission is moving toward data-center reporting and ratings. EIA has moved into data-center energy-use data collection. These are not nothing.

They are also not enough by themselves.

A corporate sustainability report is not a local proof package. A portfolio water-positive claim is not a peak-day water plan for a town. A fleet-wide PUE is not a ratepayer-protection mechanism. A 24/7 carbon-free-energy ambition is not proof that the facility has firm deliverable capacity during local grid stress. A circularity program is not proof that a decommissioned server leaving a campus is safe, sanitized, lawful, supportable, and useful. A community-first promise is not a maintained community asset.

This distinction matters because the paper should not strawman the industry. Serious builders have started building parts of the answer. The problem is that the answer is still too often fragmented:

• global metric where the town needs local proof;
• intensity metric where the community needs absolute peak demand;
• company promise where the public needs independent verification;
• annual average where the grid needs hourly behavior;
• launch announcement where the community needs maintenance;
• public-relations page where the planner needs an enforceable condition;
• security rationale where the public needs a civic-impact summary.

The next step is not to shame the industry for doing nothing. The next step is to make the good work locally inspectable and harder to abuse.

This is also where competitive advantage should appear. The strongest operators should want a higher public standard because it distinguishes them from weak operators. They should want a world where sloppy developers cannot hide behind the same generic "data center" label. They should want utility commissions, local governments, communities, and investors to see the difference between a serious site and a lazy one.

That is how a sector matures.

Airports did not become legitimate by saying no one should complain about noise. They built noise programs, flight procedures, monitoring, mitigation, and public interfaces. Industrial facilities did not become legitimate by saying discharge chemistry is too technical for the public. They built permits, monitoring, reporting, and enforcement paths. Data centers should not wait until every jurisdiction invents a separate panic-driven rule. The best operators can help define the proof layer before the bad operators define the backlash.

The claim here is not that current hyperscaler sustainability work is fake.

The claim is that portfolio legitimacy is not site legitimacy.

The site is where the public lives.

Category Discipline

The strongest idea in this paper is not "data centers are good."

It is not even "publish a better checklist."

The strongest idea is category discipline.

A serious builder may already know many of the individual tools in this paper. That is not the point. The point is that tools scattered across sustainability, permitting, utilities, construction, security, communications, and community teams do not add up to legitimacy unless they are wired together as one proof system before the narrative hardens.

Right now, the public argument often turns "data center" into one object. Water use, construction water, operating cooling, indirect power-generation water, grid upgrades, ratepayer risk, construction dust, brown-water allegations, backup generators, gas turbines, noise, tax breaks, limited permanent jobs, AI job anxiety, e-waste, and foreign strategic competition all get compressed into one moral symbol.

That compression is dangerous for everyone.

It is dangerous for communities because real harms become harder to fix when everything becomes one outrage object. A resident with brown water needs testing, source tracing, pressure logs, construction timelines, well data, utility records, and remediation. A generic debate about "AI water" does not fix their sink.

It is dangerous for builders because a fixable construction, metering, rate, noise, or stormwater problem can become evidence that the entire AI infrastructure project is anti-community.

It is dangerous for policymakers because blunt pauses and weak disclosure rules can either let bad projects through or freeze good projects unnecessarily.

It is dangerous for the country because strategic compute capacity can become politically fragile before the infrastructure is mature enough to defend itself.

The category changes the fix. It does not erase the duty to fix.

That sentence matters.

The first job is not persuasion. The first job is classification.

A water-consumption complaint, a stormwater violation, a wetlands permit, a construction-metering failure, a wastewater-discharge concern, and a drought-basin conflict are not the same claim. Treating them as the same claim helps both bad PR and bad criticism.

But again, category discipline is not responsibility laundering. A company cannot say "that was a contractor issue" and then act confused when the public associates it with the project. The community does not experience your category map. The community experiences dirty water, higher bills, trucks, dust, hum, secrecy, and confusion. The burden is on the builder to make the categories legible before the public has to infer them from headlines.

If a pipe strike, missing construction meter, bad stormwater inspection, unclear ratepayer exposure, or poorly muffled generator becomes the public's proof that AI infrastructure is reckless, that is not because the incident was too small. It is because the proof layer was too weak.

Water

Water is the easiest issue to distort because "gallons" feels concrete even when the category is missing.

Construction water is not operating cooling water. Operating cooling water is not indirect water consumed through electricity generation. Withdrawal is not consumption. Potable water is not reclaimed water. Reclaimed water is not magic. A basin-level stress problem is not the same as a national water-use statistic. A brown-water complaint is not automatically proof of operating cooling contamination. A water-positive portfolio claim is not an answer to a local pressure-loss allegation.

EPA's data-center water materials and water-related permit guidance already support this basic discipline. EPA separates operational water management from water-related permitting, construction stormwater, alternative supplies, wastewater, reclaimed water, discharge, and coordination with utilities and communities.

That distinction should become public architecture.

Construction water includes temporary use for dust control, grading, compaction, concrete work, hydrostatic testing, equipment washdown, worker facilities, temporary lines, hydrant meters, trucks, and site-prep operations. Construction water-quality risk includes erosion, sediment, turbidity, dewatering, concrete washout, runoff, oil and grease, solid waste, sanitary waste, and disturbance near public water systems or private wells.

Operating cooling water is different. It includes evaporative cooling makeup, blowdown, treatment streams, closed-loop losses where relevant, domestic water, discharge, and wastewater or pretreatment obligations.

Indirect electricity water is different again. That is water consumed at power-generation sources because of the electricity used by the facility. LBNL estimates that indirect water can be much larger than direct site water nationally, but it occurs at the power-generation locations and depends heavily on grid mix and generation type. It matters, but it is not the same civic question as whether a specific town's utility has enough peak-day water capacity.

This is why public proof has to be a ledger, not a slogan.

A serious water proof package should include separate ledgers for:

• construction water;
• operating cooling water;
• domestic/site water;
• reclaimed/non-potable water;
• groundwater or surface-water withdrawals;
• discharge and blowdown;
• stormwater/dewatering;
• indirect power-generation water;
• drought mode;
• peak-day demand;
• withdrawal versus consumption;
• basin or utility stress.

If residents show jars of brown water, do not answer with a global sustainability slide. Do not answer a brown-water complaint with a water-positive portfolio claim. Do not answer a construction-water scandal with an operating-cooling talking point.

Answer the category:

• where was the baseline sample?
• what changed?
• which line, well, meter, ditch, pond, hydrant, or system was involved?
• what was the construction timeline?
• were there pressure drops?
• were there main breaks?
• were there stormwater or sediment events?
• what did the lab test?
• who verified it?
• what is still unknown?
• what fix was triggered?

AI infrastructure does not magically poison water. Careless construction, weak metering, bad stormwater control, utility-capacity mistakes, and opaque cooling choices can absolutely damage trust and sometimes water systems. Hyperscalers have to prove the category early enough that real harm gets fixed and sloppy narrative collapse does not become the public's only model of what happened.

The Fayette County/QTS water story is useful here, but it has to be handled carefully. The public story traveled as a data-center water scandal. Fayette County's own clarification framed the issue around construction-period use, billing, metering transition, and county tracking rather than a proved operating-cooling contamination incident. Local reporting still treated the underlying governance failure as real and trust-damaging. Both parts matter. The narrow facts may be more complicated than the headline; the trust damage is still real.

Do not make residents reconstruct the category from letters, leaks, political statements, and viral clips. Publish the category evidence.

Water quality allegations should have a higher proof threshold than water-use complaints. If someone claims water was contaminated, the evidence should identify the pollutant or physical parameter, the measured concentration, the pathway, whether the issue was construction or operation, the agency record or lab result, the responsible party, and the remedy. If someone claims a facility used too much water, the proof package should identify the source, volume, peak day, basin stress, utility capacity, drought plan, withdrawal, consumption, and discharge.

Those are not the same investigation.

This is not impossible. This is the cost of wanting to build at this scale.

Scale Comparisons Do Not Settle Legitimacy

Agriculture uses far more water than data centers nationally. That is true.

But if the industry reaches for almond math every time a town asks about its aquifer, it will deserve the distrust it gets. The answer is not better whataboutism. The answer is better accounting.

USGS water-use sources show that irrigation and thermoelectric power dominate national water-use categories. LBNL's 2024 report estimated U.S. data centers directly consumed about 66 billion liters of water in 2023, with much more indirect water through electricity generation. At the national scale, data-center direct water consumption is tiny compared with crop irrigation.

That fact is useful for scale. It does not settle local siting.

The serious water question is not whether data centers use more water than farms. They do not, nationally. The serious question is whether a specific facility is asking a specific basin, utility, aquifer, or groundwater system for a volume, timing, and quality of water that the community can afford.

Almonds are a useful comparison only if they make us more honest.

Almond water-footprint research shows that almonds can be water-intensive, economically significant, nutritionally real, export-heavy, and regionally variable. That does not make data centers harmless. It makes the water argument more complicated than a meme.

Do not compare green rainwater embedded in an agricultural footprint to potable municipal cooling water as if those gallons have the same local meaning. Green water, blue water, grey water, potable supply, reclaimed water, surface water, groundwater, interbasin transfer, seasonal peak demand, discharge, evaporation, and return flow all matter.

A data center that uses reclaimed water is starting from a stronger position than one that cools on drinking water. But reclaimed water still needs proof: how much, from where, with what backup, through what treatment system, and at whose opportunity cost? Non-potable does not mean impact-free. Closed-loop does not mean no water issue. Water-positive does not mean local water-neutral unless the basin, timing, method, and verification support that claim.

Scale comparisons can correct bad math. They do not create legitimacy.

This is also true outside water. The defense budget can be a huge absolute number while being lower as a share of federal outlays or GDP than in earlier eras. That does not make criticism invalid. It means public accounting has to handle both relative scale and absolute burden. A strategically important function still has to rationalize its cost, waste, opacity, and local impact. The lesson for AI infrastructure is not to borrow the defense sector's opacity. It is to avoid it.

Data centers should use comparisons to improve accounting, not to escape proof.

The clean standard is simple:

What water, where, when, from what source, for what value, under whose governance, with what public transparency, and with what fallback if the model is wrong?

That question is harder than almond math.

It is also more useful.

Grid And Ratepayers

Water is emotionally vivid because people can see a sink, a well, a stream, or a water bill. Grid impact is less visible until it becomes a rate case, an interconnection fight, a substation, a transmission line, a generator fleet, or a reliability warning.

That makes it easier for the category to get blurry.

A data center can be nationally small and locally massive. A facility asking for hundreds of megawatts is not merely "adding some load." It can become a planning event for a utility, a transmission problem for a region, a cost-allocation fight for ratepayers, and a political problem for local officials who have to explain why a private facility gets capacity while residents worry about bills.

The strongest version of the grid concern is not "data centers always raise everyone's bills." The stronger version is:

Large, concentrated, fast-growing loads can create generation, transmission, distribution, and capacity-market costs. Whether those costs hit ordinary customers depends on tariff design, interconnection rules, cost causation, tax policy, utility planning, load flexibility, and whether assets become stranded if data centers leave or underperform.

EIA's 2026 electricity forecast, IEA's Energy and AI work, NERC's 2025 Long-Term Reliability Assessment, and PJM's 2026 market-design discussion all point toward the same reality: large new loads are now central to grid planning, reliability, and cost allocation.

This is where hyperscalers have to be bluntly competent.

Do not make households subsidize your load by accident, opacity, or weak cost allocation. Do not let the public discover through a utility proceeding that the project needs upgrades everyone else might pay for. Do not present an annual renewable-energy procurement claim as if it answers local peak load, transmission constraints, ratepayer exposure, or emergency reliability. Do not hide behind the word "clean" if the facility still needs backup generation, delayed interconnection, or temporary on-site fossil generation that changes local air and noise burdens.

The grid proof package should separate:

• requested IT load from total facility load;
• initial load from full buildout;
• average load from peak demand;
• annual clean-energy procurement from hourly/local grid impact;
• interconnection queue position from actual deliverability;
• project-specific upgrades from socialized grid upgrades;
• backup generators from continuous on-site generation;
• demand response from vague "flexibility";
• ratepayer protection from general economic benefit.

Use the boring terms because the boring terms are where the truth lives:

• cost causation;
• large-load tariff;
• interconnection deposit;
• transmission and distribution upgrade allocation;
• non-firm or interruptible load;
• capacity-market exposure;
• demand-response or flexibility bargain;
• stranded asset protection;
• tax incentive and abatement disclosure.

If the company is building, bringing, or buying power, show the mechanism. If the company is paying for delivery infrastructure, show the cost allocation. If existing customers are protected, show how. If the facility can curtail during grid stress, show the rule, the trigger, and the consequence. If the facility cannot curtail because uptime requirements are absolute, say that honestly and design around it.

This is not an anti-compute argument. It is the opposite. Strategic compute cannot rest on a ratepayer story that looks extractive. If a household sees higher bills, hears about a tax break, and then sees a walled compound with limited permanent jobs, you have built the perfect narrative machine against yourself.

Ratepayer protection is not anti-compute. It is how compute avoids becoming a public-utility backlash.

Carbon, Firm Power, And Flexible Workloads

Clean-energy claims need discipline.

Annual renewable matching can be useful. It is not the same as 24/7 carbon-free operation. It is not the same as local grid adequacy. It is not the same as a ratepayer-protection mechanism. It is not the same as physical deliverability during the hours when the facility is actually drawing power.

EPA's 24/7 hourly matching explainer supports this distinction: hourly matching tries to align generation and consumption by time and region, while annual matching is a less granular accounting model. GHG Protocol Scope 2 guidance is important for accounting. But accounting is not the same as a local deliverability proof.

A hyperscaler that wants trust should publish which claim it is making:

• annual procurement;
• hourly or regional 24/7 carbon-free energy;
• physical delivery;
• firm generation;
• battery-backed flexibility;
• demand response;
• backup resilience;
• bridge power;
• facility-level load shaping.

Those are different promises.

If the company says the facility is clean, ask when. If it says the facility is flexible, ask which workloads. If it says it brings power, ask whether that power is deliverable during the hours the facility actually draws load.

Flexibility is real, but it is not magic. EPRI's grid-flexible data-center work and National Grid's 2026 AI-grid flexibility trial point toward a real design space. But a trial is not proof that all AI workloads can flex. Some workloads can move. Some can slow. Some can checkpoint. Some cannot be interrupted without service or safety consequences.

Vague "we will optimize workloads" language is not grid relief.

Flexibility is real only if it is measurable, contracted, dispatchable, and tied to consequences. The proof should include curtailable MW, duration, response time, event limits, protected workloads, penalty, and post-event report.

The same category discipline applies to backup power. Backup generators are not automatically scandalous. Hospitals, airports, telecom sites, water utilities, and many critical systems have backup power. But a campus with dozens or hundreds of generators has to prove testing schedules, emissions, fuel handling, simultaneous-run assumptions, emergency scenarios, and noise. If those generators shift from rare backup to frequent operation or continuous bridge power because the grid connection is late, the category has changed. Say so.

Do not let "resilience" become a soft word for an under-explained local power plant.

No-build or redesign triggers should be blunt:

• annual renewable matching is presented as the answer to a local peak-load or ratepayer problem;
• the project cannot show who pays for grid upgrades;
• the facility is marketed as flexible but cannot identify a curtailable share, response time, or performance consequence;
• bridge power turns into continuous fossil generation without air, noise, emissions, and community review;
• the site depends on speculative generation, transmission, or interconnection timelines;
• the facility adds large inflexible load in a constrained region without firm deliverable capacity or enforceable demand response.

If the facility is truly a strategic asset, it should not be afraid of this proof.

Thermal Design, Heat Reuse, And Subsurface Options

Cooling is not only a water issue.

It is also a heat-rejection issue.

A hyperscale AI campus turns electricity into heat at industrial scale. The proof package should show where that heat goes: air, water, ground, district-energy loop, nearby building, greenhouse, aquaculture site, seasonal storage, or simply the neighborhood air.

This is where the underground and geothermal instinct matters, but it needs precise categories.

Do not call every underground idea "geothermal." Ground-source exchange, reservoir thermal energy storage, aquifer thermal energy storage, borehole thermal storage, mine or cavern reuse, cold-water heat exchange, liquid cooling, district heat reuse, utility-scale heat pumps, and microclimate plume mitigation are different things. They have different geology, permitting, reliability, cost, water, energy, and maintenance realities.

The correct public question is not "why did you not build the whole data center underground?"

The better question is:

Did the company run a site-specific thermal opportunity review before final design lock?

That review should ask:

• how many MW of heat the facility will reject at each phase;
• whether the heat is carried mainly by air, water, refrigerant, or liquid loops;
• whether higher-temperature liquid return loops would make heat capture easier;
• whether the site has nearby heat users: hospitals, campuses, public buildings, greenhouses, aquaculture, industrial users, affordable housing, or district-energy systems;
• whether pipe corridors, heat-exchanger tie-ins, valve vaults, mechanical-room space, and rights-of-way are being reserved before concrete makes future heat reuse expensive;
• whether the downwind neighborhood thermal plume has been modeled, not only the facility's internal cooling performance;
• whether cooling-equipment exhaust orientation, greenbelts, tree canopy, shade, parks, or acoustic/thermal barriers can reduce local heat exposure;
• whether the site was screened for reservoir thermal energy storage, aquifer thermal energy storage, ground-source exchange, mine/cavern reuse, brownfield industrial reuse, or other subsurface strategies;
• whether the answer is no, and why.

The answer will often be no. That is fine. Geology may kill the idea. Groundwater and permitting may kill the idea. Distance to useful heat users may kill the idea. Reliability requirements may kill the idea. Cost may kill the idea. A cold-water or underground advantage that works in one region may be fantasy in another.

But "we were moving fast" is not a serious answer.

NLR and NREL's 2025 reservoir thermal energy storage analysis shows that subsurface thermal storage for data-center cooling is a real technical research lane, not a random internet idea. DOE's Better Buildings showcase on Iron Mountain's Boyers facility shows a U.S. data-center example using a former limestone mine and underground reservoir for cooling. Mine and mountain-hall examples like Lefdal Mine and Green Mountain show the same broad category in favorable Nordic conditions. These examples do not prove that every hyperscale AI campus should go underground. They prove the option space is real enough to screen.

Heat reuse is also not theory. Microsoft's heat-reuse material describes capturing data-center waste heat through heat exchangers and moving it through water loops to district heating, homes, greenhouses, fish farms, and similar users, while also acknowledging a practical constraint: many data centers are too far from communities for heat reuse to be useful. That caveat matters. Heat reuse is not a press-release word. It is a geography, pipe, temperature, off-taker, utility, and maintenance problem.

Local heat should also be treated as a public-impact category. ASU's 2026 Phoenix field study summary reported measurable downwind neighborhood warming around data centers and recommended design modifications, higher-resolution modeling, and green infrastructure to reduce the thermal footprint. That does not mean every data center creates the same plume. It means the plume is measurable enough that pretending it does not exist is lazy.

The next step is to treat the facility as an integrated thermal machine.

The chip package, rack, row, slab, mechanical room, utility corridor, and campus heat sink should not be separate afterthoughts. Direct-to-chip liquid cooling, cold plates, immersion where appropriate, rear-door heat exchangers, warm-water loops, coolant distribution units, phase-change storage, radiant or thermally activated building elements, and predictive controls can all participate in the same goal: capture heat closer to the source, reduce peaks, reduce fan duty, improve heat reuse, and make the data hall less acoustically punishing for workers.

That does not mean the building replaces cooling. A concrete slab does not solve a GPU package hot spot. A fancy wall material does not erase the need for cold plates, pumps, controls, heat exchangers, leak detection, corrosion control, and maintenance access. Building-scale thermal mass can buffer and shift load. It cannot make hyperscaler heat disappear.

This distinction matters because "liquid cooling" is not one thing. Water or propylene-glycol coolant usually means a closed loop through cold plates, manifolds, coolant distribution units, rear-door heat exchangers, or facility heat exchangers while the electronics remain dry. Immersion is a different architecture and normally uses dielectric fluids. OCP's propylene-glycol guidance is explicitly about single-phase cold plate-based liquid-cooled racks. Do not let loose language turn a serious design category into a public misunderstanding.

Humidity and dew point also matter. Radiant or thermally activated building systems can be useful in ordinary buildings, but in a data center a cold surface in the wrong place can create condensation, corrosion, mold, electronics risk, and maintenance failure. If a builder wants to use thermal mass, hydronic slabs, phase-change storage, or higher-conductivity materials, the proof package should show dew-point controls, leak detection, isolation valves, corrosion plan, humidity model, and what zones are intentionally kept away from sensitive electronics.

This is the 3-4 month opportunity.

Not "build the entire facility underground in 90 days." That is unserious.

The low-regret move is to spend a few months before final design lock proving what options are real and preserving the ones that might matter later:

• run the thermal opportunity screen;
• model the downwind plume;
• reserve pipe corridors and mechanical tie-ins;
• design for liquid-loop or warm-water-loop compatibility where appropriate;
• identify nearby heat users before the site plan is frozen;
• screen subsurface thermal storage and ground/water-source options;
• plan a post-ramp cooling optimization sprint for setpoints, fans, pumps, economizer hours, liquid-loop temperatures, predictive controls, and maintenance tuning.

This is not anti-speed.

It is how you avoid moving so fast that you pour concrete over your own future optionality.

The point is not that every facility must become a subterranean thermal masterpiece. The point is that frontier compute should not leave obvious thermal design gains on the table because the construction schedule was optimized only for going live.

If you are building strategic infrastructure, thermal design is part of legitimacy.

Show the heat.

Show where it goes.

Show what you considered before you rejected it.

Land, Ecology, And Embodied Carbon

These are not warehouses.

A hyperscale AI campus is not just a building with servers inside. It is a land conversion, a material bill, a drainage change, a road and substation project, a viewshed, a noise profile, a heat-rejection machine, and a long-lived industrial neighbor.

This needs to be said plainly because the public does not experience "data center" as an abstract compute unit. The public experiences acreage, roads, fences, grading, stormwater ponds, substations, transmission, diesel tanks, generators, truck traffic, security gates, construction dust, tree removal, light spill, and the feeling that a familiar place became an industrial object.

Land is not a footnote.

EPA's 2026 guidance on Superfund and Brownfield redevelopment for AI data centers is important because it shows a better siting direction without making it easy. Brownfields and Superfund sites can have compatible features: existing infrastructure, industrial zoning, less greenfield conversion, and possible reuse of disturbed land. But they also need site compatibility, cleanup-standard review, engineering controls, liability analysis, water and energy access, conservation practices, and community fit.

Brownfield is not a permission slip. It is a siting strategy that still needs proof.

The proof package should include:

• greenfield, brownfield, Superfund, industrial infill, or conversion status;
• zoning and adjacent uses;
• acreage by phase;
• impervious surface;
• building footprint and expansion envelope;
• roads, substations, transmission, pipelines, fiber paths, and staging areas;
• wetlands, waters, floodplain, wildfire, geotechnical, habitat, threatened/endangered species, and cultural resources where applicable;
• stormwater volume, dewatering, concrete washout, erosion and sediment controls;
• tree canopy, heat-island effect, light spill, visual buffering, and night operations;
• embodied carbon estimate by structure, concrete, steel, timber, equipment, construction vehicles, and generators;
• low-carbon material specification and verification;
• deconstruction or reuse plan for existing structures if any;
• post-construction land stewardship obligations.

Company reporting already shows why this matters. Google has disclosed rising data-center construction emissions and identified construction steel, concrete, vehicles, and generators as material sources in its environmental reporting. Microsoft has acknowledged that AI/cloud infrastructure growth complicates its emissions progress and has discussed lower-carbon construction approaches. Those are company claims and disclosures, not proof that every project is good. But they show the issue is real enough that the leading companies are not starting from zero.

The industry should treat land and embodied carbon with the same seriousness it treats GPU supply chains.

No-build or redesign triggers:

• avoidable wetland or habitat conflicts are treated as late paperwork rather than siting constraints;
• stormwater and sediment controls are weak or unverifiable;
• a greenfield site is chosen despite a viable lower-conflict industrial or brownfield alternative;
• embodied carbon is ignored while the project claims climate leadership;
• visual, light, traffic, and road impacts are dismissed because the facility is "just a data center";
• cleanup, cap, contamination, or engineering-control issues at a brownfield site are hidden behind the word "reuse."

If you want to build frontier infrastructure, treat the dirt like it matters.

It does.

Noise

Noise is the cleanest example of why this paper should not defend data centers in the abstract.

A well-sited, well-designed data center can be a quiet industrial neighbor. A badly sited campus can become a 24/7 low-frequency machine next to someone's bedroom.

Those are not the same thing.

The right answer is not to call residents hysterical. It is not to treat every viral video as proof that the sector is unbuildable. It is to separate the source categories and prove the acoustic design.

Noise around data centers usually does not come from one thing called "the servers." It can come from construction, cooling systems, substations, transformers, backup generators, continuous on-site generation, truck traffic, and low-frequency or tonal sound that feels different indoors at night than it looks in a daytime dBA snapshot.

EESI's 2026 coverage of data-center noise concerns, Virginia JLARC's data-center report, and industrial noise-control references like NIOSH's Industrial Noise Control Manual all point toward the same principle: noise is an engineering, siting, measurement, and accountability problem.

It is not a vibes issue.

It is also not solved by telling residents the equipment is compliant.

If the project runs all night, the burden is on the developer to prove the acoustic design all night.

The proof package should include:

• baseline ambient sound study before approval;
• modeled worst-case scenarios: hottest design day, full cooling load, maximum simultaneous generator testing, emergency generator use, continuous on-site generation if proposed, and nighttime low-ambient conditions;
• source sound-power data for cooling equipment, substations, transformers, generators, and turbines;
• metrics beyond single dBA snapshots where needed: LAeq, Lmax, nighttime receptors, dBC or Z-weighted screening, octave or one-third-octave bands, tonal penalties;
• construction noise plan: hours, haul routes, mufflers, barriers, resident notice, complaint response;
• generator testing limits and no routine peak-shaving with diesel generators unless explicitly permitted and modeled;
• mitigation design: layout, building-as-barrier orientation, acoustic enclosures, silencers, mufflers, acoustic louvers, absorptive barriers, berms where useful, vibration isolation, low-noise equipment procurement, and retrofittable space;
• post-construction verification before full ramp-up;
• permanent or periodic monitoring at property lines and representative sensitive receptors;
• complaint-response system with a named contact, response timeline, independent review trigger, and enforceable retrofit obligations.

It should also include the inside of the facility.

Worker noise exposure is not the same issue as neighborhood noise, but it belongs in the same seriousness category. ASHRAE's liquid-cooling paper discusses acoustic pressure from higher airflow and hearing-protection thresholds inside data centers. OCP's Open Edge liquid-cooling feasibility paper found sound-level reductions in a tested mixed liquid/air design when fan configurations changed, while noting that more certification would be needed. NIOSH's engineering-control guidance points toward the right hierarchy: reduce noise at the source before relying on PPE.

A hyperscaler should therefore publish an indoor acoustic design target for occupied data halls and maintenance zones. Not sensitive operational telemetry. Not security details. A target. What sound levels are expected? Which areas require hearing protection? Which sources dominate: server fans, pumps, coolant distribution units, chillers, dry coolers, transformers, generators, turbines, or vibration paths? How does the design reduce fan duty, isolate hydraulic and mechanical noise, and protect workers during maintenance and ramp events?

Quiet outside and punishing inside is not excellence.

That same standard should shape the operator's sense of craft.

The best car makers do not treat cabin noise as a footnote. Comfort is part of quality. Acoustic refinement is part of the product. A stationary campus does not need to sound like it is announcing itself in traffic. It should not need a mechanical signature to prove it exists.

This is an analogy, not an engineering equivalence. An Audi cabin is not a cooling campus. A twin-scroll turbo is not a data-center thermal system. But the instinct matters. Other industries have spent decades treating sound, vibration, heat, airflow, combustion, exhaust, sealing, insulation, and human experience as engineering problems. Hyperscalers should import that seriousness instead of treating community annoyance as irrational.

Quiet infrastructure is not softness. It is build quality.

Do not buy goodwill with benefits while leaving the hum in people's bedrooms.

And do not hide a power plant inside the phrase "associated utility infrastructure." If a site runs turbines continuously because grid interconnection is delayed, that is not ordinary backup generation. That is a data center plus on-site generation, and the acoustic, air, permitting, and community burden should be treated that way.

Proof-Before-Permission

The central operating principle is simple:

Build faster by showing more work.

That sounds contradictory only if you think speed means hiding complexity until late-stage permitting. In reality, late ambiguity is slow. Late water panic is slow. Late grid fights are slow. Late noise modeling is slow. Late secrecy is slow. Late lawsuits are slow. Late community benefit promises are slow.

The pro-build argument should not be anti-regulation by reflex. The better argument is more serious:

1. show the site-specific proof;
2. identify the risks;
3. redesign what needs redesign;
4. kill the sites that should not be built;
5. publish enough evidence that misinformation has less room to breathe;
6. then build quickly.

The argument only works if the operating standard underneath it is real. Proof-before-permission is the skeleton: site screen, water ledger, grid ledger, land/ecology ledger, acoustic proof, community-benefit ledger, transparency tiers, internal red-team, no-build gates, and post-occupancy review.

A serious hyperscale AI campus should have:

• strategic site screen;
• public scoping and affected-community map;
• water and cooling proof;
• grid, power, ratepayer, and carbon proof;
• land, construction, ecology, air, and noise proof;
• community legitimacy and maintained-benefit proof;
• internal red-team/cross-exam approval;
• operating dashboard and post-occupancy review.

The proof clock should be visible.

Before site lock, publish the category map: water source, grid path, land constraints, sensitive receptors, high-level load range, construction envelope, and known no-go risks.

Within 30 days of formal local engagement, publish the first proof ledger: what is known, what is estimated, what is withheld for security, what third parties need to verify, and what would force redesign.

Within 90 days, publish the serious version: water ledger, grid/ratepayer ledger, construction controls, acoustic model, thermal opportunity screen, benefit ledger, transparency tier matrix, and ownership map.

Before construction, publish baselines: water quality where relevant, private-well conditions where relevant, stormwater controls, road conditions, ambient sound, receptor map, ratepayer-protection mechanism, and complaint/escalation route.

Before full ramp, publish post-construction verification: noise versus model, water use versus model, generator testing, cooling behavior, construction incidents, unresolved complaints, and corrective actions.

One year after operations begin, publish the post-occupancy review.

This is how "show more work" becomes an operating system instead of a slogan.

Some of that can be public. Some of it should be summarized. Some of it may need regulator or third-party confidential review because physical security, network security, supplier details, or exploit-relevant infrastructure cannot be disclosed fully. But security-aware transparency is not the same as secrecy.

Publish what can safely be published. Aggregate what must be protected. Give utilities, regulators, and independent auditors protected access where public precision creates real risk. But do not use security as a blanket excuse to hide water, energy, noise, cost-shifting, or benefit-delivery performance.

If you are building systems that need five-nines reliability, model-eval discipline, security review, supply-chain controls, and live-site incident response, you can also build a public proof layer for water, noise, ratepayer protection, and community benefit.

Security-Aware Transparency

The public does not need your network topology to know whether the water claim is real.

That is the entire point.

Security-aware transparency should be a tier system, not a binary argument between "publish everything" and "trust us."

This is not a loophole for secrecy. It is the opposite. It makes secrecy narrower and more defensible.

Security-aware transparency says: publish civic impacts, aggregate or delay data when precision creates risk, give protected access to people who need exact detail, and keep exploit-relevant details restricted.

If the company cannot publish enough to prove water source, peak demand, ratepayer protection, acoustic performance, generator operation, and community-benefit delivery, the problem is not public curiosity. The problem is that the project does not yet have a legitimacy architecture.

Who Owns The Proof

A proof package cannot be a pile of documents with no owner.

One reason infrastructure fights become chaotic is that every actor can point to someone else. The developer says the utility owns the grid study. The utility says the regulator owns cost allocation. The county says the state owns water rights. The state says the local government owns zoning. The contractor says construction incidents are subcontractor issues. The company says the landlord or colocation operator owns the building. The tenant says it only leases capacity. The community hears all of that and concludes, reasonably, that nobody owns the whole bargain.

That cannot work at hyperscale.

The proof model needs ownership:

• Hyperscalers and operators own the site proof, tenant/operator clarity, funding, public dashboards, construction discipline, benefit commitments, no-build/redesign triggers, and post-occupancy review.
• Utilities own load-service studies, interconnection facts, reliability analysis, ratepayer-protection mechanisms, upgrade allocation, and large-load tariff design.
• Local governments own zoning, public hearings, adjacent-use compatibility, enforcement conditions, local road and emergency-service impacts, and community representation.
• State governments own water rights, energy planning, utility regulation, environmental review, workforce coordination, tax-incentive oversight, and regional consistency.
• Federal actors own strategic-capacity framing, national reliability and security boundaries, permitting coordination where applicable, environmental law, data standards, and export/security constraints.
• Third parties own verification when trust is low: water sampling, acoustic testing, dashboard assurance, CBA monitoring, cybersecurity-aware disclosure review, and independent red-team review.
• Communities own lived feedback, local priorities, complaint records, public scrutiny, and the right to say when the proof does not match reality.

This does not mean every actor gets a veto over every detail. It means the proof layer should not hide behind fragmented accountability.

A serious site should publish an ownership map:

This map matters because "trust us" usually means "we have not made the ownership legible."

The goal is not to make infrastructure governance bureaucratic for its own sake. The goal is to prevent ambiguity from becoming the product. When the public does not know who owns water, power, ratepayer protection, noise, benefit delivery, or failure response, the project becomes a blame machine.

Good builders should not want that.

They should want the opposite: a site where every major claim has an owner, a verification path, a public artifact, and a consequence if reality diverges from the model.

No-Build Gates

A standard that always says yes is branding.

If the industry wants to be taken seriously, it has to say no sometimes. Not performatively. Not because opponents are loud. Because some sites, designs, utility arrangements, water sources, noise profiles, tax deals, or construction plans will not be good enough.

This is where pro-build people often get nervous. They think no-build language gives opponents a weapon.

I think the opposite.

A pro-build movement that cannot reject bad projects will get dragged down by them. One sloppy project can become the poster child for the entire sector. One missing meter, one weak noise ordinance, one tax deal that shifts costs onto the public, one ignored well complaint, one facility that behaves like a power plant while being sold as a warehouse, and suddenly every good project inherits the trust debt.

No-build gates are how you protect the good projects.

Examples:

• If a site depends on potable water in a stressed basin and cannot credibly shift to low-water, reclaimed, non-potable, or otherwise mitigated operation, redesign or no-build.
• If a utility cannot serve the load without shifting material grid-upgrade costs onto existing customers, redesign or no-build.
• If annual renewable matching is being used to dodge local peak load, ratepayer, or capacity questions, redesign the proof package.
• If residential adjacency makes 24/7 low-frequency noise impossible to mitigate, redesign or no-build.
• If stormwater, wetlands, floodplain, habitat, embodied carbon, or groundwater issues are being treated as late-stage paperwork instead of early site-screen questions, redesign or no-build.
• If the public proof package cannot be published because the business model depends on secrecy around basic civic impacts, redesign or no-build.
• If the community benefit package is a one-time gift with no maintenance, owner, reporting, or successor clauses, redesign.
• If a company cannot explain who pays, who benefits, who monitors, and what happens when promises are missed, pause.

A serious standard should classify defects instead of pretending every defect means the same thing.

A standard that can say "fix," "redesign," "prove it under protected review," and "no" is harder to dismiss than a standard that only says yes or no.

This is not anti-build. This is what serious builders should want.

The strongest companies should want rules that punish weak operators and reward proof-heavy ones. They should want disclosure standards that make it harder for bad actors to exploit outdated zoning or weak local capacity. They should want a public framework that distinguishes a good site from a bad one before discourse turns the whole sector into one object.

There is also a moral advantage here. Communities are more likely to trust a process that can produce "no" than one that appears designed to produce "yes" no matter what. A real no-build gate proves that the engagement process is not theater.

This is the difference between permission and legitimacy.

Permission can be procedural. Legitimacy has to be earned.

The Football-Club Model

The football-club metaphor is useful only if it is about obligation, not fandom.

A serious club is rooted in place, visible to its supporters, criticized by people who care, and judged over years by whether it improves. A compute facility cannot fake that with a logo or a sponsored event. It can only earn a local version of it through proof, maintained benefits, and governance.

Nobody, generally speaking, wants the Premier League to fail as an institution. Nobody, generally speaking, wants the Champions League to fail as an institution. People will hate certain clubs. They will criticize specific owners, managers, recruitment, transfers, training facilities, ticket prices, tactics, and dry spells. But the institution has a civic and cultural place. Supporters often demand better training facilities. They demand modernization. They demand ambition. They demand standards.

Right now, hyperscalers do not have that relationship with the communities they enter.

Many communities do not look at a data center and think: I want this facility to become state of the art because I can see how that benefits us. They think: this is a black box taking land, power, water, tax capacity, and silence.

That is the gap.

The goal is not to turn the town into fans. That would be cringe and probably dishonest. The goal is to make the facility worth defending when it is performing well and worth correcting when it is not.

The right civic question should become:

How do we make this facility cleaner, quieter, more useful, and more accountable?

Not:

Why was this imposed on us?

This is where football is useful. A supporter can want the manager fired, the owner investigated, the academy improved, and the training ground rebuilt while still wanting the club to survive. Criticism has a route into improvement.

Hyperscalers need to create that route.

That means the facility has a local civic interface, promises are visible, performance is tracked, benefits are maintained, criticism is expected, governance exists, future owners remain bound, and the public can see improvement over time.

That is not branding.

That is a relationship.

Stadium Logic Is The Warning Label

The football-club model is not stadium politics.

Stadium politics are the warning label.

A community can love sport and still reject a bad stadium deal. A community can believe in AI progress and still reject a bad data-center deal.

San Diego is the cleanest cautionary case. In 2018, voters rejected Measure E, the SoccerCity initiative, while approving Measure G, the SDSU West / SDSU Mission Valley initiative. The official final canvass showed SoccerCity losing 32.57% yes to 67.43% no, while SDSU West passed 54.46% yes to 45.54% no. The result was not close for SoccerCity, but the interesting part is why the comparison mattered.

Measure E had a strong pitch. The campaign sold SoccerCity as a privately funded MLS-oriented stadium, entertainment district, river park, jobs engine, and no-cost-to-taxpayers redevelopment. Its official argument even claimed it was fiscally better than Measure G, would pay full market value, and would create large economic activity. That is why this is a useful example. SoccerCity was not obviously a low-ambition proposal.

But the opposition framed Measure E as something else: private developer control of valuable public land, weak public review, traffic risk, no guaranteed MLS team, no guaranteed soccer stadium, no guaranteed river park, no enforceable SDSU rights, and side agreements that might not fix the legal weaknesses. The official voter pamphlet makes that legitimacy fight visible. It was not just soccer versus no soccer. It was trust in the bargain.

Measure G had its own risks. It was not a perfect civic fairy tale. Critics argued that SDSU West could still benefit private developers, create taxpayer or school-funding issues, avoid a fully open bid process, and leave financing questions unresolved. Local reporting by Voice of San Diego also pressed SDSU on how it would pay for the full plan. That caveat matters because the lesson is not "the university plan was flawless."

The lesson is that SDSU West gave voters a more credible institutional path. Its public story was campus expansion, research, housing, a multi-use stadium, river park/open space, environmental review, public input, and an enduring local anchor. KPBS's Measure G coverage described the plan as a chance for SDSU to buy a large portion of the Mission Valley stadium site and build an auxiliary campus. Voice of San Diego's post-election analysis argued that Measure G attracted a broad coalition and that SDSU's brand as a local institution mattered, while still warning that SDSU had inherited a serious delivery burden.

That is the point. The public did not simply choose "the better option" in some abstract spreadsheet sense. It chose the option that looked more legitimate, durable, and locally anchored than a private redevelopment package wrapped around an unguaranteed MLS future. KPBS/inewsource vote mapping also showed this was a real political contest with major campaign money on both sides, not a simple morality play.

Then San Diego still got MLS. Major League Soccer awarded San Diego its 30th club in 2023, with the club tied to Snapdragon Stadium at SDSU Mission Valley.

The public rejection was not proof that San Diego hated soccer. It was proof that civic legitimacy depends on the deal, the governance, the public land story, the anchor institution, and the credibility of the operating promise. A city can reject the pathway and still want the outcome under different terms.

That is the lesson for hyperscalers.

Do not assume that a polished benefit story will survive if the ownership, public cost, land use, utility burden, or long-term accountability model feels wrong.

Stadium-subsidy literature has been warning cities for decades that sports facilities often overstate local economic benefit. Sources like the St. Louis Fed and Brookings have summarized the basic skepticism: stadium jobs, tax revenue, and economic spillovers are often weaker than the pitch deck suggests.

Data centers are not stadiums. But the failure modes translate:

• "jobs and tax base" can become the data-center version of the stadium economic-impact deck;
• "privately funded" can still hide public cost through utility upgrades, grid cost allocation, water infrastructure, land discounting, tax abatements, public safety costs, or future decommissioning obligations;
• "community benefit" can become a ribbon-cutting layer over unresolved externalities;
• "if you do not approve this, someone else will" can become relocation-ransom logic;
• "strategic importance" can become a way to silence ordinary local impact concerns.

If hyperscalers want the football-club model, they must reject stadium-subsidy logic more aggressively than their critics do.

Civic affection is not collateral for a weak bargain.

Community Benefit

Community benefit is legitimate only after impact mitigation.

You do not get to trade a STEM lab for unmitigated water risk, noise, cost shifting, bad siting, or weak construction controls. A benefit does not substitute for mitigation. It complements a project that already meets a high standard.

The current jobs-and-training narrative is often too weak. Residents may assume the construction jobs are temporary, the permanent jobs are limited, and the best technical roles will be imported. That may not always be fair, but it is predictable. If the community's visible experience is disruption while the upside lives in a slide deck, the slide deck loses.

The economic story also needs category discipline.

Data centers may produce major investment and tax revenue while still producing relatively few permanent jobs compared with the capital deployed. That is not automatically a defect. It is a reason to stop overselling jobs as the whole bargain. NADO's 2026 data-center report says data centers are unlikely to be a major source of regional employment, while property tax often becomes the most significant local contribution. NCSL's 2026 incentives snapshot shows how varied state incentives are, including low job thresholds in some states and major tax relief in others.

So publish the local fiscal bargain. What tax revenue is expected? What incentive is being granted? What is the net public value after abatements, infrastructure costs, utility upgrades, emergency services, road wear, water infrastructure, and enforcement capacity? Is there a payment in lieu of taxes, also known as a PILOT? Is revenue dedicated to anything residents can inspect: affordable housing, school facilities, utility protection, conservation, roads, emergency services, workforce labs, or a maintained community fund?

If the real benefit is tax base, say that. If the tax base is reduced by incentives, say that too. Do not hide a weak jobs story behind a giant capital-expenditure number.

Community benefit has to become durable.

The durable version has a maintenance budget, a replacement schedule, a named owner, public metrics, independent monitoring, consequences for missed commitments, and successor clauses so obligations survive sale, lease transfer, tenant change, or expansion. Local benefit should run with the facility, not with the press cycle.

A public dashboard is not a marketing page. It is the scoreboard for the agreement.

The scoreboard should include wins and misses: construction incidents, stormwater and utility events, water source and usage, peak-day demand, grid upgrades and cost allocation, ratepayer protection, noise measurements, generator testing, complaint response, jobs by phase, local procurement, training completions, tax revenue against projections, maintained assets, unresolved issues, and ownership or tenant changes.

If the dashboard only shows wins, it is advertising.

Community benefit should not be support-buying. It should be earned legitimacy through proof, accountability, and durable benefit.

The no-support-buying test is simple: mitigation before benefit, benefit before branding, governance before fandom, dashboard before launch theater, and successor obligations before press releases.

Brookings has argued that community benefit agreements are necessary for data centers because communities need quantifiable data on jobs, tax revenue, workforce training, health and well-being, utilities, water, and benefits. That does not mean every CBA is good. A weak agreement can be another form of theater. But the direction is right: benefits need to be specific, monitored, enforceable, and maintained.

Do not build the village a water well and disappear when it breaks two months later. That failure mode is older than AI, and everyone can smell it.

If you promise a STEM lab, maintain it. If you promise a training pipeline, publish completion and placement data. If you promise local procurement, publish the numbers. If you promise utility protections, show the mechanism. If you promise noise mitigation, verify it after occupancy. If you promise circular hardware, show what happened to the equipment and the data.

Durability is the difference between benefit and theater.

The Local Upside

One reason the current discourse is so toxic is that the benefits often sound distant, abstract, or national while the burdens sound local and immediate.

The company says: national competitiveness, AI progress, tax base, jobs, future training, long-term growth.

The resident hears: water, power, noise, construction, traffic, secrecy, a giant wall, and maybe higher bills.

That gap matters.

People are not wrong to discount a twenty-year benefit story when the disruption is in front of their house this year. They are not wrong to be skeptical of "jobs" if the permanent jobs are limited or technical roles are likely to be imported. They are not wrong to ask why a company with enormous capital cannot make the local upside visible sooner.

The answer is not to buy support. The answer is to create real, inspectable, near-term public value that matches the scale of the ask.

That can include:

• utility bill protections or ratepayer safeguards where legally and technically feasible;
• local infrastructure funds tied to measurable needs, not vague philanthropy;
• maintained STEM, trades, robotics, hardware, or energy labs in schools and community colleges;
• paid apprenticeships with placement data;
• technical assistance for local government, water utilities, schools, and small businesses;
• public dashboards that local reporters and residents can actually read;
• community emergency-resilience investments if the facility is tied to new power or network infrastructure;
• local procurement with transparent numbers;
• repair, maintenance, and replacement budgets for anything donated;
• civic engineering staff whose job is to keep promises operating after the announcement cycle.

This is where the football-club idea becomes more than metaphor.

A serious club's training facility is not valuable because a press release says it exists. It is valuable because players train there, coaches use it, youth systems connect to it, supporters see ambition in it, and performance eventually reflects whether the institution is serious. The same logic applies here. If a hyperscaler builds a STEM facility, it should not be a ribbon-cutting prop. It should have staff, equipment refresh cycles, curriculum support, local teachers, repair budgets, usage metrics, and pathways into real work.

Forward-deployed civic engineering could be part of this. Not salespeople. Not generic community relations. Engineers, operators, educators, and technical implementers whose job is to convert promised benefit into working systems.

This matters because "we gave the town compute credits" is not enough if nobody local has the support to use them. "We built a lab" is not enough if the lab breaks, the software expires, the teacher leaves, and nobody owns the maintenance. "We funded training" is not enough if people complete the program and do not get placed.

Communities do not want to become places that host the burden while opportunity, prestige, and control accrue somewhere else. That fear may be blunt, but it is rational enough to deserve an answer. A facility that brings walls, load, noise, construction, and tax complexity while the technical and financial upside leaves town will read as extractive even if the national strategy is real.

If hyperscalers want communities to compete to host them, the upside has to be legible in the timescale of ordinary life. Not only national strategy. Not only shareholder value. Not only future productivity.

Show the short-term proof.

Show the maintained asset.

Show the scoreboard.

Culture

Culture belongs in this paper, but only downstream of proof.

A World Cup watch party is not legitimacy. A music partnership is not legitimacy. A football-club sponsorship is not legitimacy. A logo on a youth program is not legitimacy.

But culture is not irrelevant. It is one of the ways useful infrastructure becomes socially legible.

The weak version is: how do we make people see our brand?

The serious version is: what can people in this community do after we arrived that they could not do before, and how quickly can they see it?

A World Cup watch party outside Silicon Valley can matter only if it is one small ritual inside a larger legitimacy system. If the facility has not handled water, power, noise, land, construction, tax, ratepayer, and benefit obligations, the watch party is theater. If the facility has handled those obligations, and the event is attached to useful local tooling, maintained programs, real technical support, and visible proof of delivery, then it can become something else: a public surface where the community sees capability entering normal life.

The point is not to sponsor culture.

The point is to build useful systems with the people already doing the work, then let culture reveal that usefulness in public.

That is why the music example matters.

Do not lead with a prompt-to-song toy if the people you need to earn respect from live inside Ableton, FL Studio, Logic, Pro Tools, studios, live rigs, MIDI controllers, mix sessions, plug-ins, and revision workflows. Prompting a song in chat and downloading an audio file can be technically impressive. It is not what I am talking about.

Meet the workflow first. Add the model second.

The stronger music play is workflow augmentation: session automation, stem-aware editing, MIDI assistance, sound-design exploration, mix-assist tooling, metadata cleanup, collaboration support, and plug-in or SDK surfaces that live where producers and engineers already work. If that produces songs, playlists, radio shows, SoundCloud uploads, YouTube sessions, Spotify releases, or Apple Music projects, the public artifact should point back to real human workflow improvement. Not replacement theater. Not "we prompted a song." Real producers using better tools to make the work they already care about.

The same is true in football.

Do not sponsor a club and call it transformation. Do not make generic fan content and call it frontier AI entering society. Football clubs already use serious data, video, recruitment, scouting, opposition analysis, academy development, performance analysis, sports-science workflows, medical workflows, recovery planning, and operational staff knowledge. The useful AI product is not fan-content slop. The useful product is forward-deployed engineering with people who live inside the club's actual work: analysts, coaches, academy staff, recruitment teams, performance staff, medical staff, and people who have manually scaffolded domain systems for decades.

An All-or-Nothing-style documentary can be useful only if it shows the work honestly: where the tools entered, what changed, what failed, what the analysts rejected, what the coaches actually used, what the academy learned, what the community saw, and whether performance or operations improved. Otherwise it is vanity content.

In promotion-and-relegation football, performance pressure is existential. A bad system does not survive because it has a good brand deck. It has to help the club work. In MLS or other closed-league contexts, the incentive structure is different, but the rule is still the same: the tooling has to improve real operations, not just create an activation.

The same logic applies beyond music and football. If a hyperscaler says the community will benefit from AI, show local schools, trades, small businesses, civic offices, makers, students, producers, and founders using the tools in the timescale of ordinary life. Do not ask people to wait twenty years for an abstract productivity curve. Give them maintained technical support, useful workflows, and public examples that can be inspected now.

This is where the best cultural machinery in other industries has a lesson, but not the shallow one. The lesson is not "be loud like a sponsor." The lesson is that durable cultural institutions usually sit on top of real performance, craft, repetition, ritual, and visible excellence. Formula 1-style engineering culture, elite football facilities, and serious creative scenes are not powerful because someone placed a logo well. They are powerful because people can see the obsession underneath.

Hyperscalers need that obsession underneath.

But again: culture cannot launder unresolved operations.

If the water proof is weak, do not lead with a watch party.

If the noise is unresolved, do not lead with music.

If the community benefit is vague, do not lead with a football partnership.

If local people cannot actually use the tools, do not lead with a demo reel.

Do the operational work first. Build the maintained local capability second. Then culture can show participation in society instead of trying to purchase forgiveness from society.

Circular Compute

Hardware turnover can become a waste story or a builder-capacity story.

The difference is whether the company can prove what happened to the data, the firmware, the component, the buyer, and the material after decommissioning.

This is not speculative. Major hyperscalers already operate circular hardware loops. Google, AWS, Microsoft, and Meta all describe some combination of reuse, refurbishment, component harvesting, recycling, circular centers, and environmental reporting in public materials. Those company claims should not be treated as proof that every hardware stream is solved. But they show the direction of travel.

The security gates are not optional.

No data-bearing device should leave the hyperscaler environment unless it has an auditable sanitization or destruction record. NIST SP 800-88 Rev. 2 is the right kind of reference point for media sanitization discipline. Firmware and platform integrity also matter. Wiping disks is not enough if BMCs, firmware, credentials, ownership state, provenance, or supply-chain integrity are unknown.

Circular compute is not a surplus auction. It is an asset-disposition system with public value.

The tiered path should be:

1. redeploy usable hardware internally;
2. harvest parts and move them into controlled refurbishment;
3. create certified education and domestic builder channels for equipment that is safe, legal, supportable, and worth operating;
4. recover materials through certified processors when reuse is not responsible.

The homelab and education angle is powerful only if it is curated. Give students and domestic builders hardware they can safely learn from, not mystery boxes with stale firmware, unknown ownership state, exhausted parts, and unclear legal status.

And do not ignore export controls. Advanced accelerators, high-performance interconnects, remote access, and restricted components may require export classification, destination/end-user review, anti-diversion controls, and compliance signoff. Export controls are not a reason to do nothing. They are a reason to build controlled reuse channels instead of pretending secondary markets are neutral.

Circular compute does not excuse energy use, water use, noise, weak community benefit, or bad siting. It answers a different question: whether the physical machinery of AI becomes a dead-end waste stream or a disciplined supply of reusable equipment, parts, skills, and critical materials.

The Baseline Proof Package

Serious operators already know many of the basic ingredients: ledgers, acoustic models, dashboards, community agreements, thermal reviews, permits, utility filings, and post-occupancy checks. I am not pretending those words are new.

This section is the floor.

If I were a local official, resident, investor, or national-strategy person trying to decide whether a hyperscale AI campus was serious, I would still ask for the local proof package. Not everything. Not security-sensitive drawings. Not network topology. Not exploitable physical-security details. But enough to know whether the civic impacts are being measured, governed, corrected, and owned.

The baseline package should cover:

• site and ownership: what is being built, in which phases, with what approximate load, on what land, near which receptors, under what zoning, with what tenant/operator structure;
• water and construction: construction water, operating cooling water, potable versus reclaimed water, discharge, stormwater, dewatering, drought mode, private-well baselines where relevant, and withdrawal versus consumption;
• grid, ratepayer, carbon, and flexibility: requested MW, ramp schedule, interconnection status, upgrade cost allocation, ratepayer protection, backup or bridge power, clean-energy claim boundary, firm capacity, and actual curtailable load;
• thermal, noise, and air: heat-rejection path, liquid-cooling category, heat-reuse screen, local thermal plume, generator or turbine assumptions, acoustic model, indoor worker acoustic target, post-build measurements, complaint path, and retrofit obligation;
• land and ecology: brownfield or greenfield status, impervious surface, stormwater controls, sediment controls, ecology, embodied carbon, traffic, road damage, visual/light impact, and incident reporting;
• community benefit and local upside: commitments, budgets, owners, maintenance duties, local hiring/procurement, tax revenue, incentives, payment in lieu of taxes, school or community-college partnerships, utility protections, and successor clauses;
• transparency and governance: public/private disclosure tiers, dashboard and issue log, red-team memo, redesign triggers, no-build triggers, and one-year post-occupancy review.

That is not the destination.

The destination is the operating system around it. Do the artifacts talk to each other? Does water connect to drought mode, grid connect to ratepayer protection, thermal design connect to noise, community benefit connect to maintenance, and security-aware transparency connect to public trust? Is there an owner when the model misses reality? Is there a redesign gate before the project becomes politically too expensive to correct? Is there a no-build gate that proves the process is not theater?

That is how the boring floor becomes a legitimacy layer.

It is also how you reduce the attack surface for misinformation. If the proof exists before the rumor, the rumor has less oxygen. If the proof arrives only after the rumor, you are already playing defense.

Strategic Compute

There is a national-capacity argument here, and it is real.

OpenAI's April 2026 infrastructure post describes compute as a critical input for advanced AI and says future sites require coordination across communities, utilities, energy providers, chipmakers, cloud providers, construction firms, investors, skilled trades, and public-sector partners. DOE's Speed to Power work similarly treats grid expansion and large-scale power delivery as part of the AI capacity problem.

This matters.

But the wrong argument is: "AI is strategic, so accept the facility."

That will not work in a town hall. It should not work. Strategic infrastructure still has to be good infrastructure.

The better argument is:

AI is strategic, so we are going to show more work than ordinary projects. We are going to protect your water, protect your bills, protect your local environment, publish the evidence, and make sure the upside is real.

If AI infrastructure is strategic, the local proof burden is higher, not lower.

Open democratic criticism should be treated as a sensor. Not as a veto by default. Not as noise by default. A sensor.

Criticism can reveal bad siting. It can reveal weak utility assumptions. It can reveal ratepayer cost shifting. It can reveal water stress. It can reveal noise blind spots. It can reveal tax deals that do not match local value. It can reveal that the community benefit package is launch theater. It can reveal that the company is hiding behind complexity because it never built a translation layer.

That is useful if the builder is serious.

The point of open criticism is not to make every project impossible. It is to discover defects early enough that serious builders can fix them before opponents, lawsuits, and political entrepreneurs define the project for them.

This is an advantage open societies should use.

Other societies competing in AI and frontier compute may not allow the same free-form discourse, cross-exam, and public challenge around infrastructure. That can look faster in the short term. It can also hide failures, suppress local harm, and externalize costs. The United States and the West should not respond by copying opacity. They should prove they can build with more accountability and still win.

That is the American exceptionalism frame that is worth defending: not slogan-first nationalism, but the ability to build frontier infrastructure with more public proof, more environmental discipline, more local benefit, and more legitimacy than systems that treat criticism as something to suppress.

Energy Warning And Anti-Build Fatalism

The warning I would use is not 5G.

5G discourse had conspiracy mechanics, and it is useful for understanding how visible infrastructure can become a rumor magnet. But it did not strategically stop deployment in the United States.

The stronger warning is energy and nuclear.

Not because nuclear and data centers are technically the same. They are not. Nuclear has safety, waste, fuel-cycle, weapons, decommissioning, and regulatory issues that do not map cleanly to data centers.

The analogy is capacity governance.

Infrastructure legitimacy, policy sentiment, investment, supply chains, domestic capacity, and strategic dependency compound across decades. Once capacity is gone, rebuilding it is slower, more expensive, and more politically fragile than keeping it credible in the first place.

IEA's work on Europe's gas crisis describes how supply concentration and dependency can create severe price and security exposure. Research on Germany's nuclear phase-out has argued that lost nuclear generation was replaced primarily by coal-fired generation and imports under that model, with large social costs. European institutions are now again discussing nuclear investment, SMRs, energy security, industrial competitiveness, and strategic autonomy. The point is not monocausal blame. The point is that legitimacy failure can become capacity failure, and capacity failure can become dependency.

That dependency can become leverage.

The foreign-influence question belongs here, but it has to be handled carefully. The paper does not need to name adversarial states or claim ordinary data-center opponents are foreign-influenced. That would be sloppy and self-defeating.

CISA's guidance on foreign influence operations targeting critical infrastructure supports a general resilience point: influence operations can exploit divisive issues, undermine trust, bias policy development, disrupt markets, and target critical infrastructure debates. It does not prove attribution for current data-center opposition.

Attribution is not the public claim.

Resilience is the public claim.

The paper is not saying residents worried about water, rates, noise, tax breaks, or land use are foreign influenced. It is saying that strategic infrastructure debates become influence-sensitive when real grievances meet missing evidence, secrecy, institutional slowness, and exhausted public trust.

Foreign influence is a reason to reduce factual vacuums, not a reason to dismiss residents.

That is the demoralization-to-dependency risk model:

1. Real problems exist in a strategic sector.
2. Public proof is weak.
3. Legitimate concerns mix with exaggeration, uncertainty, political incentives, and hostile narratives.
4. Domestic society slows itself down or fragments.
5. Domestic capacity weakens.
6. External competitors inherit market share, technical lead, and capital.
7. Those gains can later be recycled into lobbying, cultural presence, sponsorship, and policy access.
8. The weakened society later sees the beneficiary normalized inside its own institutions.

That is a scenario and a warning model, not a proven causal chain for today's data-center opposition.

For AI infrastructure, the public-safe version is enough:

If we let legitimate criticism harden into permanent anti-build fatalism, we risk handing strategic compute capacity to foreign competitors. Ten or twenty years later, the cultural sponsor in our stadiums may be the foreign AI infrastructure company that benefited from our stagnation. That is not a reason to ignore criticism. It is a reason to convert criticism into proof, redesign, transparency, and disciplined buildout before the legitimacy surface is occupied by someone else.

The danger is not criticism.

The danger is criticism that never converts into design, proof, redesign, or a clear no-build decision.

A society can talk itself out of capacity without ever voting on a national strategy. It happens one delay, one opaque deal, one failed hearing, one bad project, and one exhausted community at a time.

Over-Deliver

The industry has enough talent to solve this.

It has engineers, hydrologists, geologists, grid experts, acoustic engineers, construction firms, environmental counsel, sensor networks, satellite imagery, AI models, digital twins, utilities, regulators, community organizations, universities, skilled trades, and capital.

So use them.

Do not accept bare minimum permitting as the ambition. Do not wait for congressional hearings where you have to explain why the proof was not ready. Do not hide behind complexity. Do not let county staff, residents, journalists, and opponents reverse-engineer your water and power profile from partial records. Do not make a community become its own acoustical consultant. Do not treat public trust as a downstream communications function.

You are building frontier compute. Act like it.

Design the data center as if the community should have rational reasons to want it improved.

Not because the community was bought. Not because they were distracted. Not because they were overwhelmed by consultants. Because the facility is cleaner, quieter, more useful, more accountable, and more locally beneficial than the alternative.

Make the water proof clear. Make the grid proof clear. Make the carbon and firm-power proof clear. Make the land and embodied-carbon proof clear. Make the noise proof clear. Make the benefit proof clear. Make the hardware lifecycle proof clear. Make the no-build gate real. Make the redesign gate real. Make the dashboard honest enough to show misses. Make the local upside visible before people are asked to trust a 20-year story.

In my own work, I have seen what happens when the default is not "do the minimum" but "solve the system." I took workflows that were burning through more than 90% of weekly model-session usage and moved them to less than 8% by changing the runtime architecture: liveness, wakeability, and attention routing moved into durable local signals while model turns were reserved for substantive reasoning and action. That is not the same problem as hyperscale infrastructure. But it is the same posture. If I had treated the default as acceptable, I would never have found the efficiency.

Hyperscalers are betting the future on innovation and progress. Apply that same seriousness to the physical world around the compute.

That is the spine of the argument: do not let many solvable failures harden into one public rejection of the buildout.

Throw the kitchen sink at the externalities early. Bring in the best people. Build the proof layer before the narrative hardens. Make the facility worth accepting. Make it worth improving. Make it so the community's rational demand is not "stop this industry," but "make our facility the best version of what this industry can build."

Build faster by showing more work.

Be competent.

Over-deliver.

Lock in.