A site plan can look intelligent and still begin with a bad premise.
The boundary may be right. The buildings may fit. The areas may add up. But if the flood layer is wrong, the power connection is not real, or the land-use data is being read as an administrative label, the masterplan is answering the wrong question.
That is why the first step in early site planning should not be drawing buildings. It should be checking the inputs that can change the answer.
The first failure is often upstream
In a recent internal data-centre test, the visible output was not the hardest part. The harder part was making sure the site intelligence feeding the output behaved honestly.
We checked three different kinds of input:
- flood and hazard data
- nearby grid and power infrastructure
- land-use information
Each one can change the development decision before a building is placed on the site.
That sounds obvious. It is easy to miss in practice because each source can look plausible in isolation.
1. A failed request must not become a confident answer
External data sources fail. A request can time out, return an error, or return an empty response.
The dangerous response is to turn that failure into a clean-looking “no risk” result. A better response is to retry a bounded number of times and then show the result as unknown if the source still cannot be verified.
In our test, one flood-data request returned a server error. The system now retries once. If the source still does not answer, the site is not quietly treated as safe.
Unknown is a useful result. It tells the team what still needs checking.
2. Nearby infrastructure is not the same as available capacity
A map can show a transmission line or a substation near a site. That does not prove that the project can connect to it.
The useful early question is narrower: what evidence exists that the infrastructure is relevant to this site, and what remains unverified?
For a large-load project, the answer may still depend on the utility, the interconnection process, the voltage level, the queue, and the actual capacity available at the point of connection. A nearby line is a signal for further work. It is not a connection approval.
That distinction should survive into the scenario, the report, and the decision conversation.
3. A land-use label must describe land use
Location datasets often contain several names for a place: a district, a local authority, a land-use class, and a description field.
Those fields are not interchangeable.
In one parser check, a district name was being surfaced as though it were the site's land-use description. The output looked tidy, but it was answering a different question. The parser was corrected to use the actual land-use fields and to reject administrative names when they appear in the wrong place.
This is a small software detail with a large planning consequence. A wrong label can affect how a team reads access, surrounding uses, environmental risk, and the next diligence step.
What a trustworthy early scenario should show
An early scenario does not need to pretend it is a final approval drawing. It does need to make its evidence visible.
At minimum, the output should separate:
- what the source directly says;
- what the system calculated from that source;
- what is still an assumption; and
- what a human must verify before the result is used for a live decision.
That separation makes the work more useful, not less useful. A developer can act on a bounded unknown. A lender can see which number still needs support. A design team can avoid polishing a scheme that was constrained by the wrong input.
The masterplan is downstream of the evidence. If the evidence is weak, a more detailed drawing only makes the uncertainty harder to see.
The right first question is therefore not “what can we draw here?” It is “which site facts could change the answer, and have we actually checked them?”
---
*This is a methodology piece based on Keystone's internal 25-09-2026 data-centre live-test and correction records. It does not make a zoning, flood, grid-connection, or land-use determination for any specific site. Real projects still require current source checks and professional review.*