Engineers in Control: How AI Is Changing the Pace of Design

Handing AI full control over mission-critical engineering work asks for blind trust, and blind trust isn't something engineering systems can afford.

At Orbital, we design mission-critical infrastructure for data centers, where a single design decision can affect equipment selection, lead times, and cost across the entire system. We built CurieOS to change the pace of how these systems get designed. One example of a CurieOS task resulted in submittal packages that used to take two to three weeks coming down to just two to three days. This was possible with engineers still directing every step and judgment, rather than reviewing a finished output after the fact, with no visibility into the decisions or assumptions behind it.

Building Trustworthy AI

The common pitch for AI in engineering is to hand off a problem and get back a finished solution. For a multimillion-dollar cooling system, that finished solution is itself the problem: the engineer didn't build it, made none of the tradeoff decisions along the way, and has no feel for where the margins are tight or an assumption might not hold. They're left checking someone else's work without knowing where to start, and they typically can't tell whether it's right without re-running the calculations themselves.

CurieOS is built on a simple principle: the fastest way to put the most capable AI to work on mission-critical engineering is to keep the engineer in every decision along the way, not to hand off a scope and wait for a finished result. The engineer works with AI as a co-pilot, directing every step, so there's nothing to catch up on and nothing to take on faith. It's how we stay on the leading edge of what these tools can do, without asking engineers to trust a black box.

On any given week, our team is fielding a backlog of design requests spread across emails, RFPs, meeting minutes, and project specifications, each one requiring a custom solution. Clients are asking for submittal documentation packages, PUE studies, WUE analyses, TOC models, thermal studies, full data center layouts. All of it needs to move fast so the real engineering iteration can begin, and CurieOS is how we work through that backlog without slowing down.

Tools in Practice

Across the projects we've worked on, three parts of the process account for most of the delay: submittal packages, product selection, and documentation review. That's where AI has helped most, with the engineer directing every step throughout.

Submittal packages consisting of compiled product data, performance specs, engineering calculations, all organized and cross-referenced, mark the handoff from design to construction: once a client signs off, procurement and equipment ordering can begin. Depending on the submittal type, a full equipment schedule can take three weeks; a narrower cost study, closer to two. Either way, it's time that has to happen before procurement can start.

Using CurieOS, it's possible to cut your total turnaround time down to two to three days. The AI handles the data extraction, cross-references specs against project requirements, flags conflicts, and assembles the package, while an engineer reviews, validates, and signs off throughout.

Review stages built into CurieOS

Product selection works differently but the time savings are just as significant. When a project lands with a set of mechanical and electrical requirements, someone has to go through manufacturer catalogs and datasheets, sometimes dozens of them, checking each one against the project's requirements to see which products actually qualify. AI parses that in minutes, pulling the relevant specs, comparing them against the project criteria, and narrowing to a shortlist. The engineer still weighs the trade-offs a spec sheet can't capture: vendor reliability, lead-time risk, how a product performs alongside the rest of the system, but starts from a shortlist AI has already checked against the requirements instead of the raw catalog.

Documentation review is the third piece. Hundreds of pages of owner's project requirements, basis of design documents, and specifications don't just need to be read, they need to be checked against the design as it develops. CurieOS builds a context map of what requirements impact your design and updates as new information becomes available. As you develop the design, the context map gives you full visibility into why decisions were made, who made them, and when they were made. That's how we track down the defining decision when large designs become constrained. CurieOS reads all file types, including drawings in their native format, so everything tied to your project stays in one place.

Project Database, Equipment Selection, and Submittal Tool built using CurieOS

Weeks of Modeling in One Afternoon

Here's a concrete example, from a project I worked on personally: I was working on a conceptual data center design where the initial architecture I proposed was outside the client's comfort zone. They wanted to understand the tradeoffs of four alternative cooling architectures (what each one meant for cost, PUE, WUE, total cost of ownership, and lead-time risk).

In a traditional workflow, that comparison could take weeks. Each architecture needs to be modelled at enough fidelity to produce meaningful numbers, but not so detailed that you're doing final design work on four options that will narrow to one. Finding that balance between concept-level numbers that are directionally accurate and over-engineering the analysis is genuinely hard to scope.

With CurieOS, I was able to spin up those four scenarios in a matter of hours. The AI handled the parametric calculations, pulled reference data, and structured the comparison. I directed what to compare, set the boundary conditions, validated the initial calculations, and interpreted the results. The client received the high-level data they needed in just a few hours, successfully wrapping up the conceptual stage and clearing the way for us to shift into detailed design.

Total Cost of Ownership Dashboard built using CurieOS

Engineers in Control

Trust in AI-generated engineering comes from keeping the engineer in the loop at every decision point. The engineer isn't reviewing a finished product they had no hand in building, they're directing the process, making the decisions, and using AI to move faster between those decisions. When the final package is ready for sign-off, they already know what's in it because they shaped it along the way.

The engineer uses AI to move through the design faster, directing each step and reviewing the design as it develops. The result is work that can be completed quickly, but that's far more trustworthy because the person who signs off on it was part of the decisions.