Michael Rustell is the founder of Inframatic, a company developing AI systems to unlock value from unstructured data in infrastructure projects. He holds a doctorate in design automation and previously worked as a maritime engineer at AECOM, where he led data science initiatives. Rustell spent six years in academia at Brunel University while building Inframatic’s core technology, recently leaving to focus full-time on the startup as client demand grew.

Sam Sherwood-Hale spoke to Michael Rustell about transforming infrastructure engineering through AI, the challenge of making unstructured data searchable, and why the next two years will separate the industry leaders from the laggards.

SSH: You’ve written about AI representing a knowledge revolution—more than just a leap forward in computing. You mentioned that 80 per cent of business data is unstructured and ignored. Could you walk me through how Inframatic transforms this ‘dead data’ into something actually usable?

MR: We’re deep in those projects right now. The company is six years old and originally started to build this system, though I ended up doing consulting work early on. For the past two years, I’ve focused on building the system, and in the past six to seven months, we’ve been reaching out to clients and kicking off projects.

Most data in business is unstructured – reports, drawings, videos, photos – anything that’s not in a table. That was always very difficult for AI to understand historically, and I spent much of my career getting that information into tables, which is painful. Previously, everything had to be in tables for AI to work with it, but now tables are actually quite hard to use, while all this unstructured material that was previously difficult has become incredibly valuable. The value of data has shifted from about 20 per cent being valuable to 80 per cent plus.

The product we build, Matic, takes this unstructured information, breaks it down, and restructures it in a searchable, useful way. For example, with a technical drawing we can break it down into individual figures
– a sleeper system or a section of a station
– extract the text, notes, and information about who created it. This becomes searchable, and when it’s searchable, it’s usable.

That dead data gets transformed from stationary documents into searchable knowledge. Once it’s searchable, you can query it by asking how many sleepers are in the system, what track gauges exist across the entire project, or doing assessments of whether a report meets employer requirements. This requires having the employer’s requirements structured and retrievable, the document you’re reviewing retrievable, and the system understanding how to correlate information to check conformance.

SSH: Much of this speeds up processes humans would do manually. But are there places where humans struggle with questions where the answer exists but is difficult to retrieve? 

MR: Very common. You’ve got a couple of problems. Most information is trapped within data, and knowing which bits contain that information is a complex task split across many people’s understanding of the project. That’s figuring out where stuff is.

Secondly, once you have the information, the answer often isn’t in one or two documents, it might be scattered across ten or eleven pieces of information. As humans, we can only hold a certain number of bits in our head at any time. That becomes very complex, particularly when working on screens, you might have a few documents here, a few there, something on your desk, an email comes in. It’s very hard to assemble the narrative from all of that quickly.

Whereas AI, if your information is structured and the system understands how to ask the right questions and get the raw information needed to answer the question and provide that to you as the engineer in a way you can understand, query, and audit. Then you have the ability to do that work with a system that can help and seed that process.

SSH: That’s really the dream isn’t it. Everyone having their own assistant. You’re a team of one, you can’t focus on everything all the time, and working alone you can miss or forget things.

MR: I think that framing is correct. If you consider how complex real projects are, they’re difficult with lots of nuance not captured in any model’s representation of the world. You have tacit knowledge and judgment in engineering, particularly in how interfaces between different disciplines work – geotechnical and structural, for example. Your model might be very good at those individually, but when combined, it’s easy to miss things.

It’s easy to check what’s incorrect when the system says something, but understanding what’s missing from an answer requires high-level human thinking: ‘We encountered this on a project before, why isn’t it here?’ or ‘Although guidance says do it like this, the real way is different because that’s how it’s done in industry, it’s just not written down anywhere.’

The idea of having an assistant that can help find information, direct what you want to do, and automate low-value but time consuming tasks like searching, rephrasing, building fairly simple but sometimes sophisticated processes, that’s the true value. It’s not a replacement tool by any means. It’s a system that can help automate low-value but time-consuming tasks.

SSH: How ahead of the game were you in terms of being aware of where this technology was going?

MR: My doctorate was in design automation, something similar to what I do now but more simplistic. It was building a system that used AI to optimise the layout of large port systems, specifically LNG terminals. Through doing that, I realised the power of this type of system would enable me to build something like what I’m doing now. I didn’t understand the exact form, but I knew I’d be using structure knowledge representation and AI.

Through my career at HR Wallingford with University of Surrey, then AECOM as a ports marine engineer I started understanding what AI could be if you could automate processes. But the big challenge was everything was unstructured. Building datasets to do anything meaningful was infeasible.

My idea was: if I could build a system that could create its own rules based on high-level planning rules from standards and methodologies in design textbooks, that would be powerful because you don’t have to explicitly write rules, rules have already been written by humans into standards.

I’ve always wanted to do this and was planning for it. When the right kind of AI came out, specifically large language models, I didn’t know what that would be, but they offered the ability to turn unstructured information into structure. Once things are structured, you can do all the autonomous writing and building processes based on industry-agreed ways of doing things contained in textbooks or standards.

LLMs unlocked the value of knowledge trapped in unstructured data, and once you have that, you can put it to work in new, interesting ways.

SSH: So for you it was the application possibilities that were most fascinating?

MR: Yeah. There was an architecture I had in mind of what I wanted to build, and there was a missing piece, how do we get knowledge into the system in the first place? That part didn’t exist; it was too time consuming. When large language models started gaining prominence and becoming useful, it was very clear that was the technology needed for the application to be realistically doable.

Now LLMs have become so capable that trying to understand what they can actually do is quite a challenge because they’ve gone far beyond where they were even six months ago.

SSH: With the projects you’re working on, how much give and take is there with clients? Are you telling them how to use it, or presenting it as a tool they can adapt?

MR: More the second one, a tailored approach. We’ve got the solution and we’re trying to fit it to the problem, which isn’t always the right way, but the end game is a system that can work at the centre of very large infrastructure projects.

Getting there requires going on a journey with client organisations to find their pain points. When you show the technology and how it can understand technical documentation, they’re quite forthcoming about challenges. Sometimes you have to tease it out, but they’ll say ‘This is something we spend ten hours a week on across ten people. Could you help?’ When the answer’s yes, that can be the foundation of a pilot project. Once you get to the end, you have something tangible that solves the problem and shows the art of the possible, this isn’t fairy tale, it’s something real. Then you think about what you could do expanding this to more problem domains.

SSH: Do you see any emerging patterns between different client requests?

MR: Yeah, definitely. The standards part has resonated everywhere. The ability to understand standards has been the consistent theme. That’s interesting because standards are copyrighted, so you have this additional layer where you have to work with organisations that create them, except ones available openly. But there’s a lot of nuance and interpretation. It’s not easy, particularly as we rely on standards as the de facto correct way to do things or from a legal perspective the backbone over which we build. But being able to understand those, make them searchable and usable, has definitely resonated consistently.

SSH: This issue of AI hallucinations, is that something that comes up often with clients?

MR: 100 per cent, because for large language models, hallucinations are how they convey information. It’s not a bug of the system, it’s what they do. They’re probabilistic models that try to estimate a distribution based on input tokens, what’s the next token? They’re very sophisticated; research suggests they’re planning multiple tokens ahead.

The hallucination aspect is very important, which is why you have to be able to ratify information with raw sources. It’s OK to say: ‘Hey, how are you?’ and get ‘I’m great, how are you!’ But if you want a technical answer, you have to have a source that contains that information and be able to check against it. That has to be built into the system so you can have the system self-validate on information it’s found, then have validation, application, checking, and the ability for humans to see all that and understand it’s correct.

If it’s just giving you something and saying ‘Here’s a reference’ and you can’t challenge that, you’re still with a system that’s not making you smarter. You need it to say ‘This is what I think is correct and here’s all the evidence I’ve used.’ Hallucinations are a feature of LLMs we have to learn to deal with.

SSH: That’s interesting, describing that as a feature. It does make sense and instils confidence because you need humans to interpret results. What training do you give people using it to ensure they interpret outputs correctly?

MR: We’re working on those parts now with these projects – what outputs need to look like for specific users. Each client has slightly different requirements. Although standards have been a central theme, what are standards being used for? You have differences in how things appear and how users interact.

That’s ongoing because you want the system to be as easy to use as possible. Onboarding should be simple, you don’t really need training, it just works how you expect and helps you understand. If your system is complex and not easy to understand, we’re trying to make it as user friendly as possible like an iPhone, you pick it up and it works. You swipe, move things, click. We want it easy and sensible so that of course if it says something you need to back that up because that’s what we do in engineering.

SSH: Your progression from AECOM’s Data Science Centre of Excellence to founding Inframatic, you’ve seen both corporate and start up approaches. What assumptions about AI adoption did you have to abandon when you started your own company? 

MR: Working in bigger companies was challenging, partly because AI wasn’t very mature and trying to prove anything had value was difficult because there wasn’t repeatability. You’d build something for a project and that would be it, never see light of day.

My thinking changed because at the big company it was very project-specific, whereas in your own company it’s visionspecific: what’s the vision, where do you see the industry in three, five or ten years, how can you contribute?

Going from corporate to startup and academia was different in terms of time. In bigger companies it’s very much about utilisation rates, you’re constantly billing and innovation gets pushed aside because of the payment system, how you book time and bill clients. The margin is very small, whereas in a startup you have fewer overheads but also less income while building.

SSH: What was the light bulb moment that made you make the switch?

MR: I was trying to build an AI-centric role for myself that was fully recognised. I was still working as a maritime engineer, which I love, but I saw I had more to offer the company. Trying to carve a new role over three years and it just not happening for whatever reason. I think the company wasn’t ready, the industry wasn’t ready.

But the other part was building this system. I saw the time was coming. I had ideas I’d been developing since my doctorate about what I wanted to do, and it was clear years, as well as working on several maritime expert witness projects as well as building software through Inframatic. I’ve actually just left academia to focus full-time on the startup. We finally have enough client work to make this sustainable.

As AI’s gotten really useful in the past few years, it’s been about trying to get ahead—build the thing while others were still sleeping. Now there’s more competition. I write about this stuff to help other people, but recognise I’m just a small company trying to do a big thing. It makes you vulnerable against big players, but you’ve got to change the world somehow.

SSH: One article was about the golden age of AI being all about knowledge. What behavioural changes need to happen for the industry to realise AI’s potential?

MR: That’s bigger than technological change. Behaviourally, a lot of engineers are towards the end of their career, AI wasn’t even a thing, computers weren’t a thing for many when they started. You have this entrenched way of doing things built into different processes. Now there are these new tools that claim to be very helpful and world-changing, and on some levels that’s right. I think that’s the long-term effect, but navigating that is always messy because big system-level changes bring disruption, and disruption is great for some and not for others.

Culturally, everything’s getting primed for these changes. It’s about ensuring Inframatic provides leadership around that because we’ve been thinking about this for such a long time. I admit I don’t understand the full cultural shift aspect, but I do see the vision for what a connected industry could look like where you have AI and knowledge systems at the centre from a technical perspective, and what that could mean for project delivery.

I’ve got some ideas around that. I know it’s going to be fundamentally different and if done correctly, would be significantly better. But there’s a lot of thinking that’s just not my expertise. I’m very niche and realise I’m a fairly limited individual when it comes to many things, but what I am good at, I’m very good at.

SSH: The system you’re building is for people like you, engineers and the way they think. If it works for you, do you expect it to work for a whole class of professionals?

MR: Yeah, I hope so. My driving force was working at AECOM thinking a lot of processes we do are fairly formulaic. There’s thinking and engineering that goes on and that’s really interesting, but there’s also administrative work that’s never much fun. If we could automate some of this stuff that’s not particularly fun and is time consuming, and have access to knowledge in a way that could help us do our jobs better, you could have a small team of maybe five talented engineers working together on fairly large projects, putting out high-quality work at the rate of a much larger team.

I was thinking that would be really interesting—if I had myself and a few good engineers and a system that could help us, we might be able to compete with bigger companies. That was the dream, what could that look like and what would a system need to do? That thinking has evolved over the years into where it is now.

SSH: There was a government report published this June about behavioural science and AI readiness at the Department of Transport. It found that passionate engineers work unpaid overtime to integrate AI. When you’re brought into organisations, what’s the difference between companies that succeed with AI and those that burn out their teams?

MR: I was that passionate engineer working unpaid overtime to build algorithms nobody asks for a lot of my career. I can relate.

We’re still on that journey, and I think you need champions. Some companies have a champion who hears the idea, loves it, and will fight for you internally, make projects happen, knock down doors, finds money, fight for you because they understand the value. Those companies where you have internal drive, not just me as a startup saying ‘buy my thing’ but a pull relationship because there’s shared understanding of the vision, that’s when projects start to happen.

If you’re pushing constantly and they’re struggling to get people involved, you’re set up for failure even if your solution is really good. You have to have that desire internally within companies, and you have to demonstrate value as well. It’s not just vision to get the ball rolling, you have to turn that into something tangible pretty quickly, otherwise they lose momentum and you need momentum just to get to the start line.

SSH: In the next five years, where do you see Inframatic going?

MR: Five years is a good time horizon. I think this kind of system will be mandated on large infrastructure projects. The government’s putting a lot of push towards AI, and if we can demonstrate that AI provides safer outputs and more auditable systems, it will create evidence to support that.

Over the next five years we’d like to be seen as leaders in that space, providing better outcomes for infrastructure, fewer errors, more auditability, faster timelines, better designs. When you start looking at all the metrics you can measure, it will become very clear that this kind of system gives you so many benefits that it would be irresponsible not to use it. We want to drive that towards better outcomes for the entire industry.

SSH: Finally, what would be an ideal client for Inframatic?

MR: Client organisations are the ones we like most. There aren’t many of them, but they offer the right mix of problems, they’re public-facing, paid for by taxpayers in one way or another, and they usually have very well curated data and assets, or at least lots of data. They often have their own standards which gets around copyright issues. Those are the clients we’re really interested in.

But that’s only a small number of companies. Others are companies genuinely wanting to lead and willing to take risks building new capabilities, wanting to create AI-first organisations. Really we’re not selling a product, we’re selling a vision of what your company could look like. It’s not a simple app purchase—you need to do significant work within your company. We can help drive that and provide infrastructure, but we need to grow along with clients to understand what this could look like.

Ideal clients are those organisations and companies really wanting to do innovative work, wanting to take their engineering to a different level, realising that’s not a one stop solution but an overhaul. The ones prepared for it will get a genuine market advantage quite quickly as they start doing things faster.

Those speed gains aren’t coming in the first six to twelve months, but 18 months to two years after you’ve done pilots, embedded the system, found what doesn’t work, failed, succeeded, and done that enough to understand the pathway. The technology will have moved on as well. Then you start seeing very big changes around 18 months from now. But until then there’s going to be a lot of ‘AI doesn’t work in engineering’ and ‘this is OK but we can’t scale it.’

The companies that go through the challenges now will be the ones that in 18-24 months realistically get all the fruits of those labours. Suddenly their two per cent profit margins become three, four or five per cent, and that’s when there are big systemic changes happening across the industry.