My recommendation, from a program I spent this year running: if the question is "will this physical design work," don't reach for a generative model at all. Reach for a surrogate model grounded in the actual physics, back it with a knowledge graph of prior art so the system knows what's already been tried, and save the generative layer for what it's actually good at — search, summarization, and talking to the humans in the loop. The distinction sounds obvious stated plainly. It is not obvious to a client evaluating a physics-AI pitch, and it was not fully obvious to me either when I started, because I came to this program as a program manager first and a physics-AI practitioner second.
The question every physics-AI pitch has to answer
Every deep-tech R&D program I've worked on this year eventually gets asked the same question by a skeptical technical reviewer: why can't a large language model just do this? It's a fair question. LLMs are good at pattern-completion over token sequences, and a lot of engineering documentation reads like pattern-completion territory — specs, prior reports, design rationales.
The honest answer is that a generative model reasons in tokens, and physical law does not live in tokens. A model trained to predict the next plausible word will produce a plausible-sounding answer to "what happens to this material under these conditions" whether or not that answer respects a single conservation law. It has no mechanism that forces its output to obey a differential equation, and nothing in how it's trained penalizes it for being fluent and wrong over being awkward and right. That's not a criticism of language models doing what they're built for. It's a statement about what they're not built for, and a physics-AI program that can't answer the defensibility question with an architecture, not a pitch, doesn't survive its first serious technical review.
Surrogate models, not generated text
The actual answer is surrogate modeling: train a fast-running model to approximate the output of a slow, expensive, physically grounded simulation, so an engineer can explore a design space in minutes instead of running a full simulation for every candidate. The program I worked on built these using Latin Hypercube Sampling to choose a representative spread of design points to actually simulate, and physics-informed neural networks — models whose training loss includes the governing physical equations, not just the fit to sampled data — so the surrogate is constrained by the physics even in the regions between the points it was trained on.
The distinction that matters here isn't just architectural, it's epistemic. A surrogate model's job is to approximate a known, trusted physical process faster. It inherits its correctness from the simulation it's standing in for, and that simulation inherits its correctness from physical law. A generative model's job is to produce plausible continuations of a token sequence. Nothing in that second description involves a physical process at all — plausibility and correctness happen to overlap a lot of the time in ordinary language, and they do not reliably overlap when the underlying domain is governed by equations the model was never given.
A knowledge graph, because the model isn't the whole system
The part of this work that surprised me, coming into physics-AI mid-career, was how much of the actual value sat outside the model entirely. A surrogate model tells you how a design behaves. It says nothing about whether that design, or something close to it, has already been tried, patented, or ruled out by someone else's prior work — and in deep-tech R&D, that question is often the one that actually saves money.
The program built a knowledge graph over patents and prior art specifically to answer that question, connected to the same staged process that governed everything else the program touched. It's a genuinely different kind of system from the surrogate models: not predicting a physical outcome, but representing what's already known and how it connects, so a team evaluating a new concept can see its neighbors before committing budget to it. Put together, the two pieces answer two different questions that a single model, generative or otherwise, cannot answer at once — "what will this design do" and "has this already been tried."
Staying honest about what's proven and what's promising
The program ran every idea through a staged gate: need, opportunity, concept, monetization. Each stage asks a narrower, harder-to-fake question than the one before it — does a real need exist, is there a credible way to address it, does a concept actually work at the fidelity we can currently prove, and is there a monetizable path from here. The value of a staged process like this isn't bureaucratic. It's that it keeps a program from letting an impressive-looking demo at one stage stand in as proof for a claim that belongs at a later stage — the same discipline, structurally, as not letting a compliance signal stand in for an outcome signal. A concept that works in simulation is not yet a concept with a monetization path, and collapsing the two because the simulation result was exciting is exactly the mistake the gates exist to catch.
That staged discipline is also what eventually resolved the defensibility question for real, rather than rhetorically. The program's first proof of concept — built for a manufacturer's R&D programme — was accepted into a major energy company's startup-incubator and innovation-partner program after passing through those stages with real physics behind the surrogate model and real prior-art grounding behind the concept, not a generative demo dressed up to look like one. Getting there took an architecture a skeptical reviewer could actually interrogate, not a confident answer in a pitch deck.
Learning the domain while running the program
I should say plainly that physics-AI was a new domain for me. I came onto this program first as a program manager and only afterward, in parallel, built real hands-on skill in surrogate modeling and the physics-informed layer underneath it — I did not walk in as an expert in the simulation tooling this space normally runs on. I'm naming that because I think it's relevant to the actual lesson here, not despite it: the reason "why not just use an LLM" survives as a live question in this field is that it's genuinely tempting from outside the domain, where the surface behavior of a fluent model and a physically grounded one can look similar right up until someone checks the second decimal place. Learning the domain is what made the distinction stop being a slogan and start being something I could defend line by line.
What I do now
- Ask, before reaching for any generative model on a technical problem: does the correct answer depend on a physical law, a conservation constraint, or a governing equation? If yes, that's a surrogate-modeling or simulation problem, not a language problem.
- Keep a knowledge-graph or prior-art layer separate from the predictive model — "what will this do" and "has this been tried" are different questions and deserve different systems, not one model asked to do both.
- Run every new concept through a staged gate that gets harder to fake at each stage, and don't let a result at one stage stand in as proof for a claim that belongs at a later one.
- When defending a physics-AI approach against "why not just an LLM," answer with the architecture — what forces the output to respect physical law — not with a demo.
- Name where you're still learning the domain, out loud, especially when you're also the one accountable for the program's credibility. It's a more honest position than borrowed confidence, and it's the position that actually improves.