We recently built an AI-powered sourcing system for industrial components, the kind of parts that go into real machinery. Bolts, springs, fasteners. Things where a wrong material grade or an incompatible standard doesn’t cause a frustrating user experience. It causes equipment failure.

This post is about what we built, the decisions behind it, and the broader lesson we think applies to any AI system operating in a domain where precision actually matters.

Why AI Search Breaks Down in Technical Domains

Before we get into what we built, it’s worth being clear about the problem we were solving.

Industrial procurement engineers don’t always search with precise technical inputs. That’s not laziness. It’s just how humans think. When you’re working on a project, you know what you need in plain terms before you’ve pinned down the exact specification. So a user might search for something like:

“I need a corrosion-resistant bolt for outdoor use”

or

“Spring for high load in a small space”

These are perfectly reasonable descriptions of a real need. The challenge is that a standard AI system will take that fuzzy input and try to fill in all the missing details. It’ll assume a load range. It’ll pick a material that seems likely. It’ll map to whichever standard feels right based on patterns in its training data.

And then it’ll return results with complete confidence, as if every assumption it made was intentional and correct.

The problem isn’t that AI systems are bad at this. The problem is that they’re designed to be fluent and responsive even when they’re uncertain. That quality is useful in a lot of situations. In industrial sourcing, it’s a liability. A wrong material spec doesn’t just mean a slightly off result, it means the wrong part gets ordered, installed, and possibly fails.

The Insight That Shaped the Whole System

Early in this project, we spent time trying to understand exactly where the failure would happen if we built this the conventional way.

The honest answer was: everywhere AI had to make a decision it didn’t have enough information to make.

What we realized is that AI is genuinely excellent at one thing: understanding what a person is trying to say. It can take “spring for high load in a small space” and accurately identify that the user needs a compression spring with space constraints and significant load capacity.

What AI is not reliable at is the next step: deciding which specific materials, standards, and dimensions are technically valid for that requirement. That’s not a language task. It’s an engineering task. And it needs engineering rules, not statistical inference.

So instead of asking AI to do everything, we split the work. AI handles meaning. The system handles precision.

That single decision shaped the entire architecture.

How the System Actually Works

Here’s the flow we built, layer by layer.

Natural Language Input

Users search the way they naturally think. No forms. No mandatory filter selections. No prior knowledge of ISO standards required. They just describe what they need.

This matters more than it might seem. A lot of industrial procurement software forces users to know their exact specification before they can search. That creates friction and often leads to errors when users guess at parameters they’re not sure about. We wanted to remove that burden entirely.

Intent Extraction (What AI Is Actually Good At)

The first thing the system does is pass the query to an AI layer. But this layer has a very limited job. It extracts structured intent from the natural language input — nothing more.

For “I need a corrosion-resistant bolt for outdoor use,” the AI identifies:

• Product type: Bolt
• Use case: Outdoor
• Key requirement: Corrosion resistance

That’s where the AI’s authority ends. It does not generate specifications. It does not suggest standards. It does not pick materials. Those decisions happen elsewhere.

This boundary is the most important design choice in the whole system. The moment you let AI cross from “understanding what was said” into “deciding what is technically valid,” you’ve opened the door to guesswork.

Parameter Structuring (Engineering Logic Takes Over)

Once intent is extracted, a separate structured parameter engine takes that intent and converts it into bounded possibilities — not final values, but valid ranges and candidate sets based on engineering rules.

For our outdoor bolt query, this means the system would generate something like:

• Material candidates: A2 stainless steel, A4 stainless steel
• Coating options: Hot-dip galvanized, none required for A4
• Standards to consider: ISO 4017, DIN 933
• Exclusions: Carbon steel without coating (incompatible with outdoor use)

Notice what’s happening here. The system isn’t guessing. It’s not saying “probably stainless steel.” It’s saying “given this requirement, these are the valid material options — and these are the ones that are ruled out.” The difference matters enormously in production.

Controlled Search

Search then happens using those structured parameters, not the original natural language query. This is another deliberate choice.

Running a search on the raw query “corrosion-resistant bolt for outdoor use” opens up the retrieval layer to semantic drift. The system might surface results that are related in language but incompatible in engineering. Searching on structured parameters keeps the results within the valid solution space from the start.

Validation Before Results Are Shown

Every candidate that comes back from the search goes through a validation layer before the user sees anything.

This layer checks:

• Do the parameters actually work together? (Some material and coating combinations are incompatible even when each seems valid individually)
• Does the part conform to the claimed standard?
• Is it available and sourceable?

If a candidate fails any of these checks, it gets rejected. The user never sees it. There are no “close enough” results and no “this might work” approximations. The output only contains parts that have been confirmed to be correct for the stated requirement.

What the User Receives

The final output includes exact matching components, full technical specifications, real-time stock and availability data, and compatible variations where they exist. Not a list of possibilities. A list of answers.

The Systems That Keep It Reliable Over Time

Getting a system like this right on day one is one problem. Keeping it right as the product catalog grows and query patterns change is a different one.

We built three continuous systems to handle this.

A pattern learning engine stores successful parameter combinations. When the same query pattern appears again, the system can reuse pre-validated mappings rather than deriving them from scratch. It gets faster and more consistent over time.

A feedback and correction loop logs any mismatches that get flagged. When something goes wrong, the rules update so the same error doesn’t repeat. This is how the system improves with use rather than degrading.

Quality monitoring tracks accuracy metrics and watches for drift. A catalog growing from 10,000 parts to 200,000 parts can quietly introduce edge cases that weren’t in the original rule set. The monitoring layer catches these before they affect production results.

What the Results Looked Like

After this system went live in a real industrial workflow, the outcomes were clear. Incorrect matches dropped significantly. Procurement teams made decisions faster because they could trust the results without manually verifying each one. Engineers who had been skeptical of AI-generated recommendations started actually using the system.

Most importantly, it was genuinely useful on the production floor, not just in a controlled demo environment. That gap between “impressive demo” and “actually used in real work” is where a lot of AI projects quietly fail.

The Broader Point About AI in High-Stakes Industries

What this project really taught us is that the question “is AI good enough for this?” is often the wrong question.

AI is quite capable of handling complex tasks. The real question is: have you designed the system around what AI is genuinely reliable at, and built deterministic controls around everything else?

Any system that works with technical components, handles incomplete user input, and needs to produce precise outputs will hit this same wall eventually. The solution we keep coming back to is the same one we applied here: AI for understanding intent, engineering logic for controlling decisions.

It’s not a constraint on what AI can do. It’s the thing that makes AI trustworthy enough to actually deploy in a context where it needs to be.

A Few Things We’d Do Differently

No project is perfect, and it’s worth being honest about that.

We underestimated how much time the parameter structuring layer would take to get right. Writing good engineering rules is genuinely hard work, and there were more edge cases in the catalog than we expected early on. If we were starting over, we’d scope more time for that layer specifically.

We’d also build the feedback loop earlier. In the first version, it came in later than it should have. The system would have improved faster if correction logging had been there from the start.

Closing Thoughts

If you’re building AI for an industry where getting the wrong answer has real consequences, the most important decision you’ll make isn’t which model to use. It’s how much of the decision-making you’re willing to let the model own.

AI is a powerful tool for understanding language and interpreting intent. It’s not a replacement for domain logic, engineering rules, or validation. Used together, those things can produce something genuinely useful. Used alone, AI will fill in the blanks with its best guess, and in the wrong context, that guess can be expensive.

We build these kinds of systems at CIZO. If you’re working on something in manufacturing, healthcare, logistics, or any other precision-critical domain and want to talk through the right approach, we’re happy to have that conversation.

Get in touch with the CIZO team

CIZO is a mobile app and AI app development company. We work with startups and enterprises to build systems that work reliably in production — not just in demos.*