Permission Has Become Infrastructure
A project can be allowed by code and still fail in practice.
Data center development has traditionally focused heavily on physical infrastructure. Developers ask whether a site has land, power, fiber, water, transportation access, and the physical characteristics necessary to support development.
Those questions remain essential.
But another form of infrastructure increasingly determines whether those physical systems can ever be converted into a project.
Permission has become infrastructure.
Formal entitlement matters. So do discretion, institutional legitimacy, process complexity, political visibility, and the tradeoffs required to maintain forward movement.
A technically feasible project is not necessarily a buildable project.
Code Allowance Is Not Acceptance
One of the most dangerous assumptions in infrastructure development is that a legally permissible use has a predictable approval pathway.
It may not.
Discretion can remain inside fire and life-safety interpretation, environmental review, agency coordination, infrastructure commitments, design review, utility decisions, public hearings, and political judgment.
The more specific and visible a project becomes, the more those sources of discretion can matter.
This creates an important distinction: Code allowance is not the same as acceptance.
A project can be legally plausible while becoming institutionally difficult to execute.
DLPT: Testing the Durability of Permission
Within the AI Infrastructure Decision Language, I use DLPT to examine whether formal permission can remain durable as a project advances.
It stands for:
Discretion
Legitimacy
Process Depth
Tradeoffs
Discretion asks where subjective judgment remains even when the underlying use appears permissible.
Legitimacy asks whether the project aligns sufficiently with local expectations, institutional trust, and the community's understanding of what belongs.
Process Depth asks how many agencies, hearings, reviews, interpretations, coordination layers, and institutional dependencies stand between an initial development thesis and actual construction.
Tradeoffs asks what concessions, mitigations, infrastructure commitments, design changes, community benefits, or other compromises may become necessary to maintain forward movement.
Together, they explain why obtaining permission and keeping permission are not the same thing.
The Legitimacy Threshold
Approval risk can also change nonlinearly.
Early in development, a project may remain relatively abstract. Few people know precisely what will be built. Impacts remain theoretical. Institutional attention may be limited.
Then the project becomes specific.
A megawatt number appears. Cooling technology is selected. Water demand becomes quantifiable. Battery systems enter the design. Infrastructure commitments become visible. Neighbors understand the scale. Agencies recognize the implications.
The project crosses what I think of as a legitimacy threshold.
Beyond that point, scrutiny can accelerate.
This is why approvals often do not fail in one dramatic moment. They can gradually deteriorate as project specificity increases, institutional scrutiny deepens, and momentum slows.
Approvals Can Age
There is another mistake hidden inside conventional development thinking: treating an approval as a permanently valuable asset.
It isn't always.
Political coalitions change. Regulations evolve. Community expectations shift. Agency personnel change. Entitlements expire. Project narratives become stale.
An approval secured years before construction may not carry the same practical value when the project finally needs to act on it.
Approvals are not always durable assets. They can depreciate unless converted into construction momentum.
That is why approval strategy and schedule strategy cannot be separated completely.
Permission Belongs in the Infrastructure Stack
Land without power is not enough. Power without connectivity is not enough. Infrastructure without approvals is not enough.
And formal approvals without durable institutional legitimacy may not be enough either.
Permission therefore belongs in the infrastructure stack because it behaves like infrastructure.
It has dependencies. It has capacity constraints. It requires maintenance. It can become more expensive. It can deteriorate over time. And when it fails, the physical systems behind it may become economically irrelevant.
That is what I mean when I say: Permission has become infrastructure.
© 2026 Suhail Y Tayeb. All rights reserved.