Response to TerraWatt’s statement on Armory Data center noise

 Data center noise is not like typical industrial or traffic noise. Data centers produce continuous, 24/7 hums that stand out sharply from background sound — sound that conventional walls, berms, and setbacks are not built to mitigate. That's the regulatory challenge municipalities are only beginning to grapple with, and it's the subject of a recent Saint Louis Public Radio story I was interviewed for, as well as a policy framework I've written on the topic.

In the same STLPR story, David Daneshforooz, CEO of TerraWatt, responded to my concerns with statements about the Armory project's permit conditions. Here is where I think those responses fall short.

STLPR story: https://www.stlpr.org/health-science-environment/2026-09-24/st-louis-scientist-data-center-noise-pollution
Policy framework: https://www.fowlerfinnlab.com/s/DataCenter_Noise_General_Guidelines.pdf


Developer: "Our permit imposes tougher restrictions... beyond the city's general noise rules"

 Why tougher does not protect residents: The CUP does indeed add specific design/operational mandates (acoustic enclosures, generator placement, restricted testing hours) that Ordinance 68130 doesn't impose on ordinary commercial uses. Furthermore, "Should any conditions not be met, the City is able to revoke the occupancy permit if issues are not corrected” is a stronger enforcement mechanism than Ordinance 68130 provides for other businesses. However, the specific restrictions that would actually make a difference in noise propagation would be using lower dB-above-baseline allowances or a strict dB limit, larger setbacks, and octave-band measurements. Critically, this pivots away from the key point that a strict dBA/dBC-based measurement buries a tonal spike by averaging it into an unremarkable broadband number. A facility can have stricter regulations and still not catch the hum that stands out from background. "Tougher" refers to degree, but does not address the fact that the kind of regulations we need do not currently exist.

Developer: "independent monitoring will measure the sound produced, including low-frequency"

 Why this actually promises very little: First, "Independent" is undefined — independent of whom, selected by whom, funded by whom, verified how? The city’s own data center ordinance BB49 (which does not apply to the midtown data center project) draw the distinction between an engineer ‘selected by the City’ and one merlely ‘acceptavble to’ an official. The armory permit does not specify which standard applies here at all. Second, saying "including low-frequency" makes it sound like a response to my point, but it isn’t at all: dBC already captures more low-frequency energy than dBA, but the real problem is the hum being heard over background noise (i.e. the scream being heard over the train). A single number (dBA, dBC, or otherwise) cannot reveal a narrow tonal band that stands out from the average no matter how restrictive the rules are. "Including low-frequency" does not refer to using the octave-band resolution that would actually catch these hums that are the source of complaints and lawsuits.

Developer: "independent monitoring will….identify any issues so that we can address them"

Why this statement also addresses very little: Given how vague this statement is, it is unclear what it actually means. There is not a specified trigger set in place, and it is not clear whether monitoring will be continuous or annual. If it is similar to BB49 (one report a year, readings from a June–August window) this is inadequate and misses the critical window in which thermal inversions cause sound to travel further (conditions most common on dry, calm nights with long hours of darkness — Missouri winters, not summers). Essentially, if a resident is bothered nightly, that doesn’t lead to testing and mitigation unless there is a complaint-triggered mechanism, and no complaint-triggered mechanism is currently in place. Thus, as stated, "identify any issues" could mean waiting up to a year between checks regardless of what nearby residents experience.

Developer: "These are enforceable requirements... not voluntary promises."

Response: "Enforceable" only tells us that something happens if a violation is caught and confirmed. If the underlying standard is inadequate (currently, it is), then this does little to protect residents. This also does not say anything about how often requirements are checked, or how quickly a violation gets identified in the first place. A weak and rarely-tested standard is still "enforceable,” but that does not make it adequate. This gets at the heart of my point: the regulations are substandard, so meeting them does not actually protect the community.

Developer: "Our responsibility is to meet those requirements and be a good neighbor."

Response: This statement equates meeting legal requirements as ‘being a good neighbor.’ However, meeting requirements does not mean it will be tolerable to live near the facility. A facility can be compliant on paper, yet still produce the specific noise signature that triggers complaints that have resulted in numerous class action lawsuits around the country.

Takeaway: Overall, everything the developer has said refers to process, but there are no numbers attached, no measurement method, no threshold, no schedule, no selection mechanism for the monitoring. Since the actual regulations are not sufficient, these statements can be 100% accurate, but completely miss the mark in terms of protecting residents.

Navigate back to the Noise Policy Page