INFASTRACTURE DEVELOPMENT · THE I3 FRAMEWORK
THREE LAYERS, THREE DESCIPLINES: HOW I3 THINKS ABOUT ENERGY INFRASTRUCTURE
By David Swank, CEO, i3 Power & Energy
The vocabulary around advanced infrastructure has expanded rapidly over the past several years. Digital twin, smart grid, integrated system, virtual power plant, flexible interconnection. Each of these terms captures something real, but the proliferation of language has outpaced the industry's ability to be precise about what any particular project actually is or what standard it should be held to. For capital to flow intelligently, and for counterparty trust to develop at the pace the energy transition requires, we need clearer language about the distinct disciplines that advanced infrastructure development actually involves.
At i3, we organize our work around three disciplines, and each discipline produces a specific deliverable. Intelligence produces our digital architecture. Integration produces our energy architecture. Interoperability produces our virtual infrastructure. Each layer addresses a different phase of the development process. Each requires a different set of capabilities. And each is the foundation for the one that follows. Together they describe what it takes to develop energy infrastructure that is ready for the grid we are actually going to operate on in 2035 and beyond.
INTELLIGENCE: BUILDING THE DIGITAL ARCHITECTURE
The first layer is intelligence, and its purpose is to produce a digital architecture that can actually inform the front-end work of site selection and capacity planning. This is where most infrastructure projects are won or lost, well before the first engineering drawing is produced.
The questions this layer answers are specific. Where is there actually grid capacity available, and under what operating conditions will that capacity be deliverable across the life of the asset? Where is load growing fast enough and in the right shape to support the kind of project we are contemplating? Where do transmission patterns, regional generation mix, and utility planning horizons align to create a window for development that will still be open when the project reaches commercial operation? How large should the asset be, given realistic assumptions about interconnection, offtake, and market participation?
These are not desk-research questions. Answering them well requires a digital architecture that integrates ISO data, utility planning documents, congestion patterns, curtailment history, load growth trajectories, and locational economics into something that can actually inform a siting decision. Imagine if you will a developer choosing between three candidate sites in adjacent markets. On paper, any of them could work. The intelligence layer is what tells us which one will still work in 2032, which one will have degraded by then, and which one will have become a very different opportunity than the prospectus assumed.
The broader market often calls adjacent work digital twin, and the phrase is not wrong in a general sense. But it has been applied so broadly, from building sensor platforms to city-scale dashboards, that it no longer communicates what work of this kind actually accomplishes. Digital architecture is the better term. The purpose of this layer is not to produce a better picture of infrastructure. It is to make a better decision about where and how much to build.
.png)
INTEGRATION: BUILDING THE ENERGY ARCHITECTURE
The second layer is integration, and its purpose is to produce the energy architecture of the project itself. Once the intelligence layer has identified where to build and at what capacity, the integration layer answers what to build. Specifically, how the distributed energy resources on a given site, generation, storage, flexible load, controls, get designed and simulated as a single coherent system.
This is the layer most traditional development treats as a series of independent decisions. A generation asset gets sized. Storage gets added separately, often later. Load is treated as an external variable. Controls and dispatch logic get bolted on after the equipment is selected. The result is a system whose components may each be sound but whose interactions were never the object of design. Integration starts from the premise that the energy architecture is the asset, and that every component should be specified against how it will behave alongside the others under realistic operating conditions.
This is also the layer where simulation does the most load-bearing work. A well-designed energy architecture is modeled before it is built, against the grid conditions the intelligence layer has identified. How does the combined dispatch of generation, storage, and flexible load actually perform across a realistic operating year? What happens in stressed grid conditions, and what happens in abundant ones? Where are the thresholds at which the system's economics change, and are those thresholds likely to be crossed more often than the base case suggests? These questions are answered in simulation before capital is committed.
RB Sloan and I sat in that seat on the utility side, and we saw repeatedly what happens when integration is treated as an afterthought. Assets that underperform their engineering specifications. Storage deployed against the wrong dispatch assumptions. Control logic that was adequate for a static grid and inadequate for the one that actually showed up. A well-built energy architecture prevents those outcomes. It is how bankable projects actually get produced, because it is how integrated systems get designed to perform as systems rather than as collections of individually optimized parts.
INTEROPERABILITY: BUILDING THE VIRTUAL INFRASTRACTURE
The third layer is interoperability, and its purpose is to produce the virtual infrastructure that connects the integrated asset to the grid it operates on. Flexible interconnection agreements, coordinated dispatch with the ISO or utility, ongoing operational planning against evolving market and system conditions.
The traditional interconnection model treats grid interface as a one-time event. A project goes through the queue, receives an interconnection agreement, and connects as a fixed-capacity resource. That model is increasingly inadequate for what the grid actually needs. Flexible interconnection, where an asset's connection terms reflect real operating behavior, ability to curtail, ability to provide ancillary services, ability to shift load or dispatch, is quickly becoming the more valuable arrangement for both the developer and the system operator.
Operating well under a flexible interconnection requires a different set of capabilities than operating under a traditional fixed-capacity agreement. The asset has to be able to respond to grid conditions in near real time. Operational planning has to account for market signals, weather, congestion, and utility coordination protocols. The interface with the system operator has to be continuous, not episodic. This is operational work, and it requires a different discipline from either intelligence or integration. The virtual infrastructure that results is what allows the physical asset to participate fluidly in a grid that is itself always changing.
I can't emphasize enough how much value accumulates in this layer over the life of an asset. A project with a rigid interconnection and no operational flexibility earns whatever its fixed terms allow it to earn. A project with a flexible interconnection and the operational capability to make use of it participates in a much larger and more dynamic set of value streams. Over the operating life of an integrated asset, that difference is substantial. Over a portfolio of such assets operating across multiple jurisdictions, it is transformative.
“Intelligence tells you where to build and how big. Integration tells you what to build there and how its parts should behave as one system. Interoperability is how the whole thing lives on a grid that is always changing.”
WHY PRECISION ABOUT THE WORK MATTERS
The layers above describe what energy infrastructure development actually requires when it is done with rigor. It is worth being direct about why that precision matters, because a large and growing set of projects now describe themselves using adjacent language without doing the underlying work. This is not a criticism of any particular project. Many of those projects are genuinely valuable in their own domains. The concern is what happens to the vocabulary, and by extension to capital allocation and policy, when very different categories of work travel under the same labels.
The distinction matters for three reasons.
The first is the difference between observation and operation. A growing number of platforms described as digital twins are essentially observational. They aggregate data across buildings, utilities, environmental sensors, and mobility systems, and they present that data through dashboards and analytics layers. That work is genuinely useful. It produces better visibility into how systems are currently performing. It is not, however, the same as a digital architecture that stress-tests dispatch economics, curtailment risk, and interconnection queue behavior before a dollar of capital is committed. One produces better dashboards. The other produces bankable projects. These are different categories of work, and when they are described with the same terminology, the capital markets have to do extra work to figure out which one they are actually looking at.
The second is how public visibility shapes shared understanding. When large platforms, major brands, and credible institutions use infrastructure language to describe smart-building or smart-neighborhood deployments, that usage quickly becomes the reference point in the broader market. A utility commissioner, a project finance lender, or a policy staffer hearing the word “digital twin” eighteen months from now is going to picture whatever the most visible recent example was. If that example is a building sensor platform, the term will come to mean a building sensor platform. That is a terminology problem for every firm doing grid-scale operational modeling, and it is a market-structure problem for anyone trying to finance the difference.
The third is the absence of grid engagement in most of what gets called infrastructure modeling today. A meaningful digital architecture has to engage with ISO queue dynamics, dispatch conditions, transmission headroom, curtailment risk, and the operational relationships with system operators that make flexible interconnection possible. An energy efficiency or sensor deployment project, however sophisticated in its own right, is not doing that work. It does not need to. It is addressing a different problem. The issue arises only when the two kinds of work are conflated, because the conflation dilutes what operational rigor actually means and makes it harder for the industry to reward projects that have done the harder work.
None of this is an argument against the broader digital twin movement. Smart buildings, smart neighborhoods, and smart cities are generating real value and deserve the capital they are attracting. The point is only that the energy infrastructure the grid is going to need over the next decade is a different category of work, held to a different standard, and it needs language precise enough to let that difference be seen.
.png)
WHY THE THREE LAYERS MATTER TOGETHER
The three layers are a sequence, and the sequence matters. Intelligence without integration produces well-sited projects that were never designed to perform well as integrated systems. Integration without intelligence produces elegantly designed systems built in the wrong locations. Integration without interoperability produces well-designed assets that cannot participate in the grid value streams the market is moving toward rewarding.
Each layer requires its own expertise. Intelligence requires people who can engage with ISO data, transmission planning, and locational economics at a level most developers do not have in house. Integration requires engineers and operators who have designed and run real integrated systems on real grids, and who understand how distributed energy resources actually behave when they are planned together rather than separately. Interoperability requires people who have managed flexible interconnections and operated assets against dynamic grid conditions, often across multiple utility jurisdictions.
The firms that will define the next era of energy infrastructure are the ones that build all three capabilities into the same organization, and that hold each layer to its own appropriate standard. At i3, these three disciplines sit alongside each other by design, because the work of the next decade requires all of them, operating in sequence and in concert. Intelligence, integration, and interoperability are what we do. Digital architecture, energy architecture, and virtual infrastructure are what we build.