MODEL DATA CENTRE DEVELOPMENT, INFRASTRUCTURE AND OPERATIONS BYLAW

A Comprehensive Regulatory Framework and Resource for Municipalities, Elected Officials and Affected Communities

The Model Bylaw can be download for FREE from two locations - Zenodo and The Internet Archive in PDF format (20kb)

I have been working on a model municipal data-centre regulatory framework for months. And for months, I have kept delaying its release.

Not because it was unfinished in the usual sense. It has been usable for some time. The problem is that almost every week seems to expose another issue that deserves to be considered.

Water use. Low-frequency noise. Behind-the-meter generation. Grid costs. Agricultural land. Emergency response. Electronic waste. Ownership structures. Data sovereignty. Decommissioning. Public consultation. Project splitting. Cumulative development.

Every time I thought I had reached a reasonable stopping point, something else appeared in the news that made me go back and ask: Does the model address this?

Eventually, that process has to end.

The County of Newell’s current data-centre bylaw review—and the remarkably well-timed announcement of a proposed campus of separately permitted small data-centre sites—has convinced me that now is the time to make the model available as it stands.

Not because it is finished forever.

Because municipalities are making these decisions now.

What are we actually trying to regulate?

There is a question that should come before almost every discussion about drafting a data-centre bylaw:

Why is the municipality writing it?

Is it trying to prepare before development arrives?

Is it responding to applications already at the door?

Is the goal to determine where and under what conditions data centres may responsibly operate?

Or is the goal primarily to make development permissible?

Are definitions being created because they represent meaningful differences in impacts?

Or because a particular kind of project needs to fit inside them?

Are requirements being written to protect the community?

Are they being written to create the appearance of regulation?

Are they being written to ensure applicants provide useful information?

Or to provide enough discretion that almost any proposal can eventually be approved?

Sometimes those motivations will overlap. But they matter.

The same subject can produce two bylaws that look similar on the surface while doing very different things.

One can establish measurable requirements that a project must actually satisfy.

Another can require reports, plans and studies while leaving almost every substantive decision discretionary.

One can examine the entire development.

Another can allow one large project to become several small ones on paper.

One can require public participation before decisions are shaped.

Another can technically provide public notice while ensuring the public arrives very late in the process.

That distinction has become increasingly difficult to ignore.

Why the County of Newell pushed me to release this

The County of Newell held a public hearing on September 10 regarding changes to its Land Use Bylaw for data processing centres.

Some of the proposed changes suggest that the County listened to concerns raised during the review. That deserves acknowledgement. But what was not incorporated is equally interesting.

Among the concerns specifically raised were the weakness of defining small-scale development without adequately considering actual capacity, the potential for a larger development to be divided among multiple smaller applications, the need to consider related projects cumulatively, and the softer public-notification requirements applying to the small-scale category.

Changes were suggested that could address those issues. They did not make it into the draft taken to the hearing.

At almost exactly the same time, a developer announced plans for what it calls a “Brooks Campus Zone”—a development strategy involving multiple separately owned and separately permitted 9.9 MW sites operating as part of a larger program.

That does not prove that the County wrote its bylaw for this development.

It does make the omissions worth examining.

And it demonstrates almost perfectly why something as seemingly technical as a definition can determine whether a regulatory framework works.

If a development consists of ten facilities that individually satisfy a definition of “small-scale,” but operate together as one campus, what exactly is the project being regulated?

Ten small projects?

Or a roughly 100 MW industrial development?

A useful regulatory framework needs to be capable of answering that question before an application arrives.

What this model actually is

The document I am releasing is not simply a bylaw that I sat down and wrote from scratch. Much of its language, concepts and regulatory approaches are not original to me.

They have been compiled, adapted and synthesized from a wide range of material: existing municipal bylaws, proposed regulations, planning frameworks, regional policies, regulatory guidance, technical standards, public-consultation material, industry practices, academic and policy research, and concerns being raised by communities already confronting data-centre development.

The work has been in bringing those scattered approaches together.

Where different jurisdictions address the same problem differently, the model attempts to reconcile those approaches.

Where requirements overlap, it attempts to organize them logically.

Where existing approaches leave gaps, it identifies them.

And where provisions sitting in entirely different regulatory silos actually address parts of the same industrial system, it puts them beside one another so the relationship becomes visible.

The result is a model framework for regulating the development, infrastructure, operation and eventual closure of data centres.

It is deliberately jurisdiction-neutral. No municipality should download it and enact it word-for-word.

Planning legislation differs. Municipal authority differs. Electricity and utility regulation differs. Environmental law differs. Building and fire codes differ. Indigenous consultation obligations differ. Enforcement powers and terminology differ.

Every provision therefore needs to be treated as a recommendation for consideration, adapted to local circumstances, and reviewed by appropriate legal and technical professionals.

It is a resource. Not legal advice.

It is enormous—and that is part of the point

The document is long. Very long.

Even after removing the Model Commentary that accompanies the provisions, it remains large and at times unwieldy.

That itself illustrates something important.

Data centres are not simply another building-use question.

They can involve electricity generation and transmission, water withdrawal, wastewater, cooling systems, fuel storage, battery-energy-storage systems, continuous mechanical noise, low-frequency sound, air emissions, lighting, transportation, emergency response, agricultural impacts, ecological impacts, electronic waste, taxation, public infrastructure, surveillance, cybersecurity and eventual decommissioning.

Trying to address all of that by declaring a data centre to be another warehouse, office, utility building or generic industrial use is inefficient at best.

At worst, important impacts simply fall between existing regulatory categories.

But the size of the model does not mean that every municipality needs to adopt a stand-alone bylaw containing every provision in it.

In practice, very few would.

A municipality may already address portions of it through its Land Use Bylaw, development standards, engineering standards, noise bylaws, traffic requirements, emergency-management plans, environmental requirements or development agreements.

Some provisions can be incorporated into those existing instruments. Others can be cross-referenced.

Overlapping requirements can be consolidated.

A municipality might choose a dedicated data-centre overlay, supplementary development standard or separate bylaw.

The value of the model is not dependent upon every provision sitting inside one document. Its value is that it attempts to provide a comprehensive checklist of the questions that have to be answered somewhere.

The fact that answering those questions may require changes across several existing bylaws is not a reason to avoid them. It may simply demonstrate that existing municipal frameworks were never designed for this kind of development.

Data centres are distinct industrial facilities

The physical appearance of a data centre can obscure what it actually represents.

A comparatively anonymous building may represent hundreds of megawatts of electrical demand.

It may depend upon major substations and transmission infrastructure.

It may contain extensive cooling systems, battery storage and telecommunications infrastructure.

It may require fleets of backup generators and substantial fuel storage.

It may produce continuous mechanical and low-frequency sound.

Its water, electricity and infrastructure demands may extend far beyond the property line.

The regulatory framework should reflect what the project does, not simply what the building looks like.

Existing industrial zoning can still provide an appropriate geographic basis for locating data centres.

But the use itself deserves specific consideration rather than regulation by analogy.

Regulate the whole project

One of the central principles of the model is that the regulatory subject should be the whole project.

That means the data centre, its phases, its tenants where relevant, and the infrastructure required to make it operate.

A municipality should not regulate the computing building while pretending that an adjacent power plant has nothing to do with it.

Nor should parcel boundaries, corporate structures, ownership arrangements, construction phases or separate permit applications be capable of hiding the actual scale of one functionally integrated development.

If several facilities operate together as one campus, the regulatory framework should be capable of seeing the campus.

That is not an abstract concern anymore.

What the model is intended to do

The objective is not to prohibit data-centre development.

Quite the opposite.

The model attempts to demonstrate that a functional and enforceable regulatory framework can still leave room for responsible development.

But responsible development requires more than asking an applicant what it intends to do. It requires establishing expectations before approval.

It requires identifying impacts before they are transferred to surrounding communities.

It requires determining which costs belong to the development rather than existing taxpayers and ratepayers.

It requires turning material promises relied upon during approval into measurable commitments.

And it requires mechanisms for determining whether what actually happens after construction resembles what was promised before it.

The distinction matters.

Design promises determine whether a project can be approved. Actual operating performance determines whether it should continue operating as approved.

The principles behind the framework

The detailed model is built around a set of recurring principles. Development should be evaluated before irreversible commitments are made.

Public participation should occur early enough to influence the outcome, not merely after important decisions have effectively been made.

Transparency should continue through construction, operation and closure.

The entire development should be assessed rather than fragmenting impacts among permits, parcels or corporate entities.

Cumulative impacts matter.

Existing residents, taxpayers and utility customers should not involuntarily subsidize costs principally created by private development.

Scarce land, water, electricity and infrastructure should be allocated deliberately rather than simply because they are technically available.

Environmental and community harm should be avoided where possible before relying upon mitigation or compensation.

Claims should be specific, measurable and capable of independent verification.

Uncertainty should not automatically be transferred from the developer to the public.

And responsibility must continue through changes in ownership, operation, closure and decommissioning.

Those principles lead to some very basic regulatory questions.

If the bylaw regulates an impact, how will it be measured?

Who will verify it?

How frequently?

Will the public be able to see the results?

What happens when actual performance differs materially from what was represented during approval?

A requirement without a mechanism for determining whether it is being met is not much of a requirement.

Another regulator does not answer the municipal question

The model also recognizes that municipalities are not the only regulators involved.

Electricity generation and transmission, environmental approvals, water allocation, air emissions, building and fire safety, occupational health and safety, transportation, privacy, telecommunications and Indigenous consultation may fall partly or primarily under other authorities.

That does not mean the municipality has nothing left to decide.

The existence of another regulator does not necessarily answer whether a particular development is appropriate in a particular location.

Where municipal authority permits, local government still has legitimate questions about land-use compatibility, setbacks, cumulative development, public infrastructure, emergency-service capacity, nuisance impacts, community protection, monitoring, transparency and enforceable development conditions.

Compliance with another regulator’s minimum standard should not automatically answer the municipal planning question.

Who is this for?

The model is intended for more than municipal administrators.

For planners and municipal staff, it provides a resource for identifying issues that may need to be addressed when drafting or updating application requirements, bylaws and development conditions.

For elected officials, it provides a reference for understanding the range of regulatory approaches available and the protections communities may reasonably ask them to consider.

And for residents, landowners, Indigenous communities, agricultural operators, businesses and others potentially affected by development, it is also a tool for asking better questions.

What information should I request?

What assumption is being made here?

How will this impact be measured?

Who pays if infrastructure has to be upgraded?

What happens if the facility becomes larger than initially proposed?

Can five supposedly separate projects actually be one development?

Who monitors compliance?

What happens when the company sells?

Who pays when it closes?

Sometimes knowing the question that has not been asked is as important as knowing the answer.

What this model is not

This is not a finished statement of what every municipality should enact.

It is not an argument against data centres.

It is not a claim that every provision belongs everywhere.

It is not legal advice.

It is not static.

Numerical thresholds, notice distances, technical standards, reporting periods, tier boundaries and setbacks should be tested against local conditions. Some will change as technology and knowledge change.

The Model Commentary included throughout the document would not normally form part of an enacted bylaw. It exists to explain why provisions are present, what problems they are intended to solve, and what someone adapting the framework should think about.

And I fully expect the model itself to continue evolving.

That is one of the reasons I kept delaying it.

There was always one more thing.

There probably always will be.

At some point, you publish

The rush to attract data-centre investment is moving considerably faster than the regulatory structures being developed around it.

That makes waiting for a mythical final version increasingly difficult to justify.

The County of Newell situation demonstrates why.

By the time a potential regulatory weakness becomes obvious, a development model may already exist that can take advantage of it.

Good regulation should attempt to anticipate that. It should not assume bad faith from developers. But neither should it depend upon everyone voluntarily choosing not to use the loopholes placed in front of them.

The ultimate purpose of this model is practical. It is intended to move the discussion beyond:

“Do we allow data centres?”

and toward more useful questions:

Where should they be permitted?

What must an applicant demonstrate before approval?

What is the complete project?

What impacts must be prevented or controlled?

What happens when several projects affect the same community, watershed, airshed or electrical system?

What costs belong to the development rather than the public?

What information should residents be entitled to see?

What promises should become enforceable conditions?

How will actual performance be measured?

What happens when the project changes?

What happens when something goes wrong?

And who remains responsible when the data centre eventually closes?

A municipality does not need every provision in this model.

It does need answers to those questions.

The Model Bylaw can be download for FREE from two locations - Zenodo and The Internet Archive in PDF format (20kb)