Text-to-CAD Isn't Enough

The grail is text-to-engineered-product.

Why is everyone so focused on text-to-CAD? Because we instinctively know CAD as the best way we currently have of communicating design intent. (Sure, sure, any engineer will tell you design intent is best communicated through drawings. But the first layer of design intent is a glance at the model, rotating it, getting a feel for it in space. Drawings "just" build on that with all the information you need to actually manufacture the thing, and arguably most of that can be embedded in the model as PMI with most modern CAD systems nowadays)

But the model is far from the only piece of engineering information needed to actually produce a product. And it's not even the real starting point!

Small manufacturers and engineering shops often have a weak or non-existent legacy of requirements engineering, because it's a domain that's easy to fuzz over when you have strong technical engineers who can intuit (or have as tribal knowledge) the requirements they're designing to. But large engineering orgs know the benefits of requirements engineering and the full systems engineering workflow to keep larger teams aligned in purpose and across domains.

Meanwhile, one of the metas that has emerged from agentic AI software development is that swarms of agents need testable goals against which to refine the artifact they're working on. Agents with a spec and a test suite converge. Agents with a vibe wander. The difference between vibe coding and "agentic engineering".

Those two observations point at the same conclusion. That's why requirements development is the first step of Cascadia's multi-stage AI-assisted Design Engine.

Step 1: Requirements are the evaluation basis

You start the engine the way you'd start any text-to-X tool: describe what you want to build in plain language. "A benchtop pick-and-place for 0402 components." "A backpack-portable water filtration unit." "An electric utility cart for use around the farm." Whatever.

But instead of geometry, the first thing that comes back is a set of structured requirements: a statement, acceptance criteria, a priority, and a source for each one. Where your description is ambiguous (as the prompt suggestions above are in almost every way), the engine asks for clarification, supplying multiple-choice options with the ability to add in your own responses. You also have the freedom to interrupt at any point in this process, as it works.

Once the engine has decided it has a sufficient number and detail of requirements, it stops. Now it's on you, the user, to review, critique, edit, reject, and flesh out the requirements generated. You can breeze over this step, but I've found that every time I do this exercise with a new system to design, I've forgotten to list some critical piece of the design criteria in the initial prompt ("we need to use the motors we have on hand," "it needs to be 48V"), and have to either manually add it here, or supply the engine's agent with those additional criteria and let it create the missed requirements. Also very common is that the generated requirements educate me on something I wasn't even thinking about for my particular project, and maybe I have to shift direction a bit, but interestingly, it's very infrequent that I have to straight up delete generated requirements.

Finally, you approve the set of requirements. It takes minutes, and it's the most productive few minutes in the whole process. It's like the difference (well, at least how the difference used to be) between throwing a one-sentence prompt at Claude Code asking it to jump right in on a major change, and putting it in Plan mode first.

The acceptance criteria are the point. The requirement is something the engine (and later you, and later still your quality process) can evaluate an artifact against. It's the same discipline that makes agentic coding work, applied to hardware development.

There's a nice side effect, too: teams that never had the time or appetite for formal requirements engineering get a requirements baseline anyway, something they can use throughout the follow-on engineering process. And they get it without having to hire a Systems Engineering team and slow down their entire development process.

Step 2: The multi-level BOM

I've worked at companies that didn't produce drawings, and I've worked at companies that didn't deliver CAD models. The one constant, everywhere, is that your complex designs have a hierarchy, and that hierarchy is represented as a bill of materials, in some form or fashion. That hierarchy is the first and final truth of your design. Once they have a general set of requirements to build to, your Chief Architects start building a high level BOM, and their sub-managers get it fleshed out from there. Your BOM is your architecture, and one of the most iteration-intensive early phases of any complex product design is architecture decomposition. AI, properly harnessed, is exceptional at structured iteration like this.

This decomposition doesn't happen in a vacuum, either. The engine searches your existing PLM data as it works; it can find the mounting bracket you released two years ago for that component you specified to use in this prompt and pull it into the tree as a reused item instead of proposing a new one. (Reuse is one of those benefits big-company PLM discipline always promises and rarely delivers. An agent that actually runs a search before inventing a part turns out to be a surprisingly effective enforcement mechanism. And it doesn't get lazy.)

Now, as we mentioned, complex products are assemblies, and most line items in a real assembly are not purchased, not designed in-house. Fasteners, bearings, motors, off-the-shelf electronics. Generating geometry, manually or via AI-assisted generation, for a part you're purchasing is worse than useless. So before any CAD, the engine decomposes the product into a multi-level BOM and classifies every node: Manufacture, Purchase, Phantom, or Software. Only the Manufacture parts will ever see a text-to-CAD prompt.

Two more things happen at this stage that pay off later. Every requirement gets linked to the part or parts that satisfy it, producing a live coverage matrix: you can see at a glance whether a requirement has no home, or a part has no reason to exist. And the engine defines the mechanical interfaces between parts. Mounting hole patterns and locations, mating faces and orientations, how children connect within each assembly. The engine's going to use that information to piece the subassemblies together and compose upwards when we have CAD (author's note: this automatic assembly composition is still being worked out).

Once the BOM's generated, you've got another review and approval gate before we move on to the CAD.

Step 3: CAD, finally (for the impatient)

Now the geometry. And here's the thing: it's better geometry than one-shot text-to-CAD, because each part is generated with its full context — its role in the assembly, its interfaces with sibling parts, the requirements traced to it. This context allows us to generate an excellent prompt without stopping to consider the details for each part, and gives the harness something to check generated CAD against, and evaluate how to change the text-to-CAD prompt automatically if necessary.

Under the hood, we generate a STEP file per Manufacture part, with a current split between using OpenCascade to parametrically generate CAD for parts that fit templates we've developed (nuts, bolts, things that are clearly parametric) and using Zoo.dev's Text-to-CAD API (byo API key) for everything else (we are deliberately not in the geometry-kernel or CAD ML business... yet...), then we convert it server-side for review in the in-browser 3D viewer, and then compose the assembly bottom-up using the interface definitions from the BOM stage. You review the models the same way you'd review anything: rotate it, get a feel for it in space. The first layer of design intent, remember?

Development checkpoint: this is the youngest part of the engine. Generated parts (espcially those coming from outside APIs) are genereally prototype-grade starting points, not release-grade models, assembly composition is still early stages, and we use .STEP as our default protocol which may not be good enough for many shops. As the LLMs and other engines improve, and we refine our engine, the quality can only go up. And we can build custom solutions for different shops that need, e.g. Solidworks models generated instead of STEP. All of these are problems with solutions, and we are taking the right road to get to the end goal, not the quick road.

Step 4: Materialization - concept to change item

Everything up to this point lives in an isolated design session. Materialization is where it exits the sketchpad and enters the digital thread: requirement items, parts, BOM relationships, CAD files in the vault; everything that was isolated to this design session becomes actual database entries.

And we use Cascadia's inherent architecture advantages to do it; API first, and isolated ECO branches. The Design Engine gets no special treatment: the AI's work enters the system using exactly the same functions as any engineer clicks in the UI do. You get a "materialization preview" of everything about to be created, then the ECO runs through your normal approval workflow. Nothing touches released data until humans approve and the branch merges. Revision letters are assigned at release, the audit trail is fully intact, and every piece of data is fully traceable for future manual or AI-led changes or inquiries.

This is the difference between a cool demo and an engineering system. It's the difference between Intellicode and Cursor. The output isn't a single file or part, it's traceable, queryable product structure across the whole digital thread. Run where-used on a generated part. Do impact analysis when a requirement changes.

Where we're going next

The pipeline so far covers requirements → BOM → CAD → released items. But we're going further.

Software. The BOM already classifies parts as Software; generating firmware against the same requirements set, traced the same way, is the obvious next domain.

Wiring Diagrams. While we don't have any immediate intent to delve into mechanical drawings, electronics wiring diagrams are a different sort of thing, and obey a certain set of rules that we can build against.

Work instructions. We already ship rich step-by-step work instructions in Cascadia with parametric fields and change alerts tied to the linked parts. Drafting them automatically from the BOM and assembly structure turns "released design" into "buildable design" a lot faster.

Simulation. Some acceptance criteria are computable. Mass budgets, envelope checks, interference, basic structural sanity; every criterion the system can evaluate automatically is a test the agents can iterate against without a human in the loop.

Reflection between stages. Today the flow is mostly forward. The interesting version is a loop: a part that can't satisfy its requirement should trigger a requirements conversation; an assembly that won't compose should question the decomposition. Agents refining across the whole product definition, not just within one artifact.

The forest, not the trees

Text-to-CAD optimizes the most demoable artifact in the process, not the hardest part of the job. A CAD model with no requirements behind it, no BOM around it, no sourcing decisions, no revision history, and no path to release isn't a product. It's a shape.

The glance at the model really is the first layer of design intent; that is exactly why text-to-CAD is so magnetic, so exciting to us. But an engineered product is all the layers: what it must do, what it's made of, what you buy versus make, how it goes together, how it changes, and who approved what, when. That's the grail we're chasing: text to engineered product.

---

The Design Engine is part of Cascadia's paid tier — for more information, or a demo against something you'd actually build, reach out to kai@cascadiaplm.com. Or start with the open-source foundation we're building on today: Cascadia PLM on GitHub. One docker compose up gets you a running instance, pre-seeded with a real robot-arm engineering dataset, in minutes.