Learning to Trust AI: What Building for Engineers Taught Us

In science and engineering, a single incorrect figure, like an understated heat load, doesn't stay in one place. It carries into the cooling plant selection, then the electrical capacity feeding it, then the equipment ordered against both. Get it wrong, and every team that built on it has to rework their part. So when we started building CurieOS, getting AI to work on hard industrial problems was only half the job. The engineers using it would also need to trust its outputs.

The engineers who use CurieOS don't all come to AI the same way. The skeptics have usually seen enough overpromising to want proof before they commit, and often with good reason. Others are curious but unsure where to start, or which parts of their own work AI could assist with. The enthusiasts expect it to do everything. And some arrive with a precise idea of how AI should work in their field, and measure everything against it.

What they share is how they approach a problem. They're trained to question a result and interrogate how it was reached before they believe it. We built CurieOS to work with that instinct.

The cost of one wrong output

When our engineers tried CurieOS, the bar was high. One incorrect output, or one unstated assumption the engineer had to catch after further probing, could undo a lot of goodwill. Given what a wrong number costs in their work, engineers are right to hold AI to that standard. For us, that meant getting it right most of the time wasn't enough. Engineers needed to be able to check any output and see exactly where it came from, so they could catch a problem before it carried into the next decision.

Most engineers started believing in AI when it helped with a task they'd done before, usually something slow that needed several people's input. On one conceptual data center design, a mechanical engineer needed to compare four alternative cooling architectures on cost, PUE, WUE, and lead-time risk. In a traditional workflow that comparison could take weeks. With CurieOS, the client had the numbers within a few hours.

Speed got their attention, but what convinced them was being able to check the methodology and sources behind the output. When they could see how an answer was reached and confirm it matched what they'd have done themselves, they were sold. That became one of our core product principles: an output earns trust by showing how it was produced and where its inputs came from, and by producing the same result when someone reruns it with the same inputs.

Show your work

Every CurieOS output points back to the source of each figure, calculation, or statement, and states the method it used to get there. An engineer can check any number against its origin instead of taking it on faith.

When an electrical engineer asked CurieOS whether a 5,000 A underground feeder could carry its full load, the quick check said yes: by the standard NEC ampacity table, its eleven sets of 750 kcmil conductors were good for 5,225 A. CurieOS reported that figure, then ran the Neher-McGrath heat-transfer calculation, which accounts for each duct heating its neighbors. Even in the most favorable standard soil, the bank could carry about 3,300 A, roughly a third short of the load. Each of the 19 steps showed its equation, the values substituted in, and where every input came from, and the model itself came within 2.5% of the NEC's published duct-bank tables. Some site data wasn't known yet, including soil thermal resistivity, peak earth temperature, and the breaker rating. CurieOS stated the value it assumed for each and ranked them by how much they could move the result, so the engineer knew what to measure first.

Screenshot showing an example CurieOS calculation record

Outputs also come in the formats engineers already work in: spreadsheets, plots, STEP files, load schedules, single-line diagrams, Revit models, OpenFOAM case files, and more. A paragraph of prose isn't enough in the domains we work in. A file engineers can open and check in their own tools lets them verify it with the same checks they'd apply to their own work.

Once people were confident they could check outputs that came back, they started bringing more of their work to it. Engineers moved from "I wasn't sure it could do that" to "I'll just ask," and some of the most useful applications came from their discovery in day-to-day use.

Where chat runs out

Chat is a good way to get a single task done, and as engineers grew more confident, many ran a lot of their day through it: asking for a calculation, pulling up the source behind a figure, then comparing the result against the last revision, all in one thread. But a conversation can't hold the full breadth of an engineering project.

A drawing review shows where that limit sits. Checking a 100% design development (DD) set against the 50% handoff and the basis of design can turn up 30 findings, and as a list of comments in a chat, they explain what details are wrong, but not where. In CurieOS each finding sits on the sheet it refers to, and an engineer accepts or rejects it there. The project lead sees which items are still open in each discipline, and the markup PDF and comment log only issue after sign-off.

Nobody in industry works alone, and work has to be shared with a team. When AI produced one-off documents and spreadsheets, we ended up back at the problem we set out to solve: fragmented outputs and a lot of back and forth. Engineers spent more time explaining things to the AI than getting their work done.

So CurieOS keeps a project's context in one place the whole team works from. A project starts as a pile of inputs: client meeting notes, email threads, a requirements doc, a site survey, and often more than one revision of each. The team decides and controls exactly what CurieOS can see, and CurieOS builds a context graph from what's connected, linking each requirement to the documents and calculation inputs that depend on it, and recording which revision governs. Every output the team produces builds on that shared record, so nobody has to re-explain the project to the AI or to each other.

Each role then works from that same context in the form their job needs. A data center project team brings together mechanical engineers, electrical engineers, and project leads, and software has rarely served them all well. Someone usually ends up in a tool built for someone else, or working from partial data. In CurieOS, the mechanical engineer sees a load calculation, the electrical engineer sees a single-line diagram, and the project lead sees a dashboard of the open tasks, all drawn from the same project data. CurieOS also works inside the tools engineers already use, like AutoCAD and Revit, so far less has to be re-entered between them. Teams can challenge the assumptions that matter and work across disciplines without waiting on the next handover.

Handoffs without the loss

Handoffs are where we've seen the biggest shift, because in engineering they've always been where information can get lost. A result moves from one team to the next as a drawing, a summary email, or a spreadsheet stripped of its workings. The next team gets the conclusion without the reasoning and the numbers without the assumptions. Context leaks at every stage, and questions that should be easy to answer turn into meetings, re-runs, or guesswork.

In CurieOS, a handoff carries the full set of results and methods from the earlier stage. Whoever picks it up sees what matters to their discipline first and can still drill into everything behind it.

Take a cooling load model as an example; on most projects, the electrical engineer sizing the power distribution receives it as a single figure in a spreadsheet. If they want to know what rack density it assumed, or what happens if the client raises it, they have to go back to the mechanical engineer and wait for an answer or a re-run. In CurieOS, the mechanical engineer builds and validates the cooling load model once, and it's handed over as a working tool rather than a number. The electrical engineer can see the assumptions behind it, run it inside their own calculations, and rerun it when the design changes, without a meeting or a revised spreadsheet. And because the engineer who owns that discipline built the model, they can trust the method as well as the answer.

Screenshot showing an example CurieOS CDU dashboard

Building trust, one workflow at a time

Engineers extend trust to AI one checked output at a time. Every source reference, native file, and shared tool in CurieOS is there so they can see what happened and why before they build on a result. If your team has a slow workflow you'd want to test that on, you can get in touch through our CurieOS page.