S&P Global’s 2025 survey of 1,006 IT and line-of-business professionals found that the share of organizations abandoning the majority of their AI initiatives before production rose from 17% to 42% in a single year, and that the average organization scrapped 46% of its AI proofs of concept between proof of concept and broad adoption. Gartner, reviewing several hundred implementations, put the post-proof-of-concept abandonment rate at 50% or higher.
Engineering simulation shows the same trend at an earlier point on the curve. In a 2023 survey of 176 NAFEMS members, 99% used classical simulation, over half at scale, while 5% had fully integrated AI or ML into product development. Two-thirds had tried it. Of the rest, just over 60% were sitting at proof of concept or pilot. The most useful finding in that survey is what changed as teams progressed: among organizations already using AI simulation, the leading obstacle became building trust with other stakeholders, ahead of any question of model capability.
That is the problem this post is about. Training a credible first Physics AI model has become achievable for a small team with existing data. Carrying it into a program, and then into the next program, is a different exercise altogether.
Getting started with Physics AI
A Large Physics Model, or LPM, is the physics equivalent of a Large Language Model. Instead of training on text to predict language, it trains on high-fidelity simulation, test, and operational data to predict how physical systems behave. Given a new geometry and operating conditions, an LPM can produce full-field predictions, such as pressure, temperature, velocity, or stress, along with forces, moments, and other engineering quantities. LPMs move engineering teams from evaluating a limited set of possibilities to exploring broad design spaces, from waiting for physical verification to having it available in seconds, and from knowledge captured for one program to knowledge that can improve and compound across many.
The foundations are increasingly accessible. Architectures are published, open frameworks such as NVIDIA PhysicsNeMo give engineers a serious starting point, and public datasets make it possible to experiment without first creating a simulation dataset. These are building blocks rather than turnkey tools for end users, but an organization with a few curious engineers can still train a credible first LPM on data it already has.
That early success can be misleading. A model works, the demo is compelling, and the organization assumes the hard part is over. In reality, it has answered only one question: can this model create value under controlled conditions? Making that value dependable, and carrying it into the next program, requires the model and the organization around it to change together.
The five stages of Physics AI adoption describe that journey. At the beginning, the model is an experiment owned by its builder. By the end, it is shared engineering infrastructure, used across programs and improved through reuse.
Physics AI adoption has five stages
Across the Physics AI efforts we have seen, from two-person experiments to high-consequence engineering programs, the same progression appears:
| Stage | What’s happening | Who’s involved | What it unlocks |
|---|---|---|---|
| Education | Learning what an LPM is and isn’t, running tutorials, reading papers, and evaluating open architectures | One engineer, self-directed | Technical literacy: the ability to separate useful applications from hype and identify where Physics AI could matter. |
| Lab Project | Training a first model on existing data to test a specific idea | One or two engineers, informal | Technical evidence: whether the data contains enough signal, where the model performs well, and what it would take to improve. |
| Pilot | Someone other than the builder uses the model for one narrow, specified use case | A small team, with a design lead watching the result | Workflow proof: faster iteration, earlier feedback, and evidence that engineers can use the model in practice. |
| Production | The model informs real decisions on a schedule the team doesn’t control, for engineers who never built it | An engineering organization, a design review, and a program schedule | An operating capability: predictions in the flow of work, shorter decision cycles, and better targeting of simulation and testing. |
| Scale | Models and their successors are reused across teams and programs | Multiple teams and multiple programs | Compounding returns: each program starts with accumulated data, models, validation, and infrastructure instead of starting over. |
An aerodynamic database, or AeroDB, makes the progression concrete. Every flight-vehicle program relies on a map from vehicle configuration and flight condition (Mach number, angle of attack, sideslip, control-surface deflection) to the forces and moments acting on the vehicle. GNC, flight simulation, structures, trajectory analysis, and design teams all depend on it.
Physics AI turns that database from a sparse table assembled point by point into a model that generates dense aerodynamic data across a validated envelope. It can begin as one engineer’s experiment, become a pilot used by a downstream team, generate validated AeroDBs on demand in production, and provide the data and training foundation for additional systems and programs at scale.
Where building in house works
For education there are a growing number of available resources. A curious engineer can read papers, run the tutorials, and train on public datasets. Luminary publishes open SHIFT reference models and datasets across applications including a pump, an aircraft wing, a battery cold plate, and full-vehicle crash.
The lab project stage is similar. If a model is trained on existing runs, evaluated by its builder, and not yet driving decisions, there are plenty of options. Its value is the technical evidence it provides about whether the use case is promising, what the data can support, and where more work would pay off.
The pilot stage is where things start to diverge. It’s generally best to keep the scope narrow (one system, a reasonable parameter space, a modest dataset) and prove both model performance and workflow fit. The important change is that people beyond the builder begin using it. This is often where limits in ML expertise, simulation-data scale, validation methods, or open-source tooling become visible. That is useful information: a well-scoped pilot should expose what production requires before the organization commits to it.
The most dangerous moment in the lifecycle is often a successful pilot. The model works, the AeroDB can be generated faster, and the value is obvious. But a pilot proves value under controlled conditions. Production has to preserve it when the geometry is unfamiliar, the original builder is unavailable, and a program schedule sets the deadline.
The production threshold
A production LPM serves engineers who did not build it, on geometries nobody anticipated, on a timeline the team does not control. That is also when its impact expands. The organization can screen more concepts, return answers earlier, and make better-informed tradeoffs inside production workflows.
For an AeroDB, the promised state is straightforward. A new configuration enters the workflow, a validated database is generated on demand, and downstream teams continue their work without waiting for a brute-force simulation campaign. High-fidelity simulation and testing remain in the loop, focused where they add the most value.
Supporting that outcome introduces four requirements:
- A deliberate data engine: Production coverage requires generating and curating simulation, test, and operational data for the intended design space, not simply reusing whatever runs already exist. SHIFT-SUV, for example, achieved drag prediction error below 3.45% using about 1,000 deliberately generated simulation samples. The payoff is broader coverage. Engineers can evaluate combinations that were never practical to simulate one by one.
- Uncertainty with every prediction: In a pilot, the builder often knows when an input looks unfamiliar. In production, that judgment has to be encoded and reported. A test-set metric does not tell an engineer whether this prediction, on this geometry, is trustworthy. Uncertainty quantification and out-of-distribution detection show where the model can accelerate a decision and where simulation or testing should remain in the loop. For a deeper look, see Luminary-SMART.
- Integration into engineering workflows: Research code runs in a Python script. Production inference runs in an always-on, governed, and often air-gapped environment. It must then reach the interfaces engineers already use. Once integrated, including through fully air-gapped deployments, an AeroDB model becomes a dependable input to design, controls, trajectory, and other systems workflows.
- Continuity beyond the original developers: A model that informs an engineering decision becomes part of the product-development record. Teams must be able to trace which version produced the result, which dataset trained it, and which tests validated it. Versioning, traceability, and repeatable validation preserve its value across years of requirements changes and retraining.
Building all of that in house typically requires senior ML, simulation, data, infrastructure, and program-management expertise working for the better part of a year. The return is not merely a better model. It is a repeatable engineering capability that provides aerodynamic data on demand, screens more configurations before simulation or test resources are committed, and creates a traceable basis for consequential decisions.
When the returns begin to compound
Scale means multiple models serving multiple teams, programs, and use cases at meaningful inference volume. Compute, model versions, permissions, data access, and governance all have to work across organizational boundaries.
Very few organizations are there. McKinsey’s 2025 survey of 1,993 respondents found 7% reporting AI fully scaled. In engineering simulation specifically, a February 2026 survey of 350 senior engineering leaders put mature scaled programs at just 9%.
Yet this is also where the largest opportunity lies. Without reuse, every model is a custom prototype. With reuse, each becomes a starting point for the next one.
For an AeroDB capability, a new program can begin with accumulated aerodynamic knowledge, proven data-generation and validation methods, tested architectures, and production infrastructure. The new model still has to be validated for its own domain, but the organization does not have to rebuild the surrounding system.
That is the difference between a model that compounds and one that gets rebuilt from zero every time. At scale, the organization accumulates reusable physics knowledge. The next effort benefits from existing datasets, tested methods, extensible validation evidence, and infrastructure that supports deployment.
One step at a time
For education, the lab, and most pilots, the answer stays the same. Build it yourself, use open tools, and see what your data can do. Each stage creates something valuable even if the organization stops there. The stages are not a maturity score, and not every use case needs to reach scale. They match expectations and investment to the outcome the organization wants.
The transition from lab to pilot happens when people beyond the builder begin using the model. Production begins when it supports decisions outside controlled conditions. Scale begins when the capability expands beyond a single program.
Engineering teams have always built fast approximations of expensive physics. What changes with an LPM is how far that knowledge can travel, beyond one spreadsheet, one expert, or one program. Education builds literacy. A lab project proves the technical idea. A pilot proves the workflow. Production makes it dependable. Scale makes it compound.
Luminary builds and operates Physics AI platforms for organizations at the production and scale stages, but that is a separate decision from the one in front of you today. Start with a SHIFT reference model and its open dataset and see what the architecture can do on your problem. If you want to try an LPM yourself, use the prediction demo. If you have a defined use case and want to understand what it would take to move from experiment to pilot, talk to a Physics AI engineer.
