4.4 An offline AI-assisted rule-based DFM assistant¶
This page is part of the study AI for DFM Engineering. It is one of the two buildable projects: a design-services vendor building an offline AI DFM assistant.
The second proposal automates the manual DFM check itself. A designer types one instruction (analyse xyz.CATPart for Customer X) and receives, minutes later, findings in the requested format1 and a natural-language DFM summary, each finding carrying its measured value, the required value, the violated standard clause, and a plain-language reason. The tool is a language agent that drives deterministic geometry checks, reads the customer's standards, and writes the report, while a human keeps the sign-off.
4.4.1 The work it replaces¶
For the design-services vendor, the workflow is four steps, and the DFM check in the middle is manual:
In short: the customer asks, the designer models the part, a person checks it by hand, then the design is delivered. Problems loop back to modelling.
RFQ: request for quotation.
Today that check is done by hand: a designer runs CATIA's built-in analyses (draft, thickness), reads the colour plots visually, looks up the customer's thresholds in PDF documents, and writes the report manually. Four separate demands make it slow and fragile:
In short: four manual steps create error risk, and mistakes can reach the customer.
The knowledge sits only in senior engineers' memory and scattered PDFs, so quality depends on who runs the check and how careful they are that day.
4.4.2 What rule-based DFM covers¶
Rule-based DFM answers one question (can this shape be moulded reliably and come out of the tool cleanly?) using only checks that are measurable directly from geometry and judged against written rules:
| Check | What is measured | Rule source |
|---|---|---|
| Draft angle | tilt of walls vs the mould-opening direction | customer standard (e.g. min 1° smooth, 3° textured) |
| Wall thickness | local thickness everywhere | material / customer tables (e.g. 2–3.5 mm) |
| Rib ratio | rib thickness vs wall thickness | typically ≤ 60% of wall |
| Undercuts | features that block ejection | must be intentional or eliminated |
| Radii / corners | sharp-corner detection | minimum-radius tables |
The key insight: every one of these is either exact geometry math or a lookup in a standards document. No prediction and no physics simulation is needed; physics-based checks like warpage prediction are explicitly out of scope.
4.4.3 The proposal: a thinking brain, simple hands¶
The exchange the opening described (one typed instruction in, a clause-referenced report and summary out minutes later) works because behind it sits a local LLM that plans, calls tools, reasons over their output, and writes the findings; the tools themselves have no intelligence.
In short: the LLM thinks and decides; the five core tools do the mechanical work, and an optional sixth reads image-only inputs.
VB: Visual Basic; STEP: neutral CAD exchange format (ISO 10303); JSON: JavaScript Object Notation; CSV: comma-separated values.
The division of labour is the core design principle:
| Layer | Role | Intelligence? |
|---|---|---|
| Tools 1–5 | the hands: measure geometry, fetch documents, write files | none; simple, exact, testable scripts |
| LLM | the brain: decides which tool, interprets numbers, judges vs standards, writes reasons | yes, but only reasoning; it never measures geometry itself |
| Agent | the arrangement: brain and hands in a loop | the system as a whole |
Traced end to end, one request looks like this:
In short: the agent measures the part, looks up the rule, judges the value, then writes the result.
PP: polypropylene; JSON: JavaScript Object Notation.
4.4.4 How the agent knows the standards: RAG¶
The LLM does not memorise customer standards. It uses retrieval-augmented generation (RAG), the open-book-exam pattern. Documents are ingested once; at query time the retriever fetches the relevant clause and the LLM answers grounded in it.
In short: documents are indexed once; at question time the matching clause is fetched, and the LLM answers from it.
OCR: optical character recognition.
Four points make the design precise:
- Tool 4 is only the retriever: the librarian who fetches the page.
- RAG is retrieval and LLM generation together.
- Agentic RAG is the overall design here, where the agent itself decides when to retrieve.
- Metadata filtering per customer also cleanly enforces confidentiality separation between customers' documents.
Two consequences follow. Standards change per customer, so swapping documents beats retraining, which is why RAG is preferred over fine-tuning. And the per-customer metadata filter keeps one customer's standards from ever appearing in another's report.
4.4.5 Development effort & buy-vs-build¶
| Component | Decision | Effort / cost | Notes |
|---|---|---|---|
| Tools 1–2, CATIA draft & thickness scripts | build | main dev effort: CATIA VB automation; well-documented territory | robust scripting is ~70% of total project work |
| Tool 3, STEP-file checker | buy (or defer) | licence a commercial DFM checker with batch/CSV export (DFMPro-class) | never hand-build geometry math; defer if tools 1–2 suffice |
| Tool 4, retriever + knowledge base | build (standard tooling) | moderate; mostly document cleanup (librarian work); tech is off-the-shelf | tables in PDFs need care; convert key threshold tables by hand once |
| Tool 5, output writer | build | trivial per format | schema-enforced JSON is rendered to the requested format (CSV / DOCX / PPTX / …); each new format is a small, format-specific add1 |
| Tool 6, drawing reader (VLM) (optional) | install (open-source) | small; add only if needed | a local vision-language model (§4.2 lists clean-licence options) reads a 2D drawing or colour plot when a spec arrives image-only; the core design leans on numeric tool outputs instead, so this is added only when an input has no CAD or numbers behind it |
| LLM + serving | install (open-source) | infrastructure setup, days | Ollama/vLLM on one 24–32 GB GPU workstation; a Qwen 32B- or Mistral-class open model (§4.2 lists the clean-licence options and the ones to avoid); OpenAI-compatible API |
| Agent loop + prompts | build | small, days once tools exist | standard function-calling pattern; frameworks available |
| GNN / physics networks | not needed | zero | see scope boundaries |
Team needed: one developer comfortable with CATIA automation and Python: no ML research team, no model training, no fine-tuning.
Note on snapshot images. Rich outputs (PPTX/DOCX) can embed a captured 3D view of each flagged region. That capture is a CATIA-tool capability (Tools 1–2 position the camera on the face and export an image). It is not free: framing the view and highlighting the offending face is its own per-finding effort, separate from the simple work of writing the file.
4.4.6 Phased roadmap & where it sits¶
The build is staged so value ships early and the team learns the easy half first:
In short: start with document Q&A, then add the geometry checks, then make it a standing gate.
RAG: retrieval-augmented generation.
- Phase 1 ships first and delivers value immediately: designers query customer standards in natural language instead of digging through PDFs, and DFM reports are auto-drafted. It builds the team's LLM skills on the easy half. A useful by-product: the same standards Q&A is not designer-only. After feeding the RFQ into the system, estimation and sales can query it against the customer's standards to check feasibility before quoting, making Phase 1 an early, visible win for the business, not just the design office.
- Phase 2 runs in parallel development: the CATIA scripts plus the agent loop. This lowers the risk: the CATIA scripts (Tools 1–2) have standalone value. Even if the agentic LLM layer is never finished, the same scripts run as plain automation, one-click draft and thickness checks that output raw measurements, so the geometry work is never wasted.
- Phase 3 makes it a permanent pre-delivery gate.
In the daily workflow the assistant runs on demand while modelling, and again as a pre-delivery gate. It is augmented AI, not autonomous AI: the designer runs the analysis, reviews what it finds, and stays the author of what ships.
In short: the designer asks, the AI checks and drafts, a person confirms before anything is delivered.
Start human-in-the-loop, earn autonomy later. In the initial version, nothing goes out on the AI's word: the designer runs the checks, confirms every finding against the geometry, and the senior engineer signs off the report the firm delivers. The AI drafts. Humans verify and own the result. First, prove the reports are accurate across many real parts. Only then reduce how much a human re-checks by hand. Trust is earned from evidence, not assumed at launch.
Governance rule (non-negotiable): the agent is advisory, read-and-report only. It never modifies geometry. A human fixes the CAD, and a human signs off. The firm's "no flaw" liability stays with qualified engineers. The AI catches more, earlier. It does not approve designs.
4.4.7 Expected outcomes & benefits¶
| Benefit | Today (manual) | With the agent |
|---|---|---|
| Check coverage | depends on the designer's discipline and memory | full battery, every part, every time |
| Standards lookup | minutes–hours in PDFs; error-prone | seconds, with the exact clause cited |
| Timing of the catch | at design review (week 3) | while modelling / on demand (minute 10) |
| DFM report | half a day of manual assembly | auto-drafted, with reasons and clauses (human-confirmed) |
| Knowledge risk | held by only 2–3 senior engineers | captured in the knowledge base; juniors query it |
| Consistency | varies by person and day | identical rule application, auditable |
| Customer trust | n/a | every delivery carries a machine-assisted, clause-referenced report; offline setup means "your data never leaves our premises" |
In summary: fewer flaws escaping to the customer means fewer rework loops, faster delivery cycles, and stronger credibility on the firm's core contractual promise.
4.4.8 What this is not¶
The scope boundaries are deliberate, and holding them is what keeps the project buildable:
- No physics prediction. Warpage, fill patterns, weld lines and sink marks depend on flow and cooling physics; that is GNN/PINN surrogate territory, it needs training data the design office does not have, and it is a product category to license later (a plug-in "Tool 6") if ever needed. Not built here.
- No model training or fine-tuning. An off-the-shelf open LLM plus RAG covers the reasoning layer entirely. Because standards change per customer, swapping documents beats baking stale rules into weights.
- No design automation. The agent finds problems; humans fix and approve them.
In short: exact checks and standards lookup are in scope; physics prediction is not.
GNN: graph neural network; PINN: physics-informed neural network.
In one line: the manual, person-dependent DFM check becomes an offline AI agent: CATIA scripts measure the geometry, a local LLM judges every measurement against the customer's own standards via RAG, and every delivery ships with an auto-drafted, human-confirmed, clause-referenced DFM report. No cloud, no model training, no physics simulation, and human sign-off retained.
Hardware & licensing. A spec-only bill of materials for this project (local-LLM GPU sizing, the CATIA-free STEP-first geometry pipeline, the open-source stack, and the CATIA licence points to confirm with the vendor) is in Annexure B · BOM for Project 2.