Most of the AI-in-MBSE chatter is about requirements: extracting them, cleaning them, tracing them. A paper presented at the 2026 IISE Annual Conference by H.S. Bank and D.R. Herber goes one step further and asks the LLM to propose an architecture. It's worth reading, mostly for how carefully it limits what the model is allowed to do.
The paper, "GenAI Workbench," is a conceptual framework and a proof of concept. The authors say plainly that implementation and validation are future work, and it reports no experimental results for the workbench itself. So treat what follows as a design pattern to evaluate, not a result to bank on.
The problem it targets
System-level requirements and architectures usually live in one set of tools. Detailed component design, especially CAD geometry, lives in another. The link between them is often a person with a spreadsheet and a good memory.
The workbench tries to connect three kinds of data: text from source documents, B-rep CAD geometry, and graphs of system relationships. The glue is a persistent unique identifier for each component, so its text, its geometry and its graph node always refer to the same thing.
How the pipeline works
The proposed flow has five steps, and the human sits in the middle of it.
An LLM reads source documents such as PDFs or Word files (with OCR where needed) and extracts requirements, which are stored as trace-linked objects in a PLM system. From those requirements, the LLM identifies candidate components and their interactions and formats them as a Design Structure Matrix, or DSM. Engineers then review and edit both the requirements and the DSM. Once the architecture is accepted, each component maps one-to-one to a CAD part or assembly.
Why a DSM is a smart output format
Asking an LLM to "design the architecture" in free text invites confident nonsense. A DSM is a square matrix: components on both axes, and a mark wherever one depends on or interacts with another. That's a constrained, checkable format.
You can look at it and spot a missing interface. You can run clustering on it. You can diff it between versions. And because it's a plain relationship structure, it can be converted into a SysML model afterwards. The architect still does the modeling work in whatever environment the team uses, whether that's Cameo Systems Modeler, Eclipse Capella or Dalus. The DSM is a starting sketch, not a replacement for the model.
Verification: the weakest and most interesting part
The paper proposes verification in two phases. Phase 1 is cross-modal compatibility checking: do the geometry, the function and the relationships agree with each other? Phase 2 proposes formal verification using symbolic methods. Only the idea of phase 2 is on the table so far. Nothing is demonstrated.
That matters because the cited accuracy numbers for the underlying tasks aren't comfortable. The paper points to related work by Li et al. reporting roughly 45 to 52 percent accuracy for GPT-based models extracting formal specifications from documents, with a two-step method reducing errors. Another cited study, by Khan et al., reports a 93.5 percent F1-score for pulling dimensions and tolerances from 2D mechanical drawings with a hybrid vision-language framework. Those are other people's numbers on other tasks, but they tell you the range: strong on narrow extraction, shaky on anything that needs formal meaning.
What it won't solve
- No evidence yet. There are no user studies or case studies. The CubeSat application in the paper is illustrative and isn't evaluated. Faster architecture exploration and end-to-end traceability are anticipated benefits, not measured ones.
- Incomplete or wrong architectures. The authors acknowledge that LLM-generated architectures may be incomplete or partly wrong. That's why review is built into the flow, and it means reviewer time is the real cost.
- Platform dependence. The approach relies on a PLM platform's API and geometry kernel. If your CAD and PLM stack doesn't expose those, the one-to-one component mapping is a project of its own.
- Unfamiliar query tools. Graph query languages aren't something most systems engineers use day to day.
- One-to-one mapping is a simplification. Real products have components that span assemblies, software that has no geometry, and functions allocated to several parts.
How to try the idea without the whole workbench
You don't need their framework to test the core question. Pick a finished program where the architecture is known. Feed an LLM the original requirements document and ask for a DSM. Then compare it to the real one.
Count what it missed, what it invented, and how long the cleanup took compared with building the matrix by hand. If a senior architect would have spent less time starting from blank, you have your answer for now. If cleanup is quick and the misses are the kind a reviewer catches easily, you've found a useful accelerator for early trade studies.
Keep stable IDs from day one either way. The paper's persistent UID idea is the part that pays off even without any AI: a component that carries one identifier across requirements, architecture and CAD is easier to trace, whoever or whatever proposed it.
Bottom line
LLM-proposed architecture is plausible as a draft generator, provided the output is a constrained format a human can inspect, like a DSM, and provided nobody mistakes the draft for a verified design. The Bank and Herber paper is a thoughtful blueprint, but it's a blueprint. Run the retrospective test on one of your own programs before you plan anything around it.
Source: Bank, H.S. and Herber, D.R., "GenAI Workbench: AI-Assisted Analysis and Synthesis of Engineering Systems from Multimodal Engineering Data," 2026 IISE Annual Conference, arXiv:2603.00251.