Is Your Engineering Data Ready for AI, and How Would You Even Know?

A CoLab customer recently uploaded an extensive standard for injection molding complete with part design, tool design, cost considerations, and more. Everyone involved thought it was a strong document. 

But when we instructed our AI to reference that standard during a design review, almost none of it was considered in the analysis.

The outcome wasn't the fault of the tool, the model, or even the prompt. It was the input; the standards document itself. And not because it was poorly written, but because it was written in a way that made it impossible for anyone (or anything) outside of the engineers who wrote it to understand what it meant.

The document was mostly images, with parts circled in green, arrows pointing out different issues, and subjective guidance like "small" and "large" features, with nothing objective to act on. When our own engineers went back and looked at it, we couldn't really make sense of it either. The knowledge in the document was real, but it was subjective and assumed background knowledge that wasn't written down.

This is the clearest case of “not AI-ready” data I’ve seen, and it’s representative of a broader question, the answer to which indicates whether or not engineering data is ready for AI: does the knowledge required to make fast, accurate decisions reside in the data or only in the heads of the people who wrote it?

As engineering teams explore incorporating AI tools into daily workflows, the question of whether your data is ready is a fair one to be stuck on and only becomes more urgent. In this article we explain the reason why most engineering data isn’t ready for AI, and how to transform yours so that it is, one use case at a time.

First, let’s unpack the mechanism behind why AI can’t make sense of most engineering data.

Why AI struggles to fill in the gap

When an engineer solves a problem, we work from two things at once: 

1. The explicit data set: drawings, standards, specs, requirements. 
2. The implicit data set: tribal knowledge, program context, experience.

Engineers lean on that implicit knowledge all the time without noticing. Information like understanding the decisions that have been made, the tradeoffs that drove them, or the lessons learned from previous programs. We understand these things intuitively, and communicate them casually—for instance when explaining to a junior engineer why a tolerance got tightened two programs ago after something came back from the field.

‍That implicit knowledge is the biggest data gap when AI is introduced to an engineering program.‍

We can provide an AI tool with explicit data, but it can’t supply that implicit context itself. What we’re really asking AI to do is have the same kind of logic and reasoning as a skilled engineer, just much quicker and much more consistently. If you leave out half of the data needed to reason through and solve a problem, it's not going to give you the answer you're looking for.

After having now deployed several AI readiness pilots with engineering teams, here are some common issues that put the implicit knowledge gap into context:

1. The provided guidance assumes context the reader doesn’t have. Most of the time it's a single line or a marked-up symbol in an otherwise solid document that only works if you already know what the author meant.

2. The knowledge is recorded, but it still isn’t usable because it’s disjointed. Design intent lives in one place, requirements live in another. The larger the program, the bigger the disconnect. One organization we work with was losing seven figures and weeks of schedule on incidents stemming from this.

3. Internally accepted rules are assumed instead of documented. This one is hard to catch because the people making the decisions already know the answers. If rules aren’t recorded, the tool guesses.

4. Decision rationale and lessons learned were either never recorded or stored in an inaccessible database. If the reasoning behind why a decision was made isn’t easily accessible, then most of the time the same decisions get rehashed.

How do I know if my data is ready for AI?

This is a daunting, intimidating question. So when I hear it from engineering teams, I encourage them to reframe it to “What’s the smallest experiment that will show me precisely where my data falls apart?”

That is ultimately how you know if your data is ready: by pointing AI at a specific problem, workflow, or use case, looking closely at what comes back, and treating it as the start of a discovery process.

Take the DFM review from the beginning of this article as an example. The injection molding standards document marked up with green circles and arrows didn’t come through in the analysis not because it was a “bad” document, but because the AI couldn’t make sense of it.

When the first pass comes back inconclusive it may feel like a failure. But I'd be careful about thinking about it that way. That's the first real value you get out of a pilot, because it points out the failure mode of the use case you brought AI in to help solve for.

Now you’ve got somewhere to start. In this case, it’s “make our standards legible to AI”. Measuring organization-wide AI readiness is an impossible task. A use case by use case approach is how you actually uncover and close data gaps. 

Here are four tests you can run today to get started.

Four tips for getting your data AI-ready

Once you have a use case in mind, the next question is deciding what to change. Across the AI readiness work we’ve done with engineering teams, four needs emerge repeatedly: relevance, structure, context, and trust.

These tips present as a list, but it’s not a rigid sequence. Start with the gap your pilot exposes, fix it, and carry the lesson into the next use case. 

1. Relevance: define the specific use case

Start with one decision, review, workflow, or bottleneck. Define the inputs and be precise about expected outputs. In one customer pilot, we narrowed the broad goal of an AI-assisted drawing review down to three specific checks: machining stock, threaded-insert hole size, and obsolete specifications. That narrowed scope showed us which standards, rules, tags, and file settings the AI needed. Test the use case on a few real examples and note where the AI succeeds, misses a rule, or lacks context.

2. Structure: turn engineering know-how into checkable rules

An AI’s usefulness depends entirely on whether the data it needs to solve a problem are expressed in a format the tool can actually parse. In one customer pilot, unstructured DFM data was found to be the cause of feedback that wasn’t helpful or applicable. By working with customer SMEs, we compared the documents with real drawings and rewrote the useful knowledge as clear checklist criteria.

More broadly, ensure each critical rule, standard, or guideline is clearly defined using consistent terms. A useful rule of thumb is to ask whether an engineer outside the program could apply the guidance without speaking to its author. If they struggle, it’s likely an AI will, too.

3. Context: tell the AI what applies

AI can retrieve a valid document and still use it in the wrong situation. Instructing which source data applies to specific jobs can reduce these errors. We’ve resolved this with a customer who needed their internal GD&T rule to take priority over several valid interpretations of an industry standard—thereby pointing AI at the right standard.

You don't need a perfect enterprise taxonomy. But a simple classification scheme can keep the AI focused on the right sources. Otherwise, it has to fill the context gap by guessing.

4. Trust: validate and govern the inputs

Extracting data doesn't make it trustworthy. At one organization we work with, engineering knowledge was scattered across legacy databases and formatted as unstructured PDFs, images, and text files. Engineers themselves couldn't always tell which entries were current.

None of that could be trusted as AI input in its raw form. The fix—which is applicable beyond this case—is to build validation into the workflow itself: extract the data, evaluate its quality, route uncertain entries to a human for confirmation, and only then publish structured, validated records for AI to reference. Validate the data before AI touches it, not after.

This data discipline isn't glamorous, but it makes it far more accessible and usable to both engineers and AI systems.

So, is your engineering data ready for AI, and how would you even know?

Chasing organization-wide AI data readiness is the wrong way to approach solving this problem. Your data will never be universally “ready” because readiness depends on the specific problem you want AI to solve and whether the required information is available, reliable, and usable.

That’s the thesis of this article and our answer to this question: AI data readiness is solved use case by use case. Start with a specific application, use it to expose the gaps, then fix those gaps until the use case can run reliably in production. That’s how you create repetition that compounds as you determine how to apply AI to more and more use cases.

This approach allows an organization to create real value along the way by solving one practical problem at a time. The alternative is trying to fix all your data at once, or letting the enormity of that task prevent you from even starting, which ultimately leads to getting stuck for years with nothing to show for it. 

If ensuring your data is AI ready sounds like a lot of work, that’s because it is. CoLab partners with engineering organizations to make this work go faster and deploy AI sooner. Learn how here.