The Pattern: Repetitive Workflow, Unique Geometry
Most automation lives on a comfortable assumption: parts belong to families. Poles, conveyors, enclosures, frames; change the parameters, and the geometry follows a template you already know. When that holds, rule-based automation is unbeatable, because the rules always know which face is which.
A whole class of manufacturers lives on the opposite side of that assumption. They never see the same part twice. The workflow around each job is perfectly repetitive, the same tooling, the same drawing package, the same sequence of decisions, but the geometry is new every single time. There is no parametric baseline, so a rule that says "offset the punch contact faces" has no way to know which faces those are. For decades the only automation for this was a rare senior engineer who could look at a novel part and simply know which surfaces mattered. That knowledge lived in a few heads, took years to grow, and left at retirement.
That is not simply a scripting gap you can close with better code. It is a recognition problem, and that is where machine learning adds capabilities rule-based automation struggles to provide. A model trained on a company's own completed projects can learn that same judgement from the same evidence, then hand its answer to ordinary CAD automation that has known how to act on it all along. We covered how that works in depth in AI in CAD Automation: What Actually Works in Production. This article is about where it applies.
One Engine Under All of Them
Every domain below runs on the same division of labor, and it is worth fixing the shape in your head before the examples, because the examples are just this diagram wearing different clothes: the AI decides what the geometry means; the CAD platform builds every feature natively.
In our production deployment this runs as a closed loop: every face of the part is given a persistent identity inside the CAD platform, the part is exported as neutral STEP AP242 so geometry and those names travel together, a locally hosted model reads it and returns labels as plain JSON (no design data leaves the building), the labels re-anchor to live faces by name, and native API operations build the result as a normal, editable feature tree. The model itself reads the part the way an engineer does, as topology rather than pixels, learning from hundreds of the company's own past projects, which is both the point and the moat: it encodes your judgement, not generic internet geometry. That is as much of the recipe as matters here; the deep-dive article walks the full pipeline.
The property that makes this reusable across industries: recognition and geometry-building never touch. Swap the training data and the output features, and the same underlying architecture adapts from a stamping shop to a dental lab. The representation, the labels, and the CAD operations change with the domain; the clean handoff between the two layers does not.
Eight Domains Where Every Part Is Unique
For each domain: the geometry that never repeats, the expert judgement it demands today, what the AI is asked to recognize, and what conventional CAD automation then builds. None of these need the AI to draw anything; it answers "what is this?" and rules do the rest.
The list is not exhaustive, and that is the point: the pattern generalizes. Anywhere a skilled engineer has to interpret a one-off geometry before a well-understood process can act on it, the recognition layer is transplantable. Thermoforming and vacuum-form tooling, architectural facade panels, custom packaging, orthotics, and repair or reverse-engineering workflows all fit the same mould.
Does Your Workflow Qualify?
The honest filter, the same one we apply on a first call, disqualifies most workflows from needing AI at all, and that is a feature:
- Do your parts follow families or templates? If yes, stop here. Rule-based automation is cheaper, faster to build, and deterministic. Most configure-to-order businesses live here.
- Does your automation keep failing at "which faces?" rather than "build it"? That is the signature of a recognition problem. The construction was never the hard part; identifying the geometry was.
- Is expert judgement genuinely required to read the part? If a novel job still needs your most experienced engineer just to interpret it before anyone can proceed, that judgement is what the model captures.
- Do you have enough history to learn from? The volume you need varies with problem complexity, geometry diversity, and how consistent and well-labelled your records are. In a narrowly defined workflow, a few hundred well-structured past projects can be enough to establish feasibility; a larger but inconsistent archive may not be. If completed projects sit in your archives, that is the place to start, and the data is usually messier than anyone hopes and still workable.
Where It Does Not Fit
The uncomfortable truth a vendor selling "AI-powered" everything will not tell you: if a rules-based system can solve your problem, adding AI makes it worse. More cost, more validation burden, less explainability, for zero added capability. AI earns its place where rule-based recognition becomes too brittle, complex, or expensive to maintain across genuinely non-repetitive geometry. Everywhere else, the rules you could have written five years ago are still the right answer, and they are cheaper to build than ever.
This is why the applications above are all tooling and preparation problems on unique inputs, not "let AI design the product." The product geometry comes from your customer or your design team. What repeats is everything that happens after it lands: the tooling, the fixturing, the drawings. That is the automatable part, and recognition is the key that finally unlocks it when the part is one of a kind.
How to Test Your Own Case
If one of the domains above is yours, the path to knowing whether it is feasible is more ordinary than the technology suggests:
- Map the workflow, not the model. List the decisions that need expert recognition versus the ones that are really rules in disguise. The AI scope should shrink as you do this; that is a good sign.
- Audit the training data. Completed projects, in CAD formats you can still open, consistent enough to label. This decides feasibility more than any algorithm choice.
- Prototype recognition first. Before building any pipeline, can a model trained on your history correctly classify a held-back part your team agrees on? That single result de-risks the whole project.
We built this for a leading watch manufacturer whose new-product team designs unique case and dial geometries. The technology is the same underneath every domain on this page, and the outcome was concrete:
If your parts never repeat and your best engineers are the bottleneck, the question worth asking is not whether this can be automated, but which of your workflows to start with.
Send us three to five representative CAD models, along with the tooling or drawings your engineers create from them. We will tell you honestly whether the problem is best solved with rule-based automation, AI-assisted recognition, or a hybrid of both.
Discuss Your Workflow →