Trust and Verification: What Every Engineer Wants from Automation

Automation is becoming a bigger part of engineering every year. There are more tools available to help with calculations, documentation, modelling and all the repetitive work that comes with getting a project out the door. The obvious benefit is time. If something that used to take an hour can be done in a few minutes, it makes sense to automate it.

But for engineers, saving time is only one part of the conversation. The bigger question is whether they can actually trust what the software is giving them.

Engineers are used to checking things. Looking at the assumptions, follow the load paths, checking whether the results make sense and questioning anything that doesn't look quite right. That's a big part of the job. So when software produces a result almost instantly, the natural response isn't to accept it. It's to figure out where the number came from and whether they can verify it.

That is probably one of the biggest challenges with automation in engineering. It is a challenge to build something that produces an answer. But it is much harder to build something that an engineer is comfortable putting their name behind.

Nobody wants to use a system where they put in a few numbers, press a button and are given a final answer without knowing what happened in between. Even if the result is correct, it is difficult to have confidence in it if the process is hidden. What loads were used? What assumptions were made? Which design checks were carried out? What happens if one of the inputs changes? These are all things an engineer needs to be able to see.

Good automation should make those questions easier to answer, not harder. The point isn't that engineers need to see every line of code or understand exactly what the software is doing behind the scenes. They need to be able to follow the engineering logic. If a beam has been selected, they should be able to see the span, the loads, the material properties, the relevant checks and the resulting capacity. If something doesn't look right, they should be able to work backwards and find out why.

That is where verification becomes so important. Automation and verification shouldn't be treated as opposites. In fact, the best automation should make verification easier. If software can do a calculation in seconds but an engineer then has to spend hours trying to work out how it arrived at the answer, not much has really been gained.

The aim should be to automate the repetitive parts while keeping the important parts visible. An engineer shouldn't have to repeat every calculation manually just to feel comfortable with the result. They should be able to review the inputs, understand the methodology, check the key results and use their own judgement to decide whether the outcome is appropriate.

And that last part is important. Automation doesn't remove the need for engineering judgement.

A computer can be very good at calculations. It can apply the same formulas consistently, work through hundreds of iterations and handle repetitive tasks without getting tired or making a typo halfway through a spreadsheet. What it can't do is replace the experience of an engineer looking at a project and thinking, "That doesn't look right."

There will always be projects with unusual conditions, incomplete information, existing structures, site constraints or details that don't fit neatly into a standard workflow. Those are the situations where experience matters most. Automation should support that experience, not try to replace it.

In a good system, the computer does more of the work and the engineer has more time to think.

That is probably a better way of looking at automation generally. It isn't about removing engineers from the process. It is about removing the work that doesn't need an engineer sitting there doing it manually.

There is a lot of engineering time that goes into moving information between spreadsheets, checking the same inputs in multiple places, updating calculations after a design change, formatting reports and repeating calculations that have already been done dozens of times before. These are all necessary parts of the process, but they don't necessarily require an engineer's full attention. If automation can take care of those things reliably, engineers can spend more time reviewing designs, solving problems and talking through projects with the people involved. That is where the real value is.

For us, trust in automation isn't about expecting an engineer to believe that the software is right. It is about giving them enough information to make their own judgement.

If the calculation is transparent, the inputs can be checked. If the assumptions are clear, they can be challenged. If the process is consistent, it can be reviewed. And if the result can be reproduced, someone else can come along later and understand how it was reached.

That's what makes automation useful in an engineering environment. The goal shouldn't be to build a system where the engineer says, "The software told me so." It should be one where the engineer can say, "I can see what it has done, I've checked it, and I'm happy with the result."

Because ultimately, automation doesn't carry the responsibility for the design. The engineer does.