In September 1999, NASA’s Mars Climate Orbiter was approaching Mars following its nine-month journey from Earth. Abruptly, the orbiter’s carrier signal was lost during its insertion into orbit. The $327+ million loss of craft and mission was not due to a design flaw, a manufacturing defect, or failure of code, but to a units mismatch between software systems built by two different teams.
Lockheed Martin's ground software calculated thruster performance in pound-force-seconds. NASA's navigation software, built to the same interface specification, expected newton-seconds. Neither tool flagged the discrepancy, because neither understood what the number actually represented. Over months of small trajectory corrections, the unit-conversion error compounded by a factor of 4.45, until the orbiter arrived at Mars some 170 kilometers lower than planned and broke apart in the atmosphere.
The Mars Climate Orbiter failure has since become a cautionary study of how engineering systems fail when assumptions between interfaces go unchecked, but it also serves to illustrate the consequences of software platforms that lack genuine understanding of what the data being processed represents.
Not understanding what the data means isn’t the only limitation of today’s R&D software stack. Design, validation, and documentation tools are often fragmented silos, and treat project management and design work as separate activities.
At the frontier of engineering development, the next step change in the R&D software stack represents a new opportunity to give every team and tool the same context when building today’s most complex systems.
Protos is built around the idea that every team and tool should work from the same technical context. What that means in practice, and how Aris Machina has chosen to implement it, is where things get interesting.
Embedded traceability
Most programs rely on developing traceability the same way: design first, across disconnected tools and then reconstruct the rationale when the subsequent process of certification inevitably arises.
Why was 316L stainless steel selected over 324? Why was the wall thickness set at 3.0 mm instead of 2.5 mm?
Answers are scattered across multiple tools and a handful of engineers’ minds, resulting in effective reconstruction taking longer than the design work itself.
The solution isn't more documentation discipline or a new tool, but capturing rationale as a byproduct of the engineering work itself, at the moment the decision gets made, linked to the specific requirement, model, and test result that justified it. The aim should be embedded traceability, not retrospective reconstruction.
Physics-grounded understanding
An incorrect physics assumption can cost an entire mission. Yet most engineering tools evaluate the output without evaluating the assumptions that produced it.
Largely, this is because tools lack an understanding of the fundamental physics in play. A stress plot or thermal render isn’t engineering knowledge by itself. It’s a color map. Red means “high” in the defined range the post-processor was set to. The tool that generated it doesn’t know why that region is hot, whether the value is physically plausible, or how it relates to a load case run in a different tool by a different engineer last week. It simply rendered pixels.
That’s why structural, thermal, and material analyses can stay siloed even on the same part: each tool visualizes its own domain competently, but carries little context from the others.
This is where the failure mode is more expensive than dangerous — not because a wrong assumption slips through, but because catching it costs so much. A thermal fix that reshapes a bracket doesn't automatically flag the structural margin it affects; nothing in the toolchain understands that the two results are physically coupled.
Programs compensate for this the only way they can: re-run the structural analysis, re-test the assembly, re-validate the margin by hand, every time a change impacts multiple domains. It’s the standard process, but it's slow, and consumes schedule and test budget.
If the toolchain instead carries an actual representation of the physics, a change in one domain surfaces its consequences in the others automatically as the design changes.
Material selection cost pressures
Alloy selection is one of the highest-leverage, hardest-to-reverse decisions on an aerospace program. Weight, cost, machinability, fatigue performance, and corrosion resistance all pull in different directions, and properly characterizing a candidate material is often bottlenecked by physical test coupons.
Programs tend to handle this in one of two ways. Either they over-test, running full characterization on every plausible candidate to be safe, which burns schedule and budget on all available options. Or they under-test, narrow to a shortlist early on partial data, and discover potential performance or manufacturability problems downstream.
The true opportunity is to compare candidate alloys against physics-grounded performance targets early, narrowing a broad field to the two or three worth physically validating. That turns material selection into a design-space problem first and a testing problem second, before a single coupon goes to test.
Front-loading physical test programs
In most aerospace hardware programs, physical testing represents a key bottleneck, more so than compute or engineering hours. A single structural test can represent months of lead time and significant costs across programs like wind tunnel runs, environmental qualification, and the likes.
In hardware, the goal shouldn’t be more iterations but committing to fewer, better-justified physical tests. Enabling this requires tools to explore the design space and narrow candidates as thoroughly as possible before hardware gets built, the same principle that applies to material selection above.
The programs that move fastest aren't running more physical tests in parallel, but running fewer, because they've already ruled out the options that wouldn't have met the standard.
Institutional knowledge
Aerospace and defense programs can span decades, outlasting the tenure of the engineers who made the original design decisions. When the rationale stays with those engineers, their departure leaves gaps that the next team has to reconstruct.
The practical implications of this kind of knowledge siloing appear all too often: a junior engineer re-derives a design decision that was already made, tested, and justified a decade ago, because the rationale lived in a retired colleague's head or archived email threads. Multiply this scenario across a program with a multi-decade lifecycle, and the re-derivation cost is enormous and mostly invisible, because it looks like normal engineering work rather than waste.
The fix is the same structural one as traceability: capture engineering rationale as it's created, tied to the decision and the data that justified it, retrievable by someone who wasn't in the room. Capturing rationale as part of the engineering process allows institutional knowledge to stay with the program, and inform the next generation of design decisions.
Introducing Protos: the AI-native R&D workspace for complex systems
These challenges point to a clear set of requirements for a modern R&D platform.
- Physics-grounded, inspectable results. Outputs should contain a representation of the underlying physics, with the calculations and assumptions immediately accessible.
- Embedded traceability. Decision rationale should be captured at the moment a decision is made, linked to the requirement and data behind it.
- A closed loop between design, simulation, and test. Test results should update the model, not just close out a checklist item.
- A single knowledge graph uniting disciplines, not one tool per domain. Project knowledge, be it structural, thermal, and materials data or background literature and internal documentation, should be connected such that a change in one surfaces its consequences in the others.
- Seamless integration with third-party apps. Engineers rely on multiple tools and platforms, all of which should be able to dock into the primary platform to allow for the ingestion of data, knowledge and context.
This outline for a modern R&D platform is what Protos, Aris Machina's AI-native R&D workspace, was built around.
Protos co-engineer grounds its recommendations, simulations and visualizations in deterministic, physics-based models, allowing it to reason across structural, thermal, and material domains as a single connected problem instead of three separate ones.
This deep contextual knowledge base, which can be supplemented with data, models and knowledge uploaded into Protos, allows Protos agents to support in exploring the design space against constraints and performance targets — proposing candidates, narrowing options, and flagging where a change in one domain will affect another. Design work in Protos is supported through built-in CAD, PLM and other drawing packages, and simulation tools support FEA and CFD.
Still without leaving Protos, simulation and test data can be readily reviewed against the design model, including its constraints and requirements. Subsequent adjustments to the design can be implemented, with the contextual test data tagged against the change.
And because every experiment, parameter, and decision is captured automatically in a living knowledge graph, traceability and institutional memory stop being separate work and become a byproduct of the engineering itself.
Protos was built for the complexities of modern R&D: physics-grounded, traceable by default, and closed-loop from hypothesis to validated design. Try Protos for free, without registration at protos.arismachina.com
