The AI Infrastructure Decision Language

A common language for deciding whether an opportunity is real.

AI infrastructure projects bring together people who do not naturally evaluate opportunities in the same way.

Developers think about land, entitlements, construction, and execution. Utilities think about generation, transmission, substations, interconnection, reliability, and load. Investors think about capital, risk, counterparties, timing, and return. Customers think about capacity, deployment, connectivity, resilience, expansion, and uptime.

Governments, regulators, and communities see still other dimensions of the project.

Every one of those perspectives can be individually reasonable while the opportunity itself remains unworkable.

The problem is often not a lack of expertise. It is a lack of shared decision language.

From Information to Decisions

AI infrastructure opportunities generate enormous amounts of information. Site plans, utility correspondence, fiber maps, engineering studies, zoning analyses, financial models, development schedules, market forecasts, customer requirements, and environmental studies can all contribute to diligence.

More information does not automatically create a better decision.

Someone still has to determine which facts matter most, how they interact, what remains unresolved, and whether one weakness can undermine everything else.

I developed the AI Infrastructure Decision Language to create a structure for making those decisions.

It operates at three levels.

Level 1: PACTS - Can the project exist?

PACTS examines Power, Approvals, Connectivity, Thermal and Water, and Schedule.

These are the foundational constraints that determine whether an AI infrastructure opportunity is feasible. If one breaks, the deal can break.

Power asks whether electricity can actually be delivered to the project in the quantity, quality, and timeframe required.

Approvals asks whether formal permission can become durable institutional and social permission.

Connectivity asks whether network infrastructure is not merely nearby, but resilient enough for the intended use.

Thermal and Water asks whether cooling and water systems can operate effectively while remaining compatible with the site's environmental, regulatory, and public context.

Schedule asks whether the project's critical clocks can align when they need to.

PACTS is deliberately an early feasibility screen. Its purpose is not to prove that a project works. It is to determine whether there is enough evidence to justify advancing the opportunity.

Passing PACTS does not mean a deal is safe.

It means the deal is not yet impossible.

That distinction is what creates the need for the second level.

Level 2: Fragility Diagnostics - Where does the opportunity become fragile?

A project can appear to pass PACTS while important assumptions remain hidden inside each constraint.

The diagnostic frameworks open those constraints and expose where feasibility can fracture.

GTSQT: Generation Availability, Transmission Capacity, Substation Readiness, Queue Position, Timeline Certainty examines the pathway from theoretical power availability to deliverable capacity.

Power is not one thing. Generation does not guarantee transmission. Transmission does not guarantee substation readiness. Substation readiness does not guarantee queue position. Queue position does not guarantee delivery when the customer needs it.

DLPT: Discretion, Legitimacy, Process Depth, Tradeoffs examines whether an approval pathway remains durable as project specificity and institutional scrutiny increase.

Code allowance is not acceptance. A project can appear permissible while discretion, legitimacy, additional review layers, and required concessions gradually make execution more difficult.

R³F: Route Diversity, Redundancy Topology, Reputation Exposure, Failure Impact examines connectivity by asking how it fails rather than how it performs under normal conditions.

Multiple providers do not necessarily mean independent routes. Apparently redundant connections can converge upstream into the same failure domain, turning a technical outage into a commercial and reputational event.

VWPP: Visibility, Water Narrative, Permitting Friction, Public Reaction Timing examines thermal and water infrastructure as a public interface.

Cooling systems do not remain inside the property line. What neighbors see and hear, how water use is understood, which agencies gain leverage, and when concern emerges can turn a technically viable cooling strategy into a development problem.

Cooling systems also do more than reject heat. They ingest the environment. Ambient heat, air quality, pollution, humidity, and other site conditions can undermine assumptions that appeared reasonable during design.

A⁴: Availability Alignment, Approval Aging, Anchor Tenant Timing, Asset Liquidity Window examines schedule as the alignment of clocks rather than simply project duration.

Power delivery has a clock. Approvals have a clock. Customers have a clock. Capital markets have a clock.

A project can deliver "on time" and still miss the opportunity.

The diagnostic layer therefore asks a different question from PACTS.

Not simply whether the constraint appears to work, but where it can fracture.

PACTS establishes feasibility. The sub-frameworks diagnose fragility.

Level 3: LENS² - Can it work for this client?

Passing PACTS and surviving the diagnostic layer still do not establish client fit.

An infrastructure opportunity can be viable and still be wrong for a particular customer, workload, or deployment schedule.

LENS² is therefore a Client Deployment Requirements Framework.

It examines Latency, Expansion Path, Near-Term Delivery, and Stability through the operational reality of the client.

Latency asks whether the facility is sufficiently close, physically and digitally, to the users, devices, networks, or systems the workload must serve.

Expansion Path asks whether the customer can grow beyond the initial deployment without encountering an entirely new infrastructure or regulatory process.

Near-Term Delivery asks whether usable capacity can actually become operational when the customer needs it.

Stability asks whether the utility, regulatory, political, environmental, and operating conditions are durable enough to support a long-term commitment.

But the superscript matters.

² = Workload × Uptime

Workload and uptime are not additional letters in LENS². They are the multiplier through which the four requirements are interpreted.

A training workload and a real-time inference workload may evaluate the same site differently. Robotics may impose latency requirements that another workload does not. A customer with extremely unforgiving uptime requirements may reject infrastructure conditions another customer can tolerate.

That is why LENS² does not ask whether the project is universally "good."

It asks: Does this opportunity work for this client, on their clock, with their workload?

And that creates an important distinction.

A project can pass PACTS and fail LENS².

That does not necessarily mean the project is bad.

It means the project and the client do not fit.