A balcony doesn't stand because an AI says it "looks safe." It stands because the load path from the railing to the foundation is continuous, the stress in the concrete stays within material limits, and the laws of physics are satisfied at every connection point. No amount of pixel analysis changes that.
Yet the architecture, engineering, and construction (AEC) industry is racing to deploy AI tools — Large Language Models and their multimodal cousins — that do exactly this: they look at blueprints the way you'd look at a photograph, and they guess. Our research into physics-informed AI for structural engineering reveals a gap between what these models promise and what physics demands, and that gap has consequences measured in human safety, not software bugs.
We call it the Deterministic Divide. On one side: AI that predicts the next pixel. On the other: AI that calculates whether a structure will hold.
The Pixel Problem: What AI Actually "Sees" in a Blueprint
When a multimodal AI model like GPT-4V or Gemini processes a structural blueprint, it doesn't perceive beams, columns, or load paths. It uses something called a Vision Transformer, which chops the image into tiny patches — imagine cutting a blueprint into hundreds of postage stamps — and then looks for statistical patterns between those patches.
The model learns that a patch containing a vertical line (a column) tends to appear near a patch containing a horizontal line (a beam). But this is correlation, not comprehension. The model doesn't understand that the horizontal line is supported by the vertical one. Remove the column from the image, and the model's confidence might dip slightly — but it has no internal physics to tell it the beam must now fall.
A connection detail that's "mostly there" but missing a critical load path isn't 90% safe. It's 100% unsafe.
Research on Vision Transformers confirms this: when image patches are scrambled, these models often maintain high classification accuracy. They're reading textures and local patterns, not spatial structure. In engineering, spatial structure is everything.
The Benchmarks Don't Lie
This isn't a theoretical concern. Two recent benchmarks put hard numbers on the problem.
DSR-Bench tested ten leading LLMs on structural reasoning — the ability to understand and manipulate complex relationships between entities, which is exactly what you need to analyze a building frame. The best model scored 0.498 out of 1.0 on challenging problems involving composite structures. That's essentially a coin flip. Performance dropped further on spatial tasks as complexity increased, and models performed worse when problems were described in plain English versus formal code — suggesting they're pattern-matching syntax, not reasoning about structures.
DesignQA, a benchmark built specifically for engineering design, found a telling split. Models could answer "What is the maximum allowed deflection?" by extracting text from a code document. But they failed at the follow-up: "Does this specific beam design meet that limit?" Extraction is easy. Application — the part that actually matters — broke them.
We explored these failure patterns in depth in our interactive analysis of the Deterministic Divide.
Perhaps most revealing: when asked about material selection, LLMs showed a consistent bias toward exotic, high-performance materials like titanium and carbon fiber — not because the design required them, but because those materials appear frequently in the "high-tech" corners of their training data. An AI reviewing a balcony design might confidently recommend an advanced alloy railing while completely missing that the concrete slab beneath it lacks the reinforcement needed to stay attached to the building.
Why Structures Are Fundamentally Different from Images
Standard AI excels at data that lives on grids. Images are 2D grids of pixels. Audio is a 1D grid of time steps. Every pixel has the same number of neighbors, and shifting one pixel to the right means the same thing everywhere in the image.
Buildings don't work this way.
A steel joint in a truss might connect to three members. A node in a complex diagrid might connect to eight. There's no fixed grid, no uniform neighborhood. Rotate a blueprint 90 degrees and every pixel value changes — but the structure itself, the way forces flow through connections, remains identical.
This is the distinction between Euclidean data (grids, where standard AI thrives) and non-Euclidean data (networks and graphs, where structures actually live). Forcing a building into a pixel grid is like forcing a subway map into a photograph — you lose the very information that matters: what connects to what, and how.
Treating Buildings as Graphs, Not Images
Our approach starts from a different premise entirely. Instead of feeding a blueprint image into a neural network, we convert the structure into a mathematical graph — a network of nodes and edges.
Think of it like this: every beam, column, slab, and wall becomes a node. Every physical connection between them becomes an edge. But unlike a simple diagram, each node carries rich engineering data — the material's stiffness, its strength, its geometric properties. Each edge carries information about the connection type: is it rigid? Is it a hinge? How much load can it transfer?
This representation captures something pixels never can: topology. The graph knows that Beam A is supported by Column B, which transfers load to Foundation C. It knows this regardless of how the blueprint is drawn, rotated, or scaled. And critically, it knows when that chain is broken.
We don't ask the AI to learn physics from data. We embed the laws of physics directly into how it thinks.
Teaching AI to Obey Newton's Laws
The most common objection to AI in structural engineering is the "black box" problem — how can you trust a neural network with human safety when you can't see its reasoning?
We address this with Physics-Informed Neural Networks, or PINNs. In a standard neural network, training means minimizing the gap between what the model predicts and what the correct answer is. In a PINN, we add a second requirement: the prediction must also satisfy the governing equations of physics.
Consider a cantilevered balcony. The physics governing its deflection — how much it bends under load — is described by a well-known differential equation (the Euler-Bernoulli beam equation, for the engineers reading this). When our model predicts how the balcony will behave, we don't just check whether the answer matches historical data. We check whether the answer obeys the equation. If the predicted deflection shape violates static equilibrium — if the math says forces aren't balanced — the model is penalized and forced to correct itself.
The result is an AI that physically cannot hallucinate a safe structure that isn't safe. The laws of physics act as guardrails built into the model's core, not bolted on after the fact.
This approach has been validated across increasingly complex scenarios. Physics-Informed Kolmogorov Arnold Networks have accurately predicted failure loads for bridge structures even with very limited training data. In railway bridge monitoring, PINNs succeeded where conventional data-only models failed to converge. The physics constraints act as a regularizer — they keep the AI's predictions tethered to reality.
Speed Without Sacrifice
The natural question: if you're embedding physics equations into AI, isn't that just a slower version of traditional engineering software?
The opposite. By combining graph-based architecture with physics-informed learning, we leverage a cutting-edge framework called Graph-Structured Physics-Informed DeepONets. Without getting lost in the acronym, the key result is this: 7–8x faster than traditional Finite Element Method solvers, with accuracy values reaching 0.9999 on an R² scale (where 1.0 is perfect).
That means near-instant structural assessment without sacrificing the mathematical rigor that traditional analysis provides. For the full technical methodology behind these benchmarks, see our detailed research on physics-informed graph architectures.
Tracing the Spine of a Building
One of the most powerful applications of the graph-based approach is automated load path tracking — tracing exactly how forces travel from where they're applied (a person standing on a balcony) down to the foundation.
We compute something called the U* Index, which maps the internal strain energy transfer through the structure. Think of it as a heat map of force flow. The "hottest" path — the principal load path — is the structural spine. If the balcony is properly designed, that spine connects seamlessly from the railing through the slab, into the beam, down the column, and into the ground. If something is missing — a discontinuous connection, an undersized member — the spine breaks visibly.
An LLM sees pixels and says "this looks like a balcony." Our system traces the load path and says "this force has nowhere to go."
We can also simulate progressive collapse by systematically removing nodes from the graph — what happens if this column fails? — and instantly evaluating whether the remaining structure stays connected. Traditional nonlinear collapse analysis takes hours. Graph-based screening takes seconds, allowing thousands of failure scenarios to be evaluated in the time it takes to run one conventional simulation.
What About Using LLMs for the Creative Part?
This is the question we hear most, and our answer might surprise people: we agree that generative AI has a role in design. Architects should absolutely use creative AI tools to explore concepts, generate options, and push boundaries.
The problem isn't creativity. It's verification.
Our framework treats this as a two-layer system. The generative layer — where probability and imagination belong — produces design concepts. Then a verification layer converts that concept into a graph, checks whether the topology is connected, traces the load paths, and runs physics-informed stress checks. If the design fails, the system returns specific, actionable constraints: "Increase beam depth by 200mm" or "Add a moment connection at this joint." The creative tool regenerates. The physics stays non-negotiable.
Why This Matters for Data Security
There's a practical advantage to physics-constrained AI that rarely gets discussed: it's dramatically more data-efficient. LLMs need the entire internet to learn what a building "looks like." Physics-informed models need far less data because the equations themselves carry enormous information. Hooke's Law doesn't change between projects.
This means smaller, specialized models that can be deployed on-premise. Engineering firms working on sensitive infrastructure — data centers, government facilities, critical systems — don't need to send proprietary blueprints to a public API. The physics engine lives on your server.
And because graph neural networks operate on nodes that map one-to-one to physical components, the reasoning is inherently transparent. We can show exactly which connections influenced a failure prediction: "The column was flagged because the combined load transferred from Beam A and Beam B exceeds its capacity by 12%." That's not a black box. It's a glass box.
What This Means for Your Firm
The construction industry occupies a unique position in the AI landscape. In software, a bug is an annoyance — you push a patch. In structural engineering, a bug is a catastrophe. The tolerance for hallucination isn't low. It's zero.
If your firm is evaluating AI tools for structural work, the critical question isn't "Can this AI read a blueprint?" It's "Does this AI calculate, or does it guess?" Pattern recognition and physics verification are fundamentally different capabilities, and conflating them creates risk that no amount of prompt engineering can eliminate.
The path forward isn't rejecting AI — it's demanding that AI in safety-critical applications be grounded in the same mathematics that has kept buildings standing for centuries. Graph theory. Differential equations. Deterministic verification.
We'd welcome a conversation with anyone navigating this decision. What's your firm's current approach to validating AI-generated structural assessments?