4.2 What a design-services vendor can build today

Everything that follows assumes one specific setting: a design-services vendor. Such a firm designs injection-mouldable plastic parts — trims, housings, brackets, panels — in CATIA, and is contractually responsible for delivering designs with no manufacturability flaws. Crucially, it owns no mould shop, runs no moulding trials, and sees no production data: its DFM is design-side only.

This section explores what such a firm can build with AI on the assets it actually has: its geometry — the CAD library — and the standards it designs to. It holds no measured production outcomes, the labels that learned prediction would need. §4.1 already sorted the opportunities by whether they need labels of that kind; the test now is practical — for each opportunity, are the open-source parts to build it already on the shelf? The section walks that shelf mechanism by mechanism, layer by layer, and reaches its verdict opportunity by opportunity at the end.

The survey behind this section examined primary sources — GitHub licences, model cards, dataset pages — for each capability below. Where a tool's licence blocks commercial use, or where no tool exists at all, that is reported plainly, in the same spirit as the rest of the study: a confirmed absence is a result.

4.2.1 The K layer — retrieval is assembly, not research

How a retrieval tool reads geometry decides which open tools fit and how each part is ingested. The three paths consume different representations of the part — a rendered image, a mesh (points sampled over the surface), or the exact B-rep (faces and edges) — and there are two ways to produce any of them from a native CATPart:

1. a licensed CATIA seat exports them directly; or
2. a one-time CATPart→STEP conversion with a standalone converter (no CATIA seat) feeds open-source tools that render, mesh or read the geometry.

Rendered images and meshes can be produced either way; the exact B-rep can only be read after a STEP conversion, because the open-source B-rep readers cannot open a CATPart directly. The retrieval project (§4.3) weighs that ingestion trade-off in detail.

Path	How it reads the part	Best open tools	Licence	Producing it from a CATPart
Rendered views	screenshots from a few angles	DINOv2 (Meta), OpenCLIP (LAION)	Apache-2.0 / MIT — clean	CATIA screenshot export, or render a STEP conversion with open source
Point cloud	points sampled from a mesh	OpenShape, ULIP-2, Uni3D	weights downloadable, but licence is unclear for commercial use [Evidence]	CATIA mesh export, or mesh a STEP conversion with open source
B-rep graph	exact faces and edges	UV-Net (MIT), AAGNet (MIT)	code MIT, but released weights are font-trained	STEP only — open-source readers can't open a CATPart

The three paths trade off differently:

• Rendered views — the pragmatic winner. A screenshot is cheap, the embeddings work with no training, and the weights are the only ones cleanly cleared for commercial use (DINOv2 is Apache-2.0). The one caveat is a known quirk: models trained on everyday photographs read untextured grey CAD renders slightly less well.
• Point-cloud encoders — more faithful, but licence-blocked. They judge 3D shape more faithfully, and their weights are downloadable — fine to prototype with — but none is cleanly licensed for commercial use (the model catalogue gives the per-model detail), so a shipping build would need that cleared first.
• B-rep graph — truest to the CAD, but heaviest. It is the closest to the exact geometry, but the one path that always needs a STEP conversion first, and its public weights were trained on fonts, so a serious deployment would train on its own parts regardless.

All three share the property that matters: they are unsupervised, giving useful similarity with no labels. The strongest measured accuracy belongs to the 3D-aware encoders — those that take a point cloud or B-rep as input: on the Mechanical Components Benchmark the best of them reach roughly 89–91% retrieval precision (trained on the benchmark, not transferring zero-shot).¹ [Evidence] Of the three, though, only the rendered-view path is both cleanly licensed for commercial use and free of any training or conversion step — the point-cloud weights are not cleanly licensed, and the B-rep path always needs a STEP conversion. So retrieval can be built today; which path a given project actually takes is a design choice, settled in the retrieval project.

4.2.2 The ML layer — open methods, no open data or solver

Here the shelf divides sharply between method and fuel, and the study's central finding reappears in the tooling.

The methods are open and permissive. To learn warpage from geometry, the mesh-and-field frameworks are all available and mostly Apache- or MIT-licensed — NVIDIA PhysicsNeMo, Bosch's TorchPhysics, the neuraloperator family, and MeshGraphNets, the last a natural fit for predicting deflection at every node of a part mesh. The architecture is not what holds anyone back.

The moulding data and weights are open nowhere. The survey confirms two hard absences:

• No open dataset pairs moulded-part geometry with DFM labels — draft adequacy, wall-thickness uniformity, sink or warp risk. The labelled CAD datasets that do exist (MFCAD and its kin) label machining features, not moulding. A learned DFM checker would have to create its own labels. [Evidence of absence]
• No open warpage model and no open moulding-simulation dataset exist. The one open moulding solver that could generate training runs, openInjMoldSim, covers filling, packing and cooling only — not warpage — ships no measured material database, and is slow. Every warpage surrogate in the literature was trained on a licensed commercial solver. [Evidence of absence]

The lesson is the one Chapter 3 reached from the company side: the value in learned moulding lives in the validated solver and its measured material database, not in the neural network. Open source hands over the machine and withholds the fuel. The two wait for different reasons:

1. The warpage surrogate is trained on simulated runs, so its data is computable — the real barrier is a validated solver that models warpage and carries a material database, which the open stack lacks. A firm that already licenses a flow simulator (Moldflow, Moldex3D) for its own DFM checks could in principle batch-run it to generate that data; even then it stays an R&D bet, since generating data at scale and building a trustworthy surrogate are efforts of their own.
2. Learned DFM is harder: its labels are real production outcomes nobody records, so it needs a labelling programme, not just compute.

4.2.3 The L layer — a full offline stack, none of it moulding-specific

The language layer is the readiest of the three, and the reason it matters is data sovereignty: automotive CAD and customer standards are under NDA, so the whole stack has to run on the company's own machines, with nothing leaving the building. A complete offline stack for that exists today, built entirely from freely licensed parts.

Role	Clean-licence open options	Licence to avoid
Reasoning LLM	Qwen3, Mistral Small 3, DeepSeek, Phi-4	Llama (custom licence + live litigation) [Evidence], Gemma (custom terms)
Drawing/VLM	InternVL3 (MIT), Molmo (Apache), Qwen2.5-VL 7B	72B Qwen-licensed variants
RAG embeddings	BGE-M3 (MIT), Nomic-embed, Qwen3-Embedding	NV-Embed-v2, jina-v3 (both CC-BY-NC)
Orchestration	LlamaIndex, LangChain/LangGraph, Haystack	—
Serving runtime	vLLM, llama.cpp, Ollama — all fully offline	any hosted-API-only model

Each role has a job, and they combine into one pipeline: the orchestration layer plans the checks and calls the others; the reasoning LLM weighs each measurement against the retrieved standard and drafts the findings; the RAG retriever fetches the governing customer clause; the Drawing/VLM reads the visual inputs a text model cannot — a 2D engineering drawing, or a colour-map analysis plot — and turns them into text the reasoning model can use; and the serving runtime hosts every model locally, so nothing leaves the building.

In short: one offline box — orchestration calls the retriever and the drawing-reader, whose output feeds the reasoning LLM (retriever + LLM together are the "RAG" pattern); the serving runtime hosts every model, and a person signs off.

VLM: vision-language model; RAG: retrieval-augmented generation.

On a single high-end GPU workstation — a 32-billion-parameter model fits in about 24 GB at reduced precision — this runs with no cloud dependency at all.

The caveat is the honest-AI test again: no open language model is trained for injection moulding, and the one framework built specifically for it (KAIST's IM-Chat) runs on a hosted model and is a research prototype. [Evidence] Every open option is assistive — it orchestrates and explains; it is not an authority on moulding physics. That is exactly why the DFM assistant leaves the deterministic rule-checker in charge of the geometry and lets the language model only plan, retrieve and write.

The same logic decides the retrieval half — why the assistant reads the customer standards at query time (RAG) rather than being trained on them. Training would be the wrong choice on three counts:

1. Customer isolation. The standards are under NDA, and one customer's rules must never surface in another's report. Fine-tuning bakes every customer's documents into one shared set of weights, where they cannot be cleanly separated again; retrieval keeps them as distinct, access-filtered documents, so a per-customer filter can guarantee only Customer X's standards are ever read for Customer X.
2. Standards change. They are revised per customer and over time; swapping a document in the index beats retraining a model each revision.
3. Traceability. A retrieved clause can be quoted and cited in the report, so a human can check it against the source; a rule trained into the weights cannot be traced.

(§4.4 shows how the per-customer filter enforces that separation in practice.)

4.2.4 Readiness, opportunity by opportunity

Putting the three tests together gives one verdict per opportunity:

Opportunity	Real gap?	Labels-free?	Tools ready?	Verdict
K — retrieval	Yes	Yes	Yes (Apache/MIT, render path needs no STEP)	Buildable now
L+R — DFM assistant	Yes	Yes	Yes (full offline stack)	Buildable now
ML — warpage surrogate	Yes	No	methods yes, data/weights no	Deferred
ML — learned DFM	Yes	No	backbones yes, no label dataset	Deferred
ML — outcome feedback	Yes	No	—	Deferred

The split falls on the labels test. Three of the five fail it and two pass — so take the three that must wait first, and why, then close on the two that can start now.

The deferred three — real, but not yet

These three are genuine, and each was tempting enough to sketch. Each fails on the same point — the labels do not exist — and must wait for an asset the firm does not have. Saying why is itself part of the answer.

Deferred project	Mechanism	What it would replace	What unlocks it
Warpage surrogate	ML → P	the slow mould-flow run	a validated flow solver — an in-house licence or a partner — plus the R&D to generate training runs at scale (the open solver does fill/pack/cool only, no warpage, no material database)
Learned DFM	ML → R	rule-based judgment	a labelling programme — no open dataset pairs moulded geometry with DFM outcomes
Outcome / metrology feedback	ML (Feedback)	nothing (the empty layer)	measured outcomes joined to geometry — best gathered through the retrieval project, over time

Chapter 3 found the middle empty because the labelled data is missing, and this section found open source withholds that same fuel. These are bets on a solver or a data partner — the right later move, and the wrong first one.

The two to build now

That leaves the two that ask for none of it. Retrieval and the DFM assistant need only the geometry and standards the firm already holds — no labels, no solver, no partner — so both are buildable now, on assets it already owns. They are the subject of the sections that follow: design-reuse retrieval and the offline DFM assistant, drawn together in the conclusion.

---

1. Kim et al., "A Large-scale Annotated Mechanical Components Benchmark for Classification and Retrieval Tasks with Deep Neural Networks," ECCV 2020. Best reported retrieval on the benchmark is around 89–91% precision-at-N (e.g. PointCNN P@N 0.892 on Dataset A, DLAN P@N 0.912 on Dataset B), for models trained on the benchmark, not zero-shot transfer. https://link.springer.com/chapter/10.1007/978-3-030-58523-5_11 (accessed Aug 2026). An earlier "~97%" figure in this study was not supported by a source and has been corrected. ↩