Skip to content

4.1 From a gap to an opportunity

Chapter 3 ended on a verified absence. Across some forty companies, the two middle layers of the engineering-intelligence stack — Knowledge and Reasoning — are empty for moulded parts: no one has retrieval over its own part history, no one has learned DFM, no customer runs a moulding surrogate in production. That chapter stopped at the absence on purpose. Showing a gap is there is one thing; deciding what is worth building into it is another, and it is what this chapter turns to.

The tempting reading is that the gap is a to-do list — swap each classical tool for a learning one and the middle fills itself. It is not that simple, in two ways worth settling before any project is named.

4.1.1 Replace, augment, or leave well alone

"Replace the classical process with AI" sounds like one move. It is really three, and telling them apart is the difference between a useful project and a wasted one.

  • Leave alone what already works. A validated mould-flow solver computes from measured material physics; a rules DFM checker applies a standard a person wrote and can explain. These are not weaknesses to be removed — they are the parts of the workflow that already do their job well. The prize is to reach the work they cannot do, not to rebuild the work they can.
  • Augment where the classical tool is silent. The strongest near-term moves keep the classical mechanism and add a learning one beside it: the rules still decide, but a language model reads the standard and drafts the report; the solver still computes, but retrieval reminds the engineer what happened to similar past parts. Most of the near-term prize is here.
  • Replace only where a learned model is genuinely faster or truer. There is one such place — a surrogate that predicts warpage in seconds where a physics run takes hours — and, as the rest of the chapter shows, it is also the hardest.

4.1.2 Three questions that turn a gap into a project

An empty layer is an invitation, not yet a plan. Three questions decide whether a gap is worth building into, and they are best asked in order — the first "no" ends the matter.

  1. Is the gap real? Chapter 3 answers this. A capability is worth chasing only where the field verifiably has nothing — a confirmed [Evidence of absence] — not merely where what exists is thin or clumsy.
  2. Does it need labels? This is the question the whole study keeps returning to. Retrieval and language work are unsupervised: an archive of old CAD files, or a shelf of standards documents, is all they need. Learned prediction is not — it needs geometry paired with measured outcomes, the very data the workflow's hand-offs scatter and lose. A gap that is real but needs labels nobody holds is a research bet, not a project you can start.
  3. Can it be built with what exists today? A capability can be proven in a paper and still be years from a working tool. What decides the difference is whether the open-source building blocks are mature enough to assemble now.

The second question does most of the sorting, splitting the field cleanly in two: the work that needs no labels and can start on assets a company already owns, and the work that cannot begin until data nobody has is created. The map below places each opportunity on the workflow; §4.2 then checks the open-source shelf and names the projects that answer all three questions with a yes, which the sections after it work out in full.

4.1.3 The map: where the AI trio can take over

The five-layer stack from Chapter 2 gives the clearest view of where a learning mechanism could stand. Each layer has a classical incumbent doing the work today; at the layers Chapter 3 found empty, a mechanism from the AI trio could take over or stand beside it. Read the stack top to bottom and the shape of the field appears on its own — the outer layers occupied, the middle two vacant, and only two of the five shifts hungry for the scarce labelled data.

Layer (§2.4) Classical today The AI-trio opportunity Replace or augment Needs labels?
Intent — requirements → tasks manual reading; R templates L reads the RFQ, drafts the response augment No
Knowledge — what we already know manual search; nothing K retrieval: "find past parts like this one" replace the manual hunt No
Reasoning — predict consequences P physics solver ML surrogate predicts warpage in seconds replace the slow run Yes
Execution — do the work R rules DFM; people L+K wrap the rules: orchestrate, ground, explain augment No
Feedback — learn from outcomes nothing ML learns geometry → measured outcome fill the empty layer Yes

The label column is the one to watch. Retrieval and language work need none, so the Knowledge and Execution shifts — and the near half of Feedback — can start on data a company already has. Only the two ML shifts, at Reasoning and true Feedback, wait on labels. That single division decides which opportunities become projects. The Intent row is listed for completeness only — Chapter 3 found that layer already occupied on both sides (Bertrandt's RFQ agent, Continental's requirements win), so it is no gap and gets no section below.

4.1.4 Opportunity K — retrieval replaces the manual hunt

Every engineer starting a new part asks the same question — have we made something like this before? — and answers it from memory and folder-digging. Retrieval turns that into a query: describe the new geometry to a model, search the archive, and get back the closest past designs with their gate positions, tool changes and outcomes attached. The model brings a pretrained sense of shape and applies it straight to the CAD files, and needs no record of what went wrong afterwards — an archive is enough.

This is the clearest win in the study, and Chapter 3 showed why. The Knowledge layer is nearly empty: one ecosystem-locked vendor product, no customer deployments, while the raw material — decades of past parts — sits unmined at every supplier with a legacy library. It replaces a manual task outright, and it can start on an archive that already exists.

4.1.5 Opportunity L+R — a language agent wraps the rules

A rules DFM check is exact geometry math against a written standard, and its plodding determinism is a virtue, not a flaw — it should be kept. What is painful is everything around the rule: the engineer has to remember to run each check, find the right threshold for this customer and material in a 200-page PDF, read the colour plots, and write up the report by hand. That surrounding work is reading, judging and explaining — the natural home of a language model, with retrieval fetching the governing clause.

So the opportunity keeps the classical checker as the authority on geometry and adds a language layer around it: the model plans the checks, retrieves the relevant standard, weighs each measurement against it, and drafts the findings — while a human keeps the sign-off. It augments rather than replaces, needs no labels, and can run entirely on the company's own hardware — which matters, because automotive CAD and customer standards are under NDA and often may not touch a cloud at all.

4.1.6 Opportunity ML — a surrogate replaces the slow physics run

This is the one place where "replace" is the honest word. A learned surrogate that predicts warpage from geometry in seconds would genuinely stand in for a mould-flow run that takes hours — and warpage is the prediction that costs money, the one that drives tool re-cuts and rejected parts. [Synthesis] Chapter 3 found the seat empty where it counts: the two neural-solver debuts of 2026 — one a research preview that stops at the filling stage (SIMCON), one shipping without moulding-specific error metrics (Siemens) — and nothing is validated for automotive warpage.

The catch is the second question from §4.1.2. A surrogate learns from thousands of solver runs, and those runs are only cheap to produce if you own — or partner with — a mould-flow solver. The methods are published and open; the moulding-specific data and trained weights are not (§4.2). This is a research bet resting on access to a validated solver — an in-house licence or a partner — not a project that begins on a library already in hand.

4.1.7 Opportunity Feedback — learn from what actually happened

The emptiest layer, and the hardest. Nobody in the study learns from geometry paired with its measured production outcome — the scrap, the as-built warpage, the tool-tuning history. This is the fourth kind of learning the study keeps circling: the one that could answer not "does this wall have draft?" but "will this geometry actually warp enough to matter?"

The labels here are worse than scarce. They do not merely need generating — they sit on the far side of the workflow's hand-offs, at a different company from the geometry. There is, though, a quiet way in. The retrieval product of Opportunity K, once deployed, is exactly where those outcomes could begin to gather — attached to indexed parts, one project at a time. The labelled dataset the whole field lacks is best assembled as a by-product of a tool people already use, not as a data-collection project of its own. That makes Feedback the long-game destination, reached through Opportunity K rather than instead of it.

Each opportunity now has a home in the workflow and a verdict on labels. What remains is the practical test — whether the tools to build it are on the shelf.