A viable project is not automatically the right project for this client.

PACTS and its diagnostic frameworks answer a specific question: can this project exist. That is a necessary question, but it is not a sufficient one. A site can pass every feasibility screen, survive every fragility diagnostic, and still be the wrong infrastructure for a particular customer, workload, or deployment schedule. Viability and fit are not the same thing, and treating them as interchangeable is one of the more expensive mistakes in AI infrastructure development.

LENS² is the framework built to test fit rather than feasibility. It is a Client Deployment Requirements Framework, and it examines Latency, Expansion Path, Near-Term Delivery, and Stability through the operational reality of the specific client being evaluated.

The Four Conditions

Latency asks whether the facility is close enough, physically and digitally, to the users, devices, networks, or systems the workload actually has to serve. A site can be excellent in every other respect and still be too far from where the workload's users are.

Expansion Path asks whether the customer can grow beyond the initial deployment without running into an entirely new infrastructure or regulatory process. A site that fits today's requirement but has no room to scale can become a constraint the moment the customer's needs change.

Near-Term Delivery asks whether usable capacity can actually become operational when the customer needs it, not at some undefined future point that happens to fall inside an optimistic project timeline.

Stability asks whether the utility, regulatory, political, environmental, and operating conditions are durable enough to support the length of commitment the customer is being asked to make.

Why the Superscript Matters

LENS² is not simply four letters. The superscript stands for Workload multiplied by Uptime, and those two variables are not additional conditions sitting alongside the first four. They are the multiplier that changes how every one of those four conditions should be interpreted for a given client.

A training workload and a real-time inference workload can evaluate the same site completely differently under the same four LENS conditions. Robotics applications can impose latency requirements that other workloads never encounter. A customer with an extremely low tolerance for downtime can reject infrastructure conditions that a more tolerant customer would accept without concern. LENS² does not ask whether a project is generally good. It asks whether this opportunity works for this client, on their clock, with their workload.

Passing PACTS and Failing LENS² Is Not a Contradiction

A project can clear PACTS, survive every fragility diagnostic, and still fail LENS² for a specific customer. That outcome does not mean the project is flawed. It means the project and that particular client do not fit, which is a different and often more common finding than outright infeasibility. Recognizing that distinction early prevents organizations from forcing a mismatch or, just as costly, walking away from a project that would have been an excellent fit for a different client.

A framework, not a scoring system.

LENS² does not produce a single number that says a site is good or bad. It produces a structured way to ask whether a viable project is viable for the client actually being considered, which is frequently the question that gets skipped once a project has already cleared every earlier hurdle.

Related Idea: The AI Infrastructure Decision Language