Most conversations about AI and engineering simulation focus on what a model can do once it exists. Less gets said about the step before that: turning a pile of technical documentation into a model in the first place. That step is usually slow, manual, and unforgiving as someone has to read the spec, understand the physics, and hand-translate it into code, checking at every stage that nothing got lost or garbled along the way.

We wanted to see what happens when an agent does that translation instead. So we pointed the Dyad Agent at one of the most thoroughly documented vehicles in aerospace engineering, NASA's HL-20 lifting-body Personnel Launch System, and asked it to build a validated simulation model from a curated set of source assets, reasoning over the specification the way an engineer would rather than being handed pre-written model code to assemble.

This post walks through exactly what the Agent started with, how it reasons over those assets to build the model, and how you can pull down the same project from GitHub and run it yourself.

Why HL-20

The HL-20 is a good stress test precisely because it isn't a toy problem. It's a hypersonic re-entry vehicle originally designed for crewed Space Station missions, and it comes with decades of NASA documentation behind it: wind tunnel data from Langley Research Center, a published nonlinear six-degree-of-freedom aerodynamic model (NASA TM-107580), and a DAVE-ML (Dynamic Aerospace Vehicle Exchange Markup Language) encoding of that aero model used across studies at Langley, Johnson, and Ames from the late 1980s through the early 2000s.

The DAVE-ML file itself is not a small artifact. It's an XML-based standard (ANSI/AIAA S-119) built to encode nonlinear aerodynamic tables, and the HL-20 version packs in 361 variables, 168 tables, and 6,240 data points across the subsonic and supersonic regimes, plus 25 built-in verification check-cases NASA published alongside the data.

What the Agent Starts From

We handed the agent a curated set of assets, built to isolate the exact capability this demo is about: an agent that reasons over a real specification and constructs a physically correct model from it. A couple of those assets also reflect where the Dyad platform is headed next, giving the Agent a head start on capabilities we're actively building into the product.

• The NASA specification. Pre-converted to Markdown, with the relevant plots and figures pulled out as separate image scans.

• The DAVE-ML aero file. The XML-encoded aerodynamic model described above with 361 variables, 168 tables, 6,240 data points, plus 25 verification check-cases.

• The full 1976 U.S. Standard Atmosphere database. Covers temperature, pressure, density, speed of sound, and other atmospheric properties.

• A README of model construction guidelines. This isn't required to produce a working model; it exists so the result can be graded. Fixing things like port names, subsystem structure, and system interfaces in advance means our automated grading infrastructure can score the result programmatically and consistently, run after run. This is what lets us track whether the Agent is getting better over time, not just whether one run happened to work.

• A Julia backend that turns the raw DML tables into callable functions, plus a Dyad model file wrapping those functions as an aero component. Native DAVE-ML ingestion is on Dyad's roadmap, and when it ships, this step disappears entirely. For now, we handed the Agent that translation layer as a ready-made component, the same way you'd hand an engineer an existing library instead of asking them to write a table-interpolation routine from scratch. The demo showcases the Agent's reasoning and modeling capability today, while the platform catches up around it.

From there, the Agent's job is to reason over the Markdown spec and figures to understand the vehicle's geometry, mass properties, and guidance and control laws, then build out the rest of the model (i.e. rigid-body dynamics, control logic, and system assembly) around the aero component it was given, following the interface contract laid out in the README.

Two-Step Validation

This is where the Dyad Agent's workflow diverges most from general-purpose code generation. Dyad models get checked in two distinct ways, and both have to pass before a model counts as "done."

Compiler-in-the-loop validation happens continuously, as the model is built. Dyad's compiler enforces physical correctness at the structural level by catching unit mismatches, conservation law violations, type errors, and over/under-determined systems before a single simulation is ever run. This is verification in the strict sense: does the model even make physical sense as constructed.

Reference validation happens after the model exists. The Agent runs the finished analyses against expected physics - the documented NASA trim conditions for the open-loop cases and the digitized TM-107580 Appendix F pitch-pulse time history for the closed-loop maneuver - and confirms the outputs land within tolerance of that reference data. This is the classical validation question: does the model actually reproduce the physics it claims to.

The combination matters because either check alone is insufficient. A model can be internally consistent (i.e. units matching, no conservation violations) and still be wrong relative to the real vehicle. Conversely, a model can happen to match reference outputs while being physically incoherent underneath, which tends to fall apart the moment you push it outside the exact conditions it was checked against. Requiring both gives you a model that's physically valid and numerically correct.