A few days ago we gave the first working version of Seallect some real questions. The kind I've been answering for customers for twenty years: a size, a fluid, a temperature, an approval that must be on paper.

The good news is it didn't make anything up. When it couldn't confirm something, it said so, and every answer linked back to the document it came from.

Not so good news, it said "I don't know" far too often, including a few times when the answer was sitting right there in our own data. Working out why taught us more than anything that went right. Here are the four problems we ran into, in plain terms, and what we're doing about each.

First off, how to get an AI to say, "I don't know". People outside software often assume this is the easy part. As simple as giving the AI your documents, the machine reads them, and answers. In practice it doesn't work that cleanly.

A language model doesn't look facts up. It generates the most likely next words based on what it has seen. The common way to keep it honest is to feed it the relevant documents with every question and tell it to answer only from those. That helps a lot. But when the documents don't contain a clear answer, the model will still try to be helpful. It can take a value from one table and a note from another page and combine them into a confident answer that no single document actually supports.

In sealing industry that's not a small error. A temperature limit borrowed from the wrong compound looks completely believable on screen.

So we don't let the model decide whether something is known. That check happens in code, against stored values, before the model writes a word. If the value isn't there, the answer is "unknown", and the model's only job is to say so clearly. It's also why we keep "unknown" and "not suitable" strictly apart. They mean very different things to the person buying the part.

The second thing appeared, A PDF is not data. This is the one that annoyed me most. In one test, the right certificate was already in our system. I could open it and read the material, the hardness and the temperature limit in about five seconds. The system still said it couldn't confirm a match.

The reason is boring and important. A document you can read is not the same as a fact a program can check. Technical PDFs are built for human eyes. Values sit in tables with merged cells, units hide in the header, conditions sit in a footnote. When software pulls the text out, it often loses which number belongs to which row and column. You end up with all the words and none of the structure.

Even when a value is extracted correctly, it isn't always comparable. One datasheet gives compression set after 22 hours at 150 °C, another after 70 hours at 100 °C. Both are "compression set". They are not the same number. Certificates have their own catch: a drinking water approval usually covers the effect of the material on water quality, not its mechanical properties, and it applies to a specific compound for a limited period.

What we're doing: every document now goes through extraction and a check before the system may use it. Each value is stored with its unit, its test method and conditions, and the page it came from. It's slow work. It's also the only way the answer can be trusted.

Also, what datasheets never say. A manufacturer writes about its own compound. It won't explain the basics every experienced person in our trade already knows.

Two examples came up straight away. EPDM swells badly in mineral oil, so you don't put it in a hydraulic system running on mineral oil. Nobody's datasheet bothers to say this, because nobody in the trade needs telling. And at high pressure, the rubber can be forced into the small gap between the metal parts it seals. That's called an extrusion. Whether it happens depends on the pressure, the size of the gap and the hardness of the material, and the usual cure is a back-up ring or a harder compound.

Because our system only trusted documents, it answered both with "unknown". That's technically honest and practically useless. Any fitter would just say "no".

Could we let the AI fill this in from general knowledge? We decided not to. A model can be right most of the time about compatibility, and "most of the time" is not good enough for a seal in a hydraulic press.

What we're doing: building a layer of engineering rules that sits above the supplier data. Material families against media, pressure against gap and hardness, temperature limits by family. These rules are written and checked by people, and each one carries its reason. If something clearly doesn't belong, it's excluded and the user sees why. This is the principle we started with, and testing made it sharper: rules decide, the AI explains.

We care a lot about evidence, so the early answers showed every document, and every status. It was honest, and, oh God, hard to read.

Think of who actually asks these questions. A maintenance engineer with a pump down, or a buyer who needs to place an order. They want three things from the machine, what should I use, how sure are you, and what do I still need to check myself.

What we're doing: answers will start with the verdict, then a short ranked list of options, then the points to check. All the evidence stays one click away, for anyone who wants to dig in or needs it for an audit. So, it's just in a more useful order.

We also hit the usual bugs of a first version. Those are being fixed and aren't very interesting to write about.

Right, Where this leaves us? A list of problems might sound like bad news. It isn't, for one simple reason: we know exactly what each one is and what fixes it. Before testing we had ideas. Now we have a work list:

1. Make the tool stable.

2. Turn every document we hold into checked, structured facts.

3. Write down the engineering rules that live in experienced people's heads.

4. Put the verdict first and the evidence one click behind it.

It's the hardest part, a system that won't invent an answer, already holds.

The third point is the one I think about most. So much of what keeps equipment running was never written down. It sits in the heads of people who learned it the hard way, and many of them are close to retiring.

If you work with sealing solutions, as an engineer or a distributor, I'd like to hear from you. Which rule do you use every day that you've never seen in a datasheet? Leave it in the comments, please. And if you want to see how this goes, follow Seallect. I'll keep writing about what works and what doesn't.