AI Doesn't Have a Data Problem. It Has a Geography Problem.

Why foundation models struggle with physical-world decisions, and what spatial intelligence and digital twins reveal about AI's next bottleneck

For a decade, the AI industry has run on one assumption: every limitation is a scale problem. Hallucinations, brittleness, narrow domain performance. The fix has always been the same prescription at higher doses. More parameters. More tokens. More synthetic data to fill the gaps the internet didn't cover.

That prescription worked remarkably well for language. It is starting to fail, quietly and specifically, for anything that touches the physical world.

The failure doesn't look like a crash. It looks like a model that is statistically correct and operationally wrong. An output that passes every benchmark the team built, then fails the moment it meets a road network, a flood plain, or a warehouse floor.

The industry keeps treating this as a data gap. It is closer to a missing primitive. Geography itself never made it into the stack, and "more data" is not the same fix for a missing primitive that it is for a thin dataset.

The Scaling Assumption Doesn't Travel Well

Scaling laws are real. But they describe a relationship between compute, data, and loss on a specific class of problems: prediction over sequences, where the right answer is a statistical regularity buried in enough examples. Text is forgiving in this way. So, increasingly, is image and video, where the underlying signal is dense and homogeneous enough that more examples reliably mean better coverage.

Geography doesn't behave like that. Spatial relationships aren't just another feature column to add to a bigger training set. They encode constraints (physical, regulatory, infrastructural) that don't average out across more data points.

Two ZIP codes can carry nearly identical income, density, and demographic profiles and still produce wildly different business outcomes. One sits on a highway off-ramp. The other sits behind a one-way grid with no left-turn access. No amount of additional demographic data resolves that gap, because the variable that mattered was never demographic. It was topological.

A fair objection here: isn't geography just another kind of data? Yes, in the trivial sense that coordinates and road networks are data too. But the title's claim is narrower and more useful than "AI lacks information." The actual failure is structural: most architectures treat location as an attribute sitting in a row next to income and square footage, when it functions as a relationship between rows. A model can have abundant geographic data and still misuse it, the same way a spreadsheet full of phone numbers isn't a phone network. The deeper problem is representation, not volume, and geography is simply where that representation gap shows up first and most expensively.

This is the part most AI commentary skips. The conversation about model limitations runs almost entirely on language, images, video, and structured tabular data. Location, distance, connectivity, and accessibility rarely appear as first-class subjects, even though they govern outcomes in logistics, retail, healthcare, utilities, insurance, and construction. These sectors collectively represent a large share of global GDP and almost none of the model architecture investment.

Statistically Right, Geographically Wrong

The cleanest way to see the gap is to look at cases where a model's output is technically defensible and still wrong in a way that only shows up in the field. Call it the pattern most AI commentary misses: a system can be statistically right and geographically wrong at the same time, and nothing in standard evaluation catches the difference.

Retail site selection. A model trained on demographic and foot-traffic data can correctly identify a location with strong household income, dense population, and high category spend.

It can still miss that the site has no left-turn access from the dominant traffic direction. Or that the nearest competitor controls the only signed intersection within half a mile. Or that parking turns over once every four hours instead of the twelve times a comparable site achieves.

The demographic model isn't wrong. It's answering a question that was never the binding constraint.

Last-mile logistics. This is the best-documented version of the problem, because a major retailer has published the data. In Amazon's last-mile routing research, the company found that drivers frequently deviate from planned delivery routes because of their tacit knowledge of the road and curbside infrastructure, customer availability, and other characteristics of the respective service areas.

The dataset behind this finding spans over six thousand actual driver trajectories from five major US cities. The headline result: models trained to predict what experienced human drivers actually do significantly outperform traditional optimization-based approaches that only minimize distance or time.

The optimizer was solving the wrong problem. The driver's mental map of curb cuts, loading zones, and one-way exceptions encoded information the routing algorithm never had access to.

Healthcare access. Demand-forecasting models can correctly predict where patient volume will rise. They routinely miss that the relevant variable isn't distance to the nearest facility but travel time under realistic conditions, which can differ by an order of magnitude between a community with a direct arterial connection and one separated from the same facility by a river crossing that floods in heavy rain.

In each case, the error doesn't show up in cross-validation. It shows up in deployment, which is exactly why it's underweighted in how the industry evaluates its own progress.

The Hidden Constraint: Geographic Relationships Don't Average

Here is the underlying reason more data doesn't fix this. Most statistical learning assumes observations are exchangeable, or close enough to it, that adding more of them improves the estimate. Spatial data routinely violates that assumption.

Geographers have a name for why. Tobler's First Law of Geography, formulated in 1970, states it plainly: everything is related to everything else, but near things are more related than distant things. A location's outcome depends on its relationship to its neighbors, not just its own attributes. That relationship is mediated by physical structure a feature vector at the location level simply doesn't capture.

This is also an architecture mismatch, not just a missing variable. Transformers, the backbone of most modern AI, are built to model sequences: token follows token, sentence follows sentence. Physical systems aren't sequences. They're graphs. A road network, a utility grid, a watershed, a supply chain: each is a set of nodes and edges where what matters is adjacency and flow, not order. Feeding graph-shaped problems into sequence-shaped architectures is part of why the failures above keep recurring. It's not that the model saw too little data. It's that the data was poured into a container built for a different geometry.

Two markets with near-identical input statistics can diverge sharply for exactly this reason: an urban infill site with through-traffic, and a suburban outparcel with the same demographics but a single ingress point. Flood-prone and stable parcels with similar elevation profiles can carry very different insurance loss histories, since watershed topology, not just ground elevation, determines where water actually moves. The missing variable in each pair isn't more data about the location. It's the structure of the location's relationship to everything around it: a graph, not a row.

Zoom out and a pattern emerges across the entire history of the field. AI's progress so far has come in three overlapping eras, each defined by what kind of structure the dominant architecture could represent.

Era one was language intelligence. Transformers learned to model sequences, and the sequence turned out to be a remarkably general container: sentences, code, even protein chains.

Era two was multimodal intelligence. The same sequence-modeling trick got extended to images and video by treating pixels and frames as sequences too, with enough success that it looked, briefly, like sequences could absorb almost anything.

Era three, the one just beginning, is spatial intelligence. Place, topology, and physical structure don't compress into sequences without real loss, which is exactly why digital twins, geo-foundation models, and graph-based architectures are emerging now rather than five years ago. They are the field building a new container for a kind of structure the old one couldn't hold.

A Second-Order Effect Few People Talk About: Digital Twins Are Quietly Exposing This

The clearest evidence that the industry is bumping into this constraint, even if it hasn't named it yet, is the maturation of digital twin technology.

NASEM's working definition of a digital twin describes it as a collection of virtual information constructs that replicate the structure, context, and behavior of a natural, engineered, or social system, continuously updated with data from its physical counterpart, with predictive capabilities that support decision-making. Strip the formality from that and the load-bearing word is "structure." A digital twin that doesn't model spatial structure isn't a digital twin. It's a 3D model with a dashboard attached.

A real deployment makes the distinction obvious. Germany's peer-reviewed Herrenberg urban digital twin case study combines a 3D model of the built environment with a street network model, an urban mobility simulation, and a wind flow simulation to manage a historic core that's strongly affected by car traffic and emissions. None of that is a data-volume problem. It's a problem where the model has to know what's next to what, what flows where, and what physically constrains what, and no amount of additional non-spatial data substitutes for that knowledge.

Digital twins are forcing the industry to confront, project by project, what pure data-scaling roadmaps have been able to ignore: you cannot simulate a physical system without first representing its geography correctly, and most AI tooling still treats geography as metadata rather than structure.

Why This Trend Is Easier to Predict Than It Appears

Skeptics will point out that "spatial AI" has existed for decades inside GIS software, and that's correct. The difference now is that the foundation-model paradigm, the thing that made language and vision tractable at scale, is being applied to location itself for the first time, and the early results are a useful signal of where the binding constraint actually sits.

Google Research's Population Dynamics Foundation Model is a useful case study. It generates compact location embeddings by ingesting regional data including search trends, points of interest, mobility patterns, weather, and air quality, then processes these features through a graph neural network to produce a rich embedding for each location.

The notable design choice isn't the data volume. It's the graph structure, because relationships between locations are the thing being modeled, not just the attributes of each location in isolation. Since release, over two hundred organizations have tested the embeddings, with the dataset expanding from the US to the UK, Australia, Japan, Canada, and beyond.

A second example, Google's AlphaEarth Foundations, takes a parallel approach for the physical landscape itself. Researchers describe it as a "virtual satellite" capable of characterizing the Earth's surface and its dynamics in unprecedented detail, integrating optical imagery, radar, LiDAR, and climate variables into a unified representation. The architecture choice that matters here is the same one: spatial relationship is structural to the model, not bolted on as a coordinate pair.

Neither of these is a market-sizing story. They're an architecture story: the field is quietly rebuilding the foundation-model approach around graphs and relationships instead of sequences, because that's what physical systems actually are.

Where This Argument Could Be Wrong

Three pushbacks are worth taking seriously rather than waving off.

Geo-foundation models could simply absorb this problem the way scale absorbed earlier ones. If graph-structured location embeddings become a commodity API layer, as PDFM's trajectory suggests, the distinction this piece draws between "data" and "structure" could collapse back into a data problem, just at a different layer of the stack. That's a real possibility, and it would be the optimistic outcome: the gap closes because the industry builds the missing primitive, not because the argument was wrong about the primitive being missing.

Plenty of physical-world AI already works fine without explicit spatial structure. Demand forecasting, fraud detection, and dynamic pricing often perform well using tabular features that happen to correlate with location, without ever modeling adjacency directly. The cases in this piece are real, but they're drawn from domains where spatial topology is the dominant constraint. They shouldn't be read as a universal claim that every physical-world model is secretly broken.

The "data versus geography" framing is, admittedly, a simplification. Geography is data. The more precise claim is that AI has a representation problem, and physical-world deployments are where that representation problem becomes visible and expensive first, because spatial relationships violate the exchangeability assumption baked into most architectures more obviously than other relational domains do. The title is a hook, not a literal taxonomy, and it's worth saying so plainly.

The Next AI Race Won't Be Decided by Model Size

The first decade of the modern AI race was a parameters-and-compute contest, and it's largely been won by whoever could afford the largest training runs. Compute still matters, and foundation models aren't going away. But the next contest is best understood as orthogonal to model scale rather than a replacement for it: spatial intelligence layers on top of large models rather than competing with them for the same budget line. The bottleneck for physical-world applications increasingly isn't a bigger model. It's whether a system can represent where things are, how they relate, and what physically constrains them, which requires a different kind of infrastructure: spatial graphs, geo-foundation models, and digital twins that are accurate about structure, not just rich in data.

Organizations sitting on physical-asset data, utilities, logistics networks, construction portfolios, telecom infrastructure, insurance books tied to real property, hold a quietly underpriced advantage here. Their data was never going to be the bottleneck. Their spatial modeling capability is.

Three Forecasts, Held to Account

Prediction 1: Geo-foundation models become a standard layer in enterprise GeoAI stacks by 2028. Probability estimate: 65%, a reasoned judgment based on current deployment pace, not a market forecast. Why it may happen: Early movers already have multi-country pilots and hundreds of testing organizations within roughly a year of release, and cloud providers have an incentive to commoditize spatial embeddings the way they commoditized language embeddings. Headwinds: Spatial data is fragmented across incompatible regional standards and licensing regimes, and enterprise procurement cycles for infrastructure-adjacent tooling are slow. Leading indicator to watch: Whether a major cloud provider ships geo-embeddings as a default, billed-by-the-call API rather than a research preview.

Prediction 2: "Spatial blindness" becomes a named, budgeted risk category in enterprise AI governance by 2029. Probability estimate: 45%, lower confidence since this depends on a few high-visibility operational failures becoming public, which is harder to forecast than adoption curves. Why it may happen: As digital twins and autonomous systems get deployed in higher-stakes physical contexts, a model being statistically correct but geographically wrong becomes a liability event, not just an inefficiency. The mechanism would most likely run through insurance underwriters first, since they already price geographic risk and have the clearest incentive to formalize a new failure category, with audit frameworks and standards bodies like NIST or ISO following once a category exists to standardize. Headwinds: Most organizations lack the internal vocabulary to even name this failure mode yet, and no existing standard currently defines what "spatial validity testing" would even mean, which slows the path to a formal governance line item. Leading indicator to watch: Whether a major insurer or a body like NIST publishes the first framework that explicitly requires spatial-validity testing for AI-driven physical-world decisions.

Prediction 3: Construction, utilities, and logistics outpace consumer tech in operational spatial-AI maturity by 2030. Probability estimate: 70%, the most defensible forecast because it extends a pattern already visible rather than projecting a new one. Why it may happen: These industries have spent decades managing physical-asset data out of necessity and already have the GIS, BIM, and asset-management infrastructure that consumer AI companies are only now building from scratch. Headwinds: Capital intensity and slower software-adoption cycles in these sectors could offset their structural data advantage. Leading indicator to watch: Whether GeoAI vendor revenue, currently led by defense and government, shifts decisively toward infrastructure verticals over the next two reporting cycles.

What Engineering Leaders Should Do Next

The strategic implication isn't "buy a GIS platform." It's narrower and more useful than that: before scaling any model that touches physical-world decisions, ask whether the model's features encode spatial relationship as structure, or merely as a latitude-longitude pair sitting alongside fifty other unrelated columns. Those are different architectures with different failure modes, and the second one is the one quietly producing confident, wrong answers in production right now.

For teams building in logistics, construction, utilities, insurance, or anything tied to physical assets, the questions worth tracking over the next three to five years are concrete. Which cloud provider's geo-embeddings become the de facto standard? Does digital twin tooling consolidate around shared spatial-data standards, or stay fragmented by vendor? And does the industry ever develop a shared name for this failure mode, the way it eventually did for "hallucination"?

The AI industry spent the last decade teaching machines to understand language. The next test is whether it can teach them to understand the place. The organizations that take that seriously now will have a real head start over the ones still waiting for a bigger model to fix a structural gap.


Need content that explains complex engineering?

Great engineering deserves equally great communication. Many companies working at the intersection of AI, infrastructure, and physical-asset data invest heavily in the technology while treating the explanation of it as an afterthought. Increasingly, that explanation is part of the product itself: it shapes how technical buyers evaluate vendors, and how AI systems parse, rank, and surface a company's content in the first place.

I help AI, infrastructure, and industrial-tech companies turn deep technical ideas into content that technical buyers trust and AI systems surface. Services include:

  • Thought leadership articles and analyst-style reports

  • Engineering explainers

  • Service page copy

  • Blog content

  • SEO, AEO, and GEO-optimized web content built for organic traffic and qualified leads

If that's useful to your team, get in touch.


Why BIM Projects Fail: The Coordination Mistake Nobody Talks About

On a mixed-use tower project, a late structural revision shifted several transfer beams after MEP coordination had already been signed off. Because the federated model was not updated before fabrication began, duct sections were manufactured to outdated geometry. By the time the clash was caught on site, four weeks of ductwork had to be dismantled, re-routed, and reinstalled. The delay rippled into commissioning and pushed the handover date by six weeks.

Nobody blamed the software. Everyone had Revit. Everyone had Navisworks. The problem was that BIM coordination had been treated as a design-stage checkbox rather than a continuous project discipline.

That is the mistake this article is about. Not a software failure. Not a skills gap. A process failure, and a specific one: project teams that adopt BIM as a visualization tool instead of running it as a coordination platform.

This pattern is behind the majority of preventable rework, missed handover dates, and facility management failures that haunt projects even after practical completion.

The Core Problem With How Most Teams Use BIM

Building information modeling software is not 3D drafting. A BIM model is a federated data environment containing geometry, materials, system relationships, fabrication requirements, maintenance data, and schedule information. The power of BIM is not in what the model looks like on screen. It is in what the model knows and how that knowledge flows between every discipline across the project lifecycle.

BIM implementation spans multiple dimensions of project data: 4D covers scheduling, 5D covers cost estimation, 6D handles energy analysis, and 7D addresses asset management. When teams treat the model as a fancy drawing, they access perhaps 20 percent of what the technology delivers.

The most damaging consequence of this underuse is not missed software features. It is the false confidence it creates. Teams believe they are coordinating because they have opened a federated model. They are not. They are looking at a snapshot of coordination from a point in time that may no longer reflect the project.

The Numbers That Make This a Business Problem, Not Just a Technical One

Coordination failures often sound like technical problems. In reality, they show up on financial reports long before they show up in BIM dashboards.

McKinsey's analysis of more than 500 large-scale construction projects found cost overruns averaging 79% and schedule delays averaging 52%, tracing back not to field execution failures but to planning and pre-coordination breakdowns.

The Construction Industry Institute consistently finds that rework accounts for 5 to 15 percent of total project costs on commercial and industrial builds. On a 50 million dollar project, that is up to 7.5 million dollars in avoidable expenditure. The majority of that rework originates in coordination gaps that existed in the model weeks or months before anyone touched the site.

A peer-reviewed study published in the journal Buildings found that when properly implemented, BIM reduces project timelines by an average of 20 percent and costs by 15 percent, while decreasing design errors by 30 percent and RFIs by 25 percent. Those results do not come from owning BIM software. They come from running a BIM process that is actually followed.

Why Teams Fall Into This Pattern: Root Causes vs. Symptoms

If the consequences are this clear, why does this keep happening? The reasons fall into two tiers. Root causes that create the conditions for failure, and symptoms that make the failure visible on site.

Root Cause 1: The BIM Execution Plan Is Not Enforced

A BIM Execution Plan is the governance document that defines who owns each model, what Level of Development is required at each stage, how clashes are assigned and tracked, and what the as-built deliverable criteria are. On paper, most projects have one. In practice, it is often a document produced at project inception and never revisited.

Without an enforced BEP, projects become vulnerable to scope creep, inconsistent file management, and version control failures that are invisible until they become expensive problems on site.

According to Autodesk's 2025 Global BIM Management Report, 68 percent of project delays in large-scale infrastructure trace back to document-based bottlenecks, primarily from static BEPs that fail to evolve with project phases.

A BEP that nobody reads past kick-off provides the appearance of process without the substance of it.

Root Cause 2: Version Control Breaks Down Mid-Project

The most common and costly failure mode is this: a structural engineer issues a revision, the architect updates their drawings, but the federated coordination model is not updated before the next round of fabrication planning proceeds.

A 2025 peer-reviewed study on BIM clash detection confirmed that conflicts occur when independently developed structural, architectural, and MEP models are combined, and that identifying those clashes before construction is critical to avoiding rework, missed milestones, cost growth, and schedule impacts.

Version control is not glamorous. But a single un-incorporated design change cascading through the MEP package can cost weeks and significant sums to untangle, as the opening case study illustrates.

Root Cause 3: No Named Ownership for Coordination Decisions

BIM management fails consistently when clash resolution has no owner. A clash detection report can surface hundreds of items. Without a structured process for triaging, assigning, resolving, and verifying those clashes, the report becomes noise. Teams learn to scroll past it.

Construction-critical conflicts sit alongside trivial overlaps in the same list. Nobody tracks whether a resolved clash in the model was communicated to the relevant trades. The model and the field begin to diverge, silently.

Symptom 1: LOD Is Misunderstood or Inconsistently Applied

Level of Development is one of the most consequential and most misapplied concepts in BIM practice. Here is the specific failure point most teams do not see until it is too late.

BIM LOD levels determine what coordination can actually be validated. LOD 300 models the duct, the beam, and the pipe geometrically, but it does not include insulation jackets, hangers, or clearance envelopes. Clearance clashes at LOD 300 are completely invisible. At LOD 350, they are immediately apparent.

The practical consequence: most coordination failures that generate rework on commercial projects come from clearance violations that teams miss because they run clash detection at LOD 300 and assume the coordination is complete.

Teams believe they have coordinated. They have caught the obvious geometric collisions. They have missed everything else.

Inconsistent LOD requirements across disciplines allow each team to model according to its own interpretation, creating gaps that only become visible during construction.

Symptom 2: Clash Detection Is Run Once and Never Again

Clash detection software like Navisworks is only as useful as the frequency and rigor with which it is used. A single coordination round during design development is not sufficient for a complex MEP package in a multi-storey building.

Coordination must continue through shop drawing review, procurement, and construction, with formal model update triggers tied to each major design revision. When it does not, the field becomes the coordination environment, and field coordination costs orders of magnitude more than digital coordination.

Symptom 3: The As-Built Model Dies at Handover

Many practical problems arise from the management of final as-built models, including model mismatch, missing models, and incorrect non-geometric information. A construction team builds a project using BIM. The model is detailed and coordinated right up until practical completion. Then the building is handed over, and the model that comes with it is either incomplete, out of date, or structured in a way the facilities team cannot navigate.

As-built drawings handed over at closeout have a long-standing reputation for poor accuracy. A model kept current throughout construction gives owners a reliable starting point for renovations, retrofits, and capital improvement planning, directly reducing future RFIs and change orders.

Facility management accounts for 80 percent of total costs over a building's life cycle. When the model is abandoned at handover, decades of operational savings are left on the table.

What Effective BIM Coordination Actually Looks Like

The antidote is not better software. It is a more disciplined BIM process.

Make the BIM Execution Plan a Living Document

The BEP must be reviewed and updated at every project milestone, not filed after kick-off. It should define LOD requirements per discipline per phase, version control protocols, clash assignment and tracking procedures, and as-built model deliverable criteria with specific validation requirements. Implementing BIM requires fundamental process modifications, and teams need to define specific implementation areas rather than treating BIM as a generic initiative.

Structure Clash Resolution Like RFI Management

Every clash needs a named owner, a resolution decision, a completion date, and a verification step confirming the model was updated. Clash detection services and coordination meetings should produce formal action registers, not informal agreements. When a clash is marked resolved, the updated model must be distributed through the Common Data Environment before fabrication or installation of any affected element proceeds.

Run LOD-Aware Clash Detection Continuously

Before each clash detection run, confirm that every model element has reached the LOD required for that project phase. A clash check on a model where MEP elements are at LOD 300 and structural elements are at LOD 350 will produce misleading results. Standardize LOD in BIM lod levels per discipline in the BEP and audit models against those requirements before each federated coordination session.

Continue running clash detection through procurement and the construction phase. Set a formal trigger: any design revision affecting structural, architectural, or MEP elements requires a federated model update and a new clash detection run before affected work proceeds.

Specify the As-Built Handover in the Contract

Define as-built model requirements in the contract documents, not after practical completion. Specify which elements must reach which LOD, what non-geometric data must be embedded (manufacturer details, maintenance schedules, warranty information, COBie data), and how the model will be validated before handover is accepted.

BIM delivers accurate as-built models that give facility managers a verified single source of truth. Using COBie-compliant data, teams can track assets, plan maintenance, and manage renovations with significantly reduced operational risk.

A Practical Framework: Phase-by-Phase BIM Coordination Checklist

At contract stage Require a BEP as a contract deliverable. Specify LOD requirements per discipline per phase. Define as-built model criteria and validation process in the scope of works.

At project kick-off Hold a dedicated BIM coordination kick-off session, separate from the general project kick-off. Assign a named BIM manager with authority to flag non-compliance. Establish the Common Data Environment and confirm all disciplines have access and understand the version control protocol.

During design development Mandate federated model updates within 48 hours of any major design revision. Run clash detection before every design freeze milestone. Treat unresolved clashes at LOD 350 as a hard blocker to issuing for construction.

During procurement and construction Require trade contractors to submit shop drawing models to the federated coordination environment before fabrication is approved. Capture construction-stage changes in the model within an agreed timeframe. This is where BIM coordination services from experienced coordinators pay their full value.

At handover Validate the as-built model against the LOD requirements in the contract. Reject handover until the model meets those requirements. Provide the facilities team with a structured orientation on model navigation and embedded data.

The Mindset Shift That Makes Everything Else Work

Every step above depends on one fundamental change in how a project team thinks about BIM.

BIM is not a deliverable. It is an operating system for the project.

A drawing is a deliverable. A clash report is a deliverable. A COBie data sheet is a deliverable. But the BIM process itself is something that runs continuously, that everyone participates in, and that produces value only when the model reflects the current state of reality.

BIM's digital models offer a single source of truth for all stakeholders, supporting lifecycle management from initial concept through to demolition or repurposing, ensuring data is preserved and used at every stage.

That vision does not appear automatically when you open building information modeling software. It appears when the project team treats model accuracy as a shared professional responsibility, enforced through process, and valued by everyone from the owner to the dryliner.

Every project pays for coordination. The only question is whether it pays in the model or on the jobsite.