I've spent a lot of time lately talking with communities about data centers and other major infrastructure projects. I've sat through public meetings, answered difficult questions, listened to legitimate concerns, and watched people get downright angry about projects that haven't even broken ground.
Some of that anger is understandable. Some of it is justified.
And some of it makes me wonder whether we've completely forgotten how to have an adult conversation.
Here's what I've come to realize.
The problem isn't that people disagree. Disagreement is healthy. Sometimes it's essential. I've spent enough years working around critical infrastructure to know that some of the most important questions come from people who aren't convinced a project is a good idea.
The problem is that we've become remarkably bad at distinguishing disagreements that can be resolved from disagreements that fundamentally cannot.
And we waste an enormous amount of time, money, and goodwill pretending otherwise.
Developers sometimes treat anyone who questions a project as an obstructionist. Opponents sometimes treat every developer as though they're trying to pull something over on the community.
That's lazy thinking. And frankly, I'm getting tired of it.
A resident asking legitimate questions about water consumption isn't necessarily anti-development. Neither is someone concerned about electrical rates, noise, environmental impacts, or whether promised economic benefits will actually materialize.
Those are exactly the questions communities SHOULD be asking.
The challenge is figuring out whether someone is interested in getting answers, whether they're objecting on principle, or whether they're simply looking for another reason to say no.
I believe there's a remarkably simple way to start making those distinctions.
I call it the Satisfiability Test.
The Satisfiability Test
Here's the question I believe should be asked early in almost every contentious infrastructure discussion:
What would have to change about this project for you to support it, or at least consider it acceptable?
That's it.
It's not a trick question. It isn't designed to embarrass anyone or force them to abandon their concerns.
It's designed to determine whether there's actually a problem we can solve.
Imagine someone says they're concerned about a data center's water consumption.
Fair enough.
What if the developer could demonstrate that its facility would use a closed-loop cooling system, require minimal ongoing water consumption, and operate under enforceable limits?
Would that address the concern?
Maybe it would. Maybe it wouldn't. Perhaps there are additional questions about water quality, drought conditions, or the demands placed on local infrastructure.
Fine. Let's examine those too.
That's constructive opposition. There are identifiable concerns and potentially measurable conditions for addressing them.
Now imagine someone responds that no amount of engineering, mitigation, independent verification, or enforceable conditions would ever make the project acceptable.
That's a different conversation.
And there's nothing inherently wrong with someone holding that position. People have every right to oppose development.
But we should stop pretending we're negotiating over water consumption if water consumption was never going to change their mind.
You cannot engineer your way around an objection that has nothing to do with engineering.
Two caveats, because I already know what some of you are thinking.
First, the test only works if information comes first. Nobody can tell you what would satisfy their concern about water if the developer won't say how much water the facility will use. Asking residents to name their conditions while withholding the numbers they need to name them isn't a fair question. It's a trap.
Second, answering the test isn't signing a contract. Telling me what would address your water concern doesn't obligate you to support the project once that concern is addressed. You may have others. The answer just tells us where the real disagreements are.
There's also an important distinction between opposing a particular project, opposing a particular location, and opposing an entire category of development.
Someone who doesn't want an industrial facility next to their house might enthusiastically support that same facility in an appropriately zoned industrial park.
Someone who opposes every conceivable location, every proposed technology, and every reasonable alternative is presenting a much broader objection.
The satisfiability test helps us understand the difference.
I'll Give You an Example. Me.
I'm not immune to categorical opposition myself.
Take Flock cameras, the automated license plate readers increasingly appearing in communities across the country.
I am 100% opposed to them.
I believe the ability to collect, aggregate, and search people's movements creates substantial Fourth Amendment concerns. I don't believe the government should have that kind of surveillance capability over ordinary citizens simply going about their lives.
And before somebody starts explaining all the wonderful ways these cameras can help law enforcement, let me save you some time.
I understand the argument. I'm a cybersecurity professional. I understand what these systems can do, and I understand why law enforcement finds them attractive.
My objection isn't that the technology doesn't work.
In some respects, my objection is precisely how well it works.
You can tell me the cameras will be more accurate. You can promise better data retention policies, stricter access controls, or more oversight.
Those measures may reduce some risks. They don't eliminate my fundamental objection.
I'm not opposed because someone failed to explain the technology to me. I'm opposed because I've considered the technology and disagree with the underlying premise.
And I can tell you that plainly.
Now, someone who supports these cameras might disagree with every word I've just written. That's fine. We can debate the constitutional questions, the legal precedents, and the balance between public safety and individual liberty.
But neither of us needs to pretend that another technical presentation is necessarily going to bridge a fundamental disagreement about the proper limits of government power.
That's the point of the satisfiability test.
It doesn't require me to change my mind. It requires me to be honest about what would, or wouldn't, change it.
There is a difference between being unwilling to consider evidence and being unwilling to compromise on a principle.
And that distinction matters enormously when we're discussing infrastructure development.
If Your Problem Is AI, Have the Balls to Say So
There's another elephant in the room that deserves some attention.
Artificial intelligence.
I've increasingly wondered how much of the opposition to data centers is actually opposition to the infrastructure itself, and how much is opposition to what people believe that infrastructure represents.
And I think that's a fair question.
AI makes people uncomfortable. Some are worried about losing their jobs. Others worry about privacy, surveillance, misinformation, intellectual property, or the concentration of power in a handful of enormous technology companies.
Those aren't imaginary concerns. Some are serious questions that society needs to address.
But here's the thing. I just told you plainly where I stand on Flock cameras. I'm asking the same of you.
If your problem is AI, have the balls to say so.
Don't tell me your fundamental objection is water consumption if you would still oppose the project after the developer demonstrated that water demand was negligible.
Don't tell me it's electricity if you would still oppose the project after the utility established a credible plan to serve it without shifting project-specific costs onto existing customers.
And don't tell me it's noise if you would still oppose the facility after enforceable limits and independent testing addressed that concern.
Those are legitimate technical questions. They deserve legitimate technical answers.
But if your real objection is that you don't want to support the growth of artificial intelligence, then say that.
We can have that conversation.
We can debate whether AI's benefits justify its risks. We can discuss employment, privacy, national security, economic disruption, and the kind of technological future we want to build.
I welcome that discussion.
What I don't welcome is pretending we're negotiating over cooling towers when the actual disagreement is about the future of artificial intelligence.
Data centers existed long before ChatGPT showed up. They support financial transactions, hospitals, communications networks, government services, and countless other systems that modern society relies upon.
Opposing AI and opposing data centers are not interchangeable positions.
And opposing a particular data center isn't proof that someone opposes AI.
If someone says their concerns are environmental, let's examine the environmental evidence. If they say their concerns are economic, let's examine the economics.
But if the answer to every proposed solution is another reason to oppose the project, eventually we have to ask whether we're even talking about the real objection.
You are entitled to oppose AI. You are entitled to oppose a data center. You are not entitled to have an unsupported technical claim treated as fact simply because it gives your opposition a more convenient argument.
Have the courage to state what you actually believe.
At least then we can have an honest disagreement.
The Tinfoil-Hat Problem
I probably won't make many friends with this section, but somebody needs to say it.
We have a misinformation problem in infrastructure debates, and I'm tired of pretending it's just passionate civic engagement.
I've encountered allegations that local officials must have been paid off because they supported a project. I've seen stories claiming that data centers are killing cattle or somehow preventing cows from producing live calves.
These are extraordinary claims.
If somebody is taking bribes, that's corruption. Investigate it. Prosecute it if the evidence supports prosecution.
If livestock are dying because of something an industrial facility is doing, that's a serious environmental and agricultural concern. Investigate it, identify the mechanism, establish causation, and address it.
An unpopular zoning decision isn't evidence that a commissioner took a bribe.
A farmer reporting livestock losses isn't proof that the data center down the road caused them.
That doesn't mean the allegations are necessarily false. It means they haven't been established merely because someone repeated them on Facebook.
An allegation is not evidence. Repetition is not corroboration. And suspicion is not proof.
I don't care how many times something has been shared on Facebook. I don't care how many people comment that they heard the same thing. And I certainly don't care how many exclamation points somebody puts at the end of a post.
Show me the evidence.
If it's credible, I'll be the first person asking the difficult questions.
But if your entire argument is built around something somebody's cousin supposedly heard from a guy who knows a farmer, don't expect the rest of us to treat it as an established fact.
Consider what happens when someone makes an alarming claim and is asked to substantiate it.
Suddenly, every answer becomes evidence of the conspiracy. The developer's information is fake, the engineers are paid off, the regulators are corrupt, and the independent investigators are part of the cover-up.
At some point, we need to ask another question:
What evidence would convince you that your belief might be wrong?
If the answer is nothing, we're no longer having a fact-based discussion.
We've crossed into a world where every piece of contradictory evidence becomes additional evidence of the conspiracy.
I call that the tinfoil-hat problem.
And it's a problem for both sides.
A resident with legitimate questions about electrical infrastructure costs shouldn't have those questions dismissed because somebody standing next to them is making wild claims about mysterious radiation killing cattle.
The nonsense can drown out legitimate concerns.
Likewise, developers who make grandiose promises about jobs, tax revenue, or environmental performance without producing supporting evidence deserve to be challenged.
You don't get to demand scientific rigor from your critics and then expect everyone to accept your marketing materials as gospel.
The burden of evidence belongs to whoever makes the claim. Not just whichever side we happen to disagree with.
A Camera Can Tell the Truth and Still Mislead You
There's another phenomenon that deserves attention: presenting something real in a way that creates a false impression.
Suppose I take video of a facility conducting an unusual operational test. Maybe it's backup generators running at full load. The equipment is loud, the conditions are abnormal, and the activity only occurs periodically.
Then I post that video and suggest this is what residents will experience every day.
The recording itself may be completely authentic.
But if I knowingly omit material context to create a false impression, am I really telling the truth?
Of course not.
Depending on the circumstances, materially false and damaging representations can even raise legal questions about defamation.
Now, the test itself might still be a legitimate concern. How often does it happen? How loud is it? Does it violate applicable standards? Should residents receive notice?
Those are reasonable questions.
But reasonable questions deserve accurate context.
The same goes for the developer who shows up with beautiful architectural renderings, manicured landscaping, and promises of a quiet industrial neighbor while conveniently leaving out important operational details.
A true photograph, an accurate number, or an authentic video can still be used to tell a dishonest story.
Context matters.
Especially when leaving it out helps your argument.
The Test Must Work in Both Directions
Here's where some of my friends in the development community might get uncomfortable.
The satisfiability test isn't just for residents.
Developers need to answer it too.
If a developer says it's committed to addressing community concerns, then what exactly is it willing to do?
Will it agree to enforceable noise limits?
Will it provide transparent water-use projections and report actual consumption?
Will it commit to paying for infrastructure upgrades attributable to the project?
Will it accept independent verification of material technical claims?
Will it put meaningful commitments in writing?
Not every requested concession will be technically feasible, legally appropriate, or economically reasonable. And a developer shouldn't be expected to agree to every demand simply to demonstrate good faith.
But if every proposed safeguard is dismissed out of hand, that tells us something too.
Developers also have their own version of moving the goalposts.
The project is about jobs. When the job numbers turn out to be modest, it's about tax revenue. When the tax abatements come to light, it's about national security.
Maybe all three are true. Then make the case for all three, with real numbers, from day one.
Then there's the secrecy. Code names. Shell LLCs. Nondisclosure agreements signed by the very officials who are supposed to represent the community.
I understand why companies want confidentiality during site selection. Competitive pressure is real, and so is land speculation.
Confidentiality during preliminary negotiations is one thing. Asking elected officials to make consequential public decisions without enough information to explain those decisions is another.
At some point, a community has a right to know who it's negotiating with. You can't ask residents to trust your answers while refusing to tell them who you are.
A developer cannot claim to be negotiating with a community while treating every question as an obstacle to be brushed aside.
Likewise, residents cannot reasonably demand transparency while refusing to acknowledge credible answers when they're provided.
If residents cannot identify conditions under which a project could become acceptable, and developers cannot identify reasonable concessions they would consider, neither side is really negotiating. They're performing.
And I have absolutely no patience for that performance, regardless of which side is putting it on.
The Cost of Moving the Goalposts
One of the more frustrating things I've observed is what happens when a legitimate concern gets answered.
Someone asks about water consumption.
The developer provides engineering documentation demonstrating minimal demand.
Suddenly the argument shifts to electricity.
The utility explains the infrastructure requirements and who pays for them.
Now it's noise.
An independent acoustic study addresses that concern.
Now it's something else.
To be clear, a project can have multiple legitimate problems. Answering one question doesn't mean all the others magically disappear. Nobody should have to identify every concern on day one.
But there's a difference between identifying additional problems and refusing to acknowledge that any problem has been resolved.
The satisfiability test creates a way to identify specific concerns, document the proposed remedies, evaluate the evidence, and determine whether progress is being made.
If a condition has been satisfied, acknowledge it.
If the information is inadequate, explain what's missing.
If a proposed remedy doesn't work, explain why.
And if you were never going to accept the project under any circumstances, have the intellectual honesty to say so.
There is nothing wrong with categorical opposition.
There is something wrong with disguising categorical opposition as a series of technical objections that no amount of technical evidence will ever satisfy.
We Need More Engineers and Fewer Cheerleaders
I've spent more than 30 years working around critical infrastructure, first helping build it and later helping secure it.
One thing that experience has taught me is that complex projects don't become safer because somebody gives a better sales pitch.
They become safer because competent people identify problems, examine evidence, challenge assumptions, and develop workable solutions.
Public relations has its place. So does community advocacy.
But if we're going to discuss electrical capacity, industrial cooling, water infrastructure, environmental performance, or operational risk, somebody in the room needs to understand the engineering.
And they need to be willing to answer difficult questions without hiding behind a polished presentation.
Communities can smell bullshit a mile away.
So can experienced engineers.
I've seen how quickly trust disappears when developers offer assurances instead of answers. I've also watched perfectly legitimate concerns get buried under conspiracy theories, while complex technical questions get reduced to slogans that fit neatly on protest signs.
It's maddening because none of this has to work that way.
We are capable of better.
What we need are conversations where inconvenient facts are welcomed rather than treated as ammunition for the other side.
Where residents can ask hard questions without being branded obstructionists.
Where developers can explain legitimate technical constraints without being accused of participating in some grand conspiracy.
And where everyone understands that the credibility of an argument depends on the quality of its evidence, not the volume of the applause it receives.
Consensus Is Not the Goal
Here's something I wish more people understood.
A community doesn't have to reach consensus to reach a defensible decision.
We seem to have developed this strange expectation that every major project must somehow satisfy every person in the community before it can move forward.
That's not how representative government works. It's not how engineering works. And it's certainly not how functioning communities make difficult decisions.
Public participation matters. A great deal.
Residents deserve to be heard. Their concerns deserve investigation. Developers deserve clear and consistent rules. Elected officials have a responsibility to weigh competing interests and make decisions grounded in evidence.
But listening to everyone doesn't mean agreeing with everyone.
And allowing someone to speak doesn't mean their claims must be accepted without scrutiny.
The satisfiability test can help local governments determine when they've adequately investigated concerns, established enforceable conditions, and reached a point where further debate is unlikely to produce new information.
That doesn't mean shutting down public comment or ignoring new evidence. Legal procedures and public participation requirements still matter.
It means recognizing that endless argument isn't necessarily the same thing as meaningful deliberation.
At some point, the people elected to make decisions have to make them.
Some residents will disagree.
Some developers will walk away.
Some projects will be approved, and others will be rejected.
That's not a failure of the process. That is the process working as intended.
A failure is when a community spends months or years fighting without ever establishing which claims are true, which concerns can be addressed, and which disagreements are fundamentally irreconcilable.
We don't need universal agreement.
We need defensible decisions.
And defensible decisions require a process that can withstand scrutiny long after the shouting stops.
Putting the Test to Work
So what does this actually look like in a real process?
It doesn't require anything fancy. For every significant concern raised, document five things:
- The concern. State it as specifically as possible. Not simply "water," but "peak summer draw on the municipal system during drought."
- The proposed remedy. What could reasonably address the concern, if a remedy exists?
- The evidence. What information would demonstrate that the remedy works, and who will independently verify it?
- The status. Resolved, awaiting information, being reviewed, or irreconcilable.
- The rationale. Why was that status assigned, what evidence supports it, and what remains disputed?
That's it. A running ledger, updated as the process moves forward and available to everyone.
Of course, a concern shouldn't be marked resolved just because the developer says it is. The evidence must actually support that conclusion.
Nor should a legitimate unanswered question be labeled irreconcilable simply because someone is impatient to move forward.
The ledger keeps resolved concerns from quietly resurfacing six months later.
However, if credible information emerges after an issue has been marked resolved, reopen it. The purpose of the ledger isn't to manufacture closure. It's to document the truth as best we can establish it.
The ledger shows residents their questions were actually tracked, not just heard and filed away.
The ledger shows elected officials exactly what remains open when it's time to vote.
And it puts genuinely irreconcilable disagreements on the record as exactly that, instead of disguising them as unfinished engineering questions.
This isn't complicated. It requires discipline, transparency, and a willingness to put the evidence on the table.
Those shouldn't be extraordinary expectations for decisions that could shape a community for decades.
The Question That Changes the Conversation
Ultimately, I don't believe the real dividing line in infrastructure debates is between residents and developers, or between people who welcome development and people who oppose it.
It's whether the people involved are genuinely willing to participate in a process where facts matter.
The satisfiability test gives us a place to start.
What concerns you?
What would make the project acceptable?
What evidence would persuade you that a particular concern has been resolved?
Would you accept credible independent verification, even if the results challenge your current position?
And are you willing to apply the same standards of evidence and accountability to the people you agree with?
Those questions won't make every controversy disappear.
Some projects genuinely shouldn't be built. Some locations are unsuitable. Some developers make promises they cannot keep. And some community objections cannot reasonably be resolved.
But we ought to be able to distinguish a legitimate impasse from an argument that was never open to resolution in the first place.
I've spent enough of my life dealing with real infrastructure problems to have very little patience for manufactured ones.
We have enormous challenges ahead of us. Electrical infrastructure, water systems, transportation, manufacturing, digital infrastructure, and national competitiveness all demand serious attention.
We're not going to meet those challenges by shouting at one another, spreading unsubstantiated allegations, or pretending that facts only matter when they support our preferred outcome.
Every community deserves an honest process, grounded in evidence rather than accusations, engineering rather than speculation, and accountability rather than political theater.
Protecting communities from bad development matters.
Protecting them from bad information matters just as much.
And at some point, after the questions have been answered, the evidence examined, and the reasonable conditions established, somebody has to have the courage to make a decision.
Consensus isn't required. Intellectual honesty is.
